AWS Lambda Deployment Model

AWS Lambda Deployment Model

AWS Lambdas are easy to design and develop in a short span of time. In order to manage the code and promote it through your deployment pipeline stages, there are several approaches and tools that can be used. We will discuss one approach to implement this.

Requirement

We have more than a few lambda functions in our application implementing event-driven framework. The challenge is to have multiple versions of the lambda functions across different environments such as development, QA, performance, and Production environments.

Implementation

There are a few tools that AWS provides to facilitate this:

• SAM
• Lambda Versions
• Lambda Aliases

SAM

AWS Serverless Application Model is a framework that can be used to simplify the development, testing, and deployment of Lambda functions. SAM is an extension of the AWS CloudFormation templates specific to the Serverless application development.

During design time, AWS SAM Cli can be used to build the code outline that can be deployed using the tool.

During development, SAM cli can be used to debug and test the application using a utility called “sam local invoke”. Sam local use docker and an aws lambda docker image to execute the lambda in a similar runtime in the local developer environment.

During pre-deployment, sam build packages the application and its dependencies as an archive that can be deployed in the AWS lambda.

Deployment can be facilitated either through the existing cicd tools or through SAM based on the archive generated in the previous step.

Lambda Versions and Aliases

Generally, as part of a development workflow, the developed Lambda goes through the usual CICD pipeline which involves development, QA, performance test, and production. Lambda versions provide a mechanism to have multiple versions of the same lambda function deployed across different environments.

Each Alias could correspond to one environment in the deployment pipeline.

For example:

This will allow us to have different versions of the lambda function deployed across different environments.

Here Version 1 will have gone through all the CICD pipeline stages such as DEV, QA, PERF, and PROD and will have environment variables corresponding to the production environment.

Similarly, Version 2,3 and 4 have the environment variables corresponding to their corresponding environments.

Aliases also provide the ability to map different triggers and destinations corresponding to each alias.

If you have different triggers and destinations such as an SQS queue per environment:

For example:

The above approach provides a way of organizing code that allows us to design our CICD pipelines in a flexible manner using our favorite CICD tools. This allows us to develop and deploy well-architected applications in the AWS serverless platform. These are well documented as referred below in the reference section.

References:

1. https://aws.amazon.com/serverless/sam/
2. https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html
3. https://docs.aws.amazon.com/lambda/latest/dg/configuration-aliases.html