There are a variety of techniques to deploy new updates for environments to production, so choosing the right strategy is an important decision, weighing the options in terms of the impact of change on the system and the end-users.
The following strategies need to be considered:
- Recreate: Version A is terminated then version B is rolled out.
- Ramped (also known as rolling-update or 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.
- Canary: Version B is released to a subset of users, then proceed to a full rollout.
- A/B testing: Version B is released to a subset of users under specific condition.
- Shadow: Version B receives real-world traffic alongside version A and doesn’t impact the response.
Let me take you through each strategy and see which would best fit a particular use case.
RecreateThe recreate strategy is a dummy deployment which consists of shutting down version A then deploying version B after version A is turned off. This technique implies downtime of the service that depends on both shutdown and boot duration of the application.
- Easy to setup.
- Application state entirely renewed.
- High impact on the user, expect downtime that depends on both shutdown and boot duration of the application.
RampedThe 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.
Depending on the system taking care of the ramped deployment, you can tweak the following parameters to increase the deployment time:
- Parallelism, max batch size: Number of concurrent instances to roll out.
- Max surge: How many instances to add in addition of the current amount.
- Max unavailable: Number of unavailable instances during the rolling update procedure.
- Easy to set up.
- Version is slowly released across instances.
- Convenient for stateful applications that can handle rebalancing of the data.
- Rollout/rollback can take time.
- Supporting multiple APIs is hard.
- No control over traffic.
The blue/green deployment strategy differs from a ramped deployment; version B (green) is deployed alongside version A (blue) with precisely the same amount of instances. After testing that the new version meets all the requirements, traffic is switched from version A to version B at the load balancer level.
- Instant rollout/rollback.
- Avoid versioning issue, the entire application state is changed in one go.
- 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.
CanaryA canary deployment gradually shifts production traffic from version A to version B. Usually, the traffic is split based on weight. For example, 90 per cent of the requests go to version A, 10 per cent 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.
- Version released for a subset of users.
- Convenient for error rate and performance monitoring.
- Fast rollback.
- Slow rollout.
A/B testing deployments are 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, briefly discussing 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
- Technology support: browser version, screen size, operating system, etc.
- Several versions run in parallel.
- Full control over the traffic distribution.
- Requires intelligent load balancer.
- Hard to troubleshoot errors for a given session, distributed tracing becomes mandatory.
ShadowA shadow deployment consists of releasing version B alongside version A, fork version A’s incoming requests and sending them to version B without impacting production traffic. This is particularly useful to test production load on a new feature. A rollout of the application is triggered when stability and performance meet the requirements.
This technique is relatively complex and needs special requirements, especially with egress traffic. For example, given a shopping cart platform, if you want to shadow test the payment service, you can end up having customers paying twice for their order. In this case, you can solve it by creating a mocking service that replicates the response from the provider.
- Performance testing of the application with production traffic.
- No impact on the user.
- No rollout until the stability and performance of the application meet the requirements.
- Expensive as it requires double the resources.
- Not a true user test and can be misleading.
- Complex to setup.
- Requires mocking service for certain cases.
There are multiple ways to deploy a new version of an application, and it depends on the needs and budget. When releasing to development/staging environments, a recreate or ramped deployment is usually a good choice. When it comes to production, a ramped or blue/green deployment is usually a good fit, but proper testing of the new platform is necessary.
Blue/green and shadow strategies have more impact on the budget as it requires double resource capacity. If the application lacks in tests or has little confidence about the impact/stability of the software, then a canary, a/ b testing or shadow release can be used. Suppose your business requires testing a new feature amongst a specific pool of users that can be filtered depending on some parameters like geolocation, language, operating system or browser features. In that case, you may want to use the a/b testing technique.
Last but not least, a shadow release is complex and requires extra work to mock egress traffic which is mandatory when calling external dependencies with mutable actions (email, bank, etc.). However, this technique can be helpful when migrating to new database technology and using shadow traffic to monitor system performance under load.
When it comes to production, a ramped or blue/green deployment is usually a good fit, but proper testing of the newthe platform is necessary.
Blue/green and shadow strategies have more impact on the budget as it requires double resource capacity. If the application lacks in tests or has little confidence about the impact/stability of the software, then a canary, a/b testing or shadow release can be used.
Suppose you require testing a new feature amongst a specific pool of users that can be filtered depending on some parameters like geolocation, language, operating system or browser features. In that case, you may want to use the a/b testing technique.