Before you close the tab, hear me out.
Kubernetes is exceptional infrastructure. It has won. That debate is over.
But there is a difference between Kubernetes as the foundation your platform runs on and Kubernetes as the interface your developers and platform engineers work in day to day. Most teams conflate the two and it costs them.
The raw Kubernetes API was designed for system builders, not for the humans who need to deploy a service, promote a release, or understand why something broke in production at 2am. Namespaces, Deployments, HTTPRoutes, NetworkPolicies, these are powerful primitives and completely wrong as the daily interface for most of the people who need to interact with your platform.
The hot take is this: in 2026 if your platform engineering team is spending the majority of their time working at the raw Kubernetes layer, something has gone wrong. The ecosystem has matured past that point. Higher-level abstractions exist. Open source, CNCF-governed, production-tested abstractions that let you keep full control of the underlying infrastructure while giving your developers and operators an interface that actually matches how they think about their work.
Core platform concepts exposed as declarative APIs, environments, gateways, pipelines, component types, mean topology and delivery behaviour can be standardised across an organisation. That is the layer platform engineers should be working at.
Developers define application intent through high-level abstractions and the platform compiles this into the necessary Kubernetes resources, network policies, gateways, and observability hooks. Kubernetes is still doing all the work underneath. It just stops being the thing humans have to reason about directly.
The teams doing this well are not abstracting away Kubernetes. They are building on top of it properly. There is a meaningful difference.
I contribute to OpenChoreo, an open source CNCF project built around this idea. The whole design principle is that Kubernetes stays fully visible and operable but stops being the daily interface for the humans above it.
Is this actually controversial or has the community already moved here? Curious where people land.
_If you want to see what this looks like in practice: _<a href="https://openchoreo.dev/" target="_blank" rel="noopener nofollow">https://openchoreo.dev/</a>

The hottest most controversial dev discussions. Found something you'd like to share? Add it in the thread 👇


controversy.dev

Platform engineering teams in 2026 should treat Kubernetes as infrastructure foundation, not as the daily human interface. The raw Kubernetes API was designed for system builders, not for developers deploying services or debugging production issues. Higher-level, CNCF-governed abstractions now exist that let developers express application intent while the platform compiles it into Kubernetes resources underneath. The key distinction is building properly on top of Kubernetes versus abstracting it away entirely. OpenChoreo is cited as an example of this approach, where Kubernetes remains fully visible and operable but is no longer the daily interface for developers and operators.

Unpopular opinion: platform engineering in 2026 should start with Kubernetes

I’d argue: not everyone needs K8s.
That said, given those that do, I’m really curious exactly what this does. I’m not a platform or ops guy. My company does not use or need K8s… so, explain it like I’m 5. Why shouldn’t I just write my own scripts to work with K8s?

Once Microsoft thought this. About so many things.
<blockquote>
It has won. That debate is over.
</blockquote>
It did not age well!