Month: March 2026

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.

The Headcount Paradox: We Built It, But They Didn’t Come

Here’s something that keeps me up at night, and I suspect it’s keeping your VP of Engineering up at night too. Gartner called it back in 2023: by 2026, roughly 80 percent of large organizations would spin up dedicated platform engineering teams. They nailed that forecast. Walk into any sufficiently complex engineering org today and you’ll find them. Dedicated team, budget line, Slack channel, the whole setup. The problem is that none of this actually guarantees developers will use the thing.

We’ve created a curious inversion of the usual tech adoption curve. Instead of building something and watching people gradually discover its value, we’ve built the whole infrastructure, hired the teams to maintain it, established governance around it, and then watched developers find creative ways to bypass it. I’ve been in rooms where a platform team proudly demos their new microservices deployment workflow to an audience of engineers who are already three commits deep into their own ad-hoc bash script approach. The disconnect is real.

The irony deepens when you look at the data. Teams with genuinely mature internal developer platforms see deployment frequency that’s roughly 2.5 times higher than those without them, and their change failure rates drop accordingly. The DORA State of DevOps Report 2025 hammers this home with the kind of consistency that makes you wonder why adoption isn’t at 95 percent instead of hovering around 60 percent. But it is, and understanding why requires getting uncomfortable with some uncomfortable truths about how we actually build platforms.

The Cognitive Tax: Why Your Platform Feels Like Homework

I watched a senior engineer spend forty-five minutes last month trying to onboard onto our internal platform. Not trying to deploy something. Not trying to solve a problem. Just trying to understand how to get set up. At the end of it, they looked at me and said, quietly, “I could have written a deploy script in this time.” They weren’t wrong. That’s the moment you realize your platform has a problem that no amount of documentation can fix.

The Puppet State of DevOps 2025 survey uncovered the two reasons developers cite most often for skipping their internal platforms entirely: the cognitive overhead of onboarding, and the simple fact that the platform doesn’t integrate with how they already work. These aren’t minor usability quibbles. These are deal-breakers. A platform that requires developers to learn new abstractions, new terminology, and new workflows before they can ship code isn’t a platform. It’s a tax on velocity.

What makes this particularly frustrating is that it’s fixable, but fixing it requires platform teams to do something counterintuitive: listen to the people who aren’t using the platform. Not the power users. Not the early adopters who find the whole thing delightful. Listen to the people who looked at your beautiful abstraction layer and decided it was faster to kubectl apply their way through the problem. Those developers aren’t lazy. They’re efficient. And if your platform made them less efficient, that’s not a developer problem. It’s a platform design problem.

Backstage, OpenTofu, and the Age of Pragmatism

The CNCF Backstage project page shows you a framework already running in production at over 3,000 companies. That sounds impressive until you do the math. Internal surveys from the community reveal that actual active usage among eligible developers sits somewhere south of 50 percent at most large enterprises. You’ve got this developer portal framework that half your developers have basically ghosted. The platform exists. The infrastructure exists. Technically, adoption exists too, but it’s a statistical ghost.

What’s been more interesting to watch is the migration pattern around Terraform and its various cousins. When HashiCorp got acquired by IBM in 2024, the licensing and pricing shifted in ways that spooked a lot of platform teams. Enter OpenTofu, the open-source fork that hit 4 million downloads per month by early 2026. This tells you something important: developers and platform teams will vote with their feet when they feel squeezed. More importantly, they’ll move toward tools that feel like they’re built with them in mind, not around them.

The lesson here isn’t about specific tools. It’s that the successful platforms in 2026 are the ones that understand their users well enough to get out of the way. Backstage works when it’s not trying to be everything. OpenTofu succeeded because it respected the workflow people were already using. Platforms that enhance existing practices beat platforms that demand new ones. Every time.

What Actually Works: The Unsexy Secret

The platform teams that are winning right now are doing something that sounds almost embarrassingly simple. They’re starting with the workflows developers are already using and adding incremental value on top. No big abstractions. No mandatory rearchitecture. Just one small thing that makes the thing they’re already doing slightly better. Then another small thing. Then another.

This approach feels glacial to platform engineers. There’s no big reveal moment. No architectural elegance to write a conference talk about. But it works because it respects the reality that developers are not waiting around for your perfect platform. They’re shipping code today with the tools they have. If you want them to switch to something new, you need to be so clearly better that the switching cost is worth it, and you need to make that obvious immediately.

The organizations I know that have cracked adoption above 70 percent share a characteristic: they measure what matters. Not platform team throughput or configuration management efficiency or any of the usual platform metrics. They measure developer satisfaction with deployment velocity. They measure time to first commit in a new service. They measure the number of decisions developers have to make before code can ship. And then they obsess over making those numbers better. When you lead with what actually matters to developers, adoption stops being a marketing problem and starts being a natural outcome.

The Conversation Worth Having

If your platform adoption is stuck in the 40 to 60 percent range, the numbers suggest you’ve got one of the best-resourced team problems in engineering. You have the budget, the headcount, the executive support, and the infrastructure. What you might not have is alignment between what you’ve built and what developers actually need. That’s worth investigating with genuine curiosity rather than defensiveness. Your developers aren’t being difficult. They’re being rational actors in a system that hasn’t yet made the new tool obviously better than the old approach.

I’d love to hear what you’re seeing on your end. Are you running a platform team? Are you the developer sitting here thinking all of this sounds familiar? Have you figured out something that actually moved the needle on adoption? Drop me a line. The platform engineering conversation is only interesting if we’re actually being honest about where we are and what’s not working.

The Headcount Paradox Nobody Talks About

By now, you’ve probably noticed that nearly every large engineering organization has a platform engineering team. Gartner called it back in 2023, predicting that 80% of enterprises would have dedicated platform teams by 2026, and they weren’t wrong. Walk into any Fortune 500 tech org and you’ll find someone whose business card says “Platform Engineer.” The problem is that while the headcount materialized right on schedule, developer adoption never quite showed up to the party.

This is where things get interesting. You can build the most elegant internal developer platform, staff it with brilliant engineers, and still watch three-quarters of your team ignore it in favor of their own scripts and workarounds. I’ve seen this pattern repeat enough times across different organizations to know it’s not a bug in execution. It’s a structural problem that most platform teams don’t adequately address until they’re already six months into wondering why adoption is stuck at 40% to 50%.

The teams that actually cracked this problem have something in common: they stopped thinking of adoption as a marketing problem and started treating it like a product problem. That distinction matters more than it probably should.

The Evidence Is Right There in the Data

The DORA State of DevOps Report 2025 dropped some genuinely compelling numbers. Organizations with mature internal developer platforms deploy 2.5 times more frequently and see significantly lower rates of change failures. That’s not marginal improvement. That’s the kind of lift that actually moves the needle on your incident response metrics and gets you out of Friday night firefighting sessions.

But here’s the twist: those numbers are dominated by the organizations that already achieved high adoption. The teams stuck in the middle, the ones with a platform that technically exists but that half their developers actively avoid, don’t see those benefits. They get the cost of maintaining the platform with almost none of the upside. It’s like paying for a gym membership and never going past the lobby.

Take Backstage. The CNCF Backstage project page shows over 3,000 companies running it in production, which is genuinely impressive for an open-source project. Except when you dig into the community discussions and internal case studies, you find that most of those deployments are running somewhere between 30% and 50% active usage among the eligible developer population. Three thousand successful implementations masking a massive adoption ceiling nobody seems comfortable discussing publicly.

Why Developers Are Choosing the Workaround

The 2025 Puppet State of DevOps survey asked a straightforward question: why aren’t developers using the platform? The top two answers were refreshingly honest. First, “too much cognitive overhead to onboard.” Second, “not integrated with our actual workflows.” Notice what’s absent from that list? Philosophical objections to the platform’s existence or fundamental disagreements about its value proposition.

Developers aren’t rejecting internal platforms because they’re fundamentally broken concepts. They’re rejecting them because the friction to adoption exceeds the perceived benefit. A developer’s immediate workflow runs in their IDE, their terminal, and their git client. If your internal platform requires context-switching through a web portal with three layers of navigation and authentication that doesn’t integrate with their usual tools, you’ve already lost half your battle before anyone even tries to use it.

I watched one organization spend eight months building an absolutely gorgeous Backstage implementation. Custom plugins, beautiful UI, integrated service templates, the whole production. Then they watched adoption plateau at 35% because developers still had to log into a separate system, navigate to the service catalog, find their component, and trigger a workflow when they could just run a shell script they’d written three years ago that lived in their home directory. The friction math didn’t work in the platform’s favor.

The winning organizations solved this by moving the platform to where developers already live. GitHub interfaces, IDE extensions, CLI tools that hook into existing command palettes. The adoption curve looks fundamentally different when you reduce context-switching from four steps to one.

The Infrastructure Decisions That Ripple Forward

Here’s something that doesn’t get enough attention in platform engineering discussions: your infrastructure tooling choices have downstream effects on adoption that go far beyond infrastructure itself. HashiCorp’s 2024 acquisition by IBM triggered pricing and licensing changes for Terraform that rippled through platform teams everywhere. A lot of organizations that built their internal platforms on top of Terraform-centric workflows suddenly faced uncomfortable conversations about licensing costs and contractual terms.

That shift pushed significant momentum toward OpenTofu, the open-source fork that hit 4 million downloads per month by early 2026. The technical reasons are solid, but the adoption story matters here too: when a platform team’s foundational tooling becomes a friction point, that friction propagates upward to every developer trying to use the platform built on top of it. Suddenly your onboarding story includes “and by the way, here’s why we switched away from the tool you saw in that blog post.” That’s not a selling point.

The lesson here isn’t about Terraform specifically. Platform decisions that feel like infrastructure concerns actually have direct effects on user experience and adoption. When you’re evaluating the tools and frameworks that will underpin your internal platform, that downstream adoption impact belongs on your evaluation rubric right alongside technical merit and operational overhead.

What Actually Moves the Needle

The platform teams I’ve watched reach 70% to 80% adoption share a few consistent patterns. They obsess over the first-use experience with an intensity that borders on fanatical. They measure activation metrics like they’re tracking production SLOs. They build integrations into existing workflow tools rather than asking developers to add new tools to their already-crowded stack. And they iterate based on actual usage telemetry, not just on feature requests from leadership.

They also tend to accept that 100% adoption probably isn’t realistic or even necessary. The goal isn’t unanimous adoption. The goal is getting adoption high enough that the platform’s positive effects become self-reinforcing. When enough developers are using the platform to drive meaningful deployments and incident response, when that becomes the cultural norm and the workarounds become the outliers, adoption stops being a problem you have to solve and becomes a natural emergent property of your engineering culture.

If you’re sitting in a 40% adoption situation right now, the good news is you’ve already done the hard part. Your platform exists. Your infrastructure is in place. What you’re missing is optimization for human friction, and that’s something you can actually fix. Start measuring adoption like you’d measure any user-facing product. Find three developers who actively avoid your platform and schedule honest conversations with them. Read their feedback as design requirements rather than excuses. That’s where the real work happens.

The Numbers Don’t Lie, But They Do Scream

The CISA Known Exploited Vulnerabilities catalog crossed 1,200 entries in late 2025. That’s not a milestone to celebrate with champagne. It’s a fire alarm you’ve been hearing for three years and finally decided to acknowledge while scrolling through Slack.

Here’s what matters: federal agencies are legally required to patch anything flagged as critical severity within 15 days under BOD 22-01. Fifteen days. In an enterprise of any meaningful size, that’s the time it takes to get through three steering committee meetings, one surprise production incident, and the inevitable discovery that your asset inventory is incomplete. The compliance theater is real. The actual security posture is another story entirely.

What makes this worse isn’t the size of the catalog. It’s the velocity. CISA added 47 actively exploited vulnerabilities in January 2026 alone, including multiple zero-days hitting Palo Alto Networks PAN-OS and Ivanti Connect Secure systems. Both vendors had already released patches. Both. Already. Released. And yet organizations were still discovering exploitation attempts against unpatched instances. This isn’t a supply chain problem. This is a process problem wearing a compliance costume.

The Exploit Window Is Collapsing in Real Time

The median time between CVE publication and active exploitation has compressed to five days as of 2024, down from 32 days in 2021. Let that number sink in. You have a work week. Five business days if you’re optimistic about meeting before Monday rolls around again. The Verizon 2025 Data Breach Investigations Report documents this precisely because this isn’t speculation anymore. This is measured, observed reality.

Most patch management processes were designed for a 90-day cycle. Test in dev, validate in staging, schedule maintenance windows, communicate to stakeholders, execute during a Tuesday at 2 AM when nobody’s looking. That was the playbook when exploits took a month to materialize. Now you’re running a process built for a completely different threat environment. It’s like using a flip phone to respond to urgent messages. Technically possible. Obviously broken.

The worst part: threat actors aren’t waiting for you to get your act together. They’re actively scanning for unpatched instances of known exploited vulnerabilities. They’ve already written the tooling. They’re already automating the reconnaissance. The only variable left is how long your systems stay visible.

You’ve Got 40,000 New CVEs Per Year. Your Triage Team Has Eight People.

The National Vulnerability Database processed over 40,000 new CVEs in 2024. That’s a 38 percent increase from 2022. Your security team’s response to this information was probably to add one more alert feed to your SIEM and call it a day. That works until 3 AM when the pager goes off because something that was supposed to be filtered actually reached your infrastructure.

Automated triage pipelines are buckling under this load. Most organizations are still using keyword matching and CVSS scores as primary filters. That’s a heuristic from 2015. It doesn’t account for asset criticality, compensating controls, or actual exploitability. So you end up treating CVE-2024-XXXX affecting an obscure font rendering library the same as CVE-2024-YYYY affecting your primary authentication infrastructure. Efficiency: zero. Alert fatigue: maximum.

The CISA Known Exploited Vulnerabilities Catalog is supposed to help with this. It does, to a point. But using KEV as your sole intelligence feed means you’re always one step behind. By definition, these vulnerabilities are actively exploited. You’re defending against yesterday’s threats while tomorrow’s are already in the development queue.

The Patch Availability Paradox Is Still Breaking Your Security Model

Here’s the number that should actually keep you awake: 60 percent of breaches in recent studies involved known vulnerabilities where patches had existed for more than 30 days before exploitation. Thirty days. Most organizations have patch windows scheduled monthly. The math here is not complicated. Patches exist. Organizations are breached. The patch was available the whole time.

This isn’t about technical capability. Vendors are shipping patches. Automation tools can deploy them. The blockage is organizational. It lives in change control boards that meet infrequently. It lives in the disconnect between security teams saying “this is critical” and operations teams saying “we have another five critical items already scheduled.” It lives in the fact that nobody’s willing to stake their career on patching without a maintenance window because the last time someone tried that, production went dark for six hours.

The vulnerability disclosure timeline hasn’t changed much. Vendors still operate on their own schedules. But the exploitation timeline has become ruthless. You’re stuck trying to run a careful, deliberate process in an environment that rewards speed and punishes hesitation. The system is optimized for patch management theater, not actual vulnerability remediation.

What Does Actually Matter, Then

Forget compliance metrics for a moment. Forget the KEV catalog milestone. Focus instead on asset visibility, prioritization criteria that actually reflect risk, and patch deployment mechanisms that don’t require seventeen approval layers. Some organizations are running quarterly security validation cycles instead of monthly patches, with real-time vulnerability scanning to catch drift. Others have implemented micro-segmentation to limit blast radius, reducing the urgency of individual patches to a manageable priority level. None of these are silver bullets. All of them work better than pretending you can manually triage 40,000 CVEs per year.

The uncomfortable truth: your patch management process isn’t broken because you lack tools. It’s broken because you’re optimizing for the wrong variables. You’re measuring time-to-patch instead of time-to-safe-state. You’re treating every CVE as equally important instead of letting data about actual exploitation drive your priorities. You’ve built processes that made sense in 2015 and are now wondering why they don’t scale.

The CISA KEV catalog hitting 1,200 entries is just a symptom. The real problem is sitting in your current change control board meeting, where someone’s explaining why a critical patch needs to wait another week for the next maintenance window. That’s where the vulnerability lives. What’s your process actually optimizing for?