Deployment Strategies Explained In-Depth | DevOps

Deployment Strategies Explained In-Depth | DevOps

Ever wondered how the applications you love and use daily are deployed on the cloud to a production environment? How are these tech giants rolling out updates and features regularly to millions, even billions of users across the globe?

In this article, I will be covering some of the major deployment strategies used in the industry to deploy applications to the production environment.

Contents

1. Recreate Deployment
2. Rolling Deployment
3. Blue-Green Deployment
4. Canary Deployment
5. Shadow Deployment
6. Conclusion

Recreate Deployment

This is the most basic form of a deployment strategy, where the current version of the running application is first stopped, then the new version is created and deployed. As the name suggests, Re-create or ‘replace’ the current working application with the new & updated application.

This strategy is good for very small applications where the build and deployment time is not that much, and it doesn’t require a complex setup. You can just SSH into your server and run a bunch of commands. This is what I used to do when I started with web development :) It’s an easy method, good for newcomers, and it gives you the joy of deploying an application on the internet.

Disadvantages with Recreate Deployment:

1. This is not a scalable approach when you have multiple nodes (servers) in your infrastructure.
2. While the application is being replaced, there is downtime faced by the end users.

Rolling Deployment

Consider there are multiple instances of your application running in order to accommodate for the traffic. In this deployment strategy, a portion of the total instances are updated at a time, rather than updating all instances at once.

Let’s consider an example:

There are 10 instances of your application in production. Now you want to push a new feature to all 10 instances using a rolling deployment strategy.

Typically, you need to specify the percentage of instances you want to be replaced at a time. Let’s consider that as 20%.

Once the rolling deployment starts, it will first create 2 pods (instances) with the updated version of the application. Then once these pods are healthy, it will delete 2 pods from your older deployment. Essentially, at this stage, there are 8 old pods and 2 new pods.

The strategy will go on as mentioned above, replacing 2 pods at a time, and will gradually replace all 10 pods. With the strategy, all the instances of your application, be it in millions, are replaced gradually over a period of time.

Do you see any disadvantages to this strategy?

Disadvantages of Rolling Deployment

1. If there are millions of instances running, it can potentially take a very long time to update all the instances.
2. Because the instances are gradually updated, there are chances of inconsistent behavior for the end-user until all the instances are updated.
3. Rolling back to the previous version of the deployment is difficult if an issue is detected in the middle of the current ongoing deployment.

Blue-Green Deployment

In the blue-green deployment strategy, two separate production environments are maintained, the “blue” environment and the “green” environment. The “blue” environment serves the production traffic while the “green” environment is idle during normal operations.

Let's say that we now want to deploy a new version of the application to production, then it is first deployed to the “green” environment. Once deployed, any type of testing/validations can be done, once the deployment goes well, then the load balancer serving the production traffic redirects to the “green” environment, which then is referred to as the “blue” environment, and the initial “blue” environment which is now idle is referred to as the “green” environment.

This helps for deploying updates to a production environment in a safe and efficient manner. Other strategies from this list can also be applied to the “green” environment during deployment because initially, this environment is not public. Another advantage is that it also allows teams to test the newly deployed version in parallel with the live version without any interference.

If any problems arise during the deployment, it is easy to handle because the entire environment is not serving any traffic. Let’s say a problem arises after the deployment is completed, it is still very easy to roll back because the “green” environment after successful deployment still has the previous (working) version of the application.

Disadvantages of Blue-Green Deployment

1. The cost would essentially be double the cost required for maintaining a single production environment. This can be tackled using an auto-scaling group on the “green” environment so that while it is idle, it does not require a high amount of resources. But, if there is a sudden spike in the traffic after the switch is made from “green” to “blue”, then the infrastructure may not be able to scale up as quickly as required.
2. From an abstract view, this deployment strategy seems relatively easy, but if we consider external dependencies like a database, there can be data inconsistencies, and also network-related issues within the infrastructure (while the load balancer is redirected).

Canary Deployment

A canary deployment strategy is a method for controlling and incrementally introducing changes into a production environment. The procedure entails deploying a new version of the program to a small portion of the production servers (referred to as the “canary group”) before progressively rolling it out to the remaining production servers.

The updated version of the application can be tested in a real-world production setting with actual users and actual data thanks to the canary deployment approach before being completely deployed. This will make it easier to find and address any problems with the new version before they spread to all users.

A small portion of traffic can be directed to the new version of the application as part of a “canary deployment”, which can then be used to test the new version’s functionality and behavior. If everything goes according to plan, the percentage of traffic can be gradually increased until all users are using the new version.

Canary deployment’s key advantage is its capacity to identify and address problems before they have an impact on the entire user base. Additionally, it lessens the possibility of deployment-related errors and enables teams to test the new application version prior to full deployment.

Disadvantages of Canary Deployment

1. Monitoring the performance, behavior, and identifying issues in the application with a small subset of traffic can be difficult because the small subset may not use all the features of the application before 100% deployment.
2. If issues are detected during the gradual increase in traffic phase once the canary group did not face any issues, then rolling back to the previous version can be time-consuming and complex, especially if the new version has already been deployed to a larger percentage of users.

Shadow Deployment

The shadow deployment (or shadowing) strategy is a method for testing fresh iterations of an application in a setting similar to production without impacting real users. In this strategy, the new application version concurrently runs with the current production version and redirects a portion of real traffic to the new version in order to monitor its behavior and performance.

The shadow deployment approach is frequently used to test new features of the application that can significantly impact performance or user experience. Teams may see how the new version of the application performs in a live environment and make necessary improvements before deploying it completely by routing a small portion of live traffic to it.

The key advantage of shadow deployment is that it enables teams to test new application versions in a setting similar to production without disrupting live users. It also enables teams to test the new version of the application before it is fully deployed, lowering the chance of deployment-related problems. Furthermore, it enables teams to test new versions concurrently with live ones without experiencing any interruptions and to evaluate how well they operate when faced with real-world stress.

It’s important to keep in mind that while utilizing the shadow deployment strategy, it’s essential to have the necessary monitoring processes in place to assess the performance of the new version and contrast it with the previous one. It’s also crucial to have the right security measures in place to safeguard the live data that is being utilized in the shadow environment.

Disadvantages of Shadow Deployment

1. Maintaining two separate production environments can be complex and requires additional resources.
2. The new version of the application may not receive live data, which can impact the accuracy of performance and behavior testing.

Difference Between Canary & Shadow Deployment Strategies

You may be wondering why the Canary deployment strategy and the Shadow deployment strategy seem very similar to each other, but let me tell you that there is a difference.

While both approaches can be helpful for testing new iterations of an application in a setting similar to production, their objectives and use cases are distinct. The canary deployment method focuses on testing the new version of the application with actual users and actual data, whereas the shadow deployment strategy focuses on testing the new version without affecting actual users and evaluating its performance.

Conclusion

Despite the disadvantages mentioned for all the deployment strategies, each strategy can be useful considering there are other processes in place:

1. Staging Environment
2. Quality Assurance process
3. Strong development practices

There is always some level of risk involved while deploying a new version of an application to the production environment, it all depends on other processes and practices involved to ensure a successful deployment of the application.

When it comes to which deployment strategy you should use, it’s important to carefully evaluate the risks, benefits, and trade-offs involved before making a decision.

That’s it for this blog, thank you for making it this far :)

Follow me for more content related to DevOps!