Blue-Green Deployments: A Definition and Introductory Guide
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. At any given time, one app is responding to user traffic, while the other app receives constant updates from your team's continuous integration (CI) server.
When your team wants to release new features, you switch the route on your load balancer from the old version of your app to the new version. At that point, your CI server then pushes updates to the app that no longer receives traffic from the router.
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 blue environment is now inactive. It receives updates from the CI server, while the green environment receives production traffic.
5. Repeat this process on 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. 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 testing and feature flag deployments.
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 deploys during non-peak hours.
Both of these strategies have costs. In the former, that cost is quantifiable downtime and some frustration from your users. In the latter, the cost might be less quantifiable, but it's still real. Also, engineering burnout or stress around your deployment process is a source for cracks in the foundation of your product.
Even ignoring downtime and stress to the 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 rollback. 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 process 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 you know works that 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'd 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 on teams with a strong DevOps skillset. The confidence and excitement surrounding safe releases can manifest in your team as excitement for more experimentation and advanced CI/CD patterns. Safety empowers your team.
Unfortunately, this strategy has trade-offs. Let's consider some real and potential drawbacks.
What are the drawbacks?
While there are many benefits to blue-green deployments, it's not all rosy. There are some cons as well—they're the other side of the coin for some of the pros. The major ones are tooling and release complexity. Also, there's some cost to consider.
Complexity in infrastructure
There are trade-offs in the decision to embrace a blue-green deployment strategy. While you might have downtime, the complexity in 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, 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.
Pushing code to the green environment
Percentage deployment between blue and green environments using feature flags
Percentage deployment complete with feature flags
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.
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 life cycle with LaunchDarkly. Sign up for a demo.