What is Blue Green Deployment?

Software development teams are often subjected to unprecedented challenges in terms of frequent releases and new updates for their applications that are live. They have to achieve a smooth release without compromising on the quality and customer experience.

To strike a balance between these two, there have been numerous developments and paradigm shifts in software development such as Agile and DevOps. Approaches like continuous integration and continuous deployment have gained tremendous traction over the years.

In short, the ability to test, build and release an application is supported by a sprawling range of tools and methodologies these days. Application release automation and build automation software play a pivotal role in pushing an update into production without manual intervention, thereby reducing technical hassles to a maximum level.

Let us now delve into one of the best deployment models used by businesses across the world- Blue-Green Deployment.

Table of contents

1. What is blue-green deployment?
2. Features of blue-green deployment?
3. Tools and services implementing blue-green deployment
4. Working of blue-green deployment
5. Conclusion

What is blue-green deployment?

Blue-Green deployment is a deployment methodology to carry out an update in the production environment with the core objective of reducing server downtime. It makes it extremely easy to roll back new changes and avoid service interruptions to applications with strict up-time requirements.

A blue-green deployment server uses two identical hardware environments- one to serve the users and the other one set idle as a staging environment. If one is blue, the other is green. The active environment acts as a target for new updates and features while the inactive deployment slot is basically a backup environment to which traffic can be redirected when the first environment gets overwhelmed with requests. In some organizations, this methodology is also addressed as Red-Black deployment methodology.

Features of blue-green deployment

1. Blue-green deployment allows seamless switching between two environments during deployment, mitigating downtime risks.
2. It incorporates database versioning practices. This means it comes with separate database instances for developers, to avoid collisions and unwanted discrepancies.
3. Rolling back to the previous deployment in the drop of a hat is a commendable feature of blue-green deployment. It is very easy to switch to the previous version in case bugs come up in the current version that has been pushed into the active environment (Production environment).
4. It does not change the value of the production environment after deployment including user configuration and other roles.

Tools and services implementing blue-green deployment

Based on the infrastructure and build of an application, there are various services such as Docker, AWS, Kubernetes, and Cloud Foundry in which blue-green deployment can be incorporated.

With the advent of cloud computing in deployment, it has apparently reduced the associated release risks faced during the entire deployment and integration process. Cloud utilities, billing, and automation have increasingly made blue-green deployment easier to employ quickly at low rates.

Blue-green deployment can be implemented through AWS by accessing several of its services that aid in the automation of deployment and infrastructure such as AWS CLI, SDK, ElasticBean, and cloud formation.

Working of blue-green deployment

Let us suppose that the DevOps team of a cloud service company has developed a game (cloud-native app) - which is basically an endless runner with a single customized map. The game’s backend is supported by multiple container-based microservices that are responsible for scoring, multiplayer, landmarks, and achievements.

The app witnesses huge traffic after its initial release. Users are logging transactions every minute. The DevOps team is keen on releasing a minor update - a mechanics microservice that involves pushing a new map into the game server.

Rather than pushing the update at midnight where the users are less active, the team plans to push the update through the blue-green deployment strategy during peak hours with zero downtime. Here’s how the whole process is carried out -

Copy the ‘mechanics’ microservice in the production environment (blue environment in this example) into another identical staging environment(green environment). After you push the new update( new map for the game) in the green environment, Q/A testing and staging by Jenkins(an open-source stress test project) is performed and then finally deployed alongside the active blue environment.

The DevOps team can also use a load balancer to distribute user’s traffic from blue to the green environment when green is made live. The blue environment can then be brought offline and used as a backup for disaster recovery purposes. Thus, blue-green deployment provides a reliable bidirectional structure to ease deployment and release events.

The above diagram describes how blue-green deployment works and how the production environment is swapped from blue to green during update pushes in the release phase.

Bottom line

Even though blue-green deployment is highly dependable and reliable, it has its own fair share of cons. It is highly resource-intensive as maintaining two production environments is costlier and blows away too much time for the system admin. Also, multiple databases for parallel production slots may result in complicated scenarios which may be too much for some organizations.

Nevertheless, the use of blue-green methodology has taken the IT world by storm, especially for organizations providing cloud services and hosting. Companies are even trying to devise new ideas that would further make deployment fully automated and the release process a simple task.