Where the line falls: the hand-drawn split between the gear you own and the gear you rent, and the five properties that make something genuinely "cloud."
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.
The switch was not really about technology; the generators worked. It was about economics. A shared grid could build at a scale no single mill could justify, run its plant closer to full, and sell the same capacity many times over as demand rose and fell across a whole city. The owner who clung to his own generator was not wrong that he owned it outright — he was wrong that owning it was the point. Every argument in this class is a version of that one, moved a century forward.
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 bootcamp — 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.
It helps to name the near-misses, because an exam and an interview both probe them. A rented physical server delivered to your building is not cloud — it is self-service in neither direction and metered by the month, not the minute. A colocation cage, where you own the machines and the provider owns the room, is not cloud either; you still bought the hardware and still carry the peak. Even a single virtual machine you rent by the hour is only the shallowest edge of it — virtualization, the trick of running many pretend computers on one real machine, is the enabling technology, but on its own it is one property standing in for five. Cloud is the whole set operating together, which is why "we virtualized our servers" and "we moved to the cloud" are different sentences describing different amounts of work.
| Before | After |
|---|---|
| Servers purchased months in advance | A server exists in minutes |
| 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 |
The closet, itemised
"Two servers in a closet" is a tidy phrase that hides a long invoice. Owning a machine meant owning everything beneath it. Someone specified it months ahead and signed a capital purchase order. Someone racked it, cabled it, and burned it in. Something kept the room cold enough that the processors did not throttle, and something else kept the power clean when the grid flickered at four in the morning. A person carried a pager so that the night a disk failed — and disks fail — they could drive in and swap it. None of that appeared in the price of the server; all of it was the cost of the server.
This is the stack the cloud actually rents you out of. Not just the processor and the disk, but the building, the cooling, the power, the physical security, the spare parts, and the labour that turns a box into a running service. When people say Azure "runs the hardware," this whole column is what they mean — and §4 puts a shape to who now pays for each layer of it.
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 — Microsoft calls this the shared responsibility model, 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.
Make it concrete with the kind of mistake that actually happens. Campux moves its product images to cloud storage and, to make the site "just work," someone sets the container to public. Nothing breaks; the page loads; the ticket closes. Months later a researcher finds the same container also holds the nightly database export, and now every customer record is a public URL. Azure did exactly what it promised — it served the file it was told to make public. The datacentre was never breached. A checkbox above the line was, by a person in a hurry. That is the whole model in one incident, and it is why the classes ahead spend so long on identity, access, and the discipline of least privilege.
The vocabulary worth carrying out of this section is the pair the figure labels on its left edge: security of the cloud and security in the cloud. Everything below the line — the datacentre, the hardware, the hypervisor (the software that splits one physical server into many isolated virtual machines) — is security of the cloud, and it is Microsoft's to guarantee. Everything above it — your data, your accounts, your configuration — is security in the cloud, and it is yours no matter which service you buy. The line's exact height changes with the service model, and Class Four will move it three times as it walks through infrastructure, platform and software services. What never changes is which side of it your name is on.
Hold on to why this is a career fact and not a compliance footnote. A provider competes by making its own half unimpeachable; that is table stakes, and it is largely solved. The market's unmet need — the thing companies cannot buy off a shelf and therefore hire for — is someone who can hold the customer's half well. Every certification you will earn in this bootcamp is, underneath, a certificate that you can be trusted above the 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.
The five, read through Campux's window
Abstractions like these only stick once you watch them touch a real company, so put each against the store you are about to inherit. On-demand self-service is the end of the eighteen-month wait: the November capacity Campux needs becomes a configuration you apply, not a purchase order finance approves in spring. Broad network access is why forty stores and one website reach the same systems over the same network, whether the till is on the shop floor or the shopper is on a sofa. Resource pooling is the uncomfortable, load-bearing truth that Campux's virtual machines share physical hardware with strangers — isolated by the platform, but not alone on the metal, which is exactly why the identity and configuration work in later classes earns its place. Rapid elasticity is the November peak met and the January trough released without anyone driving to a datacentre. And measured service is the meter that turns the other four into a bill — the same meter that will one day charge for the virtual machine nobody remembered to switch off.
Read together, the five are less a checklist than a single machine with Campux-shaped consequences. Take away metering and the elasticity has nothing to bill against; take away self-service and the elasticity waits on a ticket; take away pooling and the provider could never have offered the capacity in the first place. The properties earn their keep as a set, which is why an examiner asks for all five and an interviewer listens for whether you can say why each one is there.
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.
One orientation note, since the exam leans on these distinctions. The five characteristics answer "what makes something a cloud at all." Two further questions sit just behind them, and each gets its own class: what you rent — raw infrastructure, a managed platform, or finished software — is the service-model question of Class Four; and where it runs — public, private, or a hybrid of the two — is the deployment-model question of Class Five. Keep the three apart in your head. An interviewer who asks you to "define cloud" wants these five properties, not a recital of Azure product names.
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.
Figure 4 draws what that shift actually moves. Buying a server was never the cost of a server; it was the cost of the room it sat in, the power that fed it, the cooling that kept it from throttling, the disk you kept in a drawer for the night the running one failed, and the person who drove in to fit it. On-premises, every layer of that stack is a line in your budget and a name on a rota. In the cloud the lower layers become Azure's to own and operate, and yours only to rent by the hour.
Name the categories that leave your books, because a CFO will ask you to itemise them: the capital tied up in hardware bought for a peak; the power and cooling of a room sized for machines that mostly idle; the floor space that room occupies; the maintenance contracts and spare parts; and the fraction of an engineer's week spent on tasks that produce no feature — patching firmware, chasing a fan, swapping a drive at two in the morning. The cloud does not make that work disappear. It moves the work to a provider who does it at a scale you cannot match, and converts your share of it from a capital purchase into a metered line you can switch off.
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.
There is a second move worth previewing, because it is the answer to that sharp edge. Pure pay-as-you-go is the right default for anything spiky or uncertain, but for the baseline you know you will run — the handful of units the storefront needs every month, all year — a provider will sell you that capacity cheaper in exchange for a commitment: reserve it for a year or three and the hourly rate falls sharply. The mature pattern is a blend — commit to the floor, pay on demand for the peak above it — and getting that blend right is much of what Class Thirty-Two means by cost management. For now, carry only the shape of it: metered does not have to mean unplanned.
Play it through
Three minutes on the closet Campux is about to leave behind. Drag November onto a fixed rack, then onto Azure, and watch what each one does to the machines nobody remembered to switch off. It plays on its own and stops when it needs your hands.
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 forty-one 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 bootcamp 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.
Zoom out: the line you drew is now the system's fault-line
You have learned where the provider's responsibility ends and yours begins. Now reason about what that line does to the whole organisation, not just to one server — because a boundary this quiet reshapes who is accountable when things go wrong.
The cloud runs the hardware, so the team stops practising ops — and the skills that would settle an incident quietly atrophy until the night one is needed. What keeps the muscle alive: game-days, runbooks, and owning the half of the model that is yours on purpose?
Your uptime now rides on a provider's region, network, and pricing — dependencies you never had with a server in a closet. Map what fails if they have a bad day, and be clear which half of that failure is still yours to answer for.
The reliability ceiling of the whole system is the weaker half of the shared-responsibility line — not the provider's own uptime, which is measured in fractions of a percent, but your patching, your config, your access model. Buying a better provider does not move a wall you own.
The cloud makes spinning up a resource trivial — which is exactly why cost sprawl, shadow environments, and ungoverned growth become the new problem. The flexibility that sold the move is the thing the next forty-two classes exist to govern.
At one VM, "who owns security here" is academic. Across five hundred resources and six teams, it is the single question that decides whether a breach is a footnote or the company.
The engineer who ships is asked "does it run in the cloud?" The engineer who gets promoted is asked "and who is accountable when it does not?" — and has already drawn the line.
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.
No lab this class
Class One stays on paper, on purpose — there is no Azure subscription yet to put your hands in. That starts at Class Seven, the first class with a real resource group to create and delete. Today's hands-on is the game above, dragging November onto a closet and then onto Azure. What is left is checking whether the ideas stuck.
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 2 — 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 as a percentage of uptime, never as a certainty, 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. ↩
Next, the money reason for the cloud that nobody in the room says out loud.
Next · Why Cloud? →