Cloud Platform
Public cloud, private cloud, and on-premises infrastructure can all run the same workload competently. Anyone who tells you one is universally superior is selling that one. The useful question isn't which is better — it's which set of constraints you're actually operating under.
The four questions that decide it
1. Is your load predictable?
Public cloud's core economic argument is elasticity: you pay for peaks only when you have them. That's genuinely powerful for workloads that spike — seasonal retail, event-driven processing, anything bursty.
It works against you when load is flat. A steady workload running 24/7 on rented elastic capacity is paying a premium for flexibility it never uses. Many organisations that moved everything to public cloud on principle discovered this on the invoice, roughly eighteen months in.
2. Where must the data live, and who must be able to reach it?
For regulated sectors this often ends the discussion before it starts. If your regulator requires data to remain within a specific jurisdiction, or requires you to be able to name the physical location and the individuals with access, your options narrow sharply and correctly.
Note that this is a question about evidence, not just architecture. Being able to prove where data sits, to an auditor, on demand, is a different capability from it happening to sit in the right place.
3. What does your team already know?
An architecture your team can't operate confidently is worse than a simpler one they can. Public cloud rewards teams with strong automation practice and punishes teams without it — the same flexibility that enables good engineering enables expensive mistakes at speed.
4. How much do you want to own?
This is the honest version of the build-versus-buy question. Owning more means more control and more responsibility. Owning less means less control and a dependency you should read the contract on carefully.
The unglamorous middle: most mature organisations end up hybrid, not because it's fashionable but because different workloads genuinely have different answers. Steady core systems in dedicated private infrastructure; bursty, experimental, or geographically distributed workloads in public cloud. The complexity cost of running both is real — but so is the cost of forcing every workload into one model.
What private cloud actually gets you
- Predictable cost. A known monthly figure rather than a variable bill that requires a specialist to interpret.
- Dedicated resources. No noisy neighbours competing for the same physical hardware.
- Locational certainty. You can name where the data is and who can physically reach it.
- Configuration freedom. Network topology, retention policies, and access models built to your requirements rather than selected from a menu.
What it costs you
- Capacity planning becomes your job again. You size for peak and carry that capacity year-round.
- Scaling is a conversation and a lead time, not an API call.
- You inherit a dependency on whoever operates it — which is exactly why the operator's track record matters more than their feature list.
A practical way to decide
Don't start with the platform. Start by listing your workloads and, for each one, writing down: how variable is its load, what are its data-residency constraints, what's its tolerated downtime, and what would it cost the business per hour to be unavailable.
Sort that list. You'll usually find it separates cleanly into a group with strict constraints and steady load, and a group with loose constraints and variable load. The first group has one obvious answer, the second has another, and you've just designed your hybrid architecture without arguing about vendors once.
