Deployment Strategies, SLOs, and DevOps
Blue-Green Deployment
Two identical, fully-provisioned environments run in parallel. At any moment, one serves 100% of production traffic. The other is idle or running tests.
- Blue runs the current version, serving all users.
- Green receives the new version. Engineers run final smoke tests against it.
- The load balancer switches all traffic from Blue to Green in a single operation.
Benefits: instant rollback — if the new version is broken, switch back to Blue. Zero downtime; no request is ever served by two different versions simultaneously.
Drawback: requires double the infrastructure (two full environments), which is expensive for large systems. Not ideal for a high-risk change (e.g. a database migration) because 100% of users are immediately exposed to any defect.
Canary Deployment
Deploy the new version to a small subset of servers or users (e.g. 5%). Monitor error rates, latency, and business metrics. If the canary is healthy, progressively expand to 25%, 50%, 100%. If errors spike — auto-rollback to the previous version for all users on the old version.
Better than Blue-Green for high-risk changes (database migrations, framework upgrades, algorithm changes) because the “blast radius” of an unforeseen issue is limited to the canary group. If 5% of users experience a crash, you have a problem — but 95% of users are unaffected while you diagnose.
Exam trap: do not confuse Canary (technical health — error rate, latency) with A/B Testing (business/product value — does a red “Buy” button increase sales vs a blue control?). They are distinct concepts.
Feature Flags (Toggles) and Progressive Delivery
Deployment (moving code to production servers) is decoupled from Release (making the feature visible to users). New code sits behind an if statement controlled by a database flag:
if (featureFlag.isEnabled("new_checkout_flow", user.id)) {
newCheckout();
} else {
oldCheckout();
}This enables:
- Gradual rollout: turn on for developers → beta testers → 10% of users → everyone.
- Emergency shutoff: flip the flag to OFF in the database. The feature vanishes instantly without a code rollback or redeployment.
- Progressive Delivery: the combination of Feature Flags and Canary-style monitoring — deploy code, then release it incrementally while measuring health.
SLOs, SLIs, and Error Budgets
These concepts, formalised by Google’s SRE teams, govern the balance between shipping new features and maintaining reliability:
| Term | Definition | Example |
|---|---|---|
| SLI (Service Level Indicator) | The thing you measure. A specific, quantifiable metric. | Request latency, error rate, uptime |
| SLO (Service Level Objective) | The target value for the SLI over a measurement window. | ”99.9% of requests complete within 200 ms over a rolling 30-day window” |
| SLA (Service Level Agreement) | A contractual promise to customers, with financial penalties for breach. | ”If uptime falls below 99.5% in a calendar month, customers receive a 10% credit” |
SLO > SLA. You set your internal SLO more strictly than your contractual SLA so that you have a buffer: the SLO alarm fires and the team fixes the issue before the SLA is breached and the company pays penalties.
The Error Budget
If your SLO is 99.9% uptime, your error budget is 0.1% — roughly 43 minutes of acceptable downtime per month.
The error budget is a release throttle:
- If the budget has remaining capacity, the team may ship risky features and experiments.
- If the budget is exhausted (too many incidents this month), all feature releases freeze. The entire team redirects effort to reliability work until the error rate stabilises.
This replaces the toxic dynamic of “Operations wants stability, Development wants velocity” with a single, shared, objective number. Both teams want the error budget to be just right — not zero (which would mean no innovation), not exceeded (which would mean unreliable service).
What Is DevOps?
Historically, Developers and Operations were siloed with opposing incentives:
- Dev: rewarded for shipping features. More deployments = success.
- Ops: rewarded for stability and uptime. Fewer deployments = fewer incidents.
The result: Dev threw code “over the wall” to Ops, who then struggled to deploy and maintain code they did not write, while Ops’ resistance to change frustrated Dev. This was a structural conflict, not a personality clash.
DevOps (Patrick Debois, 2009, first “DevOpsDays” conference in Ghent) is the cultural and technical movement to merge these teams: “You build it, you run it.” Whoever writes a feature is also responsible for its production stability, its monitoring dashboards, its on-call alerts, and its incident response. This aligns incentives naturally: if you get woken up at 3 a.m. by a bug in your own code, you write more reliable code.
Expected Learning
- Describe Blue-Green deployment and explain why instant full-traffic switch enables instant rollback.
- Describe Canary deployment and explain why it is more appropriate than Blue-Green for a high-risk change.
- Distinguish Canary deployment from A/B testing.
- Explain how Feature Flags decouple deployment from release and enable Progressive Delivery.
- Define SLI, SLO, and Error Budget, and explain how the error budget governs the release process.
- Define DevOps and explain the structural conflict it resolves.
- Explain why “you build it, you run it” aligns incentives.
Past Paper Questions
Example Sheet 2, Question 4 directly asks about Blue-Green vs Canary for a high-risk database migration, the role of Feature Flags in Progressive Delivery, and how the Error Budget limits deployment velocity. The SLO/SLI/error-budget concepts are examinable and may appear in a scenario-based Tripos question.