Five Advanced Deployment Strategies To Consider for Your DevOps Methodology

For any organization in any environment, the need to revise code is inevitable. The goal of DevOps is to mitigate the troubles associated with this, including downtime and last-minute failures, so end-users will not be impacted. Engineers are constantly devising new and different types of application deployment strategies to make this change effortless and error-free. 

Application Deployment Strategies Used in DevOps

• Canary Deployment
• Blue-Green Deployment (sometimes known as red-black)
• Recreate Strategy (highlander )
• Shadow Deployment
• A/B testing Deployment strategy

Below, I will explain each strategy and when it is best to use them.

Canary Deployment Strategy

Canary deployment is a technique to reduce the risk of introducing a software update in production by slowly rolling out the change to a small subset of users before making it available to everybody. 

This deployment technique is one where the SRE of an application team uses a router or load balancer to target individual routes. Each route directs a small percentage of the overall user base to the newer version of the application. As these new users use the application, important metrics are collected and analyzed to decide whether the new update is good for a full-scale rollout to all users or whether it needs to be rolled back for further troubleshooting.

In short, the strategy is to target a small user base to collect results and predict the outcome for full-scale production deployment.

When To Use a Canary Strategy

1. I cannot afford deployment downtime for my application during an update.
2. My Infrastructure costs are way too high, and I need to manage with the limited resources I have.
3. I have designed my database schema and application environment to support two different versions of the same application in production. (N+1 compatibility)
4. The application team has the flexibility to design and implement new features.

Canary: Benefits/Advantages

• Ensures flexibility for developers to test new features and gives them the confidence to deploy and test.
• Provides a faster rollback process.
• Can be performed with limited infrastructure spending.
• Best applicable when developers want to roll out small, gradual updates.

Canary: Constraints/Disadvantages

• Long deployment cycle and slow rollout speed.
• Requires automated deployments to avoid errors. 
• Script-based processes are not recommended.

Blue-Green Deployment Strategy

A Blue-Green deployment strategy is one where the old and new instances of the application or microservice run in parallel at the same time in production, and a load balancer switches traffic from the older version to the newer version instantly.

In this strategy, SREs are trying to enable instant rollbacks at the sight of the first problem. The stable version that is currently running is usually called a blue instance, and the new one that is running in parallel is called the green instance. Both versions are always available in the production environment to avoid deployment downtime. In case of a failure, the load balancer will instantly switch all traffic to the blue instance.

In short, place the older version as a backup to always run alongside the new version.

When To Use a Blue-Green Strategy

• I can afford a large infrastructure setup, and my infrastructure is scalable.
• I don’t want a second deployment downtime for all of my users.
• I have designed my database schema and application environment to support two different versions of the same application in production. (N+1 compatibility)

Blue-Green: Benefits/Advantages

• Instant rollback.
• Elimination of version issues: All customers always access the same version.

Blue-Green: Constraints/Disadvantages

• High infrastructure costs.
• Not cost-effective for small update rollouts.

Recreate Deployment Strategy

The Recreate deployment strategy is a less sophisticated deployment strategy, where the older version of an application must be shut down before deploying the newer version. This technique implies that downtime of the service is expected, and a full reboot cycle is executed. This strategy doesn’t use a load balancer and works in infrastructures where application availability is not a major concern

In short, remove the older version after shutdown and deploy the newer version.

When To Use a Recreate Strategy

• I cannot afford any extra infrastructure than what I currently have.
• I won’t have any issues with a small duration of deployment downtime.
• When I want to change my application from scratch.
• This is most applicable in a test or staging environment.

Recreate: Benefits/Advantages

• Easy to set up and perform.
• No need to maintain an N+1 database schema and application compatibility.
• Does not require a load balancer.

Recreate: Constraints/Disadvantages

• Varied, unpredictable downtimes based on reboot and disk writing speeds.
• Lengthy impact on users.

Shadow Deployment Strategy

A Shadow deployment strategy is one where the new version is available alongside the old version in prediction, but a copy or forked version of traffic to the older version is sent to the new version for production testing. The newer version is rolled out, post successful traffic and load testing.

This is a fairly complex deployment strategy because, during the deployment cycle, SREs must maintain two versions and avoid duplicate requests getting generated by the forked user traffic. Payment gateway modules need more attention as users may get charged twice for a transaction if SREs don’t ensure that forked requests are nullified.

In short, SREs run a dummy application alongside the actual one. The dummy application receives a copy of the actual production traffic for testing performance in a real-world scenario.

When To Use a Shadow Strategy

• I have a very scalable infra and can afford a sudden rise in costs.
• I need my application to be tested with real-world production traffic for performance and stability.
• The low performance of the new application is unacceptable.

Shadow: Benefits/Advantages

• Very accurate performance and stability tests.

Shadow: Constraints / Disadvantages

• High infrastructure costs.
• Requires fast scaling on demand.
• Requires mocking of some services like payment gateways.
• Very complex setup.
• Not an accurate test of user behavior.

A/B Testing Deployment Strategy

A/B testing deployment strategy relies on real-world statistical data to decide on a rollout or rollback. It consists of routing a subset of users to a new feature or functionality under specific conditions and then gathering data on this set of users for comparison with the average of that activity for the older version. This strategy has its benefits; however, if combined with a Canary deployment, it can further improve reliability. 

In short, test the new feature with a targeted set of users based on common parameter segments of the users, such as geography or device type.

When To Use an A/B Strategy

• I have enabled my databases and application to run multiple versions of the same application in parallel. (N+1 compatibility)
• I have full control over my user traffic distribution.

Shadow: Benefits/Advantages

• Ability to test multiple versions in parallel, i.e., multiple AB tests running in parallel.
• Decisions based on real-world statistical data.
• Accurate test of user behavior.

Shadow: Constraints/Disadvantages

• Requires an expensive and intelligent load balancer.
• Highly complex compared to other strategies.

Conclusion

There are multiple deployment strategies available in the DevOps world today, and SREs need to make an informed decision based on the requirements of the application, organization, and users. For example, some strategies may be too costly for staging or test environments but worth the cost for production deployment. Here is a deployment strategy chart that you may find useful.