Important AWS Lambda Technical Constraints
In this lesson, you will learn about the important technical constraints of AWS Lambda that you should know and assess before deploying your application.
Lambda is still a relatively new service, and it is evolving quickly. I often talk about serverless development at conferences. It’s been quite fun to review my slides about problems and constraints and have to remove things every few months. Things like start-up times and Payment Card Industry (PCI) data compliance were a serious limitation in 2017, but then got fixed. A common complaint against Lambda was that there was no service-level agreement guarantee for it, but in October 2018, AWS published an SLA for Lambda as well. (It’s currently 99.95%.)
Technical limitations
By the time you read this, the constraints might have changed slightly, but at the time this was written, there were four important technical limitations that you needed to consider when evaluating whether something should run in Lambda:
- No session affinity
- Non-deterministic latency
- Execution time-limited to 15 minutes
- No direct control over processing power
No session affinity
Because the hosting provider controls scaling, you generally don’t get to decide about starting up or shutting down instances. Lambda will decide whether it needs to create new virtual machines to handle requests, as well as when to reuse an old machine and when to drop it. It might send two subsequent requests coming from the same user to the same container or to two different containers.
Purely on Lambda, there is no way to control request routing or somehow ensure that requests from the same source arrive in sequence to the same destination. You can achieve sequences and routing control with some other services such as AWS Kinesis, but Lambda can still decide at any point to throw away a virtual machine and start a new one.
This ...