Lesson229 words
Minimising downtime
Plan for minimising downtime during deployments
Three mechanisms, three different levels of the stack.
| Mechanism | Level | How it avoids downtime |
|---|---|---|
| Load balancing | Network | Drain connections from an instance before updating it |
| Rolling deployment | Fleet | Update in batches; the rest keep serving |
| Deployment slots + swap | Platform (App Service) | Warm up in staging, then swap — no cold start for users |
Slots and the warm-up
A slot swap is not a copy: the running, already-warmed staging instance becomes production. Because the app is warm before traffic arrives, users never pay the first-request cost that a fresh deployment imposes.
Two details worth carrying:
- Swap is reversible — swap back to roll back, which is what makes slots the practical blue-green implementation on App Service.
- Slot settings are configuration values marked sticky to the slot: they stay put during a swap. Connection strings pointing at staging versus production databases must be slot settings, or a swap sends production traffic at the staging database.
Rolling and maxParallel
yaml
strategy:
rolling:
maxParallel: 2With six VMs and maxParallel: 2, four remain in service at all times. Lower maxParallel means less capacity lost per iteration and a longer deployment — that is the trade-off being tested.
Primary sources