Blue Green deployment

Blue Green Deployment becomes a widespread pattern of deployment in the world of devops that was originally proposed by Jez Humble and David Farley in their book Continuous Delivery from 2010. However, if this pattern has become a classic Devops meetup, we will not meets only rarely in companies.

What is Blue Green deployment?

In the world of devops, we like to say that we can deploy without ever interrupting services. It is necessarily a very sales concept for many people within our companies. It is the concept of Zero Downtime Deployment (ZDD) that aims to offer the quality of being able to deliver regularly in a transparent and almost instantaneous way.

In a simplified way, the Blue Green deployment purposes to have a production environment identical to for the users who will receive a new version. It will be essential to have a routing tool that will move from one production environment to another to have the new version in a completely transparent way.

This diagram simplifies the previous explanation where the Green is the duplication of production that will receive the new version of our architecture while users are routed to the Blue.

This concept is no more complicated than that and some companies already used similar principles 10 years ago in a less formalized way (but in the past, it it was expensive to do that because we had physical servers).

When all the necessary checks are done, you can setup your router to bring users to the Green environment. With this method, the rollback is relatively simple to set up, because it will suffice to setup the router to return to the Blue version.

These routing actions are instant for users.

For those who are imaginative, this concept could even allow you to do A / B Test because it will be enough to route x% of your users on the Green and x% of your users to the Blue.

First problems with Blue Green deployment

If at first this operation seems very simple, there are quickly problems that you will encounter if you do not anticipate them in advance.

User sessions

The most classic problem is session management. How to migrate a user from Green to Blue without the person being disconnected?

There are two classic methods like putting the session in a cookie and the other calling a “deposit” independent memcache type, Redis … In this case users will go from Blue to Green without even realizing it.

Databases for Blue Green Deployment

Another classic concern is how to make the transactions started in Blue in a SQL database apply in Green if they start and end after the deployment?

1 / independent database for Blue Green deployment

The advantages of releasing the SQL database from the Blue Green pattern are not having the need to set up a concept of synchronization between the Green database and the Blue database and also to have no break in the service. .

This will involve other issues that we will see below.

The other issues from this last method will be when you want to apply a change in the database model.

The best way will be to have a Front-office that will call NoSQL databases that have no problem with models (CouchBase, MongoDb for example that are flexible on the datas). The SQL databases will feed the NoSQL databases.

The insertions should also be made with tools such as RabbitMQ that would create a second stack before starting production to maximize the chances of no data loss. The SQL database will only be powered by rabbitMQ entries. You will not be dependent with the database model with this method.

There is another simpler and less expensive method. This allows this separation of databases from Blue Green environments. You have to add fields and never remove fields from the SQL or in the associated APIs. It’s more traditional but it works.

2 / database inserted in the Blue Green deployment

This concept has the advantage of limiting the risks on the changes of databases models; on the other hand, it implies large synchronization needs in all directions.

This is the best model in theory, but it is the most complex to do. I strongly advise you to think carefully before making this choice which is quite complex to manage.

Do Canary Release

The canary release is a pattern that allows to put a small population on the N + 1 version; the remaining population will remain temporarily on the N version. You could test if all works before deploying for all the users.

Facebook uses this pattern to deploy a new version one day ahead for company employees. It’s a similar concept of the A/B Test that we saw above.

Do Dark launch

Dark Launch is also a pattern associated with Blue Green Deployment; he proposes to gradually switch the population from version N to version N + 1. This allows to gradually test our new version that could for example quickly show performance issues.

Conclusion Blue Green deployment

You have discovered this Blue Green deployment pattern that become very popular currently. Tools like HAProxy are very useful to make this famous routing between Blue and Green.

Do you have Blue Green deployment in your company? How did you manage the SQL databases?