I have studied this article about Blue/Green deployment, then some more googling introduced me to this article about Canary Release. I have this ambiguity : what will happen to databases? how we should make them synchronized? i have two possible scenarios in mind :
there may be third scenario, implement a Blue/Green deployment for databases inside the main Blue/Green deployment.
what do you think is the better solution and why? do you suggest any other practice or well known pattern ?
thank you
Blue-green deployment is a release management technique that reduces risk and minimizes downtime. It uses two production environments, known as Blue and Green, to provide reliable testing, continuous no-outage upgrades, and instant rollbacks.
A Blue-Green deployment is a relatively simple way to achieve zero downtime deployments by creating a new, separate environment for the new version being deployed and switching traffic into it. A rollback happens just as easily, with a traffic switch to the old version.
I have personally only worked with the backwards-compatible databases approach. The main benefit is that it well understood and works for a wide variety of deployment types, including canary and blue-green; I have used that approach even without the benefit of a blue-green deployment strategy (the mundane rolling deployment to all servers, which is essentially a fast canary deployment). Having to deploy database changes before application releases is common to several deployment strategies not that burdensome compared to the need for complicated triggering or mirroring mechanisms between different database versions.
Your third scenario also falls into the trap of needing triggering or mirroring between the database slices as well. In RDBMS terms, this is typically unsupported or completely impossible because there is only master database and all other instances do not accept write operations. The net effect of this is that the version of the master instance is the de-facto version of the whole database.
Certain No-SQL databases do not fall into this trap. For instance, MongoDB will happily allow multiple, different versions of document schemas in the same collection. This allows your application to be informed of the data version and handle the documents differently. However, MongoDB is not appropriate for all applications (just like an RDBS is not the right data store for certain types of data).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With