In 2016 I was the tech lead for a greenfield project completely devoid of legacy–I held the engineer’s promised land in front of me! I bit off as much new stuff as I could – serverless, event sourcing, functional programming, the whole gambit of cool. This is normally a very bad idea, but I had a team of strong engineers who had prior experience in this stuff, and we were ready to be technology pilots for the broader organization.
Serverless applications require a whole new approach to development workflow. In this article, Lumigo Director of Engineering Efi Merdler-Kravitz details the guiding principles and tools used at a 100% serverless company to ensure the most efficient workflow possible. We are not going to talk about product development flow (no product managers were harmed during the making of this post!).
This post takes a look at Kotlin, a relatively new programming language that runs on the JVM, and explores how it can be used to build serverless web apps on AWS using Lambda and API Gateway. In programming language terms Kotlin is a relative newcomer. It was first announced in 2011 by JetBrains, the makers of IntelliJ IDEA, and was designed as a modern successor to Java.
With AWS Lambda, you have basic observability built into the platform with CloudWatch. CloudWatch offers support for both metrics and logging. CloudWatch Metrics gives you basic metrics, visualization and alerting while CloudWatch Logs captures everything that is written to stdout and stderr. In this post, we will take a deep dive into CloudWatch Metrics to see how you can use it to monitor your Lambda functions and its limitations.
API Gateway is a powerful tool for creating a coherent API out of a set of multiple disconnected remote function providers, and API Gateway with AWS Lambda, when used properly, can give you the capacity to create truly powerful serverless APIs. However, given that API Gateway is a layer between your requests and the code itself, there are latency concerns that API Gateway Lambdas may face that may not be present when working with other architectures.
One of the great promises of serverless has always been that it would free developers to focus on writing code without having to give too much consideration to the underlying infrastructure. But the advantages presented by the instantly, infinitely scalable nature of serverless come with limitations and unique considerations that you need to take into account.
A while back, I wrote about how you can shave latency off every AWS SDK operation by enabling HTTP keep-alive, like this. It had the desired effect and I saw lots of people apply this technique in their projects. But it also resulted in the same 10 lines of code being copied and pasted everywhere! I began thinking about ways to distribute an optimized version of AWS SDK so everyone can benefit.
We’re pleased to announce that the Lumigo serverless intelligence platform now supports the Python microframework, AWS Chalice. Chalice was created by AWS to simplify the process of writing serverless apps in Python. Similar in structure to the Flask web framework, Chalice handles much of the configuration on behalf of the user, including automated IAM role policy generation.
An ever increasing number of developers and architects are using AWS Lambda to deploy serverless functions to control costs and reduce the burden of server management. Due to the unpredictable nature of end-user demand in today’s digital-first world, Lambda functions can help resolve unplanned scaling issues.
The way we build software products changes all the time. Serverless architecture opens up new opportunities to create awesome products faster. Not only that, serverless applications are more scalable, secure and maintainable – all with much less code. Serverless is the future of development and you should get ready for it. But what does it mean to be a serverless developer? What do you need to understand before jumping into the serverless pool?
