Every few years the infrastructure conversation resets around a single claim: the future is fully cloud. Everything on-prem will migrate. The data centre is a transitional technology. Just finish the move.
That claim has been accurate for some organisations. For many others — universities, research institutions, regulated enterprises, manufacturing businesses, public sector bodies — it has been wrong for a decade and continues to be wrong. Not because those organisations are resistant to cloud, but because their operational requirements do not map cleanly onto a cloud-only model.
Hybrid infrastructure is not a failure to finish migrating. In many environments, it is the correct architectural answer.
Where the cloud-only narrative breaks down
The cloud-only model works best when workloads are relatively stateless, data gravity is low, regulatory constraints are manageable, and network latency between the application and the cloud region is acceptable. Many production environments satisfy none of those conditions at once.
Universities and research institutions run high-memory compute workloads against large local datasets. Moving that data to cloud storage for every run introduces latency and egress costs that make the economics worse, not better. The right answer for those workloads is local compute.
Manufacturing and industrial environments often have equipment with fixed network connectivity requirements — OT networks that cannot route through the public internet, devices that communicate on isolated segments, control systems that need sub-millisecond response times. Cloud-hosted control logic is not an option for those systems.
Regulated industries deal with data residency requirements that are still evolving. “The cloud provider has a region in this country” is not always a sufficient answer when the regulatory requirement is about where specific data may be processed, not just stored.
None of these are edge cases. They are significant categories of real operating environments.
What hybrid actually means in practice
Hybrid infrastructure is not “some stuff in cloud, some stuff on-prem, not really connected.” That is multi-environment, which is a different problem.
Hybrid means the two environments work together as a single operational system. On-prem compute bursts into cloud capacity when local resources are exhausted. Cloud-based DR targets maintain warm standby from on-prem primaries. WAN edge devices bridge on-prem and cloud networks with routing that both sides understand.
On-prem (Proxmox) Edge (Hetzner) Cloud (GCP/Azure)
───────────────── ────────────── ─────────────────
Primary compute ──────▶ VPN gateway ──────▶ Burst capacity
Patroni primary BGP peering Cloud SQL replica
NetBox (IPAM) Landing zone
GitOps workloads Argo CD targetThe operational complexity here is real. Keeping that topology coherent — consistent routing, synchronised IPAM state, working replication across the boundary, GitOps delivery targeting the right environment — requires deliberate architecture. It does not happen by accident.
The operational challenge
The reason hybrid infrastructure has a reputation for being hard is not that the individual pieces are particularly complex. VPN tunnels, BGP peering, PostgreSQL replication, and GitOps delivery are all well-understood. The challenge is operating all of them together coherently.
In a cloud-only environment, the operational surface is relatively contained. The cloud provider handles a significant amount of the undifferentiated infrastructure work — networking primitives, storage, managed services. You still need to operate your applications, but the substrate is abstracted.
In a hybrid environment, the operator is responsible for the substrate as well. The WAN edge devices, the on-prem SDN fabric, the physical compute, the storage layer, the cross-environment connectivity. Those are your problem, and they interact with the cloud side in ways that require careful management.
This is not an argument against hybrid. It is an argument for investing in the operational model rather than treating it as a configuration problem to be solved once and forgotten.
Why the investment is worth making
The organisations that have built reliable hybrid infrastructure have something that pure-cloud environments often do not: genuine operational resilience with a known cost structure.
They can run primary workloads on hardware they own, at costs they control, without paying cloud compute rates for always-on capacity. They can burst into cloud for peak loads. They have DR capability that does not depend on keeping warm cloud instances running continuously.
They also have a richer understanding of their own infrastructure. Operating physical hardware forces a level of discipline around networking, storage, and compute that cloud abstractions can obscure. Engineers who have configured BGP peering, managed Patroni failover, and operated a GitOps delivery chain across environments have skills that survive any provider migration.
The architecture question
The interesting question for hybrid environments is not “when will we finish moving to cloud?” It is “what is the right architecture for the workloads we actually have?”
For many organisations, the honest answer involves local compute for latency-sensitive or data-heavy workloads, cloud for burst and DR, and a WAN architecture that keeps them coherent. That is a legitimate production architecture, not a transitional state.
HybridOps is built around this model: on-prem compute on Proxmox, cloud landing zones on GCP and Azure, WAN edge on Hetzner, with the operational tooling designed to treat the entire topology as a single system rather than separate environments bolted together.
The platform engineering challenge in hybrid environments is making the operational model consistent across the boundary. The same modules, the same run records, the same verification paths, regardless of which side of the boundary the infrastructure lives on. That is a solvable problem. It requires deliberate design, but it is not uniquely hard.
Hybrid infrastructure is not the consolation prize for organisations that have not yet moved to cloud. For many of them, it is the architecture they will be operating for the foreseeable future — and the sooner it gets treated as such, the better it will be maintained.