The most delicate moment in an application's life is not when it runs, but when it changes. Every release introduces new code into a system that was working a minute earlier. Stopping everything, replacing the files and restarting is the simplest method, but it forces an outage and leaves few ways out if something goes wrong. There are strategies that reduce both problems, each with its own price.
The starting point: full replacement
In the most basic strategy, also called recreate, you shut down the old version and start the new one. It is acceptable for internal tools or systems with agreed maintenance windows. It has two obvious flaws: for a few seconds or minutes the service does not respond, and if the new version has a problem the whole procedure must be repeated in reverse.
Rolling update
With a rolling update instances are replaced one at a time, or in small groups. If a service runs on four instances, you update one, check that it is healthy, then move on to the next.
Advantages:
- no outage, as long as there are at least two instances and a load balancer;
- no significant extra resources;
- it is the default behavior of many orchestrators, Kubernetes included.
Disadvantages:
- for a while two versions of the application coexist, and they must be compatible with each other and with the database;
- rollback is itself a rolling update, so it is not instant;
- a problem that only shows up under load can hit everyone before it is noticed.
Blue-green
In a blue-green deployment there are two identical production environments. One, let's call it blue, serves traffic. The new version is installed on the other, green, where it can be checked calmly. When everything is ready, the load balancer or DNS moves traffic from blue to green in one go.
Advantages:
- the switch is practically instant;
- rollback is immediate: just send traffic back to blue, which has stayed untouched;
- the new version can be tested in the real environment before exposing it to users.
Disadvantages:
- it temporarily requires double the resources;
- all users move to the new version at the same moment, so a bug that slipped past the tests hits them all;
- active sessions and long-lived connections need careful handling during the switch.
If the switch happens via DNS, remember that answers stay in caches for the duration of the TTL: some clients will keep reaching the old environment for a while. A load balancer offers much finer control.
Canary
The name comes from the canaries miners once took underground to detect dangerous gases. In a canary release the new version initially receives only a small share of traffic, say five percent. You watch errors, response times and business metrics; if everything is normal you gradually increase the share up to one hundred percent.
Advantages:
- a defect affects only a fraction of users;
- you gather real data on the new version's behavior before extending it;
- rolling back means setting the share back to zero.
Disadvantages:
- it needs solid monitoring, able to compare the two versions, otherwise the canary signals nothing;
- it requires a more sophisticated traffic-routing system;
- as with rolling updates, two versions coexist for a long time.
Quick comparison
| Strategy | Outage | Extra resources | Rollback speed | Risk exposure |
|---|---|---|---|---|
| Recreate | Yes | No | Slow | All users |
| Rolling update | No | Minimal | Medium | Growing |
| Blue-green | No | Double, temporary | Immediate | Everyone, but reversible |
| Canary | No | Limited | Fast | A small share |
The real problem: the database
Any strategy without an outage means that, at least for a few moments, the old and new versions access the same database. If the new version renames a column, the old one stops working.
The solution is to split schema changes into several compatible releases, following the pattern known as expand and contract:
- add the new column without removing the old one;
- release code that writes to both and reads from the new one;
- copy the existing data;
- when no instance uses the old column any longer, drop it in a later release.
It is slower, but every step is reversible and no version ever faces a schema it doesn't know.
Feature flags: separating release from activation
A useful complement to all strategies is feature flags, switches in the code that turn a feature on without a new deployment. The code reaches production switched off, is turned on for a few users or internal staff and, if it causes problems, is switched off in an instant. Flags must be removed once they are no longer needed, though, otherwise the code fills up with dead branches that are hard to maintain.
In short
- Full replacement is simple but means an outage and a slow rollback.
- A rolling update replaces instances one at a time and is the default choice of many orchestrators.
- Blue-green needs double resources but allows an immediate rollback.
- Canary limits the impact of defects, provided monitoring is effective.
- Database changes must be made compatible across versions with the expand-and-contract approach.
