Reduce Risk, Increase Uptime with AWS Blue-Green Deployment

As more organizations move to cloud computing, the ability to deploy with a blue-green deployment scenario is gaining popularity as a proven strategy to reduce downtime and risk. As this agile approach is one we are being asked about more often, today we will discuss the benefits of blue-green deployments, specifically within AWS hosted infrastructure, and how it can be even more easily facilitated now that Amazon CloudWatch events support AWS CodePipeline as a target.

Blue-Green Deployments Defined

Blue-green deployments are essentially two identical production environments, one blue and the other, green. As one production environment runs and serves all production traffic, (let’s say blue) the other, (green,) sits idly by. With a stable, running blue environment, developers are able to push new code to and stage for deployment of an updated green environment. Once the new green environment has been tested, production traffic can be routed to it instead of the blue environment, effectively updating the software or service to users with the flip of a switch. The practice continues, with updates leapfrogging between blue and green environments.

The benefits of a blue-green approach are that it:

• Reduces risk. If there is an issue with the new green environment, all production traffic can easily be reverted back to the blue environment, which is known to be stable.
• Eliminates downtime. In addition to fast and easy rollbacks, blue-green deployments also erase the need for downtime related to maintenance or update activities.
• Facilitates continuous deployment scenarios and in doing so speeds time to market. As we’ve written in the past, code delivery should be fast, automated and boring and a blue-green approach helps achieve all three of these goals.

AWS Blue-Green Deployments 

 
To work effectively, the blue and green environments need to be identical, which traditionally could be very expensive as IT would need two identical sets of hardware and other supporting technology. However, blue-green environments become more cost-effective in the cloud, making the approach more attainable for more businesses as you only pay for what you use.

In this vein, AWS recently announced that Amazon CloudWatch events support AWS CodePipeline as a target, which we think is quite useful in triggering deployments based on certain events, or even for a fixed schedule. To refresh, Amazon CloudWatch Events will watch for certain defined events and instantiate a specified, automated action when those events occur. CodePipeline, AWS’s CI/CD service, can now be a target for those CloudWatch Events rules, with the rules starting specific pipeline activities. So, when an event occurs, it can trigger the pipeline execution to begin processing the latest commit to the source location specified in the pipeline, which in this case can be a blue or green deployment.

For example, when a developer checks their code into a repo, like CodeCommit, the CodePipeline will be notified via CloudWatch Events that the new code has been added, and the code can be deployed out to the pipeline. Aware of blue-green environments, CodePipeline knows which environment is live and hence which environment the code should be deployed to.

Moreover, you can use CloudWatch Events to ensure success with rules that monitor for validation thresholds — logic support that ensures the new code is running properly with no errors. If the thresholds are met, the environment can go live and the updated code can be rolled out to the alternate environment to return blue and green environments to an identical state. And, if the thresholds are not met, CloudWatch can automatically rollback to the operating environment. For further background, Ramesh Adabala recently illustrated how to use AWS CodePipeline to orchestrate end-to-end blue/green deployments of a golden AMI and application code.  

Blue-Green in Action

We recently worked with an enterprise customer in the energy industry for whom we created a blue-green deployment solution as part of its AWS migration. We highlighted in this customer project how to use AWS auto-scaling and self-healing in their blue-green deployments to achieve their high availability goals. While we built their green-blue environment using EC2 instances with a Classic DNS cutover that swapped AWS autoscaling groups and launch configurations, had this new approach been available, it would have added yet another layer of automation to the blue-green deployment process.

With the advent of DevOps and the opportunity for advanced agility, developers are transitioning into more of a services team, as we outline in our Enterprise DevOps Framework. Here, they are asked to assume more responsibility for services delivered, owning not just code, but also configurations, infrastructure, VMs and more. In this new DevOps model, AWS-based blue-green deployments can provide even greater agility to the services team through automation.

Blue-green facilitated continuous deployment can be a real boon to development as it provides the ability to automatically deliver updates to users when they are ready and available, bringing updates to market weeks, sometimes months faster. Moreover, faster delivery of code fixes and new features often means greater customer satisfaction. These benefits combined with reduced risk and maximum uptime all translate into competitive business advantage.