Keep the business running – always!
Traditionally, developers used to publish new releases to the production environments by updating the lambda function code for version $LATEST or even pointing an alias to a new function version. Fortunately, AWS has introduced AWS Lambda Traffic Shifting and Phased Deployments with AWS CodeDeploy. This was definitely a game-changer and many DevOps Engineers started adopting this strategy for their day-to-day deployments. However, this was not the case for those who were using the Serverless Framework as it didn’t support this type of deployment process until the Serverless Plugin Canary Deployments has come into effect by implementing canary deployments of Lambda functions and making use of the traffic shifting Lambda feature in combination with AWS CodeDeploy.
Fortunately, we will be looking at how to completely transform the new application release approach for such cases and guarantee an almost zero downtime fully automated deployment strategy with the help of several AWS Services some of which we will discuss later in this blog.
Deploying Serverless the right way:
The architecture has been completely built using the Serverless Framework, which is an open-source software which that builds, compiles, and packages code for serverless deployment, and then deploys the package to the cloud. Moreover, the serverless framework has also been utilized to build serverless AWS services such as AWS Lambda, AWS Cognito, AWS API Gateway, AWS DynamoDB, and many more. In this blog, I will introduce a fully automated CI/CD pipeline using AWS CodePipeline for the new deployment strategy knowing the many features that this service supports in conjunction with AWS Codebuild and AWS Codedeploy. This solution depends on the Canary deployment strategy that is responsible for shifting a specific amount of traffic to a new Lambda version within a specific period of time until all the traffic is completely shifted to the new version.
How does this exactly work in a fully automated CI/CD pipeline?
Developers will still push new code to their GitHub repository as usual but this time, CodePipeline will start a source stage withing the pipeline to pull the latest code changes in a GitHub branch, AWS CodeBuild on the other hand will start the building stage by installing all the Serverless plugins and libraries and execute the “sls deploy” command. At this stage, AWS CodeDeploy will start deploying the latest code to a new Lambda version and uses the “Live” weighted alias created in the previous build step to distribute traffic between the latest version and the currently running one gradually. Now here’s where the canary deployment plugin comes into play by distributing the traffic between the lambda versions and use the Linear10PercentEvery1Minute deployment preference type to gradually shift traffic within a 1-minute interval. Moreover, CodeDeploy was also configured to monitor the Lambda Function deployments status through Amazon CloudWatch so that it can roll back to the previous running version if the “Error” monitoring metric triggers a CloudWatch alarm which indicates that the function has either fail due to timeouts, memory issues, or unhandled exceptions.
In this blog, I wanted to explain this approach and the benefits it brings for organizations but I will also do my best to create another blog showing a step by step guide on how to deploy your serverless infrastructure using the Canary Deployment Strategy.
Top comments (0)