For about a decade, "cloud-native" was a kind of identity, a signal a choice had been made about how software would be built and where it would run. It meant containers and Kubernetes and managed services and twelve-factor everything, with greenfield as the default starting position. The architecture diagram had no on-prem box in the corner, and the absence of one was treated as a feature rather than an oversight.
This identity is quietly dying, even if the conference talks haven't caught up yet. Most teams running at any real scale now operate a mix of containers, VMs, and physical servers spread across two or three clouds and at least one data center nobody wants to touch, which means the label "cloud-native" has become a description of a workload rather than a description of a company. Once teams accept this, a surprising amount of received wisdom stops holding up under any kind of weight.
Service mesh is the most obvious example of an idea built for a world which never arrived. The sidecar-per-pod model assumed every workload would live in Kubernetes, and the considerable operational cost was worth paying because the architecture was uniform enough to justify it. Neither assumption survives contact with a real enterprise, where the mesh tax is real but the more serious problem is geometric: the mesh doesn't extend to the legacy payments system running on bare metal or the analytics cluster sitting on VMs. Teams end up running a mesh for the containerized half of the estate and something else entirely for the other half, and the boundary between the two becomes the actual hard problem to solve.
North-south and east-west are the same problem in a hybrid estate, even though the mesh treated them as different because it could only ever see one of them clearly. The moment traffic crosses an environment edge, and in any real hybrid setup it crosses one constantly, teams are back to the boundary problem the mesh was supposed to abstract away in the first place.
The industry built abstractions for a world which didn't arrive, and the tools assuming otherwise are now generating most of the operational friction platform teams feel day to day. We were promised greenfield Kubernetes everywhere and we got a patchwork instead, which has been the actual condition of enterprise infrastructure for longer than most vendors are willing to admit publicly.
Something less ideologically clean is emerging in response, and a few vendors have started naming it directly. HAProxy has been talking about Universal Mesh, the idea being a single data plane spanning Kubernetes and VMs and bare metal alike, managed by one control plane sitting at the boundary of each environment rather than embedded inside every pod. The framing matters because it concedes the thing most vendors have spent years dancing around, namely the assumption a uniform substrate was ever realistic in the first place. The same policies apply whether traffic is hitting the public internet, moving between clouds, or routing between internal services, which isn't as architecturally elegant as "the mesh handles everything" but has the considerable advantage of matching the territory people are actually operating in.
There's a generational shift underneath the technical shift too, and it's worth naming directly. Engineers who came up during the cloud-native peak treated Kubernetes as the substrate and everything else as a migration target to be eventually retired, whereas engineers running platforms today treat Kubernetes as one substrate among several and don't expect the others to disappear on any reasonable timeline. They're not nostalgic about VMs and they're not waiting for the legacy systems to be rewritten, because they've accepted the rewrite isn't coming, the on-prem data center is staying, and the job is to make a heterogeneous estate behave like a coherent system regardless of where any particular workload happens to live.
That's a more mature stance than the one which preceded it, and it's the stance the next decade of platform work will be built on whether the vendors notice or not.
The interesting tooling now isn't the kind insisting on a particular substrate as a precondition for operating, it's the kind substrate-agnostic by design, running the same way on a bare-metal box, a VM, and a Kubernetes node, giving operators one place to manage all of it without pretending the others don't exist.
Cloud-native served a real purpose as a forcing function, pushing teams toward better operational habits and cleaner deployment models and real observability practices most of them wouldn't have adopted otherwise. As an identity it has outlived its usefulness, and the teams doing the best work right now aren't cloud-native or on-prem or hybrid in any meaningful self-description, they're just running infrastructure wherever it happens to live and treating the seams between environments as the actual product they're shipping.
Top comments (0)