☁ Cloud Without the Chaos — Article 01 · ⏱ 10 min read
☁ Byte Size Summary
- Hybrid cloud isn't a strategy — it's the outcome of real architectural decisions
- Most teams default to cloud or on-prem for the wrong reasons (inertia, not intent)
- Five dimensions drive every defensible placement decision: latency, data sovereignty, cost profile, operational ownership, and blast radius
- A reusable decision framework for evaluating any workload — run it before the migration starts, not after
- Network design thinking from logistics applies directly to hybrid cloud architecture — and most platform engineers have never seen it framed this way
I spent a few years working in supply chain and logistics before I ended up in cloud infrastructure. One of the first things you learn in that world is that the network is never fully yours.
You've got your own warehouses. You've got third-party fulfilment centres you use when demand spikes. You've got last-mile carriers you don't control at all. The goods flow across all of it depending on cost, speed, capacity, and — critically — what you're willing to risk having disrupted.
Nobody in logistics calls this a "hybrid warehouse strategy." They just call it running a network. The goal isn't ideological purity about who owns the infrastructure. The goal is getting the right things where they need to be, reliably, at a cost that makes sense.
When I moved into cloud and infrastructure, this framing was almost entirely absent. Teams were either "cloud first" or "on-prem forever" — both as fixed identities, not deliberate decisions. When hybrid cloud entered the picture, it was less of a strategy and more of a situation that accumulated over time.
This series is about bringing some rigour back to those decisions. Not the marketing version of hybrid cloud — the practical one.
What "Hybrid Cloud" Actually Means
Strip the vendor positioning out first.
Hybrid cloud means running workloads across at least two environments — typically some combination of on-premises infrastructure and one or more public cloud providers — with some degree of orchestration or connectivity between them. No requirement for a unified control plane, a specific vendor stack, or a particular ratio of workloads on each side.
In practice, most enterprise organisations are already hybrid whether they planned it or not. Legacy systems that can't be migrated sit in the data centre. New workloads spin up in AWS or Azure. An OpenShift cluster runs on-prem for regulated workloads. A Kubernetes service runs in Google Kubernetes Engine (GKE) for the developer-facing platform. The network connects them, imperfectly, and the operations team holds it all together with documentation, duct tape, and institutional memory.
The question isn't whether you're hybrid. It's whether you're hybrid on purpose.
This article focuses on the strategic decision layer — where workloads should live and why. The technical implementation of connectivity (VPNs, Direct Connect, ExpressRoute) comes later in the series.
Why Most Hybrid Architectures Are Accidents
Most hybrid architectures evolve the same way.
A team starts running everything on-prem because that's what they know and what the business already owns. At some point there's a project that needs to move fast, or a new team that doesn't want to wait for physical provisioning, and something lands in a public cloud. Then another thing. Then three more things during a peak traffic event that nobody had capacity for on-prem. Now you're hybrid.
Or the reverse: a cloud migration programme moves a significant portion of the estate to public cloud. But some workloads — the database with the compliance requirements, the legacy system that can't be containerised, the one application that cannot tolerate a 100ms latency spike — stay behind. Now you're hybrid.
Neither is necessarily wrong. But both share a problem: the placement decisions were made reactively, and nobody wrote down the reasoning. Two years later, a new engineer reverse-engineers why a workload is where it is, and the answer is "history."
That's a real cost. It makes it harder to have intelligent conversations about what should move, what should stay, and what the actual cost model is.
The Five Dimensions That Actually Matter
After working across on-prem and cloud environments — and spending years in supply chain thinking about network design — five dimensions consistently drive the right placement decision. Answer these clearly and you'll reach a defensible architectural position.
1. Latency tolerance
How sensitive is this workload to network round-trip time? A real-time manufacturing control system talking to floor sensors has hard latency requirements that cloud can't reliably satisfy. A reporting pipeline that runs overnight doesn't. This is easy to underestimate — especially for workloads that look like batch jobs but have real-time dependencies buried inside them.
2. Data sovereignty and compliance
Where does the data have to live? Regulated data in healthcare, financial services, or government frequently has hard requirements about physical location, access controls, and audit trails. Public cloud providers have made significant progress with regional isolation and compliance certifications — but not every jurisdiction accepts "it's in an EU data centre" as sufficient. Know the actual requirements before you architect.
3. Cost profile and demand shape
Cloud is cheaper at the margins — burst capacity, unpredictable demand, short-lived environments. On-prem is cheaper at steady state — predictable, high-utilisation workloads where you'd be running equivalent cloud compute continuously. Applying cloud economics to steady-state workloads, or on-prem economics to spiky ones, is the most common cost mistake in hybrid architecture. The shape of demand matters as much as the raw compute cost.
4. Operational ownership appetite
Cloud shifts operational responsibility to the provider for the infrastructure layer, but it doesn't eliminate operational work — it changes it. You're still responsible for your application, your data, your network configuration, your identity model. A managed Kubernetes service in the cloud may be cheaper in operational time than a self-managed OpenShift cluster, even if the compute costs are higher. Or it may not be, depending on your team. Be honest about this.
5. Blast radius and failure domain
If this workload fails, or the environment it runs in fails, what's the impact? Placing a critical system on a single public cloud introduces a blast radius tied to that provider's regional availability. Placing it on-prem introduces a different blast radius — your data centre's power, cooling, and network uplinks. Neither is inherently safer. The question is which failure mode you have more control over, more visibility into, and more organisational capacity to recover from.
A Decision Framework You Can Actually Use
| Dimension | Question | Signal |
|---|---|---|
| LATENCY | Sub-5ms requirements, or direct integration with on-prem systems? | → On-prem or edge. Everything else is negotiable. |
| SOVEREIGNTY | Hard data residency requirement your cloud provider can't satisfy with certifications? | → On-prem or private cloud. If they can satisfy it, document that explicitly. |
| DEMAND SHAPE | Consistent, predictable utilisation above ~60%? | → On-prem likely wins on cost. Spiky, seasonal, or unpredictable? → Cloud wins. |
| OPERATIONS | Does your team have the skills and bandwidth to manage the infrastructure layer? | → On-prem or self-managed. Would a managed service free up meaningful capacity? → Cloud. |
| BLAST RADIUS | Which failure mode is more recoverable — cloud regional outage, or on-prem infrastructure failure? | → Architect toward the one you can recover from faster. |
Run any workload through these five questions. If the answers point consistently in one direction, the decision is clear. If they conflict — and they often do — you're having an explicit architectural conversation rather than an implicit one. That's already progress.
The Placement Decision Table
| Workload type | Typical best fit | Reason |
|---|---|---|
| Real-time control systems | On-prem / edge | Latency and reliability requirements |
| Regulated data stores (PII, PCI, PHI) | On-prem or certified cloud | Sovereignty — verify per jurisdiction |
| Dev/test environments | Cloud | Short-lived, variable, low blast radius |
| Burst compute (ML training, batch jobs) | Cloud | Elastic capacity on demand |
| Internal developer platforms | On-prem or hybrid | Integration with internal systems, security posture |
| Customer-facing APIs | Cloud | Global distribution, managed scaling, CDN integration |
| Legacy monoliths (can't containerise) | On-prem | Migration cost exceeds benefit — for now |
| Disaster recovery / backup | Cloud | Offsite resilience, pay-per-use when idle |
What the Supply Chain World Understood First
In logistics, there's a discipline called network design — deciding where to place inventory, distribution centres, and transport capacity to optimise for cost, speed, and resilience across a network. It's not about owning everything. It's not about outsourcing everything. It's about understanding the specific characteristics of each node and flow, and making placement decisions accordingly.
The most important lesson from that world: over-centralising creates fragility, and over-distributing creates complexity that erodes the resilience you were trying to build. The answer is never all-in on one model. It's a considered network, with explicit reasoning behind each decision.
Hybrid cloud is the same problem. The data centre is your warehouse. The cloud is your third-party fulfilment network. Some workloads belong in your warehouse because you need control, compliance, or latency. Others belong in the fulfilment network because you need elasticity and don't want to own the capacity. The failure mode is treating this as a binary choice rather than a network design problem.
💡 From the field: Before any migration or placement decision, create a simple workload inventory: what it does, what it talks to, what its latency and compliance requirements are, and what it currently costs to run. Most teams don't have this and make significant architectural decisions without it. A rough spreadsheet surfaces conversations that would otherwise never happen.
The Honest Tradeoffs
There's no version of hybrid cloud that's free of complexity. Running across two environments means two sets of networking concerns, two operational models, two security boundaries, and often two teams with different toolsets. That's real cost, and it's worth naming before you commit.
The question isn't whether hybrid cloud creates complexity — it does. The question is whether the complexity is worth it relative to the alternative. For most enterprise organisations with a heterogeneous workload mix and real compliance requirements, the answer is yes. But "yes" should come from an analysis, not from a vendor briefing or a conference keynote.
The teams that get this right treat placement as a first-class architectural concern — documented, revisited periodically, and tied to actual cost and operational data. Not a one-time migration project. Not a fixed philosophical stance. A living decision.
Key Takeaways
- Hybrid cloud is not a destination — it's a network of deliberate placement decisions
- Most hybrid architectures are accidents — the goal is to make yours intentional
- Five dimensions drive placement — latency, sovereignty, cost profile, operational ownership, blast radius
- Treat workload placement like network design — optimise for the whole, not the individual node
- Complexity is unavoidable — the question is whether it's justified by the requirements
What's Next in Cloud Without the Chaos
Article 02 — Managed Services vs Self-Hosted: When to Hand Over the Keys
You've placed the workload in the cloud. Now: do you manage the infrastructure yourself, or hand it to a managed service? The next article works through the real tradeoffs — including the moment a managed service genuinely saves your team 20 hours a week, and the moment it quietly doubles your incident response time.
Read the Cloud Without the Chaos series index for the full learning path.
Written by Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI
Top comments (0)