Serverless Framework Canary Deployment (Lambda)

By default, deployment using the serverless framework is an all-at-once process. When a new version is release, every request will be hitting the new version. This setup is not ideal for production environment, because if anything goes wrong in the new version, all the users will be affected.

In this article, i will be talking about how we can leverage on the Serverless Plugin Canary Deployments to improve the deployment process.

What is a Canary Deployment?

Canary deployment is a deployment strategy that releases an application incrementally to a subset of user. A canary deployment release is less risk prone as it helps to minimise the risk by limiting the percentage of user using the new version and it allows us to test in production with real users. Lastly, it is fast and safe to trigger a rollback.

How does the plugin works?

• Your existing lambda function will have an Alias created, your trigger will shift from your main lambda function to the Alias
• You will see a CodeDeploy Application created, that reflects the deployment and traffic shifting configuration

Canary Setup Architecture

Setup Example

Before i move on, you can refer to my previous article on how to set up a serverless environment.

Install the plugins

npm i --save-dev serverless-plugin-canary-deployments

Add the plugins to your `serverless.yml`file

Serverless.yml

I have added the plugin into the plugins section and under the lambda functions i have included the deployment settings configuration. In this example, i will be using 10% traffic for the first 5 minutes before 100% traffic for the new version. This is configurable under the type section (e.g. Linear10PercentEvery1Minut, Canary10Percent30Minutes)

Deploy your lambda function

Run `serverless deploy — verbose — stage dev` to deploy

After deployment, you can see a Live alias being created and it will point to 2 version with different weightage.

Lambda Function Alias Traffic Shifting

After x minutes, it will update all the traffic to the latest version.

How to verify your new version is working?

Next you might be wondering, how to verify if the 10% traffic is working and how to differentiate the older version logs and new version logs.

In lambda, each version will have its own log stream. You can access the latest version log steam to see the 10% traffic. If there is any error in the logs you can always rollback to the previous version.

Cloudwatch Log Stream

Now you have successfully configured the canary setup. But for every deployment it is necessary to have a rollback plan incase of failure.

Rollback Options

Manual

Manual rollback can be done via the AWS CodeDeploy, when the new version encounter error. You can access AWS CodeDeploy and select the Step and rollback deployment , you will be able to see the traffic shift 100% back to the previous version.

Rollback via AWS CodeDeploy

Auto

When there is an error triggered the CodeDeploy will trigger a rollback, but before that the auto option require configuration to your serverless.yml file. First you will need to install this plugin.

npm i serverless-plugin-aws-alerts — save-dev

Serverless.yml with Auto Rollback

Update your serverless.yml, to the code above. Here are some of the changes added.

• Add the alarms portion under the lambda functions. In my example, when there is any error to my lambda within 60 seconds it will trigger an alarm.
• I attached the alarm to my deployment settings, so once the alarm is being triggered. It will start the rollback and shift the traffic back to the previous version.

This help to ensure the entire rollback option is smooth without constantly monitoring the logs after deployment.

Conclusion

This is a simple example on how you can improve your serverless deployment with minimal changes to the current infrastructure setup. You can refer to my source code at github. Do comment below or reach out to me via LinkedIn if you need clarification on the implementation.