Public, private, hybrid — where it runs and who is allowed to touch it, mapped out without the marketing gloss.
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
Edge — when the round trip is the problem
There is a fourth arrangement worth naming now, because it answers a problem the other three cannot: distance. Edge computing pushes compute out of the big central regions and places it physically near where the data is made — in a store, on a factory floor, inside a vehicle, at the base of a cell tower. The driver is almost never cost and almost always physics. Light is fast but not instant; a round trip from a shop floor to a datacentre four hundred miles away and back has a floor no amount of money removes, and for some workloads that floor is intolerable.
Reach for the edge when one of three things is true. When latency must be lower than the nearest region can deliver — a robotic arm that cannot wait sixty milliseconds for permission to stop. When bandwidth makes shipping everything to the centre absurd — a wall of cameras generating more video per hour than the site's uplink could ever forward, so the analysis has to happen locally and only the summary travels. Or when the site must keep working while the link is down — a store that still has to take payments when its connection drops. In each, the answer is not a bigger central cloud; it is a small piece of cloud moved out to meet the data where it lives. Edge does not replace the public cloud — it extends it, and the two are almost always run together, which is why edge and hybrid are cousins rather than rivals.
Play it through
Three minutes, two workloads. Send the one with nothing holding it back to Azure, then place the one with a licence nailed to a machine before you waste a month moving it twice. It plays on its own and stops when it needs your hands.
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.
That secure link comes in exactly two grades, and you should be able to name both long before Classes Fourteen and Fifteen wire one up. A VPN — a virtual private network — is an encrypted tunnel across the public internet: cheap, quick to stand up, and subject to the internet's moods. ExpressRoute is a private, dedicated circuit from your premises into Microsoft's network that never touches the public internet at all: predictable bandwidth and latency, bought through a connectivity provider and priced accordingly. Every hybrid bridge in this bootcamp is one or the other.
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 Concretely: when Class Eight's Azure Policy starts enforcing rules across Campux's estate — require this tag, forbid that configuration — the same policy that audits the cloud VMs can be applied, through Arc, to the on-premises POS server, so the one machine that stayed behind is governed by the same rulebook as everything that left. 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.
Be concrete about what Arc actually buys, because "single pane of glass" is the sort of phrase that means nothing until you can price it. Without Arc, the on-premises POS server lives in a separate universe: its own patch process, its own inventory, its own security review, its own tags kept in a spreadsheet nobody trusts. Anything the cloud side gains — a new policy, a monitoring dashboard, an access rule — has to be rebuilt by hand on the other side or simply skipped, and "skipped" is how the one machine left behind becomes the one nobody is watching the night it is breached. Arc collapses that: the server registers into Azure as a first-class resource, inherits the same role assignments, the same policy, the same monitoring pipeline. The saving is not a screen; it is the elimination of a second, parallel operation that a six-person team cannot afford to staff. This is also the bridge to edge — the same Arc machinery that governs a datacentre server governs a box sitting in a store, which is how a distributed edge estate stays one system instead of forty.
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.
Two costs in particular tend to be invisible in the boardroom and painful in the invoice. The first is egress: cloud providers charge to move data out of their network, and a genuinely resilient multi-cloud design copies or synchronises data across both — so you pay, continuously, for the privilege of keeping the second cloud current. The second is people. Deep fluency in one cloud takes years; multi-cloud asks for it twice, or asks each engineer to be shallow in two places instead of expert in one. The failure pattern is predictable and well documented: a team adopts a second cloud "for resilience," discovers it cannot staff both to the same standard, quietly standardises its real work on one anyway, and is left maintaining the other as dead weight — all the cost of two clouds, the benefit of neither. That is why the mature version of the multi-cloud conversation is not "how do we run everywhere" but "what single, specific thing forces us off one cloud, and is it worth this bill?"
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. Before the case file, hold the general shape: a deployment model is never chosen for its own sake — it is forced by a constraint, and if you cannot name the constraint, the honest default is a single public cloud. The table below is the one to carry into an interview, because it answers "when would you go private / hybrid / edge?" with a driver instead of a slogan.
| Reach for | Only when the driver is | The tell in the room |
|---|---|---|
| Public (single cloud) | Nothing forces you off it — the honest default | "Where should this run?" has no constraint attached to it yet |
| Private | A regulator or contract demanding physically isolated hardware; a truly flat, never-varying load; a datacentre with depreciation left | Sovereignty or residency law, not "we want control" |
| Hybrid (bridge) | A migration in progress — some systems moved, some not yet | There is an end date, or there should be |
| Hybrid (home) | A workload pinned on-premises with no end date in sight — a data-residency rule, or a machine-bound licence nobody can renegotiate | A specific system that cannot move, named |
| Edge | Latency below the nearest region, bandwidth too large to ship, or operation that must survive a dropped link | Physics — a distance or a duty-cycle you cannot argue with |
| Multi-cloud | An acquisition on another cloud, a single service that lives only elsewhere, or a regulator mandating provider diversity | A named, specific forcing function — never "to avoid lock-in" |
Read the middle column as a lie detector. Every legitimate move off single-public-cloud has a concrete driver behind it — a law, a licence, a distance, an acquisition. When the stated reason is instead an abstraction — "control," "flexibility," "avoiding lock-in" — you are almost certainly looking at a preference dressed as a requirement, and the plain public-cloud default should have to be argued away, not into.
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.
Zoom out: every model you add is a surface you now operate
You can name public, private, hybrid, and multi-cloud. Now reason about what each choice does to the whole estate, because a deployment model is a promise about how many worlds your team must keep alive at once.
"We'll go multi-cloud to avoid lock-in" adds a second set of tools, identities, and skills, so velocity drops, so teams standardise on one anyway — but now maintain two. What actually justified the second cloud, and what does it cost every sprint after?
Hybrid couples the cloud's usefulness to the on-premises link — the VPN or ExpressRoute, and the DNS both sides must agree on. The bridge is a dependency, and a system is only as available as its narrowest link.
The constraint on multi-cloud is rarely technology — it is human: two clouds is two on-call rotations, two security models, two bills to reason about. The limit is the team that must fluently run both.
A private-cloud choice made for control also inherits the capex, the capacity planning, and the hardware-refresh cycle the public cloud existed to delete — the very reason you left, quietly re-created.
A hybrid link that is fine for one nightly batch becomes both the bottleneck and the single point of failure once the whole estate depends on cross-boundary traffic.
The engineer who ships is asked "where does it run?" The engineer who gets promoted is asked "and how many worlds does the team now keep alive?" — and has counted the cost of each.
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. ↩
Next, the three big clouds side by side, without the fan-club noise.
Next · AWS, Azure & GCP →