What is Blue-Green Deployment? Read this to learn about the benefits and how to implement
- Max S.
- 15min read
The bigger the business is, the more painful and costly any post-release downtime can be. The dilemma is how to implement updates without any delays or interruptions to service. Of course, there are a lot of reasons for downtime but you can definitely face disruption while an application is deployed. There are various strategies like Blue-Green deployment that can solve this issue.
Deployment is an essential part of software development, thus developers are always looking for the best deployment model. As you know, at DeployPlace we are always working to improve the Deployment Automation Tool. Sometimes we face a situation when Junior DevOps engineers and developers without a sysadmin’s background have a lack of understanding of deployment strategies.
That’s why we’ve decided to write this article in simple, easy to understand language with clear examples. Below we’ll describe all you need to know about Blue-Green Deployment strategy, its best practices and use cases. This is a model introduced by Dan North and Jez Humble, that will help you reduce the downtime of a site or application during deployment.
It’s important to have a basic understanding because it will help you to choose the best deployment model for your project. We will also write articles about other strategies like Canary, Shadow, etc. Having more information to hand allows you to enjoy wider expertise and to make better choices in your work.Deployment automation is not just a trend, it is almost the standard – or at least a good ambition. Deployment automation changes the state of software and moves it from testing to production seamlessly.
Just as with any other deployment strategy, the main idea of Blue-Green Deployment is downtime minimization. It is possible because of having two production environments working simultaneously, in parallel. The two environments are very similar but not always identical and one of these productions should be always active. The first is called Blue and the second is Green, that’s where the name is derived from for this model.
How does Blue-Green Deployment Work?
Imagine you have one router and two production environments: Blue and Green. Let’s make Blue active for now. When you prepare a new version of the software, you make tests in the Green deployment environment. After successful testing, you tune the router and all incoming requests go to the Green environment while the Blue one is in standby mode.
In this case, you also can return to the previous state. If something goes wrong, you can just switch to Blue again. But there is one important thing – you should do something with missed transactions because Green production is still active. You have two options here. The first is to direct transactions to both productions and make the Blue one the backup replica of the Green one. The second way is to switch software to read-only mode before synchronization and then switch it to read-write mode. In some cases, this simple procedure is enough.
To make all these operations possible, both environments should be independent of one another – but as identical as possible. It can be two servers or virtual machines based on one or several computers. Also, you can make two production environments in a single operating system split into different zones with separate IP addresses.
Blue-Green deployment uses the same basic mechanism as the hot-standby model. So, using this deployment model you will have the ability to make tests faster.
Thus said, the main idea is to create two easily switchable environments. There are a lot of ways to realize this strategy. One of them, for example, is to switch the web server and not the router. Another one is to use one database and make switches for the web and application level.
You might also face some database challenges, especially if you need to change some logic realization for the maintenance of the new software version. In this case, you should split the software updates from the logical structure changes. In such a situation, you should make a database refactoring first.
It is necessary to change the structure for the maintenance of both old and new versions. Then you should deploy these changes, check the state of the system and after that make deployment of the new version of the application.
Blue-Green vs Red-Black vs Blue-Green-Yellow: how do they differ?
You might also hear about Red-Black and Blue-Green-Yellow deployment. So, let’s define what’s the difference and which approach is better.
Is Red-Black Deployment the same as Blue-Green Deployment?
Some specialists say that Red-Black and Blue-Green deployment strategies are similar. They have common features. Both models use two switching productions. While Red is working, you deploy the Black one and then can switch the router and redirect the traffic to it. If something goes wrong, you just return to the Red version. Looks very familiar to Blue-Green, right?
But here is the difference. In the Blue-Green deployment, both versions can receive requests simultaneously, whereas in the Red-Black model only one version can receive requests. Thus, we can call Red-Black deployment a variant of Blue-Green. There is also an opinion that Red-Black is absolutely identical with the Blue-Green model and is only named differently, as it is used by Netflix in its operations. But this statement can’t be verified.
What about Blue-Green-Yellow Deployment?
Well, there is a place for some misunderstanding. When Dan North told the story of Blue-Green naming, he said the very first idea was to call them deployments A and B. But they soon rejected this idea because the team thought if something goes wrong in the B version, the customer says they should use A version – because all people know that A is always better! So, such a small joke lead to the colored names – as they appear neutral.
That’s why domains were called Green, Blue, Yellow, Orange but not Red because Red is something dangerous (guys using Red-Black are super-brave, for sure). So, at the end of Dan North’s story, he said that they decided to leave only two domains and they were Blue and Green. According to this story, you can name your deployments any color.
The other idea is that the Blue-Green-Yellow deployment strategy is about two domains and one router. A lot of people depicted the router as a yellow block on schemes. That’s why people often think about the third color. But in the original approach, there are only two “colorful” domains – Blue and Green and the router without a special color.
Actually, in practice you can call it what you want. If you call this model Blue-Green or Green-Blue deployment, you have more chance of being understood correctly, that’s all. If you use some special or unusual name, you might face misunderstanding with colleagues. But it is possible to use different colors and it still will be good old Blue-Green deployment.
Why Do You Need Blue-Green Deployment?
As we said above, the main idea is to minimize downtime and risks. Any downtime can be critical for business, so Blue-Green is useful in any case. It prevents your customers or you directly from losing money while an application is updating.
Benefits of Blue-Green Deployment
- Downtime reduction. Yes, we talk about downtime minimization again, because it is a really important and essential benefit of this methodology. If you work with a small project like a website or an application, you might not suffer from the problem of deployment downtime too much. But try to imagine how much money an online-shop like Amazon will lose if it has downtime. This website has millions of requests every minute, thus every pause leads to losing money. That’s why it is so important to use Blue-Green for huge-scale projects.
- Risk reduction. It is not a secret that every project has risks and an experienced Project Manager with a good development team always tries to predict and avoid them in advance. By deploying a system without downtime, you reduce a big part of risks related to data loss. Just put yourself in the end users’ place. You want to order some products, for example. You would fill-in a fields with your address, phone number and the final step is the payment confirmation. So, you carefully complete these fields, but something goes wrong and you receive an error message saying that the website is temporarily offline. You’ve just lost your time and won’t receive your purchase. A Blue-Green deployment will protect users from such errors – and your or your customer’s business from losses.
- Immediate rollback. This advantage also relates to risk reduction. With this deployment model, you’ll always have a stable release of your software to rollback to. If something goes wrong, you can immediately return to the working version and after that start bug fixing without any rush and dealing with a crowd of angry users.As you can see, using such a deployment model is quite beneficial. Talking about disadvantages, you might face additional spending on infrastructure and meet the requirements of advanced system orchestration tooling – but in general, the benefits prevail.
Blue-Green Deployment Implementation Guide and Quick Tips
We’ve discussed the main idea of Blue-Green implementation and now let’s figure out how you can start to use this deployment model in your own work. Before the implementation itself, you should adopt a few good practices for the smooth work of Blue-Green.
Tips for Green-Blue Deployment
- Use Load Balancing over DNS switching. When you switch between environments, you should tune the domain so that it points to different servers. The browser might need some time (maybe a few hours) to get a new IP address due to caching, so you shouldn’t change the DNS management interface at this point. This time is called “propagation” and can lead to a long traffic “tail” when your clients will be routed to the old server address. It means that some of your users will use the old environment and you won’t have full control of the traffic. To avoid this from happening you can use load balancing. It will help you to set a new server immediately independently of DNS. In this case, the DNS record will point at the Load Balancer and you can just change the servers. It helps you to be sure that all traffic goes to the new production environment.
- Use Rolling Update. When you switch all your servers from the old version to the new one, even with Blue-Green deployment, you might have downtime. To avoid it you can use the Rolling Update approach. In this case, you should work with the integrated environment instead of simultaneous switching of all the Blue servers to all the Green and vice versa. You can add one new server, remove one old server and repeat it until you replace all the servers. But first, make sure that your code can work in parallel with old code because they do need to work together. Also, you will need a Load Balancer. You can see the scheme below.
- Monitor the environments with alerts. It is obvious you need to monitor the production environment, but keeping an eye on the non-production environment is very important too. It is important that you catch all the possible issues. We need to highlight that non-production monitoring isn’t as critical as the production one though, so you shouldn’t monitor it all night long, you just need to know about the issues in the morning. As you know, one environment can be both production and non-production, so you need a simple way to switch between the two states. You can provide it using different API tokens for production and non-production reporting or by changing the reporting policy using the programmable tools.
- Automate. Make scripts of all the possible response scenarios you can think of and add new ones as needed, instead of doing the same work manually over and over again. Or use deployment automation tools, such as DeployPlace. You will receive a lot of benefits by doing so. Switching between the environments will be faster, easier and safer. Also, such automation will enable self-service and every person with appropriate permissions will have the ability to run a script.
- Make code backward compatible. As you surely understand, both new and old code versions are working together, so it’s very important to make sure they can co-exist.
Guide for Blue-Green Deployment
Now let’s return to the guide. You remember about the two colored productions. To implement this deployment model, you should stick to the following steps:
- Let’s start with the Green domain. We have a router and a production environment.
- Now we need to deploy the Blue domain, this is a clone of the Green one. At this step, you can also make smoke tests if needed.
- Now we have two identical productions. One of them is connected to the router, the other is not. So, we need to connect Blue production to the router.
- The last step is disconnecting the first (Green) production from the router. Also, you can eliminate the old version if it is needed.
This is the main process logic, and it will have differences depending on the language and the platform you use. The good news is that almost every existing platform supports this kind of deployment.
How to perform Blue-Green Deployment with popular platforms
It’s time to have a look at how exactly Blue-Green deployment works on different platforms, and what features and pitfalls are waiting for you.
Blue-Green deployment with Cloud Foundry
We suggest you start with a small application called “demo-time”. This is a web page where you can see the date and time on the server and the inscription “Blue time”.
- We need to use the Cloud Foundry Command Line Interface (CF CLI) for pushing the application. Let’s name the application “Blue” with the “demo-time” subdomain:
$ cf push Blue -n demo-time
Now the Blue is running on Cloud Foundry (CF) and the CF Router sends all the traffic “demo-time.example.com” to the Blue one.
- Now we need to update the application and push. Let’s make changes. We need to replace the Blue with Green and rebuild the original application file. Run cf push one more time using the name “Green”:
$ cf push Green -n demo-time-temp
Now we have two instances of our application – original Blue and new updated Green.As you can see, the CF Router still sends the traffic called “demo-time.example.com” to the Blue version but also it sends the “demo-time-temp.example.com” traffic to the Green one.
- At this step, we should switch the router so that all the incoming requests go to both Green and Blue versions. You can make it by mapping the original URL route “demo-time.deployplace.com” to the Green app using the cf map-route command:
$ cf map-route Green example.com -n demo-time
After that, the CF Router still sends the “demo-time-temp.example.com” traffic to the Green production and begins to perform the load balancing of traffic for “demo-time.example.com” between Blue and Green.
- As soon as you are sure that the Green version is working as intended, you should stop sending requests to the Blue version. You can do this with the next command:
$ cf unmap-route Blue example.com -n demo-time
After this command, the CF Router will stop sending traffic to the Blue version. Thus, all the traffic goes to Green.
- Now is the time to remove the “demo-time-temp.example.com” route from the Green version by using the cf delete-route. As for the Blue version, you can eliminate it or keep it in case you’ll need to roll the changes back.
- Cloud Foundry makes deployment easier but you also should try another deployment automation tool – DeployPlace. This is a solution with Deployment Templates, Deployment Targets, Extended Dashboard, Integration with CI and many more functions that will help you to make deployment far more simple.
How to perform Blue-Green Deployment with Octopus
If you want to implement Blue-Green deployment in Octopus, you should create two environments. Logically, one is Blue, another is Green.
In a dashboard you will see which release is in which environment and choose the environment for the deployment.
You need to configure the lifecycle in the right way. Usually, you’ll have both Blue and Green productions in a shared “Production/Staging” phase.
As you see, Blue-Green deployment is quite simple with Octopus.
If you like Octopus, you for sure should try DeployPlace. It has convenient Extended Dashboard features, Deployment Templates and a lot of other great functions designed to help you.
Blue-Green deployment with AWS
Let’s have a look at Blue-Green deployment on AWS. The idea is the same, but what about the implementation?
You can implement Blue-Green deployment on AWS using the AWS CodePipeline that provides very quick (about 15 minutes) creation of CI/CD pipelines.
When you develop and deploy an application in the AWS Elastic Beanstalk, two separate but identical environments (Blue and Green) can reduce risks and increase availability. In Quick Start, the Blue production environment usually receives traffic by default. The CI/CD pipeline architecture makes an identical Green production environment of the Elastic Beanstalk. After that, the pipeline can swap the URL addresses of these production environments.
CodePipeline deploys and tests the code in the original environment while the temporary environment can handle the traffic. After successful testing and review, the pipeline swaps URLs again. Thus, Blue production serves the live traffic and the Green one is terminated by the pipeline.
Do you have experience with using AWS and if so, how it’s going? Do you like it or are you looking for something new? We propose that you test a new solution. You should try DeployPlace. This is a new solution on the deployment automation market and we believe you’ll enjoy benefitting from it.
Blue-Green Deployment with Kubernetes
Deployment in Kubernetes specifies a group of application instances and creates a replica set for keeping the necessary number of instances in a working state.
Let’s create the Blue environment using yaml. Save the following code to the blue.yaml file:Deployment is done using the following command:
$ kubectl apply -f blue.yaml
After that, we can provide access to the deployment instances with Services. Services are separated from deployments, so you don’t need to point the service at the deployment. Instead, you should point the label selector. Usually, it is set up in such a way that it matches the deployment pods.In our example, we have two labels version=1.10 and name=nginx.
We need to set them as a label selector for the service. Save the following in the file service.yaml:You’ll also need to run the following command:
$ kubectl apply -f service.yaml
Now we will create the Green deployment. At first, let’s make the green.yaml file:As you see, it is very similar to the Blue one. The command is also very similar:
$ kubectl apply -f green.yaml
We have the following situation:
Now we have two deployments and they look like this because the services are pointed to the Blue environment:
To change the situation we need to edit the service.yaml and change the version to “1.11”:Don’t forget about this:
$ kubectl apply -f service.yaml
Now we have the next situation:
This is how you can use Kubernetes for Blue-Green Deployment. You will likely know about Kubernetes and may have already used it. We propose you test our new tool – DeployPlace. It has its own features that will interest you. We recommend you test this great new tool and discover its many benefits for yourself.
Blue-Green Deployment and Database
The main issue with databases in a Blue-Green Deployment strategy is how many DBs you need. The database is the most tricky component in this scheme. You can use two databases but it’s a more complicated approach because you need to set them up in the right way. You’ll need to make changes in the schemes and there is more room for mistakes.
So, the easier way is to use one database from the start. In this case, you don’t need to clone tables or create a new one. With one database you’ll have less manual work. But of course, the final decision about how many databases you use depends on the individual project.
Blue-Green Deployment Tools
There are a lot of companies providing Blue-Green deployment. Above we’ve listed a small number of them. For example, you can use Blue-Green deployment with platforms like AWS, Octopus, Kubernetes, Cloud Foundry and others. Also, we highly recommend you try deployment automation with DeployPlace, the new tool providing many useful and convenient functions.
The choice of tool usually depends on the project, language, the platform used and, of course, your personal preferences.
Wrap up: what does a typical Blue-Green Deployment process look like?
Blue-Green deployment is a good decision for projects where you need to reduce the deployment downtime and risks. The main idea of this deployment model is to create two production environments: Blue and Green. It is important to make them as identical as possible.
The typical Blue-Green Deployment process switches between two deployment environments to achieve a result. Thus, when you make all your tests and are sure that the Blue environment works appropriately, you can switch the router from Green to Blue. After that, you’ll have an updated application without downtime. The common benefits of this approach are the ability to perform an immediate rollback, as well as risk and downtime reduction.
There are multiple ways to implement Blue-Green deployment. The implementation features depend on the language and platform you use. We have listed the variants of Blue-Green deployment for Cloud Foundry, Octopus, AWS and Kubernetes. Of course, there are many more ways to achieve this deployment as well.
In general, Blue-Green deployment is one of the reliable methods that can help you minimize downtime and save your money.
Does DeployPlace support Blue-Green Deployment Strategy?
We do plan to implement Blue-Green Deployment in DeployPlace. We will do so in the near future and most likely we’ll not include this function from the very start. We want to launch the product as soon as possible and we are preparing a minimal functional set so that it starts to benefit our users as early as possible.
We have added to our roadmap multiple functions like Blue-Green and others, and we’ll provide it little a bit later. If you want to try our product, you can become an Early User who will get a discount and early access.