‘Serverless’ computing continues to impact the model of software development and provision. It is streamlining DevOps, simplifying the process of getting code into production, and massively improving the scalability of software.
AWS Lambda was one of the first FaaS vendors offering public cloud infrastructure. As their service has matured, so has the awareness of the dev teams as to what aspects of the ‘serverless’ service affect their customers’ experience of their software. It is one of these issues that this article will consider; that of the AWS Lambda cold start.
All serverless computing is vulnerable to cold start issues, not just AWS Lambda. A cold start is the latency or the time you wait, while the code is provided with the environment within which to run it and all the connections it needs.
When a user triggers an event that calls your server-provider the first step is to invoke your code. AWS Lambda will invoke the Lambda function in a container (similar to a Docker container). Once this is in place, the function can run and return its output. Any declarations in your Lambda function code remain initialized for a period (typically at least 20 minutes, with all containers collapsed within an hour). This allows the function to be easily invoked again. For example, if your Lambda function establishes a database connection, instead of reestablishing the connection, the original connection is used again. Once you are warmed up, you are ready to roll.
A dev team may never have to consider cold start times, let alone how to mitigate them. If, for example, they are using their cloud provider for scheduled backups, then a five-second cold start time is not going to have a meaningful impact on performance. If, however, a customer-facing application suffers a five-second addition to loading time or response time, then the cold start issue can result in lost customers.
Traffic may also impact latency. For example, request A that comes in first may suffer latency, then request B that follows it enjoys the time-benefit of the initiated Lambda instance. Multiple concurrent requests to AWS, however, will all face the AWS Lambda cold start problem. This means that if request A hits at the same time as request B and there are no active containers, then both require a new instance to be invoked and, therefore, both suffer from latency.
There are two main options available when you want to reduce the impact of the AWS lambda cold start problem, the first is to reduce the latency by choosing an appropriate language and architecture. The second is to minimize the number of times cold starts occur, a clever workaround to prevent AWS lambda colds starts is to schedule ping events to keep your container and all its connections warm and ready to roll.
In fact, there is potential to go even further and, with more sophisticated data analyses, or in response to marketing campaigns, dev teams can predict traffic and schedule the initialization of multiple containers in anticipation of customer activity.