Understanding AWS Lambda

At Peaksware, we use AWS solutions for our serverless needs. Understanding Lambda functions involves

1. How AWS scales up/down and picks up code changes?

2. Understanding AWS Lambda companions like Layers and Step functions.

3. Coding best practices when writing lambda functions.

Benchmarking information in this section is summarized from a detailed paper written by Wang Liang and colleagues — Peeking Behind the Curtains of Serverless Platforms

Scaling up Lambda

When a request comes in, AWS creates a container on top of a VM in one of AWS’s hosts. The container has the runtime and the function code. The function is called and lambda waits for the execution to finish. The execution stops on

1. Successful completion of the function code
2. Exception in the function code
3. Execution timeout

As more requests comes in, AWS scheduler could use the same container, spin up new containers in the same VM or add more hosts+VMs. AWS handles concurrent requests by initializing up to 1000 concurrent containers. The containers are packed tightly within a VM to optimize for the VM’s memory utilization. Even two different functions from the same AWS account can potentially share the same VM.

Cold start

• A cold start may involve launching a new container, setting up the runtime environment, and deploying a function, which will take more time to handle a request than reusing an existing container.
• Cold start latency decreases as the allocated function memory increases. One possible explanation is that AWS allocates CPU power proportionally to the memory size; with more CPU power, environment set up becomes faster.

Scaling down Lambda

AWS will keep the container idle for arbitrary amount of time to respond to the requests faster. AWS will shut down half of the idle instances of a function approximately every 300 seconds until there are two or three instances left, and eventually shut down the remaining instances after 27 minutes. A virtual machine can stay up for 9hrs.

Updating Lambda code

There is a small chance that incoming requests could be handled by an old version of the function. The scheduler is not atomic, if you update a function while there are 50 or more concurrent requests hitting the function, 3.8% of instances might run an inconsistent version. 6 seconds seem to be the ideal time between function update and requests to avoid running older version of the function.

You can also prevent this by using blue-green deployment methods using code deploy instead of updating the function directly.

Lambda Layers

Lambda functions are executed in containers and lambda layers is a logical extension of existing lambda functionality.

• The code size (including all the libs used by the function code) should be under 50MB.
• Layers are a nice way to package the dependencies separately so the deployment package size is reduced.
• Layers are useful to share common code across multiple functions.
• A function can have up to 5 layers and have a max code size of 250MB.

AWS Step functions

AWS step functions allows us to create a state machine by chaining together Lambda functions.

In distributed microservice based architecture world, coordination between microservices is done using a pub-sub or event stream model. AWS has taken a stab at abstracting the communication between loosely dependent functions using step functions. Step functions can be seen as orchestrator of functions that helps create and visualize the entire workflow.

Use cases for step functions

• ETL data processing
• Move few tasks from a monolith to serverless.
• Orchestrate Lambda functions into a Service.

AWS documentation provides more use cases and examples.

Writing code for Lambda Functions

Even though the blast radius is limited with a Serverless Function, all the engineering best practices still apply with some minor implementation changes.

• Logging — Use the provided logging mechanism (CloudWatch) and take the log stream to a central location using ELK stack for further processing.

• Versioning — AWS provides the option to version the function code. Versions are immutable and provides the opportunity to rollback the lambda code if needed.

• Monitoring — Use the tools like DeadLetterQueue, SNS topics and CloudWatch alarms to get notifications on failure. Monitor 5XX, 4XX on gateway. Monitor Throttling, Errors and ConcurrentExecutions on Lambda.

• Security — Create a separate role for lambda execution and provide only the needed privileges. Keep lambda behind a VPC if the lambda has access to any private resources.

Are we are ready to put all this knowledge to use? Follow along to the next chapter.

Next: Deploying a web app using Lambda, API Gateway, DynamoDB and S3 with Serverless Framework