A big tradeoff for implementing a serverless architecture is cold start times.
The serverless cold-start tax is typically within a few hundred milliseconds but it has been reported that Lambdas executed in the AWS VPC environment to take an upwards of seconds.
A very scientific test I conducted on my own serverless function found that the total round-trip time for my email sign-up lambda was around 1500ms cold as opposed to 650ms warm.
In some contexts like user-facing, this cold-start time has a huge impact. AWS announced a solution at their recent re:Invent conference on December 3rd. Provisioned Concurrency provides AWS users with more control of their serverless platform and guarantees that a serverless function will be invoked within 100 ms as long as it is within the allocated concurrency.
Lambdas execute within a container which is created upon a trigger of an HTTP request, S3 event, etc. The time it takes for AWS to stand up the execution environment is considered the cold-start time. Lambda is smart enough to reuse a container that has already been stood up.
If 2 Lambda triggers are done one after another, only a single Lambda container is created and only the first call experiences the cold start. This differs from 2 request done concurrently where Lambda will stand up two Lambda Containers and both executions will experience the cold start.
Consistent and regular traffic to Lambda ensures less total requests are impacted by cold-start time.
Provisioning Concurrency tells AWS Lambda to prepare a set a specified amount of execution environments. Request will use the already stood up environments and only when execution concurrency is greater than the provisioned concurrency, new environments are created.
Provisioned Concurrency guarantees that execution start time (ms) is within double-digits for all allocated request.
Should you use provisioned concurrency? It depends.
Provisioned concurrency gives up some of the advantages which are typically inherent with a FAAS (Function as a Service) model for guaranteed execution speed.
While there are cons which should be considered before utilizing provisioned concurrency, it was built into AWS lambda for a reason. There are scenarios when provisioned currency can be justified. When the cost of re-architecting software to handle latency is greater than the cost of implementing provisioned concurrency. Or when the extra cost is worth minimizing cold start to double-digit times, like in user-facing applications.
Seeing the development of serverless features like provisioned concurrency at AWS re:Invent shows how serverless will continue to mature and it will be interesting to see how other serverless platforms like Google's Cloud Functions and Azure Function respond.