The deploy blue/green pattern is very simple in its concept, and it is very efficient to send new versions of software for production. For the implementation of the deploy blue/green pattern, the API gateway, with microservices architecture, is of great help.

In a monolithic application, generally, deployments are slower because every time a new version of the software is to be released, it must run the deployment of all the monolithics again. As the monolithic grows and becomes larger, it can become slow and problematic. With microservices, we can deploy individual components several times; it is usually faster and easier because of the size of the application thread itself being sent for production.

It is in the process of sending a new version of a microservice for production that the blue/green pattern is used. For example, if we have a microservice in version 1.0.0 and want to deploy version 1.0.1, an API gateway can know the location of both components and then provide an interface to switch traffic from the previous version to the new. The following diagram demonstrates very well the work of the API Gateway to make the change of versions using the blue/green pattern:

However, some deployments may entail a greater risk to the business of the application. In this scenario, a full version turn, as in the blue/green pattern, may not be the most appropriate. What would be interesting would be to run deploy, but direct the requests to the new version of the software in a controlled way.

As a solution to this type of situation, we have the pattern called the Canary release. The process is very similar to what is executed in blue/green patterns, and the difference is due to the gradual redirection of requests for the new version.

The requests control can be executed directly at the gateway. In this way, the impact in case of an error on the release of a new version will be much smaller. Take a look at the following diagram for an overview of this process:

The progress of the number of requests redirected to the new version of the application will depend directly on how confident the development team is. This process is gradual and does not have a predetermined time. The goal is to transfer 100% of the requests to the new version of the application.