Application Strategy Deployment

Application deployment strategies refer to the process of deploying software applications into a production environment. An effective deployment strategy ensures that the application is deployed efficiently and safely while minimizing downtime and disruptions.

Deploying applications can be a complex process, but with the right strategy, it can be streamlined and efficient.

Deploy Considerations

Here are some considerations that are commonly applied when deploy an application to production:

• Minimize application downtime, if any
• manage and resolve incidents with minimal impact on users
• Address failed deployments in a reliable, effective way
• Minimize people and process errors to achieve predictable, repeatable deployments

Deployment Patterns

• 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.

Recreate

The 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.

Key benefits

• Easy to set up.
• Application state entirely renewed.

Considerations

• High impact on the user, expect downtime that depends on both shutdown and boot duration of the application.

Rolling Update

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.

Key benefits

• Easy to set up.
• Version is slowly released across instances.
• Convenient for stateful applications that can handle rebalancing of the data.

Considerations

• Rollout/rollback can take time.
• Supporting multiple APIs is hard.
• No control over traffic.

Blue/Green

The blue/green deployment strategy differs from a ramped deployment, version B (green) is deployed alongside version A (blue) with exactly the same amount of instances. After testing that the new version meets all the requirements the traffic is switched from version A to version B at the load balancer level.

Key benefits

• Instant rollout/rollback.
• Avoid versioning issue, the entire application state is changed in one go.

Considerations

• 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.

Key benefits

• Zero downtime.
• Convenient for error rate and performance monitoring.
• Fast rollback.

Considerations

• Slow rollout.

A/B testing

A/B testing deployments consists 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 conversion of a given feature and only roll-out the version that converts the most.

Key benefits

• Several versions run in parallel.
• Full control over the traffic distribution.

Considerations

• Requires intelligent load balancer.
• Hard to troubleshoot errors for a given session, distributed tracing becomes mandatory.

Shadow

A shadow deployment consists of releasing version B alongside version A, fork version A's incoming requests and send them to version B as well 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 fairly complex to setup 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.

Key benefits

• 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.
• Monitor the target audience

Considerations

• 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.

Check the summary bellow.

Conclusion

Choosing the right deployment strategy depends on the specific needs of an organization and the application being deployed. However, an effective deployment strategy should ensure that the application is deployed efficiently and safely while minimizing disruptions and downtime.