Five Advanced Deployment Strategies to Consider under DevOps Methodology.

For an organization, in any environment, the day is never too far when the code and software need change or an upgrade. As this change is inevitable, the goal of DevOps is to mitigate the troubles associated with it, like downtime and last-minute failure. This shift or change must be smooth so that the end-users will not be impacted. Engineers have been constantly devising new and different types of application deployment strategies to make this change peaceful and effortless. 

The different types of application deployment strategies used in DevOps methodology

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

While I explain each strategy, we will simultaneously learn when to deploy the strategy in question.

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 development team relies on a router or load balancer to target individual routes. They target a small fragment of the overall user base with the newer version of the application. Once this new set of users are have used the application important metrics will be collected and analyzed to decide whether the new update is good for a full scale rolled to all the users or whether it needs to be rolled back for further troubleshooting.

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

Canary Deployment Strategy

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.

NOTE: Canary deployment has taken birth from a strategy called a rolling deployment strategy (or Ramped). the Ramped strategy is one where an application is upgraded by rolling out small instances of the new application one after the other until the whole application is updated. As on when a new instance is deployed the older version of that instance is removed.

Because this method has multiple problems like a long deployment rollout and rollback time with no control over traffic. It has been superseded and modified to become the Canary Deployment strategy.

The Blue-Green Deployment Strategy

A Blue-Green deployment strategy is one where the old and the 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, the SRE’s 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 these 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 and run alongside the new version.

Blue Green Deployment Strategy

When to use a Blue-Green strategy?

• I can afford a large infrastructure setup and my infra is scalable.
• I don’t want a second of 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)

Recreate Deployment Strategy

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

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

Recreate Deployment Strategy

When to use a Recreate Strategy?

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

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 a fairly complex deployment strategy as during the deployment cycle SRE’s have to 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, SRE’s 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.

Shadow Deployment Strategy

When to use a Shadow Strategy?

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

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 general average of that of the older version. This strategy has its benefits, however, if combined with a canary deployment it can further improve reliability.

Read more on how we at OpsMx perform this augmented Canary Analysis.

In short, test the new feature with a targeted set of users (not random), but based on common parameters segments of the users like 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

Conclusion

There are multiple deployment strategies available in the DevOps world today and an SRE has to choose and make an informed decision on what suits him or her requirements best. Some strategies may be costly to be used in staging or test environments, whereas the costs are worth it in a production deployment. Here is a deployment strategy chart that you may find useful.

Advanced Deployment Strategy Comparision

Advanced Deployment Strategy Comparison