Blue/green deployment

I’ve already covered recreate deployments and canary deployments, so now it’s time for yet another deployment strategy, the blue/green deployment, which is a very common approach to deploying containerized software, for example.

Blue/green deployment

Blue/green deployment hinges on a simple concept, that you should ensure that your application is running and healthy before routing any real traffic to it. In practice, it happens as follows. First you need to ensure you have two separate, but identical, environment. The first environment is running the old version of your application (which we call blue) and the other environment is running the new version of your application (green) but without any real traffic going through it. While the green application is up, you monitor its health to ensure that it is running properly and, after you have ensured this, traffic is routed to it. However, if something goes wrong after routing traffic to the green application, you can simply reroute it to the blue application that you still have and know that it works as expected. While some teams choose to keep the blue environment as a kind of staging/testing environment, the most common practice I’ve seen is to just delete it after a successful deployment.

Pros and cons

This strategy has some obvious advantages. The first and foremost is that it reduces risk by allowing for a very simple and straightforward rollback process, since all you need to do is redirect trafic to the blue environment. On the other hand, it has the issue of requiring a whole new environment for the new software version. Depending on the architecture, this can be very costly and complicated to manage. I’ve also seen blue/green deployments give a false sense of security, mainly when used in conjunction with Kubernetes, since, in this case, traffic is routed after ensuring that the application is healthy, which just means it is running without crashing, not that it is processing data as it is supposed to.