Select Page
by

Gopinath Rebala

|
last updated on January 3, 2024
Share

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

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

Advanced Deployment Strategies eBook by OpsMx

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.
Canary: Benefits / Advantages
  • This ensures flexibility for developers to test new features and gives them the confidence to deploy and test.
  • We get a faster rollback process.
  • I can perform this with limited infrastructure spending.
  • Best applicable when developers want small gradual updates for rollout.
Canary : Constraints / Disadvantages
  • It has a long deployment cycle and slow rollout speed
  • The platform must be enabled with automated deployments to avoid errors. 
  • Script-based processes are not recommended.

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.

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)
Blue-Green: Benefits / Advantages
  • I get the feature of instant rollback.
  • At any point in time, there are no customers accessing a different version of the application. We bypass version issues.
Blue-Green : Constraints / Disadvantages
  • High Infra Costs
  • Small update rollouts may not be cost-effective with this strategy.

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.

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.
Recreate : Benefits / Advantages
  • SRE’s can easily perform the process and it also very easy to set up.
  • There is no need to maintain an N+1 database Schema and application compatibility.
  • I don’t require a load balancer
Recreate : Constraints / Disadvantages
  • The downtimes will greatly vary based on reboot and disk writing speeds.
  • The impact on users will be for a long time.

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.

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.
Shadow: Benefits / Advantages
  • Performance and stability tests are very accurate
Shadow : Constraints / Disadvantages
  • It has expensive infrastructure costs
  • I need to scale my infrastructure quickly on demand
  • It will require mocking of some services like payment gateways
  • The whole setup will be complex
  • It doesn’t provide an accurate test for 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 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
Shadow: Benefits / Advantages
  • I can test multiple versions in parallel i.e. multiple AB tests running in parallel
  • I can make decisions with real-world statistical data.
  • It gives an accurate test of user behavior.
Shadow : Constraints / Disadvantages
  • It needs an expensive and an intelligent load balancer
  • The complexity of the process is very high as compared to other strategies

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 Comparison

Gopinath Rebala

Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures of OpsMx Enterprise for Spinnaker. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well known leader in continuous delivery and in the Spinnaker community. Previously, Gopi was a co-founder and CTO at N42, which delivered machine learning tools for large operational systems.

Link

1 Comment

  1. kailas popat tambe

    Very meaningful ans impotant concepts presented in simple and super way!!

    Thanks a Lot! Keep Writing!

    Reply

Trackbacks/Pingbacks

  1. Why you need to scale beyond Jenkins to unlock Speed and Stability - […] system. The backups will have to be managed with the help of separate plugins. For carrying out an advanced…

Leave a Reply to kailas popat tambe Cancel reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.