The Kubernetes Question That Isn’t Really a Question Anymore
I remember 2019 like it was yesterday. Teams were still asking whether they should run Kubernetes, treating it like a genuine fork in the road. Some organizations had already committed, others were waiting to see if it was a real technology or just the new shiny thing that would fade when something else caught the industry’s attention. I was skeptical myself, having watched enough failed orchestration platforms come and go. But the numbers tell a different story now. Roughly 84 percent of organizations running containers have adopted Kubernetes, and that number isn’t moving backward.
What shifted wasn’t the software. Kubernetes didn’t become fundamentally easier between then and now. What changed was the supporting ecosystem. The tooling matured. People figured out how to run it without needing a dedicated team of platform engineers who’d spent two years reading every issue on GitHub. More importantly, the alternative of managing containers without orchestration became untenable faster than anyone predicted. The moment your deployment strategy involves more than three services, the manual approach breaks down.
The real lesson isn’t that Kubernetes won. It’s that distributed systems at scale require some form of declarative orchestration, and Kubernetes happened to be the vehicle that got there first with enough community momentum to stick around. I’ve seen organizations try to avoid it, and I’ve watched them spend more engineering time fighting their own hand-rolled solutions than they would have spent learning Kubernetes properly.
Docker Desktop Isn’t Going Anywhere, Despite Everything
There’s this thread in tech culture where we collectively hold grudges against companies for licensing decisions. Docker Desktop licensing changes created real friction a few years back, and the industry collectively held its breath to see if people would switch to Podman, Colima, or one of the other containerization alternatives. The narrative was compelling: Docker’s time was ending, the community would fork, and proprietary tools would lose.
Except that didn’t happen. Docker Desktop usage has remained steady through all of it. Why? Because switching your entire local development environment costs something too. It costs friction, learning curve, and most importantly, the certainty that your local environment matches what runs in production. Docker Desktop delivers that certainty without requiring extensive configuration. Most developers value that trade-off more than they resent licensing policies.
I use Docker Desktop every day. I’ve tried the alternatives. They’re genuinely fine, and they’re free or cheaper, and I respect what they’ve accomplished. But I stick with Docker Desktop because it works reliably and because the ecosystem is built around it. That’s not exciting, but it’s honest. Docker monetized developer convenience, and enough developers decided that convenience was worth paying for. This doesn’t mean Docker Desktop is perfect or that there aren’t legitimate reasons to choose other options. It just means that having the “right” technical solution sometimes matters less than having the one that integrated most completely into how people actually work.
Platform Engineering Teams Are the Actual Infrastructure Now
If I had to point to one structural shift in how containers changed operations, it would be this: dedicated platform engineering teams are no longer a luxury consideration. They’re table stakes. Organizations with serious container deployments have realized that Kubernetes and the surrounding ecosystem are too complex for general infrastructure teams to manage alongside everything else.
A platform engineering team’s core mission is radical simplification. They take the full complexity of container orchestration, networking, storage, monitoring, and security, then abstract it into a set of simpler APIs and workflows that application teams can use without needing deep Kubernetes expertise. You provision a database. You specify resource requirements. You deploy. The platform team handles the details that used to require three senior engineers arguing about taints and tolerations.
The organizational pattern is becoming standardized now. Platform teams define the paved roads, and application teams walk them. This works because it acknowledges a basic truth: not every team needs to be an infrastructure expert, but every team needs reliable infrastructure. When this division of labor works well, you get faster deployments, fewer configuration errors, and fewer midnight incidents because someone misconfigured a network policy. I’ve seen this transformation happen at five different organizations now, and every time it works, it’s because the platform team took on the burden of complexity instead of distributing it randomly.
Observability Without Touching Your Code
The emergence of eBPF as a real tool for observability is something genuinely interesting happening at the kernel level. For years, observability meant instrumenting your application code. You added libraries, you pushed telemetry, you got visibility. If you wanted to understand what your system was actually doing at runtime, you had to plan for it when you wrote the code.
eBPF changes that equation. It lets you observe system behavior from the kernel without modifying application code. You can trace network packets, system calls, function execution, memory allocation, all without touching a single line of your application. This matters for a few reasons. Legacy systems and third-party applications become visible. You can instrument new behaviors without redeploying. And the burden of observability shifts from application developers to infrastructure teams, which is often where it belongs anyway.
I’ve watched teams adopt eBPF-based tools for security monitoring and performance analysis, and the experience has been consistently positive. The learning curve is real, and the debugging skills needed are different, but the payoff is genuine visibility without the performance tax of application instrumentation. That said, application-level instrumentation isn’t going anywhere. eBPF is a complement, not a replacement. But as a tool for infrastructure teams to understand what’s happening without developer cooperation, it’s unexpectedly powerful.
The Quiet Transformation at the Edges
WebAssembly on the server side is growing quietly in places where it makes sense. I mention this because it’s not getting the hype that browser-side Wasm received, and that’s actually appropriate. Server-side Wasm workloads are filling a real niche: lightweight, fast, sandboxed execution for functions that don’t need the full overhead of a containerized application. Not everything should be Wasm. Most things shouldn’t be. But the places where it fits, it fits well, and adoption is steady.
GitOps has also stopped being interesting and become normal. Organizations with mature DevOps cultures now expect all infrastructure and configuration to live in Git, with automated deployments triggered by commits. This isn’t controversial anymore. It’s just how the work gets done. The CNCF landscape shows dozens of tools built around GitOps principles because the pattern proved itself repeatedly.
The broader insight is that containerization created a foundation for a different kind of operations culture. Once you accept that your application runs in a declarative, versionable package, it becomes natural to version everything else the same way. Configuration, infrastructure, policy. The container wasn’t just a packaging format. It was permission to rethink how we build and deploy systems.
I’d like to hear what you’re seeing in your own work. Kubernetes shops dealing with real complexity, platform teams finding what actually works, observability challenges you’ve solved or are still wrestling with. The best insights come from people doing this work every day. Drop a comment or reach out if you want to talk through what you’re building.
