Are you eager to deploy the next version of your software? Or are you afraid of the possible downtime during deployment? Or worse, that issues will arise and you’ll have to do a painful and complicated rollback?
Then I recommend you look at blue-green deployments. Let’s look at how software is traditionally deployed, what blue-green deployments are, and how you can use them.
In a more “traditional” situation, we have a single production environment for our application. Even if we have a server cluster running multiple instances of our application, they run the same version. When we want to update the application, we deploy the new version in one go.
That usually includes taking the application down, copying over new binaries, and restarting the application. Because we need to take the application down, there is a short moment in time where users can’t interact with the application. At least, we try to keep it as short as possible.
When things go wrong, we need to perform a rollback. A rollback means we deploy the previous version of the application on the server(s). And so we have some downtime again.
If you’re having a very bad day, bringing the service back online fails, and your short downtime becomes a lengthy one-sometimes even hours. Nobody likes explaining that to management or the customers.
If your application is even a tiny bit critical for its users, this isn’t a good situation. In some cases, you might even face legal consequences. There has to be a better way. And there is: blue-green deployments.
First, let’s take a look at what blue-green deployments are. Then we’ll see why they’re such an interesting technique for deploying software.
Blue-Green Deployments Explained
To implement blue-green deployments, we need two identical environments to deploy our application to. We can use a single server with two instances of our application, or two separate servers. The important bit is that we deploy our application twice and run it on systems that are as identical as possible.
These two environments are called the blue and the green environment.
Next, we put a routing component in front of our environments and route each request through that. The router is configured to send all requests to one of our environments. In the example below, we’re sending the requests to blue:
Now let’s say we have a new version of our software. The first step is to update only one environment, the non-production environment. In our case, green.
We can now configure our router to send some specific requests to green. In most cases, we’ll send internal requests to green so that we can test the application. This becomes our QA environment. We still route the production requests to the blue environment.
When we decide that the new version is ready for production, all we need to do is start sending all requests to green:
And now the environments switch roles. In our example, green takes on the production role, and blue becomes the staging environment (with yet a newer version of the application):
Advantages of Blue-Green Deployments
Blue-green deployments have two significant advantages.
Because we just flip a switch (in the router component), there is no downtime. We can take all the time we want to get the staging environment ready and then just route all requests to the updated application.
Rolling Back Is Easy
When a bug actually slips through our tests and makes it to production, we can quickly flip the switch in our router and send all requests back to the previous version of our application.
Of course, this assumes that you haven’t yet updated the other environment. To solve this issue, you could add extra colors to your environments. For example, adding one extra environment could give you separate production, staging, and rollback environments:
This way, you always have an environment to roll back to.
There are some things to keep in mind though.
Why is it so important to have identical environments?
First, you actually have two production environments. They take turns in being the production environment, but you don’t want to serve your application on a slower machine every other week!
But there’s another good reason. While you’re testing your application in a test environment, it’s always useful to run the application in an environment that resembles the production environment as closely as possible. This is true in other deployment schemes as well. Having identical environments ensures that you can find issues with infrastructure before going to production.
This does put some extra stress on system administrators though. They now need to run, monitor, and maintain two environments with the same high level of scrutiny and quality.
Changes to Downstream Services
How should we tackle breaking changes in downstream services?
Database changes are one example. What if we need to rename a column in a table as part of our deployment? The other environment that contains the old code won’t be able to work correctly anymore. And if we remove parts of the database, rolling back won’t be possible either because the data is lost forever. You can’t really have a separate database for each environment because they alternate as the production environment.
This occurs often with database changes, but I mentioned “downstream services” because it can happen with updates to other external services as well.
The solution is to work in two steps, using backward-compatible changes. First, you change the downstream service or database in such a way that it supports both the old and the new code. Then, as a second step, when all environments have been updated, you can do the breaking change. In the example of the database, the old tables or columns are no longer being used, so you can safely remove them.
Plan Your Deployments
The blue-green deployment technique is a simple idea in theory but not always in practice. Once you have your infrastructure set up, you’ll have to keep track of which environment is the production environment and which is the staging environment.
You’ll also need to know which version of your software is running where, especially if you have more than just the blue and green environment.
And if you need to make breaking changes, some careful planning will be required.
Keeping track of all this can be easy if you have a single application of limited complexity. But this is seldom the case in professional software development. Deploying a new version of your software might involve multiple steps, both automated and manual.
This is where deployment planning kicks in and where a tool like Plutora can help. Deployment tools allow you to plan and execute your blue-green deployments, even if multiple products and teams are involved.
Deploying software can be complicated enough and often requires a myriad of tools from different vendors. Adding extra environments to the mix as we do with blue-green deployments will make the whole process more complex. With a deployment tool, you can keep an overview of your environments, as well as plan, execute, and follow up on your deployments.
Why Blue and Green?
As a fun aside, here’s the story about where the colors came from. When Dan North and Jez Humble first implemented their idea, they didn’t want to choose letters because A and B can be seen as hierarchical (i.e., A is more important than B). So they went for colors and avoided using red because that is traditionally seen as a “bad” color.
Blue-Green Deployments, Not Nearly Used Enough
The idea of blue-green deployments has been around for more than a decade, but you won’t encounter it very often. It seems it hasn’t gained a lot of popularity in enterprises, even though it’s a powerful way of ensuring that quality software is released to the customer and that stress levels in the team remain low.
With blue-green deployments, you can test your software internally in an environment identical to the production environment, and there is no downtime when deploying new versions. If things do go wrong, you have an easy way of rolling back.
Want to learn more? Visit https://www.plutora.com/blog for more handy articles about agile, scrum, and software development.