Introduction

If you're developing an application today it'll most likely be a distributed application. These are ubiquitous nowadays, and rightly so because there are many benefits when it comes to them in terms of scalability and high availability. However, when it's time to make changes or updates to our application, we have to plan the process ahead of time and carefully consider the different strategies and how they may affect our users. That's where deployment strategies come in.

In this article, we'll take a closer look at five of the most common deployment strategies and their pros and cons, so you can choose the right one for your application.

Deployment what?... Miguel, what do you mean by Deployment Strategy?

A deployment strategy is an approach for how and when to roll out a software update or change to a live application.

Think of a deployment strategy as a game plan for a sports team. Just like a sports team has different strategies for different games, different deployment strategies are used for different software systems. Some teams play an all-out aggressive game, trying to score as many points as possible in one go. Similarly, some deployment strategies involve deploying software updates to all nodes of the system at the same time, in an all-or-nothing approach. On the other hand, some teams prefer a more measured and cautious approach, gradually working their way up the field and testing their moves before making a big push. Similarly, some deployment strategies involve deploying to a subset of nodes first, testing and then gradually rolling out the rest of the nodes.

The choice of a game plan (deployment strategy) depends on factors such as the size of the system, the criticality of the software, and the risk tolerance. The goal is to have a deployment strategy that results in a successful outcome, just like winning a game.

1. All At Once - All Nodes Deployed at the Same Time

This is the most basic deployment, it deploys a new version of the application to all nodes of the distributed system at the same time. This method is simple but your users will experience a total outage while the deployment takes place, so this is not recommended for mission-critical production systems that need to be available 24/7.

Also, if your update fails or there's a bug in the new version that was not visible until it's deployed, you will need to roll back the changes by re-deploying the original version to all nodes of the distributed system causing yet another outage for your users while deployment takes place - oops!

I would only recommend this type of deployment for development and test environments.

2. Rolling Deployment - Slow and Steady Wins the Race

Imagine you're driving down the highway and you come across roadwork ahead with a sign that says "Rolling Closure" and you're able to proceed with caution, one lane at a time. This is exactly what a rolling deployment is like.

With a rolling deployment, the new version of the software is deployed in batches, then each batch is taken out of service while the deployment takes place, once the deployment is confirmed to be successful, it's then deployed to the rest of the nodes. This means you will not get an outage but you will experience a reduced capacity and will limit your availability during the deployment.

This strategy is not recommended for applications that are sensitive to performance e.g. a high-traffic e-commerce website, but it's a good option if you want to keep your application up and running and performance is not a factor like for example, a local coffee shop/library website.

3. Blue-Green Deployment - The Bench Player is Always Ready

Think of two players in a sports team, one is playing on the field and the other one is sitting on the bench. During the game, only one of them is on the field at any given time, and if the main player is not feeling well, the bench player is ready to step in. A blue-green deployment works similarly, with two identical production environments being maintained, with only one being active at a time.

With a blue-green deployment, we deploy the new version to a fresh new group of nodes and once these new nodes pass the health check and the deployment is confirmed to be successful, we route the traffic to the new nodes and delete the old ones. This strategy minimizes downtime and provides a quick way to revert to the previous version if necessary. If something goes wrong with the new version of the application then you can just point the router back to the original environment and delete the new instances.

4. Canary Deployment - The Canaries in the Coal Mine

Miners used to take canaries with them into the mines to detect poisonous gases. If the canary stopped singing, it was a sign that it was time to evacuate. In a canary deployment, the new version is first deployed to a small subset of the users and monitored for any issues. If everything is working well, it is then rolled out to everyone.

Similar to the blue-green deployment you start by deploying to a subset of nodes to which no users are routed, then you start to gradually route a few selected users to it, and once these pass the health checks and the deployment is successful you roll out everyone.

This strategy minimizes risk to the overall system and allows for testing in a real-world environment. However, the deployment process can take longer and may be more involved as you may be required to manage multiple versions of your software at once.

5. A/B Testing Deployment - The Battle of the Versions

Imagine you're trying to choose between two different brands of cereal. You try a little bit of each and see which one you like better. A/B testing deployment works similarly, with two different versions of the software being deployed to different subsets of nodes at the same time, and their performance is compared.

This is similar to canary deployments in a way. The new version is only available to a subset of the users who are routed to "Version B" while the rest of the users are routed to the old "Version A" of the application. These users are selected based on conditions and parameters you choose according to your business needs which could be the user's location, type of device, etc. and the versions are evaluated according to the criteria of your choice. The "better-performing" version is then deployed to the rest of the nodes.

This deployment strategy is recommended when you want to test new features and it can help you identify performance issues before they become widespread. However, this may be more complex to set up and it may be more involved due to the need to actively maintain multiple versions of your application.

Conclusion

In conclusion, there's no one-size-fits-all solution for deploying software on a distributed application, but with a good understanding of the different deployment strategies, you can choose the one that's right for your specific requirements and constraints. Whether you take an all-or-nothing approach to win the game, you're driving down the highway, preparing to play, exploring a mine, or choosing a cereal, the key is to be prepared and have a plan in place to ensure a successful deployment.