avatarAli Zeynalli

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

1676

Abstract

ch the app.</p><p id="28ae"><b><i>A/B Testing…</i></b></p><p id="f8f4">This is a slight modification of Canary release, where you define exactly through request header parameters (cookies etc.) which specific user should reach to new version pods. This might be done especially when you want experienced users or testers reach the newer version to test and give qualitative feedback. In this type of deployment strategy you have configuration overhead with for example load balancer that needs to be configured intelligently that can filter users through some given criterias.</p><p id="3880"><b><i>Ramped…</i></b></p><p id="9a01">The basic idea of this deployment type is to gradually switch old version with the new version of the app. The pod instances of old version are decreased slowly and replaced with the new pods of newer version. The main fallback of these strategy is difficulties with supporting multiple API versions. Luckily there is another deployment strategy that handles this problem…</p><p id="2d94"><b><i>Blue/Green…</i></b></p><p id="73a9">I have mentioned that Ramped deployment strategy can’t handle multiple API versions simultaneously. But with Blue/Green deployment strategy, where you not only deploy new version (green) but also same amount of old version pods (blue), can address issue. Deploying same amount of old and new version enables you to handle different API versions at same time. Over time you can switch the traffic from old version to newer version. But here you might need all resources doubled, since you need to support two versions same time.</p><p id="736b"><b><i>Recreate…</i></b></p><p id="248c">This is the most straightforwa

Options

rd deployment strategy, where you just terminate all old version pods and reinstantiate them with new version. You need to expect down time here, since unlike above mentioned strategies you don’t switch to the new version gradually but doing once at same time. That is why Recreate deployment strategy is good for development environments.</p><p id="8940">In this git <a href="https://github.com/ContainerSolutions/k8s-deployment-strategies">repo</a> you can find Kubernetes examples of all deployment strategies with relevant .yaml files, which can be tested locally with Minikube.</p><p id="7b0f">If you are interested in more Software Engineering topics take a look at my other articles.</p><p id="5b87"><b><i>Relevant Articles:</i></b></p><ol><li><a href="https://azeynalli1990.medium.com/12-must-read-books-for-software-engineers-1be76d3ae79d">12 Must-Read Books for Software Engineers</a></li><li><a href="https://readmedium.com/designing-software-architecture-attribute-driven-design-2f591a96e349">Designing Software Architecture: Attribute-Driven Design</a></li><li><a href="https://readmedium.com/7913f109decc">23 Basic Principles in Software Architecture</a></li><li><a href="https://azeynalli1990.medium.com/cloud-native-architecture-patterns-60a010d90978">Cloud-Native Architecture Patterns (Part 1)</a></li><li><a href="https://azeynalli1990.medium.com/cloud-native-architecture-patterns-part-2-9704f160525f">Cloud-Native Architecture Patterns (Part 2)</a></li></ol><p id="b9e6">P.S. You can connect with me on <a href="https://twitter.com/zeynalli1990">twitter</a> or <a href="https://www.linkedin.com/in/ali-zeynalli-27590933/">linkedin</a>.</p></article></body>

5 Popular Deployment Strategies in Cloud-Computing

Canary, A/B Testing, Ramped, Blue/Green, Recreate…

Photo by Kimon Maritz on Unsplash

In Cloud-Computing there are plenty of ways to construct the new release deployment process. The correct strategy must be chosen accurately to have a stable application while new release rollout. In tools like Kuberenetes or Openshift you can preconfigure the exact deployment strategy easily. Without further due, let us have a look at some well-established deployment strategies.

Canary…

In this type of deployment strategy you deploy the new version of the application to small group of users in order to get feedback before heading to the big release. The advantages of Canary Deployment are especially error monitoring, easiness of deployment due to small traffic, fast rollback with no big consequences. On the other side, Canary Deployment brings some overhead in configuration management since you need to distribute server requests accurately between new and old version. In the language of different orchestration tools, you would need to have two replicasets (one for old version pods, one for new version pods) and small number of pods with new version that is directed from loadbalancer when test group tries to reach the app.

A/B Testing…

This is a slight modification of Canary release, where you define exactly through request header parameters (cookies etc.) which specific user should reach to new version pods. This might be done especially when you want experienced users or testers reach the newer version to test and give qualitative feedback. In this type of deployment strategy you have configuration overhead with for example load balancer that needs to be configured intelligently that can filter users through some given criterias.

Ramped…

The basic idea of this deployment type is to gradually switch old version with the new version of the app. The pod instances of old version are decreased slowly and replaced with the new pods of newer version. The main fallback of these strategy is difficulties with supporting multiple API versions. Luckily there is another deployment strategy that handles this problem…

Blue/Green…

I have mentioned that Ramped deployment strategy can’t handle multiple API versions simultaneously. But with Blue/Green deployment strategy, where you not only deploy new version (green) but also same amount of old version pods (blue), can address issue. Deploying same amount of old and new version enables you to handle different API versions at same time. Over time you can switch the traffic from old version to newer version. But here you might need all resources doubled, since you need to support two versions same time.

Recreate…

This is the most straightforward deployment strategy, where you just terminate all old version pods and reinstantiate them with new version. You need to expect down time here, since unlike above mentioned strategies you don’t switch to the new version gradually but doing once at same time. That is why Recreate deployment strategy is good for development environments.

In this git repo you can find Kubernetes examples of all deployment strategies with relevant .yaml files, which can be tested locally with Minikube.

If you are interested in more Software Engineering topics take a look at my other articles.

Relevant Articles:

  1. 12 Must-Read Books for Software Engineers
  2. Designing Software Architecture: Attribute-Driven Design
  3. 23 Basic Principles in Software Architecture
  4. Cloud-Native Architecture Patterns (Part 1)
  5. Cloud-Native Architecture Patterns (Part 2)

P.S. You can connect with me on twitter or linkedin.

DevOps
Software Architecture
Software Engineering
Deployment
Software Design
Recommended from ReadMedium