Blue/Green Deployment on AWS

Blue/Green Deployment on AWS

Coming from an Infrastructure side of things, I had never heard of the Blue/Green Deployment technique before I started following AWS technologies. For those rookies who are in the same boat as me, this post will focus more around what a Blue/Green Deployment technique is and what AWS technologies we can use to implement this technique for our application deployments. Basically, this is a technique that we can use to publish new versions of our applications by slowly shifting traffic from the old version to the new version. So at any given point during the upgrade, we will have two versions of the same application running, which gives us an upper hand to deal with errors/success. If we realize that there are bugs in the new version of the application, then we can simply move all the traffic back to the older version. But if we feel that the new version is working properly, then we can redirect all the traffic to the new version, thus successfully upgrading our application without impacting the user experience and application performance in a major way.
Folks out there who are still using their On-Prem DataCenters to host their applications won’t agree with this method of upgrading applications, as this mean that we need to have additional capacity to run multiple versions of the same application. And once we have successfully upgraded the application, then some of the capacity is just sitting idle, not running anything. This is not an ideal scenario, and you don’t want to be the one who is explaining this to the upper management and try to order new hardware when we still have some that is not being utilized. This is where public cloud changes the game. Public Cloud providers like AWS, Azure etc. help you use this upgrade technique. You can have a set of instances running the older version of your application, and you can very easily spin up new instances to run the newer version of your application. Once you feel comfortable with the newer version of the application, then you can turn off the older instances, so you don’t have to pay for them anymore. Using this technique in the cloud also enables us to change other things along with the application code, like the instance size. If you want to deploy the newer version of the application on compute-optimized or memory-optimized instances, you can easily do that when you spin up new instances.
Let’s quickly look at the different AWS Services that can help you deploy your applications using this technique:
1. Route 53: You can use weighted routing and gradually move traffic from the older version to the newer version of your application.
2. Elastic Load Balancer and Auto Scaling Group(ASG): You can create two ASGs for the two different versions of your application and then gradually decrease the number of instances in one ASG and increase the number of instances in the second ASG.
3. Elastic Beanstalk: You can have two different Beanstalk environments, running two different versions of your application, and when you are ready you can use the Swap Environment URL feature to point users to the new version.
4. OpsWorks and CloudFormation: You can have two different stacks in OpsWorks and CloudFormation, which enables you to easily migrate from one version to the next without any downtime.
Here is a simple image to show you how you can use Route 53 weighted routing along with Elastic Load Balancer and Auto Scaling groups to do a Blue/Green Deployment of your application.
BlueGreen
All this can look exciting, but there are scenarios where you should not opt for the Blue/Green Deployment technique. One of those scenarios is where you backend database schema is changing. You cannot have two versions of the same application point to different data sources and expect to have a seamless experience for the end user. So if this sounds like something that you have, then don’t use this technique. Another example is trying to use the Blue/Green method along with a commercial vendor supported application. Using these two in conjunction can add additional unwanted risk to your application upgrade. If you would like to learn more about this technique, you can refer to the following links:
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s