AWS Lambda is the compute service under the AWS Serverless ecosystem. For development and deployment of Lambda function along with the infrastructure it needs, one tends to use development frameworks. Two of the most popular frameworks used for this purpose are —
- AWS Serverless Application Model (SAM)
- Serverless Framework
Assuming you are using AWS SAM, initializing a green field Hello World Lambda function with SAM CLI (tool that operates on an AWS SAM template and application code) is a three-step process:
Step 1 > sam initIn this step, you get the option to select runtime for the Lambda function, provide service name and few other options depending on the runtime selected. Once done, you get a folder structure with basic resources created.
The Hello World Function inside the template file looks as below:
Step 2 > sam package --s3-bucket <bucket name>In this step, the application code and dependencies are bundled into a deployment package and is pushed to S3 bucket. And generates a Yaml template file as output.
Step 3 > sam deploy --template-file package.yaml --stack-name hello-world --capabilities CAPABILITY_IAMIn this step, the lambda function and other infrastructure resources gets deployed via SAM template which gets converted to CloudFormation stack.
Every time the sam deploy command is issued, SAM template gets translated to CloudFormation template, and it eventually publishes the new version of the Hello World Function. This new version is tagged as $LATEST.
With this deployment, any new request coming for the Hello World function is handled by the latest version of the lambda. And all existing running instances of Hello World function gets terminated. Cool!!!
But what if the new function has got some bug in it which could not be captured in the early stages of Unit testing and Integration testing. All your traffic will be impacted, and User Experience will go for a toss 😩.
We can handle such issues by following the Blue Green deployment strategy. It helps to increase the availability of the system and reduce risk associated with deployment.
In this strategy, we can have 2 versions of the function running at the same time and traffic can be diverted to the latest version in an incremental fashion.
AWS SAM supports multiple traffic dialing strategies out of box.
- Canary — Traffic is shifted in two increments from old version to new version
- Linear — Traffic is shifted from old version to new version in equal increments with an equal number of minutes between each increment.
To use the Blue/Green option, SAM template has two attributes which needs to be configured in the Lambda function —
- AutoPublishAlias — AWS SAM manages the traffic distribution by creating an Alias with the name specified and assigns the percentage of traffic to be distributed between new version and old version depending on the deployment preference type mentioned below.
- Deployment Preference Type — Dictates how distribution of traffic between new and old version is to be handled.
Some of the pre-configured deployment preference type are available out of box —
Let’s say we want to route 10 % of the production traffic incrementally to new Lambda version every 1 minute. To configure this, the Hello World Lambda Function will look something as below —
When sam deploy command is issued with the above changes, AWS SAM internally configures AWS Code Deploy (another AWS Serverless service for deploying the code and managing the traffic distribution using Blue/Green pattern) application which manages the traffic dialing.
This is how it looks like in the AWS Code Deploy console when the deploy command is issued —
You can also configure Cloud Watch Alarms which if triggered can roll back the deployment process.
As part 2 of this blog, will have an actual Serverless Micro service implemented with Lambda and configured with end to end CI/CD DevOps process using AWS Development tools — AWS Code Commit, AWS Code Build, AWS Code Deploy and AWS Code Pipeline.
Till then, Cheers!!!