Zero-downtime deployments with service mesh

You can use service splitters to implement zero-downtime deployments. These components, often used in service mesh architectures, allow traffic to route between different versions of an application dynamically.

Service splitters dynamically route traffic between different application versions. They allow you to gradually shift traffic from the old version to the new version, allowing you to rollback if issues arise. This approach combines the benefits of canary and blue/green strategies while maintaining continuous availability.

How to implement service splitters with Consul

You can use Consul to help make traffic splitting decisions. Consul proxy metrics gives you detailed health and performance information about your service mesh applications. This includes upstream/downstream network traffic metrics, ingress/egress request details, error rates, and additional performance information that you can use to understand your distributed applications.

With blue/green deployments, you can configure a service splitter to initially direct all traffic to your application's "blue" (current) version. When you are ready to deploy the "green" (new) version, you can gradually adjust the splitter to shift traffic from blue to green.

You can use Consul to manage traffic for zero downtime deployments using the following steps:

First, you register your service’s blue and green versions with Consul and configure health checks to monitor the availability and health of each service instance. Once the instances are healthy, you can deploy your new version to the green stack, ensure it passes Consul's health checks, and then update traffic splitting or routing rules to shift traffic from the blue to the green service gradually.

Since your green service is now receiving traffic, you should monitor the health and performance of both versions. If issues arise, you can roll back the traffic to your blue service. Once all health and performance checks pass, you can decommission the blue service to complete your blue/green deployment.

With canary deployments, you can release new software gradually, and identify and reduce the potential blast radius of a failed software release. You first route a small fraction of the service to the new version. Similar to blue/green deployments, this can be done with a service splitter. When you confirm no errors, you slowly increase traffic to the new service until you fully promote the new environment.

Amazon EKS and Azure Kubernetes Service can use Consul service mesh to observe traffic within your service mesh. This observability enables you to quickly understand how services interact with each other and effectively debug your services' traffic.

HashiCorp resources:

• Deploy seamless canary deployments with service splitters tutorial
• Register your services to Consul tutorial
• Monitor your application health with distributed checks tutorial
• Observe Consul service mesh traffic tutorial
• Monitor application health and performance with Consul proxy metrics tutorial
• Service splitting documentation

Next steps

In this section of Zero-downtime deployments, you learned how to use service mesh to deploy with zero-downtime. Zero-downtime deployments is part of the Define and automate processes pillar.