Canary detects potential bugs and disruption without affecting every other system running. Canary releases are typically short-lived and used to validate whether a release meets the requirements it set out to.
Canary deployment is relatively straightforward, but there are a lot of nuances in how we should approach deploying software this way. Often, we must know ahead of time that we’ll be canary releasing.
Canary deployments have a cost and they add complexity to our processes and our systems. The approach also presents challenges for supporting our product as we have customers with issues on a number of differing versions of the software.
AWS Lambda Aliases and Canary Deployments
A Lambda Alias is like a pointer to a specific Lambda function version. It serves as a proxy that can dispatch traffic to the specific Amazon Resource Name ARNs that make up your Lambda function library.
When a new version is created, you can simply update the alias to point to the new version without needing to update the calling application. In addition, AWS Lambda Aliases provide a method of routing alias requests to two different versions of the same function. This allows you to scale new function deployments as needed and identify issues as early as possible, without significantly degrading user experience.
Defining Canary Success Metrics
To determine success of canary deployment you can make use of:
- xray tracing
- log streams
- user events
- analysis of data flow
Assumptions:
- Canary is the latest published version
- Once you promote an application to production there is no going back (this is not strictly true, if you know the previous version of the application then you can update the alias)
Use case 1: Deploy Canary Application Scenario: We have a new application and we would to deploy a canal version of this application Input required: Application code and percentage of traffic to the canary Command: aws lambda update-alias --function-name --name --routing-config "AdditionalVersionWeights={<canary_version>=}” Comments: Do not update alias
Use case 2: Roll back from canary to application Scenario: We have tested our canary application and we would like to roll back to our original application Command: aws lambda update-alias --function-name --name --routing-config "AdditionalVersionWeights={}” Comments: You can do scenarios 2 or 3 - not both
Use case 3: Promote canary to production Scenario: We have tested our canary application and we would like to promote it as the main application I.e. production Command: aws lambda update-alias --function-name --name --routing-config "AdditionalVersionWeights={}" --function-version <canary_version> Comments: You can do scenarios 2 or 3 - not both
- AWS Lambda Function deployed (name: blue-green-dev-eu-west-1)
- AWS Lambda Function published (versioned)
- AWS Lambda Function Alias created
# split traffic 50/50 between v1 and v2
export current_version=1
export next_version=2
aws lambda update-alias \
--function-name "blue-green-dev-eu-west-1" \
--name dev \
--routing-config "AdditionalVersionWeights={$current_version=0.5}" \
--function-version $next_versionTake it for a test drive:
while true; do
aws lambda invoke \
--invocation-type RequestResponse \
--function-name blue-green-dev-eu-west-1:dev \
--region eu-west-1 \
--log-type None out.txt ; cat out.txt | jq .; sleep 2 ;
done