Blue-Green Deployments

From NovaOrdis Knowledge Base
Revision as of 03:02, 3 February 2022 by Ovidiu (talk | contribs) (→‎Overview)
Jump to navigation Jump to search

External

Internal

Overview

The idea behind the blue-green deployment technique is that at any time there are two identical instances of the application in operation. One instance takes production load, while the other is being upgraded to the next version of the application, tested, and prepared for production. Then, the traffic is switched over from the current instance to the new one. The sequence is repeated indefinitely. This technique reduces the time it takes to put "done" software in production, and also fastens recovery, in case of problems, as it will be explained below.


Application instance vs. environment. An instance of an application my comprise a large multi-node cluster. We avoid naming it "environment", because we reserve the word "environment" for a different logical abstraction, a multi-application structure that provides complex business functionality to its users. While we can certainly design a workflow that relies on blue-green switch-over at environment level, we want to make sure that components of an environment - the applications - can undergo a blue-green switch-over in isolation from other components of the environment.

One of the most sensitive moments of putting a new application version in production is the cut-over moment. At it simplest, it requires scheduling a maintenance outage: traffic is cut, the old version is shut down, the new version is spun up and traffic is resumed. This strategy ends up in downtime, which is something we want to avoid. Moreover, if the new version breaks, the application will not work. This requires shutting traffic down again, while the old version is restored and put back into traffic. This incurs to significantly more downtime. Blue-green deployments are a solution to this situation.

Blue-green technique requires two application instances running at the same time. They are conventionally named the green instance and the blue instance. The instances must be as similar as possible. At a certain moment, the blue instance is live. The green instance is shut down and replaced with a new version of the application, becoming the new green instance. The instance is tested and once the software is proved to be working correctly, the production traffic is switched over to the green instance. The on-going traffic is drained from the blue instance until it becomes idle. At this point, the entire production traffic is served by the new application version running as the green instance, and the blue instance can be used to prepare the next version.


The application instance being prepared for production could be deployed manually, but that is not advisable. A more efficient approach is to perform the application deployment and testing (and optionally the infrastructure provisioning) as part of a completely automated continuous delivery pipeline.

Organizatorium