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
Aliascreated, your trigger will shift from your main lambda function to the
- You will see a CodeDeploy Application created, that reflects the deployment and traffic shifting configuration
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
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.
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.
Now you have successfully configured the canary setup. But for every deployment it is necessary to have a rollback plan incase of failure.
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.
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
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.
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.