A traditional approach to application deployment, you typically fix a failed deployment by redeploying an older, stable version of the application. Redeployment in data centers is typically done on the same set of resources due to the cost and effort of provisioning additional resources. Although this approach works, it has many shortcomings. Rollback isn’t easy because it’s implemented by redeployment of an older version from scratch.
This process takes time, making the application potentially unavailable for long periods. Even in situations where the application is only impaired, a rollback is required, which overwrites the faulty version. As a result, you have no opportunity to debug the faulty application in place.
Applying the principles of agility, scalability, utility consumption, and automation capabilities of the AWS platform can shift the paradigm of application deployment. This enables a better deployment technique called blue/green deployment.
Blue/green deployment is a technique for releasing applications by shifting traffic between two identical environments running different versions of the application.
Blue/green deployments can mitigate common risks associated with deploying software, such as downtime, and rollback capability.
Blue/green deployments provide near zero-downtime release and rollback capabilities. The fundamental idea behind blue/green deployment is to shift traffic between two identical environments that are running different versions of your application. The blue environment represents the current application version serving production traffic. In parallel, the green environment is staged running a different version of your application. After the green environment is ready and tested, production traffic is redirected from blue to green. If any problems are identified, you can roll back by reverting traffic back to the blue environment.
Benefits of Blue/Green
Traditionally, with in-place upgrades, it was difficult to validate your new application version in a production deployment while also continuing to run your old version of the application. Blue/green deployments provide a level of isolation between your blue and green application environments. It ensures spinning up a parallel green environment does not affect resources underpinning your blue environment. This isolation reduces your deployment risk.
After you deploy the green environment, you have the opportunity to validate it. You might do that with test traffic before sending production traffic to the green environment, or by using a very small fraction of production traffic, to better reflect real user traffic. This is called canary analysis or canary testing. If you discover the green environment is not operating as expected, there is no impact on the blue environment. You can route traffic back to it, minimizing impaired operation or downtime, and limiting the blast radius of impact.
This ability to simply roll traffic back to the still-operating blue environment is a key benefit of blue/green deployments. You can roll back to the blue environment at any time during the deployment process.
In AWS, blue/green deployments also provide cost optimization benefits. You’re not tied to the same underlying resources. So if the performance envelope of the application changes from one version to another, you simply launch the new environment with optimized resources, whether that means fewer resources or just different compute resources. You also don’t have to run an over-provisioned architecture for an extended period of time. During the deployment, you can scale out the green environment as more traffic gets sent to it and scale the blue environment back in as it receives less traffic. Once the deployment succeeds, you decommission the blue environment and stop paying for the resources it was using.
AWS Tools and Services Enabling Blue/Green Deployments
Amazon Route 53
Elastic Load Balancing
Elastic Beanstalk
Auto Scaling
CloudFormation
CloudWatch
OpsWork
I’ll discuss the blue-green deployment with Route53 and ElasticBeanStalk.
Update DNS Routing with Amazon Route 53
DNS is the mechanism for switching traffic from the blue environment to the green and vice versa, if rollback is necessary. In AWS, this technique applies to environments that are:
Single instances, with a public or EIP.
Groups of instances behind an ELB.
Services running on an Amazon EC2 Container Service (Amazon ECS) cluster fronted by an ELB.
Instances in an ASG with an ELB as the front end.
Elastic Beanstalk environment web tiers.
DNS Pattern
The above picture shows how Amazon Route 53 manages the DNS hosted zone. By updating the alias record, you can route traffic from the blue environment to the green environment.
You can shift traffic all at once or you can do a weighted distribution. With Amazon Route 53, you can define a percentage of traffic to go to the green environment and gradually update the weights until the green environment carries the full production traffic. A weighted distribution provides the ability to perform canary analysis where a small percentage of production traffic is introduced to a new environment.
You can test the new code and monitor for errors if any issues are encountered. It also allows the green environment to scale out to support the full production load if you’re using ELB, for example. ELB automatically scales its request-handling capacity to meet the inbound application traffic.
DNS Pattern with distributed traffic
In Blue-Green deployment, you will be running with both version, once the test completed successfully with production traffic in the green environment, we can remove the blue environment to save the resources and cost.
If issues arise during the deployment, you achieve rollback by updating the DNS record to shift traffic back to the blue environment.
Swap the Environment of an Elastic Beanstalk Application
Elastic Beanstalk enables quick and easy deployment and management of applications without having to worry about the infrastructure (no need to manage Servers, SG, ELB, ASG) that runs those applications. To deploy an application using Elastic Beanstalk, upload an application version in the form of an application bundle and then provide some information about your application. Based on application information, Elastic Beanstalk deploys the application in the blue environment and provides a URL to access the environment (typically for web server environments, we have web server and worker type environments in Elastic BeanStalk).
Elastic Beanstalk provides several deployment policies that you can configure.
All at once (deploy all in one go)
Rolling
Rolling with Additional Batches
Immutable
Blue-Green
ElasticBeanStalk with Blue Environment
Elastic Beanstalk provides an environment URL when the application is up and running. Then, the green environment is spun up with its own environment URL. At this time, two environments are up and running, but only the blue environment is serving production traffic.
Blue-Green Environment
To promote the green environment to serve production traffic, you go to the environment’s dashboard in the Elastic Beanstalk console and choose Swap Environment URL from the Actions menu. Elastic Beanstalk performs a DNS switch, which typically takes a few minutes. When the DNS changes have propagated, you can terminate the blue environment. To perform a rollback, invoke Swap Environment URL again.
Live with Green Environment(Blue Terminated)
When Blue/Green Deployments Are Not Recommended
Are your schema changes too complex to decouple from the code changes? Is sharing of data stores not feasible?
In that case, we wouldn’t perform the Blue-Green deployment when sharing a data store isn’t desired or feasible. Schema changes are too complex to decouple.
So, this is all about a long introduction about Blue-Green Deployment approach, as blue/green deployments become more popular, developers and companies are constantly applying the methodology to new and innovative use cases.
Hit the clap button if you find it useful.