The utility that arrived late
Electricity was, for a while, something a factory made for itself. Each mill kept its own generator, its own engineer, its own reserve of coal. Then the grid arrived, and the question stopped being how much generating capacity do we own and became how much power did we draw last month. Nobody misses the generator.
Computing took an extra century to make the same move. Until recently, running an application meant buying physical servers, racking them in a room with expensive cooling, and guessing — eighteen months in advance — how much capacity you would need. Guess low and the site collapses on the busiest day of the year. Guess high and money sits in a closet, depreciating quietly.1
Cloud computing is the grid. A provider — Microsoft Azure, in this manual — owns the buildings, the machines, and the fibre. You draw what you need, when you need it, and stop paying when you stop drawing.
- Definition
- Cloud computing is the on-demand delivery of computing resources over the internet, metered and billed by consumption.
Three clauses, all load-bearing. On-demand means you provision it yourself, in minutes, without asking anyone. Over the internet means it is reachable from wherever the work is. Metered means the invoice reflects usage, not intention. Remove any one of them and you have something else — a hosting contract, a leased rack, a colocation facility. Not cloud.
| Before | After |
|---|---|
| Servers purchased months in advance | A server exists in ninety seconds |
| Paid for in full whether idle or not | Paid for while running |
| Capacity is a forecast | Capacity follows demand |
| Your staff replace failed disks | Someone else replaces failed disks |
| One room, one failure domain | Regions, zones, deliberate redundancy |
Where the line falls
Here is the idea most often misunderstood, and the one most reliably asked about in an interview. Moving to the cloud does not hand your problems to Microsoft. It relocates the line between their responsibility and yours — and the position of that line is the single most consequential fact in your working life.
The provider is not breached. You are.
Read that as arithmetic rather than rhetoric. Microsoft's datacentres are guarded, audited, and redundant to a standard almost no enterprise could self-fund. What fails, over and over, is the layer above the line: a storage container left open to the internet, a service account granted Owner because it was quicker, a key committed to a public repository at eleven at night.2
Which is inconvenient for the sales brochure and excellent for you. The half of the model the provider will never take is precisely the half you are paid to hold. Every class after this one is, in some sense, about defending that line.
Five properties, and the ones that are missing
The formal definition — the one that survives contact with an examiner — lists five characteristics.3 Learn them, because they distinguish cloud from a rented server pretending to be one.
- On-demand self-service
- You provision through a portal or an API. No ticket, no procurement, no waiting on a hardware team.
- Broad network access
- The resource is reachable over the network from wherever it needs to be reached.
- Resource pooling
- Many customers are served from shared physical hardware, isolated from one another.
- Rapid elasticity
- Capacity expands and — this is the part people forget — contracts, automatically, with demand.
- Measured service
- Consumption is metered by the second, the gigabyte, the transaction. Metering is what makes the rest billable.
Note what is not on the list. Not "cheaper." Not "always available." Not "secure by default." Those are outcomes you may or may not earn, depending on how well you do the job described in the previous section. A cloud is a set of properties, not a set of promises.
The accounting argument
Migrations are approved in finance meetings, not engineering standups. It pays to speak the language.
- CapEx
- Capital expenditure. A large purchase, made once, depreciating across years. Servers in a room. On-premises IT.
- OpEx
- Operational expenditure. An ongoing cost, paid as incurred, like the electricity bill. Cloud.
The move from one to the other is why a company with no capital can launch on Monday, and why an enterprise can stop paying rent on capacity nobody is using. It is a genuinely good argument.
It also has a sharp edge, and you should be the person who names it before the invoice does: pay-as-you-go is pay-for-what-you-forget. A virtual machine nobody remembers provisioning bills at three in the morning on a public holiday. An oversized database sized "to be safe" is safe in precisely one direction. Cost discipline is not a finance afterthought bolted on in Class Thirty-Two — it is an engineering property of the systems you build, and it starts at the first resource you create.
The company you are about to join
Campux Retail
Every November their site slows to a crawl under holiday traffic. Every January those same two machines idle at eighty percent unused, billing full price in electricity, floor space, and the salary of the person who babysits them. Last month a disk failed and the storefront was dark for nine hours.
Leadership has approved a move to Azure. You have been hired as their first cloud engineer. Over the following thirty-five classes you will design their identity model, their network, their delivery pipelines, their monitoring, and — eventually — their first AI feature. Every drill and every build in this manual concerns them.
Hold their shape in mind: a sharp seasonal peak, a long idle trough, and a failure that cost real money. Almost everything in §3 and §4 was written for a company that looks exactly like this one.
Turning a buzzword into a balance sheet
A founder catches you by the coffee machine: "Remind me why we pay Azure instead of buying servers?" You do not hand-wave. You walk her along the shared-responsibility line — what Microsoft runs, what you run — and name the two costs that vanished the day you left the server closet: the capital up front, and the Saturday someone used to spend swapping a dead drive. She nods. You just turned a buzzword into a balance sheet.
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. All three clauses must hold — on-demand, over the internet, metered. A and C put someone else's hardware in the picture but neither is self-service nor metered. D outsources the people, not the infrastructure. The distinction is not pedantry: an examiner and an interviewer both use it to find out whether you memorised a phrase or understood a model.
C. Look again at Figure 1 — the line moves, but never above data and identity. A, B and D sit permanently below it. This is why "we moved to the cloud, so security is handled" is not merely wrong but expensively wrong.
Elasticity, measured service, self-service. Free tiers are bounded by design, and no provider guarantees uninterrupted availability — service agreements are written in nines, never in certainties, and you will spend Phase Two learning to architect around the gap between them.
MEMORANDUM — Cloud migration, executive summary
1. Cloud shifts our spend from CapEx to OpEx.
2. Capacity scales automatically for the November peak.
3. Once we migrate, the provider secures our data and user accounts.
4. Pay-per-use means the January trough stops costing full price.
Line three. Lines one, two and four describe OpEx, elasticity and metering correctly. Line three hands the top of the stack to Microsoft, and Microsoft has not agreed to take it.
Consider the consequence rather than the error. Had that memorandum reached the board unchallenged, the security budget would have been written as zero, and the first breach would have been traced to a decision made in a slide nobody read closely. Catching this line is the job.
A strong answer concedes before it argues. He is not wrong that steady, predictable workloads can be cheaper on owned hardware — say so first, and you have his attention rather than his defences.
Then move to his numbers, not yours. The sticker price of a server omits power, cooling, floor space, the disk that failed last month, the nine hours the storefront was dark, and the salary of whoever spent those nine hours fixing it. And owned capacity must be bought for the November peak, then paid for through the January trough. Campux has the sharpest possible seasonal shape — the exact profile that consumption pricing rewards and ownership punishes.
The move that lands is arithmetic in his own units: nine hours of downtime, priced. That is a conversation about money, which is a conversation he wants to have.
The trap is the premise. Cloud was never supposed to be cheaper. It was supposed to be metered. Accept the premise and you spend the next month apologising for a property of the model.
Diagnosis, in order: open Cost Analysis and group by resource, then by tag if anyone bothered to apply them. Look for the four usual findings — machines running through nights and weekends nobody needed, sizes chosen "to be safe," premium storage under test data, and the orphans: disks, addresses and snapshots outliving the resources they belonged to.
The sentence: "Cloud is cheaper when we run it like a utility rather than a purchase — give me a day and I will show you exactly which meters we left running." You are formalising that instinct into budgets, alerts and tags in Class Thirty-Two.
Five things that will still be true in ten years
- Cloud is on-demand, networked, and metered. All three, or it is something else wearing the name.
- Responsibility is shared, and the line never rises above your data and your identities.
- Five properties: self-service, broad access, pooling, elasticity, measurement. Cheapness is not among them.
- CapEx became OpEx. The invoice now reflects what you forgot as faithfully as what you use.
- The provider is rarely breached. Configurations are. That asymmetry is your entire profession.
- The eighteen-month figure is a convention, not a law — procurement, racking and burn-in simply take longer than anyone plans for. The point survives at six months. ↩
- Industry breach analyses have converged on the same finding for the better part of a decade: the dominant failure mode in public cloud is customer misconfiguration, not provider compromise. Treat the specific percentages you see quoted with suspicion; treat the direction as settled. ↩
- The five characteristics originate in NIST Special Publication 800-145, which remains the definition examiners reach for. It is barely three pages of substance and worth the twenty minutes. ↩