- Kingland Platform
Blue. Green. Red. Black. No, I'm not just talking about colors. I'm talking about a specific deployment technique we use at Kingland that allows for near zero downtime and the ability to easily rollback to a previous release if there are too many issues with the latest release.
Blue/green is a deployment technique where there are two identical sets of infrastructure. One set/environment - blue - has the current production release installed. The other set/environment - green - has the next production release installed. To keep things running smooth, a load balancer sits in front of the two environments and is pointed at the blue environment. When the green environment has the latest release installed, has been smoke tested and is ready for production, the load balancer is changed to point to the green environment. Any transactions occurring in the blue environment are allowed to finish, but all new transactions are directed to the green environment. In the event there is an issue with the release in the green environment, the release is rolled back by changing the load balancer to point to the blue environment.
Why use blue/green deployments?
In the past, deployments have typically been large events where the online system is taken offline during a deployment, causing downtime for production.
As cloud has matured and becomes mainstream, customers expect near zero downtime for their production environments. Customers still require updates and new features, but not at the cost of production downtime. A blue/green deployment allows new features to be released while providing for near zero downtime, thus satisfying the needs of the customer.
How do database changes work?
Traditionally, a deployment has always included code changes as well as database changes; both have been dependent on each other. This has always worked when doing in-place upgrade type deployments since the existing production system is taken offline for a period of time while the deployment takes place. However, with blue/green deployments, database changes are not deployed at the same time as code changes, as this would prevent the ability to quickly rollback to the previous version, as there may be database changes that are incompatible with older code. This means code and database changes need to be backwards compatible for some period of time. The green release of code needs to be able to run against the blue version of the database as well as support any new code required for a database change.
The new green code changes that are in support of future database changes may need to be toggled off until the database changes have been made. This allows the green environment to be put into production with the latest code, but still have the ability to rollback to the blue version if there is a problem. Once the green, now blue, environment is working well, database changes can be deployed, and another green deployment can occur that enables the new features. This enabling can be done slowly, enabling the new features for a small set of users, then gradually enabling it for all. This helps ensure any new feature that relies on the database change can be quickly corrected before all customers experience the problem.
Having separate database deployments mean the database changes need to be non-destructive in nature. New fields need to be added with defaults, fields are not renamed, and fields are not removed until support in the code has been removed. Feature toggles should also be used to disable the code path that utilizes the new database changes and only enabled gradually once the database schema changes have been deployed.
Blue/green deployments are one of the ways we're using our Kingland Platform and cloud capabilities to deliver more resilient solutions for our clients. Near zero downtime for new releases and the ability to quickly rollback to the previous release without doing re-installs - thereby reducing risk - are great benefits of blue/green deployments.
See the Kingland Platform and its capabilities.