Where it runs, without the gloss
Consider a commercial kitchen. A young restaurant rents time in a shared one — professional ovens, cleaned and maintained by someone else, billed by the hour, and busy with other people's cooking the rest of the day. A large chain builds its own kitchen, controlling every burner and paying for all of them whether lit or not. And a few keep a small prep bench on-site while renting the big kitchen for the heavy work. Same food, three arrangements, and the right one depends on how much you cook and how much you can afford to own.
Deployment models are that decision for computing. In Class Four you chose how much of the stack to manage; now you choose where it physically runs and who else shares the hardware. The two dials are independent — you can run PaaS in a public cloud or IaaS in a private one — and confusing them is the most common way this topic goes wrong in an interview.
- Public cloud
- Resources run on the provider's shared hardware, rented on demand. Azure, in this bootcamp. Someone else's kitchen, spotless and metered.
- Private cloud
- Cloud-style provisioning on hardware dedicated to one organisation — in your own datacentre or a hosted one. Your kitchen, your bill for every burner.
- Hybrid cloud
- Public and private (or on-premises) used together, with connectivity and, ideally, coordinated management between them.
- Multi-cloud
- Two or more public providers used by the same organisation. Not the same thing as hybrid, and often confused with it.
Hold that last distinction firmly. Hybrid mixes public with private; multi-cloud mixes public with public. They solve different problems, carry different bills, and answer to different reasons — and the rest of this class is mostly about the reasons, because the reasons are where the money is either well spent or quietly wasted.1
What "private cloud" actually costs
"Private cloud" is the phrase that most often smuggles an old habit into a new vocabulary. It sounds like you get the cloud's elasticity with the safety of owning the hardware. What you actually get is a datacentre with a self-service portal bolted on — and the bill underneath is the one Class One taught you to see.
- Private cloud
- Dedicated hardware, cloud-style operation. You still buy for the peak, still pay through the trough, still replace the disks — you have simply added software that lets colleagues provision from a pool you own.
Look at what does not transfer. The elasticity that made the public cloud worth having depends on a pool so vast that your November peak is a rounding error in someone else's capacity. A private pool is bounded by what you bought; when your peak arrives, the "elastic" cloud can only stretch as far as the hardware in the room. You are back to forecasting capacity eighteen months out — the exact problem the grid was supposed to end. Private cloud, stated plainly, is CapEx in cloud clothing.
There are honest reasons to run one: a regulator who demands physically isolated hardware, a workload whose scale genuinely never varies, an existing datacentre with years of depreciation left. Those are the §4 exceptions from Class Three, wearing a different hat. But "private cloud for cost savings" almost never survives contact with the numbers, because you have taken on every expense the public cloud amortises across millions of tenants and are now amortising it across one: yourself.
Hybrid: a bridge, and sometimes a home
Hybrid is the most useful and the most abused word in this class. Useful, because almost every real migration passes through it — you rarely move forty stores' worth of systems in a single weekend, so for a while some things live in Azure and some stay on-premises, connected across a secure link. Abused, because "we're hybrid" is also how organisations describe having started a migration and stopped.
The distinction that matters is bridge versus destination. Hybrid as a bridge is a transition state: a deliberate, temporary arrangement while workloads move, with an end date and a plan to reach it. Hybrid as a destination is a permanent choice, justified by the same hard limits as always — a workload pinned on-premises by latency, by a residency law, or by a licence bound to a machine. Both are legitimate. What is not legitimate is drifting into the second because you never finished the first.
Azure gives hybrid real tooling rather than good intentions. Azure Arc projects on-premises servers, Kubernetes clusters and databases into Azure so you can govern and monitor them with the same policies and the same portal as your cloud resources — one pane of glass over both sides of the bridge.2 The point is not the product name; it is that a hybrid estate managed as two separate worlds costs you twice the effort, and the whole art of running one well is refusing to let it become two.
Multi-cloud: the honest version
Multi-cloud — running on two or more public providers at once — is sold on a single seductive promise: freedom from lock-in. Spread across Azure and a competitor, the pitch goes, and no vendor can hold you hostage on price or hold you down in an outage. It is the idea a board is most likely to arrive at already believing, and the one most worth examining slowly.
| The claim | The honest version |
|---|---|
| "It removes vendor lock-in" | You now depend on two vendors and the glue between them — often harder to leave, not easier |
| "It gives us resilience" | Only if you run genuine active-active across both, at close to double the cost and complexity |
| "We can pick the best service from each" | True, but you architect to the lowest common denominator and forfeit each cloud's best-integrated features |
| "It strengthens our negotiating position" | Sometimes real — but split spend also thins the volume discounts each vendor offers |
Multi-cloud doubles the lock-in it promises to remove.
None of this makes multi-cloud wrong. It makes it a deliberate, expensive choice with genuine uses: an acquisition that arrived on another cloud, a single best-of-breed service that lives only on one provider, a regulator requiring provider diversity. Those are reasons. "To avoid lock-in" and "for resilience," stated as slogans, usually are not — because the team must now hold deep expertise in two platforms, pay to move data between them,3 and build every system to the shrunken set of features both clouds share. For a six-person team at Campux, that is not freedom. It is two mortgages and a rule that you may only ever cook what both kitchens allow.
Where Campux lands
The models are only worth learning if they resolve into a decision. For Campux, they do, and the decision is unremarkable in exactly the way good decisions usually are.
Public-first, with a bridge that has an end date
Campux goes public-first on Azure. A six-person team serving a seasonal storefront has no business building a private cloud — it would re-buy the capacity problem Class Two just solved — and no business splitting itself across two providers to fend off a lock-in that costs them nothing today. Single public cloud, chosen deliberately, is the boring correct answer.4
The one exception is a hybrid bridge, and it is explicitly a bridge, not a home. The POS batch job — the workload you refused to migrate in Class Three, with its licence nailed to one machine — stays on-premises during the move, connected to Azure over a secure link so the rest of the estate can reach it. That arrangement carries a date: it ends when the licence is renegotiated and the job finds its proper home, which you will design in the classes ahead.
Notice what you did not do. You did not adopt multi-cloud to sound sophisticated, or a private cloud to feel in control, or permanent hybrid because finishing is harder than starting. You matched the deployment model to Campux's actual constraints, and where a constraint was temporary, you gave the bridge an expiry. That restraint — choosing the plain thing and refusing the fashionable one — is the whole of the judgement this class is teaching.
Sorting the estate by its constraints
Legal says a certain dataset cannot leave the country, and a regulator wants some workloads on infrastructure you control. Instead of panicking, you sort the estate: public cloud for the stateless front end, a hybrid path for the regulated data. You map each workload to the model its constraints demand — and hand compliance an architecture instead of an argument.
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. Hybrid mixes public with private or on-premises. A describes multi-cloud — the confusion this class exists partly to end. C and D describe ordinary public-cloud arrangements dressed up in borrowed words. If you can state which side is the provider's shared hardware and which side is dedicated to one organisation, you can tell hybrid from everything pretending to be it.
B. Public elasticity works because the provider's pool is so large your peak is a rounding error in it. A private pool is only as big as what you purchased, so when the peak comes it can stretch exactly as far as the idle iron in the room — and no further. That is the return of eighteen-month capacity forecasting from Class One. A and C are simply false; D confuses the two dials this class spent §1 separating.
Regulatory isolation, hard latency needs, and unamortised sunk cost. Each is the same limit — law, physics, money — that Class Three named, now deciding a deployment model. The two wrong answers are the slogans: private cloud is rarely cheaper once you carry the full bill yourself, and "no vendor dependency at all" is a fantasy — you always depend on someone, the only question is whom and how deliberately. Reasons rooted in constraints survive scrutiny; reasons rooted in mood do not.
MEMORANDUM — Resilience via multi-cloud
1. Run the storefront on Azure and a second public cloud in parallel.
2. If one provider suffers an outage, the other serves all traffic.
3. This also reduces our dependence on any single vendor.
4. Cost impact is minimal, since we would pay for the compute either way.
Line four. The strategy can be made to work, but it is the opposite of cheap. Genuine failover means running the storefront live on both clouds at once — double the compute, double the platform expertise, plus the cost of continuously synchronising data across providers and paying egress to move it between them. "We'd pay for the compute either way" quietly assumes one bill where there are now two and a half.
Consider the consequence. Approved on the promise of minimal cost, this plan surfaces as a doubled infrastructure bill and a data-consistency problem nobody scoped — discovered the first time the two clouds disagree about the state of an order mid-checkout. The resilience is real; the price tag on line four is fiction, and fiction on a board memo is how a team commits to something it cannot afford.
Concede the real benefit before you price it. Multi-cloud genuinely can reduce dependence on one vendor and satisfy a regulator who demands diversity — say so, so the board hears an engineer weighing a trade, not a loyalist defending Azure. The disagreement is about cost and timing, not about whether the benefit exists.
Then show the bill under the slogan. "Avoiding lock-in" by adding a second cloud usually deepens it: you now depend on two platforms and the fragile glue between them, staff must master both, data costs money to move across the gap, and every system is built to the features both clouds share rather than the best of either. For six people, that is a permanent tax paid against a risk that is currently hypothetical.
Close on the proportionate move. The real protection against lock-in is portable practice — infrastructure as code, containers, standard interfaces — which you will build regardless and which keeps the option to move without paying for two homes today. Recommend single-cloud now, portability by default, and revisit multi-cloud when a concrete reason arrives. That is lock-in managed with arithmetic instead of anxiety.
Name the two kinds of hybrid before you judge this one. Hybrid as a bridge is a temporary state with an end date, while workloads move. Hybrid as a destination is permanent, and earns its place only where a specific constraint pins a workload on-premises — latency, a residency law, a machine-bound licence. "Just in case" is neither; it is the migration stopping halfway and calling the pause a strategy.
Price the "foot in both worlds." Permanent hybrid without a reason means paying to run and secure two environments forever, keeping staff fluent in both, and reasoning about every failure across a link between them. That is a standing cost with no matching benefit — the most expensive way to feel safe.
Give the rule, then apply it. Keep hybrid only where a named constraint requires it; everywhere else, finish the move. For Campux that means exactly one permanent-ish exception — the POS batch job until its licence is resolved — and a plan to retire the bridge for everything else. Hybrid should be something Campux is passing through, not somewhere it decides to live because leaving felt like effort.
Five things worth carrying out of this class
- Service model is how much you manage; deployment model is where it runs and who shares the hardware. Two independent dials.
- Hybrid mixes public with private; multi-cloud mixes public with public. They are not synonyms, and interviewers check.
- Private cloud keeps the costs the public cloud amortises away. Elasticity does not survive a pool you had to buy.
- Hybrid is a bridge with an end date, or a destination justified by a hard constraint — never a migration that quietly stopped.
- Multi-cloud is a deliberate, expensive choice, not a free hedge. "For resilience" and "to avoid lock-in" rarely pay as slogans.
- For the record, the formal NIST definition lists a fourth deployment model: the community cloud, shared by several organisations with a common concern — a consortium of hospitals, say. It exists, it is rare, and Azure does not sell it as a category; you will meet it on a definitions slide long before you meet one running. ↩
- Azure's hybrid tooling has been renamed more than once — the on-premises infrastructure product formerly called Azure Stack HCI is now Azure Local, and hybrid management runs through Azure Arc. Learn the capability, not the branding: the ability to govern on-premises and cloud resources under one set of policies is what matters, and the names will keep moving. ↩
- Moving data between two cloud providers is egress on both sides of Class Three's asymmetry — you pay to send it out of one cloud, and the pattern that requires it tends to require it constantly. A multi-cloud architecture that shuffles data across the gap is paying that meter as a permanent line item. ↩
- "Public-first" is a default, not a dogma. It means the burden of proof sits with keeping something off the public cloud, and that burden is met often enough — by the POS batch job here — that the word is "first," not "only." The discipline is making each exception earn its place. ↩