There are most of the organization has been followed/ing the Blue-Green Deployment and have proved it as safe method for continuous deployment.
Software deployment is one of the critical parts of software development, if there is any issue, it may lead to lot of issues, like downtime or you may have to spend more time to troubleshoot, which may lead your users to not able to access the feature. In case if you have automated the release process and scheduled it on weekend or late night, if there is any issue, you may need to spend your precious time on troubleshooting.
Well, there are lot of ways we can overcome this by following some best deployment practice’s available. But there are lot of it, like canary, blue-green, etc., it will be hard to find which suits for our environment to achieve minimal or zero downtime. Today, lets learn about blue-green deployment, and coming posts will see about other available deployments, so it will be easy to choose the best solution which fits your requirement.
Blue-Green Deployment
A blue/green deployment is an application deployment strategy in which you create two separate, but identical environments. One environment (blue) is running the current application version and one environment (green) is running the new or to-be application version.
Using a blue/green deployment strategy increases application availability and reduces deployment risk by simplifying the rollback process if a deployment fails. Once testing has been completed on the green environment, live application traffic can be directed to the green environment and the blue environment can kept idle for some time and then we can retire it.
How Blue-Green Deployments Works?
Why Blue-green? Does that fulfil all our requirement? Well yes, it fulfils most of standard processes part of deployment.
- Seamless: users shouldn’t experience any downtime.
- Safety: low chance of failure.
- Easy Rollback: we can undo the change without adverse effects.
The basis of the blue-green method is side-by-side deployments. For that, we need two separate but identical environments. And I mean environment in the most general way, including servers, VMs, containers, configurations, databases, among other things. Sometimes we can use different boxes or we can use separate VMs running on the same hardware or it can be different containers running in a same machine.
In simple term, we need to duplicate all the resources in our deployment side, like we need to build two independent production environments.
But sometime it is hard to keep two different environments with all the resources, as production contains a greater number of depended resources. Replicating and keeping them updated will be another set of challenge in large setup, so in that, you could see, most of the blue-green deployment environment contains shared resources as following.
As we have two environments now, it is time to plan for switching the connection between environments. For that we may need some load balancer or router or proxy server to switch it. You can find the below example; this will help to route the traffic between different versions/environments.
Blue and green take turns to play the role of production. Only one of the environments is live at any given time. Say, for instance, that blue is active. In that case, it receives all the traffic—meanwhile, green acts as a staging area, where we can deploy and test the next version.
Users continue accessing v1 on blue while the new v2 release is deployed on green.
Once we make sure the version running in green is working well, we’ll switch the route. Then the cycle begins again.
Deployment is complete once users are switched to the new version running on green.
The Cloud Makes Blue-Green Deployments More Feasible
When we speak about two separate environments, it will add most cost for the organization, especially for on-promises setup. How we can avoid? Yeah, great solution is cloud. Cloud added more flexible for the organization which helps to create on-demand environments using automation tools like Terraform, pulumi, ansible, etc. Also, we can simplify releases with containers, or orchestrate deployments using Kubernetes. This also provides flexibility and cost reductions.
Blue-Green Deployments Benefits
Blue-green is a good solution when you expect,
- Uptime: when we can’t afford to bring down a system to update it.
- Accurate tests: when need more reliable and accurate tests.
- Reliability: when we want to improve the reliability of our deployments.
To use blue-green deployments, we’ll need a few things:
- Automation: we need continuous delivery pipelines to automate the provisioning, deployment, and testing process.
- Testing: we need exhaustive tests. We’ll rely on them to decide when releases are ready to deploy. We should use continuous integration to catch errors quickly and test new versions before going live.
- Isolation: we need two identical and separate environments. Otherwise, one environment may affect the other.
The Pros of Blue-Green Deployments
Before you decide, please check the pros and cons of the deployment strategy, it should help you to pick right deployment process.
- Testing parity: Testing parity means that tests truly mirror the reality of production. This is what Dan and Jez were looking for when they devised blue-green. By running tests on the same hardware and software, they made them more useful and meaningful.
- Deploy at any time: no downtime means that we can make releases at any time. There is no need to wait for maintenance windows.
- Instant cut-over: users are switched to the new version instantaneously, or nearly so. Everyone sees the latest release at the same time.
- Instant rollback: the cut-over works both ways. If we decide to go back to the previous version, we can switch all users back in an instant.
- Hot standby: blue-green can save us from disaster scenarios. Suppose that one data center goes offline, bringing the live environment down. No biggie, we’ll switch to the other until the problem is fixed. This will work as long we have had the precaution of not putting blue and green on the same availability zone.
- Post-mortem: debugging failed releases is hard with in-place deployments. When faced with downtime, the priority is always to return to normality. Collecting debugging data is secondary, so a lot of valuable information may be lost during the rollback. Blue-green doesn’t suffer from this problem—rollbacks always leave the failed deployment intact for analysis.
The Cons of Blue-Green Deployments
At this point, you might be thinking that blue-green must have a catch. Otherwise, everyone that could would be using it. So, let’s examine the drawbacks:
- Cold starts: users may experience slowness when they are suddenly switched to the new environment. Also, any undetected performance problems are likely to appear at this point. Warm-up jobs and stress tests mitigate these issues.
- Costs: compared to other methods, blue-green deployments are more expensive. Provisioning infrastructure on-demand helps. But when we’re making several scaled-out deployments per day, the costs can snowball.
- Time: setting up the blue-green deployment process takes time and effort. The process is complex and has a great deal of responsibility. We may need to do many iterations before we get it working right.
- Databases: database migrations are harder, even to the point of being a showstopper. Databases schema changes must be forward and backward compatible. We may need to move back and forth between the old and new versions. The problem is compounded when we have two databases, one for blue and one for green. Keeping data in sync is a pain. Common strategies to deal with this involve using replication or making one database read-only.
- User transactions: during the cut-over, some user transactions will be interrupted. We must carefully consider how to handle them. How should we deal with half-applied transactions? Do we present an error message and tell the user to try again? Or do we try to carry them over to the new environment? One possible solution is to feed all the transactions to both environments simultaneously, in parallel. In this scenario, we would need to deal with any duplicated data after the deployment finishes.
- Shared services: databases and other shared services can leak information between blue and green. We need to be cautious here, otherwise one environment may affect the other indirectly. This could break the isolation rule and interfere with the deployment.
Hope this helps to understand about the blue-green deployment and this also may help you to decide you to pick the right deployment strategy. In coming post will see about canary and other deployment strategies, that may give more idea take right choice. You can read also about canary vs Blue-Green deployment.
