Public, Private, or Hybrid: Choosing What Actually Fits
Stop treating deployment models as a maturity ladder. Map each workload to the model whose cost curve and constraints actually match it.
Every few months a team asks me the same question, usually phrased as a decision they have already half-made: "We're going all-in on public cloud, right?" The honest answer is almost always "it depends on the workload", and the teams that internalise that early spend far less money and lose far less sleep.
Public, private, and hybrid are not a maturity ladder where hybrid is the beginner rung and public cloud is enlightenment. They are three tools with different cost curves, control surfaces, and failure modes. The job of a platform team is to map each workload onto the model that actually fits it, not to win an architectural religious war.
The three models, without the marketing
Strip away the vendor decks and the trade-offs are concrete. Public cloud rents you elasticity: you pay a premium per unit, but you can provision in seconds and shrink to zero. Private infrastructure, on-prem or dedicated hardware, flips that: high fixed cost, low marginal cost, and full control over where data physically lives. Hybrid is the deliberate stitching of both so each workload runs where its economics and constraints point.
Those numbers are illustrative, not gospel, your mileage depends on reserved-instance discounts, hardware amortisation, and how spiky your traffic is. But the shape holds: public cloud wins on time-to-capacity and elasticity; owned infrastructure wins on steady-state unit cost and physical control.
Explore the trade-offs
The interesting decisions live between the extremes. Drag the slider below from fully public to fully private and watch the trade-offs move. Notice that operational simplicity is highest at the extremes and dips in the middle, hybrid buys you flexibility but you pay for it in moving parts.
A workload-placement heuristic
Instead of choosing a model for the company, choose one per workload. The questions that actually decide it:
- How spiky is demand? Bursty, seasonal, or unpredictable traffic (Black Friday, batch jobs, viral spikes) belongs on public cloud where you pay only for the peak you actually hit.
- Is the baseline predictable? Steady 24/7 workloads at scale are where owned or reserved capacity quietly wins on unit cost.
- Where must the data live? PII, PHI, and regulated financial records with residency or audit constraints often have to stay on infrastructure you control.
- How latency-sensitive is it? Trading systems, control planes, and real-time inference may need to sit physically close to other systems.
Place workloads, not companies
"Are we public or private?" is the wrong question. "Where does this workload belong?" is the right one, and the answers will be different across your own portfolio.
Building the bridge that makes hybrid work
Hybrid only pays off if both halves feel like one system. Three things make or break that: workload portability, unified observability, and a single security boundary. Without them you don't have a hybrid platform, you have two silos and a VPN.
Kubernetes is the usual portability layer because the same manifests run on managed clusters and on-prem. A trimmed example of a workload that is deliberately cloud-agnostic:
apiVersion: apps/v1
kind: Deployment
metadata:
name: checkout-api
labels: { tier: steady-state }
spec:
replicas: 6
template:
spec:
# no cloud-specific node selectors, schedules anywhere
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
containers:
- name: api
image: registry.internal/checkout:1.8.2
resources:
requests: { cpu: "500m", memory: "512Mi" }
The point is what's absent: no provider-specific node selectors, no managed-service coupling in the hot path. The bridge layer, service mesh, GitOps, and a single observability stack scraping both environments, is what turns two data centres into one logical platform.
The expensive anti-patterns
Two failure modes show up again and again:
- Lift-and-shift to public cloud, then act surprised at the bill. Moving a steady-state VM fleet onto on-demand instances and never reserving or rightsizing is how you turn a capex line into a much larger opex line.
- Hybrid by accident. A few shadow workloads on public cloud plus an ageing on-prem estate is not a strategy, it's two silos with double the operational surface and no portability between them.
Key takeaways
- Public, private, and hybrid are tools with different cost curves, not maturity stages.
- Decide placement per workload using demand shape, data residency, and latency.
- Hybrid only pays off with portability, unified observability, and one security boundary.
- The two big money sinks are un-rightsized lift-and-shift and accidental hybrid.
Not sure where each workload belongs?
We architect the bridge so both halves feel like one system, workload portability, unified observability, a single security boundary.
Design my hybrid stack