Canary deployments, also known as linear or traffic shifting, have similarities to the blue/green approach. We also deploy a new environment alongside our live environment but, instead of a traffic cutover event, we configure a small amount of traffic to be served from the new environment. We monitor closely, and when we gain more confidence that the change we have introduced has not adversely affected our service, we can gradually increase the amount of traffic that's served out of the new environment until the previous environment is no longer active.
The idea behind this is that by introducing a change slowly, and to a small subset of users, we can greatly reduce the impact should something go wrong. All going well, a deployment should be transparent to any clients or users. A rollback here immediately shifts the traffic back to the last environment by setting the traffic shifting weight to zero or deleting the canary altogether:
It's also really important to identify the key metric or metrics that you want in order to trigger a failed deployment. These could be error rate-related at the infrastructure or application level, for example, measuring the number of application exceptions over a certain time period. Alternatively, they could be product-related; for example, are my users still clicking on a particular button? Has the experience changed for my users? Only you will be able to select the best metric for your trigger, so it's a good idea to canvas different stakeholder groups to make sure you choose the right thing.
How we enable a variation of this method in the Serverless Framework is by using a plugin that was developed by David Garcia, aptly called Serverless Plugin Canary Deployments. This utilizes the traffic shifting capability in Lambda as well as AWS CodeDeploy to automatically update Lambda alias weights:
The plugin supports everything that you will need to run your own canary deployments, including various shifting schemes, alarms to trigger deployment rollbacks, and process hooks to run your own customization or integration tests using lambdas and the CodeDeploy SDK. Hats off to this plugin—it takes care of some complex Lambda automation to make the configuration straightforward to understand.
So far, we've learned about some of the methods we can use to deploy our stacks. Some have less risk than others, and we can apply this lens to our own environments. The next chapter will introduce some of the services that are involved in implementing the patterns we have talked about here. They are all serverless and native to AWS.