With the growth of the DevOps culture, new concepts are emerging. One such concept is Blue/Green deployment, which is closely linked to this work philosophy. So, what exactly is Blue/Green DevOps? What are the benefits and challenges? How can this pattern be effectively utilized? Find all the answers right here.
What is Blue Green DevOps?
Blue Green deployment and DevOps culture
Blue Green deployment emerged in 2010 through the book “Continuous Delivery” by Jez Humble and David Farley. In other words, it came into prominence shortly after the inception and popularization of the DevOps concept.
And for a good reason, this deployment pattern is closely tied to the DevOps culture.
For this work philosophy, the goal is to deploy high-quality software solutions quickly, all without disrupting services.
However, to achieve this goal of continuous improvement, DevOps teams need an optimal production environment. This is where Blue/Green Deployment comes into play.
A concept for DevOps
When developers design a new version of an application, they must have a routing tool capable of transitioning between environments, whether it’s for web servers, microservices platforms, or databases.
To achieve this, a Green environment is duplicated from the initial version. At the same time, developers are directed to a Blue environment that allows them to work on the new version seamlessly. This is version N.
Once the improvements are verified and validated, they can be implemented in the Green environment. This becomes version N+1.
Both versions are run concurrently within the production environment to promote continuous deployment and minimize interruptions. This is known as Zero Downtime Deployment (ZDD).
It’s worth noting that just because the transition is complete doesn’t mean that version N will disappear. In fact, it can be retained (especially in anticipation of future restoration or later updates) or removed permanently.
What are the advantages of Blue/Green DevOps?
Blue-Green deployment offers numerous advantages for users:
1. Speed of Deployment: Blue/Green allows for software to be launched at any time, or nearly so. In fact, a simple routing change is all that’s needed to put the software into production.
2. Enhanced User Experience: Using Blue/Green deployment enables rapid and regular release of changes. As a result, users always have access to the latest updates without any service interruptions.
3. A/B Testing: Blue Green DevOps techniques also facilitate A/B testing. In this scenario, you can direct 50% of users to the Green environment and 50% to the Blue environment. Then, you can make different changes in each environment. At the end of the test, DevOps can easily identify the most effective modifications.
What are the challenges of Blue Green deployment?
While Blue Green deployment simplifies the work of DevOps, its use does present a variety of challenges.
User sessions
This involves moving the user from one environment to another, without disconnecting them. This can be achieved by placing the session in a cookie, or by using an independent repository.
Both of these techniques make it possible to switch environments instantly, without the user even noticing.
Lack of resources
While Blue Green deployment is well-known in the world of DevOps, still too few companies employ this method of continuous deployment. The reason being, some lack the internal resources to successfully carry out the CI/CD processes.
Currently, Blue Green DevOps is not yet widespread. That said, as organizations digitize and applications evolve, they become increasingly capable of supporting continuous delivery.
Databases for Blue/Green deployment
Beyond user sessions, Blue/Green deployment poses some challenges in terms of database management. Indeed, for this technique to work, it’s crucial to apply transactions initiated in the SQL database from one environment to the other. But how is this done? It depends on the type of database.
1. Independent Databases: In this scenario, there’s no need to synchronize the Blue and Green databases. Therefore, there is no service disruption. However, these independent databases imply a change in the model. To avoid this situation, it’s possible to use NoSQL databases or separate the databases for the two environments.
2. Embedded Databases in Blue/Green Deployment: Here, there is no issue with changing the model. However, it’s essential to synchronize the databases in both directions. This model is much more complex to implement but minimizes the risk of errors to a great extent.
How to use Blue/Green DevOps?
A/B testing
This is a pattern used for Blue Green deployment. In this context, you select a small slice of the population to use version N, while another group uses version N+1. Separating the two allows for testing of features and ensuring there are no errors.
This method is particularly effective and is notably used by Facebook when planning to launch new features.
Before the official release, an initial deployment is launched among the company’s employees. They are tasked with testing the new version of the application.
Progressive deployment
Here, it’s primarily about a gradual transition from one environment to another.
Thus, the enhanced features in version N are not all implemented at once in version N+1 but gradually.
This allows for the detection of potential errors in each feature one by one.
This is useful when you are making numerous changes to your software solutions.
The tools
For Blue Green deployment, DevOps teams will require efficient tools.
For example, HAProxy simplifies the routing transition between Blue and Green. Not to mention Red Hat’s Openshift platform, which automates container operations and incorporates CI/CD features. Additionally, F5 is useful for load balancing and consolidating native services.
