Blue/green deployment on the cloud makes updates easier
App deployment in the cloud operates differently than it does on physical infrastructure. The blue/green deployment model has a couple variations, each of which can save on time and errors.
With system isolation, ease of replication and rapid deployment, virtual infrastructure is the ideal way to run preproduction testing, system integration and production staging. It has become the foundation for canary, rolling and blue/green deployment models. These techniques require significant effort by DevOps and network teams that manage internal virtual server farms. Cloud services lessen these problems.
IaaS magnifies the advantages of virtual infrastructure, because it removes infrastructure operations and inserts a service-level abstraction layer between the user and the physical resources. Cloud services -- from Amazon Elastic Compute Cloud (EC2) and Elastic Block Store to Microsoft Azure Cosmos DB, Google Cloud Storage and the many other options available -- eliminate provisioning tasks required with private infrastructure and simultaneously provide an API layer that facilitates task automation and reproducibility.
Cloud services are an ideal implementation platform for undisruptive, high availability application deployment patterns. In addition, higher-level developer services can fully automate application deployment processes across multiple test and production environments.
Cloud deployment patterns
Deployment strategies are idiosyncratic to the given organization or application, but Itay Shakury of Codefresh's five categories cover most of the models:
The blue/green setup requires almost no downtime, and on cloud services, there's a simple way to switch between versions, both to upgrade and roll back, and to completely replicate a production environment during test.
Reckless deployment: IT ops teams are familiar with the rip-and-replace approach -- out with the old and in with the new. This deployment method works best with immutable infrastructure.
Rolling upgrade: New code is slipstreamed into the old, in a single environment. Given the gradual nature of a rolling upgrade, users transition incrementally, rather than en masse, to the new code.
Blue/green deployment: A blue/green deployment pattern entails two completely parallel stacks running the old and new environments. Ops cuts users over from old to new, after a period of beta testing.
Canary deployment: Similar to the blue/green deployment model, canary testing runs new and old code at the same time. However, only a small group of users opts into the new version for live testing. Google deploys the Chrome browser via a complex example of canary testing that features stable, beta or developer release channels.
Versioned deployment: This variant of the canary deployment model keeps different versions of code available indefinitely, with users given the option to choose a release.
With the exception of reckless upgrades, these are parallel deployment strategies, in that they require ops to simultaneously host different application versions in a productionlike environment. Resource cloning for a parallel deployment strategy is particularly easy on cloud services.
Cloud services for parallel deployment automation
A blue/green deployment model is perhaps the most popular option for virtualized applications. Both canary and versioned patterns are variants on this approach. The blue/green setup requires almost no downtime, and on cloud services, there's a simple way to switch between versions, both to upgrade and roll back, and to completely replicate a production environment during test. Blue/green deployment on the cloud requires no capital investment, and the old environment -- or new ones for various tests -- can be spun down as quickly as needed. AWS is representative of the other cloud services, so the example in this article articulates a blue/green deployment pattern on AWS.
Figure 1. The blue/green environment switch is simple, and admins can easily revert it if the new deployment has issues.
AWS provides detailed instructions for blue/green deployment. It uses a range of cloud services:
Domain name system (DNS): The DNS directs user traffic to each environment -- for example, to beta.myapp.io or prod.myapp.io. AWS offers Route 53.
Load balancing and scaling: The deployment model should include an ability to scale infrastructure, particularly when testers ramp up the workload. AWS has two load balancing options, Application Load Balancer and Network Load Balancer, plus an Auto Scaling service.
Resource templating: Templates facilitate automated deployments, which go hand in hand with advanced approaches, like the blue/green model. For AWS, use CloudFormation.
Resource orchestration: Cloud admins should take advantage of programmable deployments, in particular to clone entire environments. For example, AWS offers OpsWorks and Elastic Beanstalk. Elastic Beanstalk, which supports the most popular web application platforms, including Java, PHP, .NET, Node.js, Python and Ruby, can clone an environment with one click in AWS Management Console.
Service monitoring: Deployment is only the beginning. Live code should be tracked to ensure metrics stay within set limits. In the event of service failures or performance anomalies, alerts should trigger. AWS has CloudWatch for this purpose.
Once the blue/green environments are set up, switch which one is live production (green) via a DNS change. This is a simple operation on AWS Management Console with Route 53. Due to DNS caching and server time-to-live (TTL) settings, DNS transitions are gradual, as the old (blue) address ages out and is replaced with the new IP address on servers around the internet. For a faster cutover, the admin can combine Elastic Load Balancing and Auto Scaling by attaching the green group to the production ELB pool and scaling it up, while decommissioning instances from the blue group.
Automate the blue/green deployment cycle
DevOps teams that have adopted CI/CD pipelines can further automate the blue/green deployment pattern or model via a programmable software deployment service. On AWS, this product is called CodeDeploy for EC2 and the serverless cloud option Lambda, and it has built-in blue/green support. A programmable deployment service relies on the cloud provider's load-balancing and scaling capabilities to replicate environments and transition between blue and green.
On AWS, set up a blue/green CodeDeploy configuration using AWS Management Console. The service automatically clones the production environment into another Auto Scaling group. Developers tag software pushed to a code repository, such as GitHub or Amazon's Simple Storage Service, with a revision label that corresponds to a blue or green environment. As CodeDeploy pulls code updates, it determines the target and deploys to the appropriate environment. When new code is deployed in a CI/CD pipeline, CodeDeploy can immediately route traffic to the new environment. For those doing production testing on the green revision, set it up to require a manual switchover, which puts the blue/green environments in the same Auto Scaling group before turning off the blue instances.
Figure 2. Canary testing is a similar deployment model to blue/green, wherein only a small segment of users see the new release at first. They are the proverbial canaries in the coal mine.
The process works a bit differently on serverless Lambda functions than it does with IaaS EC2 instances. With Lambda, CodeDeploy creates parallel blue/green environments, and users must select one of three options to shift traffic from old to new: canary, linear or all-at-once. These approaches will be familiar to application deployment specialists and are not specific to serverless:
Canary shifts traffic in two increments, with configurable percentage and interval between shifts. For example, 15% of the traffic jumps to green for one day for testing, after which time the remaining 85% shifts.
Linear brings traffic over to the new deployment in equal increments with a set time between each. For example, in five steps, 20% of traffic moves to the green production environment every eight hours.
All-at-once cuts all traffic from blue to green in one fell swoop.
AWS alternatives for cloud deployment
Other cloud providers can also enable a blue/green deployment model. For example, Microsoft Azure users can configure Azure Service Fabric, which defaults to rolling deployments, with multiple application versions and use PowerShell to automate the cutover from blue to green. A similar technique will create and transition blue/green deployments in the Azure App Service PaaS.
Likewise, Google's App Engine PaaS accommodates traffic splitting that directs set percentages of incoming connections to one environment or another. Google Kubernetes Engine, its cluster manager and orchestration system for application containers, offers an intriguing option for blue/green deployments. The open source Spinnaker CI/CD tool can tell Google to create an automated pipeline that includes a canary test environment in order to stage new code before deploying to production. Other deployment patterns with Spinnaker or the Jenkins pipeline tool are adaptable for a blue/green or other parallel deployment strategy.
A high availability, simplified application deployment process isn't the main motivator for enterprises to move apps to cloud services or develop cloud-native code. However, cloud adopters who take the time to set up these models reap compelling benefits from the combination of easy, fast and low-cost service instantiation, programmability and available CI/CD services.
Dig Deeper on Systems automation and orchestration
