The case, stated honestly
A purchase order for a server is a promise about a future you cannot see. Someone signs it in the spring for capacity that arrives in the autumn, sized against a forecast written in the winter. By the time the machine is racked, cabled and burned in, the demand that justified it has either failed to appear or outgrown it. The lag between deciding and having was, for most of computing's history, measured in fiscal quarters.
Cloud collapses that lag to minutes, and this — not the invoice — is the real reason companies move. The pitch to the board leans on cost because cost fits on a slide. But the engineers who have lived through both worlds will tell you the thing that changed their working lives was speed: the ability to try an idea on Tuesday instead of budgeting for it next quarter.
- Time to value
- The interval between deciding to build something and having it serve a real user. Cloud attacks this number harder than it attacks any other.
Consider what a shorter interval actually buys. A feature that used to require a hardware requisition now requires a command. An experiment that would have needed a capital case can be stood up, measured, and — this is the part that matters — torn down again the same afternoon if it fails. Cheap failure is the quiet engine of everything cloud is credited with. You are not paying for servers; you are paying to be wrong faster and less expensively than a competitor who still buys hardware.
Cost matters too, and §2 will price it precisely. But if you walk into an interview and say the reason for cloud is that it is cheaper, a good interviewer will spend the next ten minutes showing you a bill where it was not. Say instead that it trades a slow, capital-heavy guess for a fast, metered adjustment — and that the speed is what pays for itself. That answer survives contact with reality.
Elasticity, with the arithmetic shown
Elasticity is the property that capacity follows demand in both directions — up for the peak, and — the half that pays for itself — back down for the trough. Owned hardware cannot do the second half. You buy for the busiest hour of the year and you pay for it through every quiet one. Campux Retail is the textbook shape: a November that needs everything, a January that needs almost nothing.
Numbers make it concrete. Take a unit of production compute costing roughly $150 a month to run continuously.1 Suppose the storefront needs three units to serve an ordinary month, but ten units to survive the November peak without collapsing. There are two ways to hold that capacity.
| Approach | What runs | Twelve-month cost |
|---|---|---|
| Provision for the peak | 10 units, every month, all year | 10 × $150 × 12 = $18,000 |
| Scale with demand | 3 units for eleven months, 10 for November | (3 × $150 × 11) + (10 × $150) = $6,450 |
| The difference | The seven units nobody used for eleven months | $11,550 — about 64% |
The provision-for-the-peak row is what owned hardware forces on you, and it is also what a careless cloud deployment reproduces exactly — a fixed fleet sized "to be safe," billing around the clock. The savings do not come from the word "cloud." They come from the second row actually happening: from something scaling down when the traffic leaves.
Elasticity you never configure is a discount you never take.
This is the first place your job appears in this class. Autoscaling is not a checkbox that ships enabled; it is a design decision, a set of rules, and a test you run before November rather than during it. The $11,550 in the table is not a feature Microsoft grants. It is a thing you build, and it is precisely the kind of result that reads well on a résumé because it reads well on an invoice.
Reliability, and the arithmetic of nines
Availability is sold in nines, and the nines are seductive because each one looks like a small step. It is not. Every nine you add cuts the permitted downtime by a factor of ten, and the vocabulary that describes this is something you will be expected to speak fluently.
- SLA
- A Service Level Agreement: the provider's stated commitment to availability, and the schedule of bill credits owed to you if they miss it.2
Read that definition twice, because the second clause is the one people miss. An SLA is not a promise that the service stays up. It is a promise that if the service falls below a stated percentage, the provider refunds a slice of what you paid them — never a cent of what the outage cost you. It is a design input, not an insurance policy.
The nines translate directly into minutes. Against a thirty-day month of 43,200 minutes:
| Stated SLA | Allowed downtime / month | Where you meet it on Azure |
|---|---|---|
| 99% | ≈ 7 h 12 min | Little you would run on purpose |
| 99.9% ("three nines") | ≈ 43 min | Single VM on Premium SSD |
| 99.95% | ≈ 22 min | Multiple VMs in an availability set |
| 99.99% ("four nines") | ≈ 4 min | Multiple VMs across availability zones |
Figure 2 draws the same fact as a ruler, because a table lets you read the numbers while a ruler makes you feel them: the distance between three nines and four nines is smaller than most people picture, and the distance between any of them and a real outage is larger.
Now the part that separates people who quote SLAs from people who can be trusted with one. Real systems are not a single service; they are a chain of them. A request to the storefront might pass through Front Door, an App Service, a SQL database and a storage account — and it only succeeds if all four are up at that instant. When services depend on one another in series, their availabilities multiply.
- Composite SLA
- The effective availability of a system built from dependent services, found by multiplying their individual SLAs. It is always lower than the weakest component, never higher.
Put the storefront's four services through the arithmetic — 0.9999 × 0.9995 × 0.9999 × 0.999 — and the product is about 0.9983, or 99.83%.3 That is roughly 73 minutes of expected downtime a month: worse than every component in the chain, including the storage account you thought was your weak link at 99.9%. Nobody promised you a worse number. The dependencies did it on their own.
Every dependency you add subtracts a nine.
This is why serious architectures reduce the number of things in the critical path, add redundancy to the components that must be there, and treat a vendor's headline nine as the ceiling of a single brick rather than the strength of the wall. When leadership reads "99.99%" on a datasheet and relaxes, your job is to do the multiplication they didn't.
When the answer is no
A cloud engineer who can only argue for the cloud is a salesperson with a certificate. The credible ones know the three places the honest answer is "not this, not yet," and can say so without flinching. Leadership tends to raise them in this order.
- Compliance & residency
- Some data is bound by law or contract to live in a particular country, under a particular custody, sometimes on hardware you can point to. The cloud has answers — sovereign regions, residency guarantees — but they are answers you must design for deliberately, not assume.
- Latency & physics
- Light is not negotiable. A factory sensor that must react in a millisecond cannot wait for a round trip to a region three hundred kilometres away. Some workloads belong at the edge or on-premises because the speed of light says so, and no SLA overrules it.
- Sunk cost
- A company that bought a datacentre eighteen months ago is depreciating it for years yet. Moving today means paying twice — once for the idle asset, once for the cloud. Often the correct engineering answer is "at the next refresh," and saying so earns more trust than a migration that bleeds money to prove a point.
Note that only one of these three is technical. Compliance is a legal fact and sunk cost is an accounting one, and you will meet both far more often than you meet a workload that is genuinely impossible to move. The skill is not knowing that the cloud is powerful. It is knowing where its power stops being the point.
The number the CFO could not argue with
In Class One, Campux Retail's finance director stopped you in a corridor with a five-year sum that made owning servers look cheap. He was not being unreasonable; he was being incomplete. This class is where you go back to him — not with a rebuttal, but with his own figures finished.
What changed his mind
You did not argue that cloud is cheaper. You took his five-year comparison and added the rows he had left out. First, the peak: his owned figure had to buy ten units of capacity for a November that lasts one month, then carry them through eleven months of January-shaped quiet — the $11,550 of idle iron from Table 1, every year. Second, the outage: nine hours dark, priced in lost carts at the one hour of the year the store cannot afford to be dark, a number he had never put on the sheet because it lived in the operations report, not the finance one.
Then you gave him the honest half. You showed him the composite-SLA arithmetic and told him plainly that moving would not make the storefront invincible — that four services in a chain land near 99.83%, and that buying it back up would cost real design effort you would bill for. You conceded the sunk cost on last year's hardware and recommended the migration finish at its refresh, not before.
He signed. Not because you won the argument, but because you had clearly already made it against yourself and it survived. His words, more or less: "You're the first person who put the downtime on the same page as the servers." That sentence is the job. Speak finance's language, show your own workings, and concede what is true, and the technically correct answer becomes the one leadership chooses on its own.
The launch that did not fall over
Marketing greenlights a campaign that could bring ten times the traffic for one weekend, then drop back to nothing. On-premises, that is a procurement meeting and a rack of servers idle by Tuesday. You size for the spike, set it to scale back down on Monday, and pay for the weekend rather than the quarter. Elasticity stops being a slide and becomes the reason the launch neither fell over nor bankrupted anyone.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
B. Speed — time to value — is the driver that holds up under scrutiny. A is the boardroom pitch and it fails against any real bill; C contradicts everything in Class One; D is contradicted by the very existence of SLAs, which exist precisely because services go down. If you reach for cost first in an interview, you have handed the interviewer the counter-example; reach for speed and cheap failure, and you sound like someone who has run a workload rather than read a brochure.
B. Three nines against a 43,200-minute month is about 43 minutes; four nines is the 4-minute figure in A, and 99.95% is the 22 minutes in C. But the sharper half of the question is the remedy: an SLA breach earns you a service credit — a slice of that service's bill — and never the business you lost. Confuse the two in front of leadership and you will promise a refund that isn't coming. The percentage is a design input; the credit is small change; the lost revenue is yours to prevent.
Elasticity, faster time to value, the CapEx-to-OpEx shift. Those three are structural properties of the model. The other two are the traps: cloud is only cheaper when run like a utility rather than a purchase, and security stays firmly above the line you drew in Class One. Notice that the two wrong answers are the two most likely to appear on a vendor's homepage — the marketing benefits are exactly the ones a real invoice or a real breach will disprove.
AVAILABILITY ESTIMATE — storefront, request path
1. Front Door 99.99% (global entry)
2. App Service 99.95% (web tier)
3. Azure SQL Database 99.99% (baseline SLA)
4. End-to-end, since every tier is at least 99.9%,
the storefront is 99.9% available (~43 min/month).
Line four. The component figures are right; the reasoning is not. Dependent services multiply, they do not default to the weakest number — 0.9999 × 0.9995 × 0.9999 works out to about 99.93%, and that is before you add the storage account and the rest of the chain, which drag it toward 99.83% and roughly 73 minutes a month.
Consider the consequence. Had this estimate gone to leadership as written, someone would have promised the business 43 minutes of risk and delivered nearly double it, and the gap would surface as a missed target in the worst week of the year. Catching that one word — "since every tier is at least" — is the difference between an estimate and a liability.
A strong case leads with speed and closes with a number. Open on time to value, not cost: the company can ship and test ideas in the time it currently takes to raise a purchase order, and kill the failures cheaply. That is the shareholder story — faster response to the market — and it is the true one.
Then earn trust by naming the limits before anyone asks. Say that cloud is not automatically cheaper, that it saves money only if capacity actually scales down, and that reliability is something you architect rather than buy. A board has heard the unlimited-upside pitch before and discounts it; the person who lists the caveats is the person they believe on everything else.
Land it on Campux's own arithmetic: eleven months a year they would stop paying for seven units of idle capacity — around $11,550 — and the nine-hour outage becomes a problem you design against rather than survive. One page, one honest argument, one number in their units.
The trap is treating a component SLA as a system SLA. 99.99% is the guarantee for one well-configured tier of compute. The storefront is not one tier; it is a chain — entry, web, database, storage — and a request fails if any link does. The director has quoted the strength of a single brick as the strength of the wall.
Correct the maths, not the person. Agree first: the zonal figure is real and worth having. Then show the multiplication on the whiteboard — four dependent nines-something services land near 99.83%, roughly 73 minutes a month, not four. Make it the arithmetic's fault, not theirs; the number is genuinely counter-intuitive the first time you meet it.
Then turn it into a plan. The composite figure is not a reason to despair; it is a map of where to spend. Reduce what sits in the critical path, add redundancy to the components that must be there, and quote leadership a system number you can actually defend. That is the difference between reciting an SLA and owning one.
Five things worth carrying out of this class
- The real driver is speed, not cost. Time to value, and the ability to fail cheaply, is what pays for the move.
- Elasticity is a discount you build, not one you are given. Capacity that never scales down is owned hardware with a cloud logo.
- An SLA is a bill-credit scheme, not insurance. It refunds a slice of your spend, never the revenue an outage cost you.
- Each nine costs ten times less downtime than the last — and dependent services multiply, so a chain is always below its weakest link.
- Knowing when the answer is "no" — compliance, latency, sunk cost — is what separates an engineer from a salesperson.
- The $150 unit and the three-versus-ten split are illustrative, chosen to make the arithmetic legible; real prices depend on VM family, region and commitment, and change often. Treat the specific dollars with suspicion and the direction — idle capacity is pure waste — as settled. ↩
- Azure's published VM figures at the time of writing: 99.9% for a single instance on Premium SSD or Ultra Disk, 99.95% for multiple instances in an availability set, and 99.99% for multiple instances spread across availability zones. Providers revise SLAs; always read the current service-level agreement for the exact service and tier before you quote a number to anyone who will act on it. ↩
- The composite figures assume the services sit in series — every one required for a request to succeed. Redundancy changes the arithmetic in your favour: parallel paths multiply their small failure probabilities together instead of their availabilities — two independent 99.9% paths fail together only 0.1% of 0.1% of the time — and that is the whole reason to build them. Class Thirteen returns to this when it puts real load balancers in front of the storefront. ↩