Amazon Web Services Lambda is a Serverless event-driven computing platform that was launched in November 2014 as a part of Amazon Web Services. Lambda is actually undergoing a lot of changes. Things like start-up times and Payment Card Industry (PCI) data compliance posed serious issues in 2017, but then they were fixed. Lambda was frequently criticized for lacking service-level agreements, but in October 2018, AWS released one as well. (It’s currently 99.95%).

Technical limitations

The constraints listed here might have changed since this was written, but at the time, there were four important technical limitations to consider when evaluating whether something needs to run in Lambda:

• No session affinity
• Non-deterministic latency
• Execution time-limited to 15 minutes
• No direct control over processing power

No session affinity

In general, because your hosting provider manages scaling, you don’t get to choose when to start or stop instances. Lambda determines when new virtual machines should be created, when old ones should be reused, and when old machines should be dropped. It may send two consecutive requests to the same container or two other containers, depending on the user.

In Lambda, requests cannot be routed or ensured that requests arriving from the same source arrive at the same destination in sequence. Some other services, such as AWS Kinesis, offer sequences and routing control, but Lambda can still decide at any time to start a new virtual machine.

Because of this limitation, as well as the way functions are named, Lambda’s execution mechanism is commonly misconstrued. Lambda functions are not stateless in the sense that nothing is maintained between two executions in functional programming.

If Lambda decides to reuse a virtual machine and each instance has its own container with its own local memory space, a request can nevertheless exchange state in memory. Virtual machines also have access to a temporary local disc space, which can be used to store information in between requests. However, state preservation across requests is not guaranteed, and application developers have no control over routing.

In Lambda, it’s best not to rely on any in-memory state between requests. When designing Lambda functions, design for share-nothing architecture, not stateless execution. You can cache or pre-calculate things that don’t depend on a particular user, but user sessions and state must be stored elsewhere. There are also several alternatives for session data.

‍

Non-deterministic latency

In Lambda, the goal is to maximize throughput, not to minimize latency. The system prioritizes the handling of a large number of requests so that no one has to wait long for a single request to be handled. Therefore, some requests will need to wait for a new Lambda instance to start, while others won’t. The latency of processing a single request isn’t really deterministic.

‍

Cold Start

A cold start is when an incoming request needs wait for a new Lambda instance to be built in Serverless language. Lambda cold beginnings were typically a few seconds long in the beginning. Many blog entries suggested keeping some Lambdas heated in reserve to avoid frigid beginnings. Lambda start-up speeds have greatly improved since its inception, thus you can generally disregard that outdated advice. Although AWS does not provide any official information concerning cold starts, empirical studies reveal that the cold start time using JavaScript or Python is less than half a second. It may take a little longer with Java and C#, depending on the size of the application, which is another reason why lightweight environments are recommended for Lambda.

‍

Virtual Private Cloud (VPC)

AWS significantly improved start-up times for Lambda functions connected to virtual private clouds (VPC) after the first version of this book was published in late 2019. Furthermore, they enabled users to reserve minimum capacity for applications that cannot avoid lengthy initialization, preventing cold starts.

‍

Execution time limited to 15 minutes

The total permissible execution time is another key technological constraint. By default, a Lambda function can run for three seconds, but you can customize it to run for up to 15 minutes. If a task takes longer than expected to finish, Lambda will destroy the virtual machine and return a timeout error.

The 15-minute limit is now a hard limit, so unless you have a really special relationship with AWS, you won’t be able to request an extension. Long-running jobs must be separated and conducted in separate batches, or they must be run on a different service. AWS also offers certain alternatives, such as Fargate, which are more expensive and start slower but can run for extended periods of time.

‍

AWS Step Functions

In many cases, designing an app with Lambda in mind helps you work around the execution-time constraint. For example, you could create a Lambda function that starts a remote task, and then kick off another Lambda function after receiving the result. This approach allows you to avoid having to wait for your remote task to finish before starting your next step. You can use AWS Step Functions to coordinate workflows that last up to one year, and invoke Lambda functions when required. Don’t pay for waiting.

‍

No direct control over processing power

The final important technological constraint of Lambda is processor selection. Today, it’s common for container execution environments to provide a wide range of processor options, including GPUs, different CPU speeds or core counts, and instances optimized for certain tasks. With Lambda, though, you don’t get to choose any of that. The only option for a container is the memory size, which ranges from 128 MB to around 3 GB. Lambda is not suitable for operations that demand the use of GPUs.

‍

Lambda CPU allocation

Memory configuration has an indirect impact on processing power. Lambda allocates CPU power in proportion to memory, so that at 1792 MB, a function has access to one full virtual CPU. With Node.js, all tasks run through a single core anyway, so with JavaScript you won’t get any further processing speed improvements if you ask for more than 1.75 GB. With Java or other languages that can take advantage of multiple cores, asking for the maximum allowed memory might give you faster responses and lower cost for CPU-intensive tasks.

Lambda pricing is determined by two factors: the base price for memory allocation and the amount of time it takes to execute. The notion that greater memory means more CPU power might lead to cost structures that are counterintuitive. More RAM allocates a higher base price, but more CPU power might result in much faster execution, lowering the price.

Because processing power cannot be directly controlled, the only way to reduce costs and improve performance is to experiment with different parameter combinations. Fortunately, AWS Lambda makes it simple to adjust these settings and run many versions in parallel at a low cost. I strongly advise testing out several memory allocation methods for processes that become expensive or slow to find a sweet spot between price and performance. The open source project AWS Lambda Power Tuning by Alex Casalboni can help you visualize the performance of various Lambda function setups.

‍

Payload Size Limit

There is a 6 MB payload size limit for synchronous invocations and a 250 KB size limit for asynchronous invocations.

When we try to return a response with a payload that is larger than the allowed size in Lambda, we get a LambdaRuntimeClientError.

‍

Conclusion

Serverless architecture follow various formal and informal approaches whether you’re working on a custom software development or refactoring an existing one. Keeping AWS Lambda best practices and technical constraints in mind will help you in designing a better and clean software, over which we obsess at CodeStax.Ai.

‍