Editor's note: This article has been recently updated from a previous version.
What are blue-green deployments?
A blue-green deployment is an application release strategy for safely updating apps in production with no downtime. This deployment process involves creating two identical instances of a production app behind a load balancer. As there are two production apps at any given time, one app is live and receives user traffic (this is the blue environment), whilst the other app (green) receives constant updates from your team's continuous integration (CI) server. Once you have ensured the green environment is stable, and the new features are working, you can transfer production traffic over to the new application (green). The blue version is now on standby in case you need to roll back to the old version of your application.
Here's a general overview of a blue-green deployment:
1. The blue environment is live.
2. New code changes are deployed to the green environment, which isn't accessible through the load balancer.
3. Once you're ready to release a new version of your app, you cut over from the blue environment to the green environment.
4. The previous version (blue environment) is now inactive. It receives updates from the CI server, while the green environment receives production traffic.
5. Repeat this process in the next deployment, but do it in reverse order, with the green environment starting out live.
What are the benefits of blue-green deployments?
Using a blue-green deployment strategy offers several benefits. Perhaps first among these is safety in your deployments. With a running copy of your existing deployment still available, you have the immediate ability to roll back to the previous version without having to redeploy the application entirely. Additionally, there are cascading benefits from that safety that allow you to realize other benefits.
Because you can release safely, you can release more frequently. When you release more frequently, you gain competency in releasing. When you gain competency in releasing, you can try more advanced deployment techniques, such as canary deployments and feature flag rollouts.
However, to reap the benefits, release safety is paramount.
Safe deployments are cheaper and less stressful
As I mentioned, the safety blue-green deployments give may be the most important benefit. Without this strategy, you have to take several factors into account when deploying new versions of your software. These may include planned downtime or deploying a new version of the application during non-peak hours.
Both of these strategies have costs. With planned downtime, that cost is quantifiable downtime and some frustration from your users. In the off-peak deployment strategy, the cost might be less quantifiable, but it's still real. Also, engineering burnout or stress around your deployment process is a source of cracks in the foundation of your product.
Even if you weren’t concerned about impacting uptime or stress caused to your engineering team, what happens if your release doesn't go well? You can take the cost of the first deployment and then double it to roll back. Then you'd have to repeat the process when you try to release it the second time.
The costs of failure on a planned outage to release a new version of your app mean that your team needs to add significantly more overhead to ensure the release goes smoothly. This comes in the form of additional time and processes around release candidate verification and testing. The blue-green deployment method helps alleviate these issues.
With a blue-green deployment strategy, you already have an instance that you know to work, which you can roll back to for disaster recovery. While it's still important to do health checks and stay alert during the deployment, the cost to both your users and the health of your team is mitigated by the fact you can easily swap back to the working instance.
Additionally, because there's no downtime, that means you can release whenever you want—and you should! Your engineering team can build confidence in deploying often. Let's talk a bit more about that.
Production deployments should be non-events
Because you can easily switch between your blue version and green version, your team can develop great confidence in your deployment process. While you still want to follow good engineering practices, blue-green deployments don't require the amount of overhead you need in larger planned releases. This means your team can release more frequently and in smaller batch sizes. This translates into a faster turnaround from features going into your backlog to when they reach your end users.
Frequent releasing, or continuous deployment (CD), is often a cultural norm in teams with a strong DevOps skillset. The confidence and excitement surrounding safe releases can manifest in your team as excitement for more experimentation, advanced CI/CD patterns, and working up to more advanced software deployment practices such as canary releases or rollouts using feature flags. Safety empowers your team.
As with anything, this strategy has trade-offs. Let's consider some real and potential drawbacks.
What are the drawbacks of blue-green deployments?
While there are many benefits to a blue-green deployment process, it's not all rosy. There are some cons as well, the major ones being tooling and release complexity. Also, there are some costs to consider.
Complexity in infrastructure
There are trade-offs in the decision to embrace a blue-green deployment strategy. While you might not have downtime, the complexity of managing your routes and continuous integration server is non-trivial. When you're serving a blue instance, you want your continuous delivery pipeline to push to the green instance, and vice versa when you swap. Some platforms offer solutions for this, but it's something to consider no matter which platform you use.
Infrastructure isn't the only area where you'll see an increase in complexity.
Complexity in deployments
I've mentioned that blue-green deployments give you the ability to safely roll back changes if your release doesn't go well. However, that might not always be the case. If your apps used a shared database, for example, and a release depends on a schema migration, rolling back might not be an option.
While there are strategies for dealing with situations like these, they're certainly more complicated than downtime deployments. With more moving pieces, there's more to automate and more that can go wrong. You'll need to invest more time in your CI/CD toolset and skillset to manage this.
Cost and scaling considerations
If you're going to maintain two instances of your app, then you can decide for your team if the additional hosting costs are worth the benefits. Each use case is different. For example, if you have a microservice architecture or several apps, your costs could start to increase rapidly. In that case, a modified version of the blue-green deployment might be more appropriate for your team. You could achieve the same "no downtime" benefit during deploys by persisting the old version only while you're evaluating a deployment before removing it.
There are also alternative strategies to strict blue-green deployments that might better suit your team.
Feature flags as a complement to blue-green deployments
Feature flags aren't strictly an alternative to blue-green deployments, although you can use them as such. They're essentially a collection of conditional statements in your production code that you can use to gate access to new features. While you'd still need a blue-green strategy to achieve zero-downtime releases, you could achieve it in a more granular fashion through the use of feature flagging.
Imagine you have a new version of a critical part of your application. You can deploy this feature to your production environment, hiding it behind a feature flag. If you're currently routing production traffic to your blue environment, and the new code is deployed to green with the feature toggled off, you can safely re-route traffic to the green environment. Once the green environment is the main, you can toggle the feature flag on for the new version of your critical feature.
Here's an example in which you use feature flags to route incremental percentages of users from the blue environment to the green environment.
Current state
Pushing code to the green environment
Percentage deployment between blue and green environments using feature flags
There are many ways to do this that go beyond the scope of this article, but one way is to use a managed service, such as the feature management platform provided by LaunchDarkly.
While the implementation is simple, it's really powerful! The blue-green deployment gives you safety in your new releases, while the feature flag gives you safety at the feature level. You can expand the feature toggle to handle only a percentage of requests, providing even more feature-level safety. If the feature rollout doesn't go as expected, it's probably faster and certainly cheaper to toggle off the feature than it would be to roll back to the previous environment.
Keep improving
Blue-green deployments enable continuous delivery and reduce or eliminate downtime. Any strategy has tradeoffs, and blue-green deployments are no exception. It's up to you and your team to decide if the tradeoffs are worth the cost. Choose a strategy that allows you to be confident in your deploys and enables you to experiment safely.
Incorporate feature management into your software development lifecycle with LaunchDarkly. Sign up for a demo.