Top 7 different microservices deployment strategies | blue green canary rolling shadow AB|CodeDecode

This video contains top 7 different deployment strategy for microservices in cloud or Kubernetes.

Recreate Deployment

Description: This approach involves shutting down the current version of the application and deploying a new version. It’s a simple and direct method but causes downtime, as users experience a break in service until the new version is up.
Best Used When: Suitable for noncritical systems or lowtraffic periods where downtime is acceptable.

Rolling Deployment
Description: In rolling deployments, a subset of instances of the application are gradually replaced with the new version. This continues until all instances are updated, allowing for minimal downtime. For example, in a cluster with five instances, the system might upgrade one instance at a time.
Best Used When: Useful when minor disruptions are tolerable, such as in scenarios with multiple nodes in production.

Steps
Step 1: Kubernetes creates 1 new pod with the updated version (`v2` ), making it 6 pods total (5 old + 1 new).
Step 2: Once the new pod is up and running, Kubernetes terminates 1 old pod. This brings the total back to 5 (4 old + 1 new).
Step 3: Kubernetes repeats the process by adding 1 new version pod and terminating 1 old version pod until all pods are updated to the new version.
BlueGreen Deployment

Description: This strategy involves maintaining two identical environments: one is the "Blue" (current live version), and the other is the "Green" (new version). The traffic is switched to the Green environment once it’s verified as stable. If issues are detected, traffic can easily revert to the Blue environment, enabling a quick rollback.
Best Used When: Ideal for critical applications where minimizing downtime is crucial, as it enables an instant switch between versions


Steps to Implement:
Kubernetes Resources: Use two distinct `Deployments` — one for the Blue environment and another for the Green environment.
Blue Environment: This is the currently running stable version (existing `Deployment` ).
Green Environment: Deploy the new version to this environment, but it remains inactive until fully tested
Deploy both versions (Blue and Green) as separate deployments in Kubernetes.

Route traffic using a load balancer to the Blue environment.
After testing the Green environment, switch traffic from Blue to Green.
Optionally, delete the Blue environment once Green is stable, or keep it for easy rollback.
Canary Deployment

Description: Canary deployment involves releasing the new version to a small subset of users first. If it performs well, it gradually rolls out to more users until it fully replaces the previous version. This approach reduces risk by allowing issues to surface with a limited impact.
Best Used When: Appropriate for hightraffic applications where gradual user exposure to new features is desirable, and it’s crucial to catch potential issues early.

Steps to Implement:

Kubernetes Resources: Canary deployments involve updating a small percentage of pods with the new version (Canary version), monitoring it, and gradually increasing the number of updated pods.
Canary Configuration:
Use Deployments with different pod replicas for the canary version and stable version.
Configure the Kubernetes `Deployment` strategy to deploy a small number of pods with the new version first.

Deploy the stable version and a small subset of pods with the canary version.
Route a small portion of traffic to the canary version.
Monitor the performance and error rates of the canary pods.
Gradually increase the number of canary pods or route more traffic to the canary version if no issues are detected.
Once the canary is verified, gradually shift all traffic to the new version.

A/B Testing

Description: A/B testing is similar to a canary deployment but is typically used for feature experimentation. Different versions (A and B) are served to different user groups simultaneously to determine which performs better.
Best Used When: Effective in scenarios requiring user feedback for feature optimization, especially in UI/UX changes or behavioral testing.

Steps to Implement:

Kubernetes Resources:
You’ll need to deploy multiple versions of the application (A and B) as separate services or deployments. Kubernetes will help you manage and route traffic to each version based on predefined rules.



Shadow Deployment

Description: In shadow deployment, the new version runs in parallel with the old one but receives a copy of the live traffic without impacting the actual user experience. This setup enables extensive testing of the new version under realworld conditions.


Feature Toggles (Flags)
Description: With feature toggles, new features are included in the deployment but kept disabled for users. A toggle can gradually enable these features to selected users, allowing testing in production while minimizing risk.

Тэги:

#microservices #Top_7_different_Microservices_deployment_strategies #kubernetes #deployment_strategies_in_kubernetes #deployment_in_kubernetes #microservices_deployment_strategy #strategy_deployment #blue_green_deployment_kubernetes #blue_green_deployment_vs_canary_vs_rolling #canary_deployment_kubernetes #blue_green_deployment_aws #canary_deployment #rolling_update_deployment_strategy #shadow_deployment #feature_toggle #top_5_deployment_strategies #top_7_deployment_strategies

Скачать видео