Deployment Strategies

We have previously explored various deployment options. In this section, we will examine how to deploy a service, with a particular focus on updating an existing one.

Imagine we are running a service with several instances:

There are multiple deployment strategies, each suited to different use cases:

Recreate Deployment

The concept is straightforward: the old version of the service is completely shut down before the new version is deployed.

Running different versions simultaneously can lead to conflicts and inconsistencies due to code changes. The Recreate strategy ensures that only one version is running at any given time, making this approach suitable for applications that prioritize consistency above all else.

The most significant drawback is the lack of a smooth transition between versions, which results in prolonged downtime. During the deployment, users cannot access the system until the new version is fully set up. This is problematic for services requiring high availability.

Blue/Green Deployment

Blue/Green deployment is similar to the Recreate strategy in that only one version is live at a time, but it significantly reduces downtime by fully preparing the new version before making it active.

This strategy involves managing two identical production environments, traditionally named Blue and Green. At any moment, only one environment is active and exposed to client traffic.

Initially, let’s say the Blue environment is active:

When a new version is ready for release, it is deployed to the inactive environment (Green).

Once the new version in the Green environment is thoroughly tested and deemed stable, traffic is routed to it. The Green environment becomes active, and the Blue environment becomes inactive.

If any unexpected issues arise with the new version, traffic can be promptly redirected back to the old version in the Blue environment, minimizing downtime and impact.

This strategy reduces conflicts by operating only one active version at a time. However, unlike Recreate, users continue to access the old version during the deployment of the new one, minimizing downtime. It also allows for rapid rollback if errors occur.

The main disadvantage is cost. Maintaining two full production environments concurrently can double infrastructure costs.

Rolling Update

Instead of shutting down everything simultaneously, Rolling Update is a strategy that gradually replaces instances of the old version with instances of the new version.

This strategy ensures a smooth transition between versions because it always keeps some instances running to serve traffic. It’s also generally cheaper than Blue/Green because the total number of concurrently available instances is minimized.

There are two primary problems with this approach:

• Rollback Complexity: If the new version has problems, rolling back to the previous version is not immediate. It typically involves another rolling update to revert the changes.

• Inconsistency: During deployment, some users might be routed to instances running the old version, while others are routed to instances running the new version. This can lead to inconsistent user experiences if there are breaking changes or significant differences between versions.

Canary Deployment

Canary deployment is a strategy that offers finer control over the deployment process. The new version is deployed experimentally to a small subset of users, known as the Canary Group.

For example, we route 10% of traffic from the canary group to the new version.

Performance metrics, errors, and user feedback from the canary group are closely monitored. If everything works well and the new version is stable, the canary group is gradually expanded, and an increasing percentage of traffic is routed to the new version.

This strategy is particularly valuable when releasing new features incrementally or when the new version carries a higher risk. It allows teams to collect early user feedback and detect unexpected issues with minimal impact.

Additionally, if the new version proves problematic, it’s relatively quick and easy to roll back by routing all traffic back to the old version.

However, canary deployments add the complexity of splitting traffic and maintaining multiple versions, at least temporarily.