Application Deployment Strategies

Using Enterprise Deployment Design Patterns

The Introduction

Software deployment is an integral part of the Software Development Life Cycle (SDLC). With the advent of cloud based architectures, the understanding of strategies and patterns around this is very important to any software professional.

We tend to build a proper deployment strategy mainly to:

1. Minimize the application downtime
2. To manage and resolve incidents with minimal impact on users
3. To address failed deployments with a proper rollback strategy
4. To minimize manual errors by automating the whole process

Deployment Patterns

There are multiple deployment strategies / patterns, which are widely used in the modern enterprise design.

1. Recreate deployment pattern
2. Rolling deployment pattern
3. Blue-Green deployment pattern
4. Canary test deployment pattern
5. A/B test deployment pattern
6. Shadow test deployment pattern

Lets, now discuss these patterns in a bit more detail.

Pattern 1 - Recreate Deployment Pattern

Version 1 is terminated and then the Version 2 is rolled out (See Figure 1). Initial set of nodes are completely decommissioned before spinning up the new set of instances with the new version (Version 2).

Figure 1 — Recreate Deployment Pattern

Pros

1. Simplicity — No need to manage more than one application version at a given time.
2. Can avoid backward compatibility

Cons

1. Involves a down time
2. Not suitable for mission critical applications.

Backward Compatibility — This feature ensures that the database is compatible with all active versions, which are considered. You may use Parallel Change Pattern to implement this at the code level. with the help of this pattern, each version will point to a different database schema or a version at the database level. After the complete rollout you may disregard the old version and stick to the latest version.

Pattern 2 — Rolling Deployment Pattern

Version 2 is gradually rolled out and replaces it with Version 2 (See Figure 2). The number of nodes, which are being rolled out at each stage of the transformation is called as the window size.

Figure 2 — Rolling Deployment Pattern

Pros:

1. No downtime — incrementally updates the deployment targets based on the “window size”.
2. Reduced deployment risk — Easy to setup
3. Handling stateful application is comparatively easy

Cons:

1. Slow rollback — If something goes wrong in the new replicas, redeployment is needed for those new replicas

2. Backward compatibility

Pattern 3 — Blue-Green Deployment Pattern

Version 2 is released alongside with Version 1. The traffic is switched to Version 2 after it is fully tested. It performs two identical deployments, where “blue” represents the “current” application and the “green” represents the “new” version. After the deployment succeeds, you can either keep the “blue” environment or decommission it.

Figure 3 — Blue-Green Deployment Pattern

Pros:

1. Zero downtime
2. Instant rollback — You can rollback at any moment by adjusting the Load Balancer to by direct traffic back to the “blue” environment.
3. Environment separation can reduce the deployment risk.

Cons:

1. Cost and operational overhead by having a duplicate environment.
2. Need to test Version 2 properly before the cut over.
3. Handling stateful applications could be hard. If you plan to decommission the current version, it is required to allow appropriate connection draining (See Figure 4) for existing transactions and sessions. This allows requests processed by the current deployment to be completed or terminated gracefully.

Figure 4 — Connection Draining

Pattern 4 — Canary Test Deployment Pattern

Version 2 is released to a subset of users followed by a full rollout (See Figure 5).

Usually the traffic is split based on the weight. For example, 70% of the requests will go to Version 1 and 30% of the traffic will go to Version 2. Gradually, you can increase the Version 2 traffic until it completes its rollout.

Figure 5 — Canary Deployment Pattern

Pros:

1. Multiple versions can be released for subsets of users. Can be a very effective feature when it comes to future releases.
2. Full rollback
3. Zero downtime
4. Good strategy to detect problems in the new release

Cons:

1. Slow rollout
2. Backward compatibility
3. Sticky sessions

Pattern 5 — A/B Test Deployment Pattern

Version 2 is released under “specific conditions” to a subset of users (See Figure 6).

You may route to a subset of users based on routing rules. It is a good technique for making decisions based on statistics rather the deployment strategy.

Routing rules often include factors such as: query parameters, browser version, user agent, geo-location, language and operating system.

Figure 6 — A/B Test Deployment Pattern

Pros:

1. Can run several versions in parallel for many conditions/ rules.

Cons:

1. Requires an intelligent Load Balancer (Application Load Balancer) for intelligent routing
2. Troubleshooting cloud be hard

Pattern 6 — Shadow Test Pattern

Version 2 received real world traffic without impacting user requests (See Figure 7).

Figure 7 — Shadow Deployment Pattern

You deploy and run a new version alongside the current version, but in such a way that the version is hidden from the users.

Shadow testing is fairly complex to set up. Also, like blue-green deployments, shadow deployments carry cost and operational implications because the setup requires running and managing two environments in parallel.

Pros:

1. Can do production testing of the target application with the production traffic.
2. No rollout until the stability and performance of the application meets the requirement

Cons:

1. Expensive as it requires double the resources
2. Complex to setup
3. Requires quite a few mocking service to test some critical use cases (such as on-line payments, which can lead to a double payments for a single transaction)

Choosing the right deployment strategy

Choosing the right deployment strategy is purely based on multiple factors.

1. The cost factor — It is very much required to forecast the cost factor before embarking the deployment strategy. Strategies such as Blue-Green and Shadow are rather costly to adopt if you have a small budget allocated for deployments. Unless otherwise, if you could convince the client, it is advisable not to do go ahead without the client’s permission.
2. The critical nature of the software — If you are running a mission critical application, it is always to recommended to select a deployment pattern other than the recreate deployment pattern. Recreate deployment pattern has a definite downtime and may not go well with end-users.
3. For more testing — It is always recommended to choose either Canary, A/B or Shadow if you need to have a deployment with more testing capabilities. Canary can do user based testing and A/B can further extend the user based testing to have more advanced conditioning at the load balancer level. Shadow test pattern can by itself can be used for production level workloads without exposing the new version to the end users.

References

1. Introduction to Deployment Strategies — https://harness.io/blog/continuous-verification/blue-green-canary-deployment-strategies/
2. Application Deployment and Testing Strategies — https://cloud.google.com/architecture/application-deployment-and-testing-strategies
3. Continuous Delivery — https://martinfowler.com/tags/continuous%20delivery.html
4. Six Strategies for Application Deployment — https://thenewstack.io/deployment-strategies/
5. Four Deployment Strategies for Microservices Deployment — https://www.infoworld.com/article/3565750/4-deployment-strategies-for-resilient-microservices.html
6. Parallel Change Pattern — https://martinfowler.com/bliki/ParallelChange.html