The Container Plateau We’re Not Talking About
Let’s start with a truth that might sound boring but absolutely isn’t: 84 percent of organizations running containers have standardized on Kubernetes. That number used to feel like the horizon line. Now it feels like the floor. And that shift tells you something fundamental about where we are in this cycle.
Five years ago, if you asked a room of engineers whether Kubernetes would become the default orchestration layer, you’d get spirited debate. Someone would mention Nomad. Someone else would defend Docker Swarm with the kind of conviction usually reserved for vinyl records. Today? It’s not even a conversation. Kubernetes won. The interesting part isn’t that it won—it’s that everyone seems to be asking what comes next.
Docker Desktop is still humming along with steady adoption despite the licensing controversy that had everyone ready to burn bridges back in 2021. That tells you something important: people complain about licensing, but they don’t actually leave. The developer experience matters more than we thought, even when it costs money. That’s signal. Whether this reflects complacency or just sensible pragmatism is a harder call.
Platform Engineering: Abstraction as Strategy
Here’s where things get interesting. Platform engineering teams are growing precisely because Kubernetes made infrastructure complex enough that you need specialists whose entire job is to hide that complexity from other engineers. Think about that for a second. We built abstraction layers to manage abstraction layers.
This isn’t cargo-culting. It’s actually elegant. Your average backend engineer doesn’t need to understand networking policies, resource quotas, or the seventeen different ways to configure a service mesh. They need to deploy code and observe it running. Platform teams are becoming the translation layer, the people who speak both the infrastructure language and the application language fluently.
The signal here is hard to ignore: organizations with mature DevOps cultures are investing in platform teams specifically to shield their developers from orchestration complexity. This is no longer a luxury. It’s table stakes for any organization running more than a handful of services. You can see this playing out in the CNCF landscape, which has become less of a landscape and more of a dense forest where most sensible organizations need a guide.
Observability Without Instrumentation: eBPF Changes the Game
eBPF deserves its own discussion because it’s one of those technologies that sounds like academic research but is actually shipping in production systems right now. The core idea is almost offensively clever: get visibility into kernel-level events without modifying application code or restarting containers. You’re intercepting syscalls at the kernel boundary and making sense of what flows through.
This matters more than you might initially think. Traditional observability requires either code instrumentation, adding logging and metrics libraries to your applications, or proprietary agents that hook into runtimes. Both approaches have friction. eBPF removes that friction almost entirely. You get network traffic analysis, system calls, and file access patterns without touching a single line of your application code.
The signal versus speculation distinction matters here. eBPF adoption is real and growing, but most teams are still using it for specific use cases rather than as a foundational observability layer. That transition will happen. The question is whether it happens in the next two years or the next five. My money is on sooner, but I’ve been wrong before at 3 AM while trying to understand why a pod was consuming memory like it had a personal grudge.
WebAssembly on the Server: From Browser Party Trick to Infrastructure Component
WebAssembly started as a browser technology. Most engineers still think of it that way. Increasingly, that’s like thinking of Docker as just a tool for running containers locally before pushing them to production. Technically true. Completely misleading about what’s actually happening.
Server-side WebAssembly workloads are gaining momentum. Not in a “everyone’s doing it” way, that would be speculation, but in a “multiple independent organizations are shipping this to production” way. The appeal is straightforward: portable binaries that run consistently across different environments, with predictable resource consumption and genuinely strong isolation guarantees.
Here’s where I separate signal from speculation. The signal: organizations are experimenting with Wasm for edge computing, FaaS platforms, and plugin systems. The speculation: that this becomes the dominant compute paradigm. It won’t. There are workloads where standard containerization is just better. But Wasm will carve out significant territory, especially in scenarios where you need extremely fast startup times or cross-architecture portability without the overhead of full Linux containers.
GitOps: From Trend to Table Stakes
GitOps has made the jump from “interesting practice” to “how we actually do things” in organizations with mature deployment cultures. The principle is disarmingly simple: your Git repository is the source of truth for your infrastructure and application configuration. Changes flow through pull requests and code review before they touch your cluster.
This is signal, not speculation. GitOps adoption correlates almost perfectly with infrastructure reliability metrics in organizations I’ve worked with or observed. It’s not magic. It’s just that treating infrastructure configuration like application code, complete with review processes and version control, prevents the vast majority of preventable disasters.
When you combine GitOps with the Kubernetes documentation and modern platform team practices, you get systems that are simultaneously more reliable and easier to reason about. The audit trail is explicit. Rollbacks are atomic. Your infrastructure has a clear history of why decisions were made and who made them.
What We Actually Know Versus What We’re Hoping
The container ecosystem is consolidating and maturing. That’s signal. Kubernetes isn’t going anywhere. Platform engineering is real work that organizations actually need. eBPF observability is shipping. GitOps is becoming standard practice. These are the things I’d bet money on.
What I’m less certain about: whether we’ve solved the operational complexity problem or just reorganized it. Whether platform teams will avoid becoming bottlenecks. Whether eBPF will actually replace traditional instrumentation or just supplement it. These are the questions that actually matter for where we’re headed.
The container landscape of five years from now will look different. More abstraction, more specialization in platform teams, better observability without instrumentation overhead, more diverse workload types. But the fundamentals, containerization, orchestration, treating infrastructure as code, those are staying. We’re not starting over. We’re getting better at what we already do.
What’s your view on where containerization goes from here? Have you shipped eBPF observability in production? Is your organization building platform teams to manage Kubernetes complexity? I’m genuinely curious what the signal looks like from where you’re sitting.