Blue-Green Deployment
A secure way to release your applications
With the digital transformation that all companies are suffering, each day becomes more important to get available improvements to the existing applications in an agile way.
With this, new techniques emerged to attend to this demand. In complex computing environments, where it’s not possible to create and maintain an identic homologation environment as the production environment — often because of wrong data — it’s not possible to perform a homologation that gives complete confidence in the new version. Not rarely (in this scenario), we find bugs only when the improvement is already in the production environment.
Blue-Green Deployment is a technique to deploy systems that consist in to create a “mirror” environment of the production environment. We called this environment Green. We called Blue the current environment.
All users of the application have access to the Blue environment. In the Green environment, we perform the update to the new application version. This up to date environment is accessible only by homologation people and regressive testers of the improvement.
After the tests/homologation phase completion (with all possible bugs fixed), is done the publish of Green version for all the users of the application.
The publish consists simply in a redirect in the load balancer, that points the traffic to the Green environment, instead of the Blue, as the image:
In this way, the publish occurs with zero downtime — no one user receives system unavailable error, at any time.
The Blue environment, on the other hand, will be used in the next release. The current version will be in the Green environment, and the whole updating procedure, tests, and homologation will be performed on the Blue environment. After this homologation phase, the load balancer points to the Blue, and the cycle restarts:
Database
The database managing between the Blue and Green environments is one of the most complicated issues when we working with this deployment kind.
To mitigate this problem is recommended uses the same database instance in both environments, as the image below:
If it is not possible to use the same database instance in both the environments, must be guaranteed that there is a synchronization of the data in the environment changes.
There is too the problem of improvements that changes the data structure. Keep in mind that the database has to be changed in a way that works in both environments.
A used strategy is to separate the database changes that are in the new application version. The procedure follows the order (considering that the Blue is the current environment):
- the database structure is updated
- the Blue must keep working normally
- the Green is updated with the new application version
- the tests and homologation are carried out in the Green
- the load balancer does switching between the Blue and Green
Note that at beginning activity the database is updated, having the potential to impact the current version. Because of this, there is a need for the database changes to work in both environments.
Granularity
The simplest way to use a Blue-Green Deployment is to mirror the entire production environment: all applications and microservices. However, depending on the ecosystem size becomes financially inviable.
To reduce the costs, a more dynamic strategy should be used: to keep the stable applications (usually the legacy systems, that are no longer updated) out of Blue and Green environments. Both use these same applications, as the image:
Rollback
When we find a critical problem in the new version after it is released to the final user, we often decide to perform a rollback (independent of the deployment strategy is Blue-Green or not).
If we are using the Blue-Green strategy the rollback is very easy. Simply we redirect the load balancer to another environment.
Disaster Recovery
Disaster Recovery is a structured plan to recover the system if happens a critical problem that compromises all (or a significant part of) the productive environment.
If your Blue-Green strategy consists on to keep each one in a different infrastructure (different geographic regions), you can use the Blue-Green as a perfect Disaster Recovery.
Furthermore, each new release tests the Disaster Recovery plan. When we don’t use the Blue-Green, created the plan and rarely (or never) have the opportunity for validating that it covers all points. When its use is necessary, noticed that existing many details untreated.
Conclusion
The Blue-Green Deployment is a strategy of release software that gives great security for business and technical areas. If the homologation is well done difficultly new bugs are introduced.
The biggest obstacle is financial. Replicating and maintaining a productive environment isn’t cheap, and a thorough study should be done to evaluating if whether or not it is worth.
In scenarios where bugs in production environments cause big damage — as financial as to brand — and even so, constantly we can’t guarantee in homologation time the new version isn’t inserting more bugs, this strategy works fine.
Required Reading
