What Are Application Deployment Strategies?
An application deployment strategy is a way to upgrade an application with the new version of code. The aim is to make the changes without downtime in a way that the user barely notices the improvements.
In this post, we are going to talk about the following strategies:
- Recreate: Version A is terminated and then version B is rolled out.
- Ramped (rolling-update/incremental): Version B is slowly rolled out and replacing version A.
- Blue/Green: Version B is released alongside version A, then the traffic is switched to version B. A canary deployment consists of gradually shifting production traffic from version A to version B. Usually, the traffic is split based on weight. For example, 90 percent of the requests go to version A, 10 percent go to version B.
- Canary: Version B is released to a subset of users, then proceeds to a full rollout.
- A/B testing: Version B is released to a subset of users under specific conditions.
- Shadow: Version B receives real-world traffic alongside version A and doesn’t impact the response.
Ramped/Rolling update/Incremental:
The ramped deployment strategy consists of slowly rolling out a version of an application by replacing instances one after the other until all the instances are rolled out. It usually follows the following process: with a pool of version A behind a load balancer, one instance of version B is deployed. When the service is ready to accept traffic, the instance is added to the pool. Then, one instance of version A is removed from the pool and shut down.
Pros:
- Easy to set up.
- Version is slowly released across instances.
- Convenient for stateful applications that can handle rebalancing of the data.
Cons:
- Rollout/rollback can take time.
- Supporting multiple APIs is hard.
- No control over traffic.
Blue/Green:
Version B is released alongside version A, then the traffic is switched to version B. A canary deployment consists of gradually shifting production traffic from version A to version B. Usually, the traffic is split based on weight. For example, 90 percent of the requests go to version A, 10 percent go to version B.
Pros:
- Instant rollout/rollback.
- Avoid versioning issue, the entire application state is changed in one go.
Cons:
- Expensive as it requires double the resources.
- Proper test of the entire platform should be done before releasing to production.
- Handling stateful applications can be hard.
Canary
A canary deployment consists of gradually shifting production traffic from version A to version B. Usually, the traffic is split based on weight. For example, 90 percent of the requests go to version A, 10 percent go to version B.
This technique is mostly used when the tests are lacking or not reliable or if there is little confidence about the stability of the new release on the platform.
Pros:
- Version released for a subset of users.
- Convenient for error rate and performance monitoring.
- Fast rollback.
Con:
- Slow rollout
A/B testing
A/B testing deployments consist of routing a subset of users to a new functionality under specific conditions. It is usually a technique for making business decisions based on statistics, rather than a deployment strategy. However, it is related and can be implemented by adding extra functionality to a canary deployment so we will briefly discuss it here.
This technique is widely used to test the conversion of a given feature and only roll out the version that converts the most.
Here is a list of conditions that can be used to distribute traffic amongst the versions:
- By browser cookie
- Query parameters
- Geolocalisation
- Technology support: browser version, screen size, operating system, etc.
- Language
Comments
Post a Comment