Rolling Updates: Deploying Code Without Downtime

Why it exists

Deploying new software versions traditionally required taking the application offline, creating a service outage for users. Rolling updates solve this by enabling zero-downtime deployments, ensuring the service remains available throughout the update process.

The mental model

Think of a rolling update like changing the tires on a moving car, one by one. Instead of stopping the car (the service), you replace each old tire (an application instance) with a new one while the car keeps going. The service never stops, though its capacity might be slightly reduced or increased temporarily.

How it works

A controller, like a Kubernetes Deployment, manages the process. When you trigger an update, it creates a new version of your application's configuration. Then, it gradually scales up the new version while scaling down the old one. For example, it might add one new instance, wait for it to pass its health checks and report "ready," and only then terminate one old instance. This cycle repeats until all old instances are replaced. You can control the speed and resource overhead using two key settings: maxSurge, which allows a certain number of new instances to be created above the desired count, and maxUnavailable, which defines how many old instances can be taken down at once.

When to use it

This is the default and most common deployment strategy for stateless applications, such as web servers, APIs, and microservices. It's ideal when all instances of your application are identical and interchangeable, and when the application can tolerate running a mix of old and new versions temporarily.

When not to use it

Avoid rolling updates when a new code version requires a backwards-incompatible database schema change, as the old and new code versions cannot coexist. It's also not ideal for stateful applications that require careful orchestration or when you need to test a new version on a small subset of traffic first (use a Canary deployment instead). For instant, atomic cutovers, a Blue/Green deployment is a better choice.

One canonical example

In Kubernetes, a Deployment object uses the rolling update strategy by default. If you have a Deployment running 10 pods of my-app:v1 and you update the manifest to use my-app:v2, Kubernetes automatically starts the process. With maxSurge=1 and maxUnavailable=1, it will launch one v2 pod. Once that pod is ready, it will terminate one v1 pod. This continues until all 10 running pods are version v2, all without interrupting service.