Traditionally deploying a new release and making it live in production involves replacing the existing release with the new one, this leads to a period of downtime which may be considerable for large, monolithic applications. The solutions adopted to tackle this problem are usually some variation of the o called blue-green deployment process.
The diagram below illustrates this set up in which all public traffic is routed through a reverse proxy (like Nginx or HAProxy) that forwards request to the correct release of the application (which then interacts with its correct instance of a database)
The releases are referred to by the colours green and blue. Assuming the current live release is the blue release, then all traffic will be forwarded to the blue application, when the new release is deployed to production it becomes the green release. All tests can be done on the green release on production environment while live traffic is being routed to the blue release, only when the green release has passed all tests do we switch the live traffic to be directed to the green release through the reverse proxy. This switch is aided by the use of service discovery
This ensures that there is no downtime during the deployment of the green release while allowing comprehensive tests to be done on that release before live traffic is routed to it. This mechanism also allows for a swift “roll-back” to the previous (blue) release should an issue be found after switching live traffic to the green release. Once the green release has settled in with the live traffic the blue release is removed freeing that colour for the next release and repeating the procedure with the colours reversed.
In the illustration above the application is labelled as microservice, this should be an immutable self sufficient container that can be brought up and shut down easily and quickly, without affecting other systems. The blue arrows show the flow of data for blue release while green arrows shows the same for green release. The microservices are shown to use two seperate database instances, the database element is the cause of a significant challenge because at times new releases come with database changes that are not compatible with the previous release.
When deployments are quick, safe and automated it is advisable to make frequent deployments to production introducing small incremental changes, this way this challenge may be avoided altogether and a single instance of the database could be used, otherwise the team may decide to have separate instance of databases and colour code them too.
Combining the blue-green process with immutable deployments using containers gives us a very powerful and safe deployment mechanism which is fast and can be fully automated in continuous deployments
comments powered by Disqus