AWS Lambda has become the most widely used deployment pattern for serverless applications. It allows developers to set aside worrying about server provisioning, maintenance, idle capacity management and scaling, and instead to focus solely on writing business logic. But that’s not entirely true. Because while Lambda is a self-managed AWS service, it still requires careful design to get the best performance out of the computation capabilities it provides.

In the second of our new series of posts, Yan Cui highlights the key insights from the Amazon Builders’ Library article, Using load shedding to avoid overload, by AWS Principal Engineer (AWS Lambda) David Yanacek.

In the first article in our new series, Yan Cui highlights the key insights from the Amazon Builders’ Library article, Timeouts, retries and backoff with jitter, by AWS Senior Principal Engineer Marc Brooker.

AWS today announced Provisioned Concurrency, an exciting feature to allow Lambda customers to not have to worry about cold starts anymore. And we at Lumigo are proud to be an official launch partner for AWS Provisioned Concurrency. In this post we’ll drill into the problems cold starts pose, explore how Provisioned Concurrency resolves them, and explain some rough edges you need to understand when it comes to working with this new feature.

AWS recently launched the Serverless Event Bus, AWS EventBridge. Some have described it as an extension of CloudWatch Events, while others say it is provides the same features as AWS SNS. So, what exactly is EventBridge? And how does it fit into the existing AWS serverless ecosystem?

You’ve no doubt heard that IOpipe has been acquired by New Relic (congratulations to both). As part of the acquisition, New Relic has said it intends to retire the IOpipe platform in the next 30 days. If you’re currently relying on the IOpipe platform to monitor and debug your serverless application you have an important decision to make. One option is to try out New Relic’s serverless monitoring functionality.

In this article we’ll introduce the AWS Cloud Development Kit and explore how it can boost the productivity of your development and infrastructure teams. Infrastructure-as-Code is fast emerging as a de-facto standard for development organizations.

Serverless Hero Yan Cui explains when and why you should use API Gateway service proxies, and introduces an open source tool to make it easy to implement. One of the very powerful and yet often under-utilized features of API Gateway is its ability to integrate directly with other AWS services. For example, you can connect API Gateway directly to an SNS topic without needing a Lambda function in the middle. Or to S3, or any number of AWS services.

When you look at an X-Ray trace for a Lambda cold start, you will see an Initialization subsegment. This subsegment represents “the function’s initialization code that is run before the handler”. This is where the runtime would resolve any dependencies, or initialize global variables. These are executed only once, so they don’t have to run on every invocation. The more dependencies you have, the longer this initialization step takes.

Here at Lumigo, we are big fans of serverless. And a big part of working with AWS Lambda involves using many other AWS services. For example, services such as SNS and SQS are often used to chain Lambda functions together. They are essential ingredients of an event-driven architecture, where systems are loosely coupled through events. However, they also pose a challenge to how we test our systems and how to get fast feedback on what’s happening in the system.