Blue-Green Deployment Nuances

Blue-Green Deployment Nuances

MicroServices and Polyglot deployments

Attribution: Stephen Goodwin [CC BY-SA 4.0]

If we already have a mature Blue Green deployment setup, it is better to stick with it. However if we are going from having downtime based deployments to zero downtime deployment then it may be important to consider below points before you decide if Blue-Green is the right fit.

Cost

It is expensive to maintain two complete production environments. In its most basic version your infrastructure cost is double.

We can save cost by standing up green infrastructure just in time for a release and then tear down the blue after you switch to green. If you can do this you will also avoid Snowflake servers in the process. However consider additional infra automation cost.

An application has to be loosing significant business during downtimes to justify the cost.

Zero downtime

It depends. Even under the best scenarios, we will only have read availability. In any OLTP system we have to put the application in read only mode for some time to allow data to migrate over to green infrastructure before we can commence testing and then switch.

So technically it is a good idea to still plan a release when there is low traffic. Sometimes this may not sit well with business stakeholders when there is a blip in availability after all the spending.

Database

Strictly speaking we need to have two Database instances, a blue and a green. Even here we have put the application in readonly mode as mentioned above. There are some teams that perform Blue-Green deployments with a single logical database unit. In these cases we may even have to take a write availability downtime when we are applying DDLs on the shared DB.

Rollback

This can happen. Not all verifications result in a green signal to switch. Any errors caught in the verification phase is still good. You will not have accumulated any data or exposed your features to users. Just call off switching.

However once we switch to Green instances, then the switch back to the Blue environment may not be as simple as it appears.

Any data accumulated in the new release should be retained even after the flip. Also after a rollback when we deploy another release with the fixes this data that was collected by the erroneous release may need some correction.

In such scenarios, Roll-forward (Deploy another release with the fixes to Blue environment and switch over. Even if you cannot fix it, disable any broken features and cut a release) may be a better option.

In a Monolithic application or an application with a small number of Monolithic services, we usually have to stick with a uniform deployment strategy and have to think long and hard to choose the best fit.

With MicroServices, just like how we can choose language and stack for each service, we can also choose deployment strategies. Expensive strategies such as Blue-Green can be reserved for critical services. Less important services can still take a downtime and deploy.

Features which need to be released based on user cohorts can go through Canary releases. We can limit sticky sessions only to those services.

Rolling deployments are handy when you may want to deploy without any perceived downtime in a cost effective manner.

Originally published on Medium on July 19, 2019.