create a canary release deployment with api gateway
Share on facebook
Share on twitter
Share on linkedin

Create a Canary Release Deployment with API Gateway | AWS DevOps Pro


As I detailed in my last blog post, I’m continuing to update the Linux Academy AWS DevOps Pro certification course. The course has three new sections:

  • Deployment Pipelines
  • AWS Lambda, and
  • AWS API Gateway

One of the nice things about creating sections for Lambda and API Gateway is that they kind of go hand in hand. API Gateway is often used as a front-end to invoke Lambda functions. It sounds sort of complicated right? Not so much really. I’ve created a new lesson about Canary releases, and even better yet, I created a hands-on Lab that will allow you to master Canary releases and use API Gateway to invoke Lambda functions in no time!Canary DeploymentSo before we get too far down in the weeds, let’s define Canary Deployment. The term is derived from an old mining practice of sending a real Canary down into a mine. If the Canary spent some time in the mine and came back out, still breathing, and said everything was OK (C’mon! Let’s use our imagination, I’m talking about a cartoon Canary. Of course it speaks!), then it was OK for the miners to go down into the mine. Now, I’m not creating any mining courses, so how does this work in AWS? Well, in a Canary Deployment, you send a small percentage of requests to your new application as a way of testing it without exposing the majority of your users to this new and untested app. If the app performs well, you can continue to increase the percentage of requests that it receives until finally, you have promoted it to receive 100% of the requests. An analogy I like to make is that Canary Deployments are conceptually similar to Route 53 Weighted Routing, where you determined the percentage of traffic each node will receive.Blue/Green DeploymentsAnother comparison can be made to Blue/Green Deployments which is covered in another section of the DevOps Pro course. The key difference is that with Blue/Green Deployments, you are looking to shift all traffic at once. With Canary Deployments, you are looking to perform a gradual shift. Both have their place and use cases, the choice usually comes down to your requirements.API Gateway Canary Release DeploymentSo how do we do this in AWS? Well, in the hands-on Lab titled ‘API Gateway Canary Release Deployment’, I decided to have the API invoke a Lambda function. The first step in the process is to go to Lambda in the AWS Management Console and create a Lambda function. It’s important to understand that it could really be any Lambda function. So we create the Lambda function, and because Lambda is event-based, it’s sitting there waiting to be triggered (Sound like some people you may know? Walk away!). I chose to use a few simple Math functions (Math.ceil and Math.floor) – We’re DevOps Engineers and it’s more important to understand how this all works rather than getting too in-depth on a Lambda function. So given a number as input such as 999.99, the Math.ceil function is going to return a result of 1000. Conversely, given the same number, the Math.floor function is going to give a result of 999. Now when we set up our Canary Deployment and decide to send 90% of our traffic to the Math.ceil function and 10% of our traffic to the Math.floor function, we should expect to see an output result of 1000 a bunch of times and 999 a few times (1 out of 10 if you run the test enough times for the test to normalize). OK, so we have our two Lambda functions for testing, now what? Well, as you might expect, we need to go to API Gateway and create an API to trigger our Lambda functions. Specifically, we need to create a REST API:Now that we have our REST API, let’s think about how we can invoke our Lambda function. And the answer is that the API is going to use an HTTP GET method request which will ultimately invoke our Lambda function. So once the API is created, we need to configure this GET method:And we can direct our GET method to invoke any of our Lambda functions:And with that, we have configured an API as a front-end to our Lambda function. It’s really not too complicated. So any time a client makes a request to our API, our Lambda function is going to be invoked and ultimately our Lambda function will send a response to the client (through API Gateway). As terrific as that is, do we want to spring a new, untested function on our end users? Well, that’s a loaded question and may depend on your current mood. But ideally, we would want to test our new function out a bit to a very limited audience before springing it on the whole user base. And that’s where Canary Deployments come into play. If we have a very large user base with a lot of traffic, we can send 5% of requests to our new function and the other 95% will be handled by our current PROD function. After awhile, if we’re happy with the results so far, we can bump up the percentage, maybe a 75% – 25% split. We can keep adjusting the percentage of our requests accordingly until we’re satisfied that our new function will perform admirably under a full load. So this can be a functional test as well as a load test. In the AWS Management ConsoleSo that’s how it works in theory. But how does it work in the AWS Management Console? Because at this point, if you’re following along, you’re not seeing anything related to Canary in the Management Console. Well, we first need to deploy the API (which can be done from the same ‘Actions’ dropdown pictured above). After we deploy our API, we are given an invoke URL as well as several tabs for the API (one of which is the Canary tab):And from there we can set up our Canary Deployment. Now I have to leave a bit of suspense because I want you to take the Lab! The hands-on experience is truly key in retaining what you’ve learned. So, check out the Lab and take the entire course here: AWS DevOps Pro Certification course


Get more insights, news, and assorted awesomeness around all things cloud learning.

Get Started
Who’s going to be learning?
Sign In
Welcome Back!

Psst…this one if you’ve been moved to ACG!