1. Overview
In this tutorial, we’ll describe the six most common deployment strategies.
2. Deployment Strategies
Whenever we deploy an application, we have to carefully plan the process. We need to consider different aspects and how it affects the user experience. A deployment aims to install or upgrade the application without downtime and without disturbing the user experience.
A deployment strategy describes the process of how these upgrades should be performed.
3. Recreate Deployment Strategy
The most basic strategy we discuss is called the “Recreate” deployment strategy. As the name suggests, we stop and then recreate the application. The newly created deployment runs the updated version of the application.
Users will experience some downtime because we need to stop the application before the new version is running. The application won’t be available while the original version is shutting down and the new one is starting.
On the other hand, this strategy is easy to set up. We don’t have to manage two different versions of the application simultaneously. If we choose this approach, the updated application will be available for all users immediately. This has a drawback though, because the new version might introduce bugs to the application, and the users will see those as well.
We might even need to completely roll back to the previous working version. Unfortunately, the rollback causes downtime, too. To revert the deployment, we need to stop the updated application and recreate the original one.
In conclusion, this deployment strategy is fairly simple to set up and manage, but we need to consider its drawbacks before we use it.
4. Blue-Green Deployment
The next deployment strategy we discuss is called “Blue-green” deployment. In this case, we assign different colors to different application versions. That’s where the name comes from. The original, old version is called blue environment, and the new updated version is called green environment.
Let’s see how this strategy works. Firstly, we have the blue environment. This is an existing application that handles all user traffic. We would like to update the application without downtime. To accomplish this, we create an almost identical environment. There is a difference, though. The new environment will contain the updated application version. Now, both environments are running our application, but the users are still using the old version:
The above image shows the state when we already started the new version, but users are still using the blue environment. The next step is to switch to a green environment by transferring all user traffic to it. This switch can happen very quickly, so users won’t experience downtime. In addition, they can use the application the same way as before, and they don’t know that their requests are being served by the updated application:
If we need to roll back the changes, it can happen immediately by routing the traffic to the original, blue environment. When the deployment is finished and we don’t want to roll back, we can remove the old, blue environment. Then we rename the updated version from green to blue. The next release can follow the same procedure.
We can see that this process is preferable in terms of uptime and being able to roll back. However, it has disadvantages too. It has higher resource needs because we create two nearly identical environments. This can be expensive and time-consuming to set up. Secondly, we might run into problems with the rollback if the new version makes some non-backward-compatible changes. For example, changes in the database.
5. Rolling Update
The next strategy is called “Rolling Update”. It is applicable only if we have multiple instances of an application.
Initially, all the instances are running the old version, and all of them can process user requests. This is important here because the process will remove instances, and the remaining ones must be able to serve the users to prevent downtime.
Firstly, we create a new instance that runs the updated version. When this new instance is started, we consider it a part of the application, so the user requests might already be processed by it:
After this, we remove one from the instances that run the old version. This way, we have two instances running the old version and one instance running the updated version. This indicates that we must be able to support different versions at the same time if we would like to use this deployment strategy. Otherwise, the old or the new instances might not work as expected.
The process continues to add instances running the new version and remove their pairs:
The deployment is finished when the last instance is replaced with an updated one, and we made sure that the application works as expected. Of course, we can test during the update too. If we find any issues, we can roll back all changes.
This deployment strategy can be parameterized to better fit our needs. We can usually set how many instances we want to update at a time. It can be more than one. We were using this value in our example for simplicity.
6. Canary Deployment
The following deployment method we examine is called “Canary deployment”. The main idea is that we deploy the update to more and more users in iterations.
Initially, only a small part of the users receive the update. After this step, we test the system to make sure the application is working properly after the changes. This way, we can reduce risks, and even if we introduce bugs to the system, only a subset of users will see it.
When we are sure that the update is successful, we can continue the rollout to all of the users. This can happen incrementally as well, meaning that the update reaches more and more users gradually. For example 25%, 50%, 75%, and then 100%. We can even re-test the system between each increment:
During testing, we might notice that the application is not working properly. In this case, we need to roll back the changes similar to the previous examples.
Canary deployments provide a high level of control, but this might be difficult to implement. We need to make sure only a limited amount of users receive the update. Compared to blue-green deployments where we simply needed to switch traffic from one environment to another, this is more challenging. On the other hand, it gives us more flexibility and reduces risk.
This process doesn’t need as many resources as the blue-green deployment because we are not duplicating the environments. However, we face the same problem if the new application version makes some breaking changes in the database.
The canary deployment strategy involves another interesting aspect. We need to select the target audience who gets the updates first. Ideally, they are a targeted group who would report if they find any problems with the updates. However, we can choose users based on demographics, physical location, device type, etc.
7. A/B Testing
A/B testing is very similar to canary deployment. It can be considered a variant of it. This process deploys the update to a subset of users, just like canary deployments. However, A/B testing is mainly about getting feedback from the users about our changes. One part of the users keep using “version A” of the application while another part of them uses “version B”:
Our goal is to decide if we want to roll out the update to all users. This can be a complicated process. We should consider technical aspects like application performance, but we might also want to receive feedback from users if they like the changes or not. For example, with A/B testing, we can measure if the users are more likely to click on a button if we replace the text on it.
8. Shadow Deployment
Shadow deployment is similar to blue-green deployment in the sense that it uses two identical environments. One of them is the original production environment. The other one is the shadow.
However, it is different from the previous deployment strategies. In all of the previous approaches, user requests were served by the updated environment. When we use shadow deployment, both environments receive the requests, but the responses come from the original application version:
This way, we don’t have the risk of introducing bugs to the system while we can monitor and test the new version under load.
On the other hand, having two deployments can be expensive and difficult to manage. Furthermore, we need to ensure that the new version doesn’t have any side effects. For example, if we process payments, we need to mock the payment service in the new environment to avoid charging users twice.
When we are sure the updated version is stable, it can replace the old one, and we can redirect user traffic to it.
9. Conclusion
In this article, we described what are deployment strategies and compared six different strategies.
We should consider many aspects and compare the possible deployment strategies before choosing what to use in our system.