What is a rolling deployment strategy and what are its trade-offs?

A rolling deployment is where component compute nodes are updated sequentially. This can follow a canary deploy where a very small number of nodes are updated first.

As two versions of code are deployed at the same time, this can give challenges for dependencies such as database schema changes, where the whole stack must support having multiple code versions running at the same time.

Sequential updates also mean a long deployment window, that can be longer with the more nodes you have. This should be mitigated by updating multiple nodes at once.

High availability is maintained during the deployment. As there are lots of nodes available to serve traffic, a very small number of nodes are offline whilst being updated.

Rollback is difficult. If a rollback is required, the current rolling deployment must be stopped and another one triggered to revert to the previous version. This means due to the length of time for a sequential update/revert, the errors will persist until the rollback is complete. Mitigation involves a blue-green hybrid deploy for quick revert. Old nodes are kept in a separate pool until the deployment is complete.

A common configuration caps the change to one node at a time (Kubernetes' maxSurge: 1 / maxUnavailable: 0 is the equivalent default idea) — slower than updating everything at once, but capacity never dips and only one node is ever running the new version while the rest catch up.