Zero-downtime application deployments

Application changes can use blue/green, canary, rolling, or a combination of the three. Your deployment method depends on whether you use virtual machines or containers, along with the criticality of your application. In the following sections, you will learn how these deployment strategies work with load balancers, non-containerized applications, and containerized applications.

Load balancers and proxies

Load balancers and reverse proxies can manage your application by directing traffic between your blue and green environments. They can then direct a subset of users for canary deployments and testing and control traffic for rolling deployments.

Load balancers and proxies route traffic between application environments during updates. They support blue-green deployments and canary releases, allowing you to gradually shift users to new versions while maintaining the ability to roll back if issues occur. By continuously monitoring application health and automatically routing around failed instances, they increase service availability throughout the deployment process.

Regardless of your cloud provider, you can use Terraform to manage the deployment and control of load balancers and proxies. Using Terraform for IaC allows you to version control your load balancer configurations alongside your application code, ensuring that changes are tracked, reviewed, and rolled back if needed. You can define target groups, health check parameters, routing rules, and SSL certificates declaratively, then apply these configurations automatically as part of your CI/CD pipeline.

HashiCorp resources:

Read the use Application Load Balancers for blue-green and canary deployments tutorial.

External resources:

Non-containerized applications

Using a blue/green or rolling deployment is a good approach if you are deploying applications on virtual machines. Blue/green deployments limit downtime and reduce risk by maintaining two identical production environments - one live, one idle. You deploy to the idle environment, test thoroughly, then switch traffic over. If problems occur, you can roll back immediately by switching traffic back.

For high-impact applications, we advise incorporating canary testing into your blue/green deployment strategy. This testing method allows you to validate your new version before fully transitioning your traffic, ensuring a stable and desired user experience.

The following is an example of canary testing your green environment:

After the green environment is ready, the load balancer sends a small fraction of the traffic to the green environment (in this example, 10%).

Canary test/deployment. All traffic is directed to the blue environment initially. When you perform a canary test, 10% of the traffic is directed to the green environment.

If the canary test succeeds without errors, you can incrementally direct traffic to the green environment (50/50 — split traffic) over time. In the end state, you redirect all traffic to the green environment. After verifying the new deployment, you can destroy the old blue environment. The green environment is now your current production service.

Rolling deployment. After the initial canary test, traffic to the green environment is split evenly with the blue environment (50/50). Finally, all traffic is directed to the green environment.

Containerized applications

Containers can use rolling, blue/green, and canary deployments, through orchestration tools like Nomad and Kubernetes.

Blue/green, rolling, and canary deployments each lowers downtime risk.

Blue/green deployments provide instant rollback capability by maintaining two identical environments and switching traffic between them, ensuring zero downtime but requiring double the resources.
Rolling deployments gradually replace instances one by one, minimizing resource usage while maintaining availability, making them efficient for resource-constrained environments.
Canary deployments mitigate risk by releasing to a small subset of users first, allowing you to validate changes and catch issues before full rollout.

Rolling deployments are a popular strategy for deploying applications using orchestration systems. With rolling deployments, the orchestrator gradually replaces old instances with new ones. Once the new instances are available and pass health checks, the orchestrator can direct traffic to the new instances and then destroy the old instances.

Nomad supports rolling updates as a first-class feature. To enable rolling updates, you can annotate a job or task group with a high-level description of the update strategy using the update block.

By default, Kubernetes uses rolling updates. Kubernetes does this by incrementally replacing current pods with new ones. The new Pods are scheduled on Nodes with available resources, and Kubernetes waits for those new Pods to start before removing the old Pods.

As described in infrastructure-changes, both Nomad and Kubernetes support blue/green deployments. Before sending all your traffic to your new cluster, you can use canary testing to ensure the new cluster is working as intended.

HashiCorp resources:

Learn how to use blue/green deployments with the Nomad blue/green and canary deployments tutorial.
To learn about Nomad rolling updates, refer to the Nomad's Rolling updates tutorial.
Learn about Nomad's update block. The update strategy is used to control things like rolling upgrades and canary deployments.

External resources:

Kubernetes - Performing a rolling update

Next steps

In this section of Zero-downtime deployments, you learned about methods to deploy application changes with zero-downtime. Zero-downtime deployments is part of the Define and automate processes pillar.