1. Overview
A deployment aims to install or upgrade the application without downtime and without disturbing the user experience. Whenever we deploy an application, we have to carefully plan the process. In particular, we need to consider different aspects and how the deployment affects the user experience. For convenience, we group such considerations into so-called deployment strategies, which dictate how upgrades are to be performed.
In this tutorial, we’ll describe the six most common deployment strategies.
2. Deployment Strategies
In short, a deployment strategy dictates how an application or other product should be released live into production.
Specifically, deployment strategies may be required for different reasons:
- interface changes
- performance
- interconnectivity
- upgrades
- continuity
All of the above factors and many more drive the process of deployment strategy formation.
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 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 usually easy to set up:
- no need to manage two different versions of the application simultaneously
- the updated application is available for all users immediately
Still, a major drawback is that if the new version introduces bugs in the application, users are immediately exposed to them without an easy way to revert. Consequently, if we do decide to roll back, it may cause even more downtime. To revert the deployment, we need to stop the updated application and recreate the original one, same as with an upgrade.
In conclusion, this deployment strategy is fairly simple to set up and manage, but we need to consider its drawbacks.
4. Red-Black and Blue-Green Deployments
The next two strategies are sometimes considered to be the same. In fact, they sometimes are. However, there can be a slight difference.
Still, in either case, we assign different colors to different application versions, which is where the names come from.
4.1. Red-Black
In this deployment strategy, the original old version is called the red environment, and the new updated version is called the black environment.
Initially, we have the red 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 contains the updated application version.
Now, both environments are running the application, but the users are still mostly or entirely directed to the old version.
So, we may start the new black version, but users are still on the red environment. The next step is to switch to the black 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 might not know that their requests are now being served by the updated application.
4.2. Blue-Green
In this sometimes nearly identical strategy, the old version is red, while the new one is black.
Outside of this terminological difference, the main divergence between the blue-green and red-black deployments can be the percentage of redirected requests.
To elaborate, although each of the versions comprises a single instance, due to the many clients that can use them, we have the option to only partially direct requests to each.
In other words, blue-green deployments may perform load balancing to check how the new version behaves. In contrast, red-black deployments often only use one or the other deployment at any given point.
4.3. Rollback
Either way, we can see that blue-green and red-black deployments are preferable in terms of uptime and being able to roll back. If we need to perform a rollback of the changes, it can happen immediately by routing the traffic to the original blue or red environment.
Conversely, when the deployment is ready and we don’t want to roll back, we can remove the old, blue or red environment. Then, we rename the updated version from green to blue or from black to red. The next release can follow the same procedure.
4.4. Disadvantages
However, these strategies have disadvantages, too. They have higher resource needs because we create two nearly identical environments. This can be expensive and time-consuming to set up. Further, we might run into problems with the rollback if the new version makes some non-backward-compatible changes. Examples of such include changes to the database.
Notably, as we see later, these strategies are similar to a merge between two other methods.
5. Rolling Update
The next strategy is the rolling update. It’s 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 removes instances, and the remaining ones must be able to serve the users to prevent downtime. If an application only has a single instance to begin with, this strategy becomes a basic recreate or blue-green deployment.
To perform a rolling update, we first create a new instance of the application 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 of the instances that run the old version. This way, we have several 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. In other words, interoperability is key.
The process continues by adding more instances running the new version and removing their older counterparts:
The deployment is finished when the last instance is replaced with an updated one, and we make 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 the current needs. We can usually set how many instances we want to update at a time. It can be more than one, especially for larger deployments.
6. Canary Deployment
The next deployment method we examine is called canary deployment. The main idea is deploying an 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 see them.
When we ensure that the update is successful, we can continue the rollout to all users. This can happen incrementally as well, meaning that the update reaches more and more users gradually. For example 25%, 50%, 75%, and only then 100%. We can even re-test the system between each increment:
During testing, we might notice that the application isn’t working properly. In this case, we can 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 much resources as the blue-green deployment because we don’t duplicate 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 that gets the updates first. Ideally, they are a targeted group that would report any problems with the updates. However, we can choose users based on demographics, physical location, device type, and similar.
7. A/B Testing
A/B testing is very similar to canary deployment. It can be considered a variant of it.
This process deploys an 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:
The 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.
As its name suggests, an A/B deployment isn’t always related to an upgrade, but can rather be a feature test.
8. Shadow Deployment
Shadow deployments are similar to blue-green deployments in the sense that they use two identical environments. One of them is the original production environment, while the other one is the shadow.
However, a shadow deployment is different from the previous deployment strategies. In all other approaches, user requests were served by the updated environment. When we use a shadow deployment, both environments receive the requests, but the responses come from the original application version:
In other words, we simulate the new updated environment in the production phase, without letting users get a request response from it. 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 ensure the updated version is stable, it can replace the old one by starting to serve requests and sending responses.
9. Conclusion
In this article, we described what deployment strategies are and also compared a number of different strategies.
We should consider many aspects and compare the possible deployment strategies before choosing what to use in a given system.