CNCF Q1 2026 Report — Why Feature Flagging Is the Hidden Gateway to Cloud Native Maturity

20 million cloud native developers#

The headline number first. The cloud native community has grown to 19.9 million developers, up from 15.6 million in Q3 2025. That’s roughly 39% of every developer on the planet. Almost four in ten of us.

But there’s a wrinkle in the backend data that most recaps are going to skip right over. Among backend developers, 52% are classified as cloud native. That’s a drop from 58% last quarter. Still higher than the 49% we saw a year ago, though. And SlashData doesn’t dodge it: either the 58% in Q3 2025 was inflated, or this is a real quarter-on-quarter correction. Q3 2026 will tell us where the true baseline sits.

One more number worth holding onto. 71% of backend developers use at least one cloud native technology, but only 52% clear the classification bar (which means using 3+ technologies). That 19-percentage-point gap? Those are people in the early innings of adoption. They’ve picked up a tool or two, but they’re not running a mature stack yet.

Cloud native stopped being an emerging technology a while ago. It’s now what git became a decade ago. The default baseline skill.

Containers became invisible#

Container usage in the survey fell from a steady 60%-plus all the way down to 40%. Glance at that and you’d assume containers are dying.

They aren’t. They just turned into infrastructure.

Some of the drop is methodology, plain and simple. SlashData widened the definition of a backend developer to fold in web backend folks who work through higher-level services. Run the model with the old historical definition and container adoption is actually 58%, not 40%. So changing who got surveyed mechanically dragged the number down.

The deeper story is the one that matters. 88% of backend developers now work with some form of infrastructure standardization, up from 80% six months ago. And the slice of developers with no formalized platform or DevOps practices dropped from 20% to 12%.

Platform engineering teams went and built internal developer portals. You click “deploy,” and somewhere underneath there’s Kubernetes, containers, orchestration, all of it humming along. You just never see it. No Dockerfile. No SSH-ing into a cluster.

The report has a striking example here. 39% of backend developers use microservices, yet only 27% explicitly say they use Kubernetes, even though microservices usually run on it. So the report poses a blunt question. When a developer ships a containerized app through an IDP without ever touching a Dockerfile, do they even think of themselves as a “container user”?

Containers haven’t gone anywhere. They’ve become the electrical wiring in your office. Critically important. Completely invisible until the moment something fries.

And this is where I get a little nervous, and so do the report’s authors. They say it outright: organizations need to make sure infrastructure expertise still exists within teams to manage, troubleshoot, and optimize the platforms that enable productivity. So when the platform breaks at 2am, who on your team actually knows what’s under the hood?

I lurk in the DevOps communities, Reddit, Hacker News, the K8s Slack, and over the last six months a pattern has gotten really hard to miss. More and more mid-level developers are asking genuinely basic questions about kubectl. These are not juniors. These are people who’ve been deploying through an internal portal for three years and have literally never seen raw Kubernetes.

Feature flagging, the report’s biggest surprise#

This is the finding that makes the whole report worth your afternoon.

For the first time, SlashData ran association analysis. That means looking at which technologies show up together more often than random chance would predict. The metric is called “lift.” A value above 1.0 means the technologies are connected. Above 1.7 is a strong connection.

The data shook out into three tiers of maturity:

• Foundational: Kubernetes + microservices. The price of admission.
• Mainstream: Observability, streaming/messaging, event-driven architecture. Operational sophistication.
• Advanced: Immutable infrastructure, chaos engineering, service meshes. Only 6-7% of teams are here (immutable 7%, chaos 6%).

So the real question becomes: what actually moves a team from mainstream to advanced?

Your gut says more Kubernetes, or some fancy service mesh. Sounds reasonable. The data says no. The answer is feature flagging.

The specific lift numbers spell out why. Feature flagging has a strong link to mainstream and advanced practices at the same time:

• with observability tools: 1.53
• with event-driven architecture: 1.45
• with chaos engineering: 1.44
• with multicluster management: 1.40
• with immutable infrastructure: 1.33

It’s literally the bridge between tiers 2 and 3. For anyone who hasn’t lived with it: feature flags let you deploy code to production without showing it to users right away. You roll a feature out to 5%, watch the metrics, then keep going. Or you roll it back without redeploying a thing.

The report explains the gateway effect like this. Feature flagging drills two ideas into a team. Decoupling deployment from release, and incremental testing on a subset of traffic. Those mental models carry straight over into advanced practices, chaos engineering (controlled failure injection) and immutable infrastructure (deployments as disposable experiments).

When I asked Liam about all of this, he handed me the context that never made the PDF:

“We did the analysis blind, so as not to put any of our expectations on it. However, for several years we have been grouping these cloud native practices and technologies into three groups on usage rates (entry, mainstream, advanced). This has kind of been normalised as a description, but has previously lacked the data to demonstrate that this tiered approach reflects an actual journey of maturity. During the analysis, we found validation for our previous descriptions, but were surprised by how pivotal feature flagging as a practice was to the cloud native maturity journey. Bringing this to people I consider experts in this space, the general consensus was that it ‘makes sense’ for feature flagging to be so important to engaging in the elite cluster of practices, but they would not have predicted how important it was.”

— Liam Bollmann-Dodd, Principal Market Research Consultant, SlashData

There’s an important nuance buried here: there are two roads to the advanced tier, not one. You get there through experimentation maturity (feature flagging) or through operational visibility (observability tools, which carry a 1.33 lift with immutable infrastructure). But feature flagging is the friendlier on-ramp.

Why does that matter in practice? Because you can stand up feature flagging without re-architecting your whole system. It isn’t a months-long migration. For teams stuck spinning their wheels in the mainstream tier, the data hands you a specific, actionable answer.

One last detail, and it’s a good one. The strongest connection in the entire dataset is immutable infrastructure + chaos engineering, sitting at 2.22. Which tells you that teams reaching the advanced tier don’t pick these practices off one at a time. They adopt them as a bundle. The advanced tier isn’t a gradient. It’s a cluster. You’re either in it or you’re not.

AI teams are taking a different path#

Here’s where the data gets genuinely fun. AI teams are not walking the same maturity path as backend teams.

For your standard backend developer, immutable infrastructure is an elite-tier destination (that 2.22 lift with chaos engineering). For AI teams? Immutable infrastructure is a gateway technology they reach for early.

Why? Reproducibility. The report says it plainly: for AI teams, immutable infrastructure ensures reproducible training environments and consistent deployment artifacts. Plenty of AI teams park in the experimentation phase, where reproducibility is everything and chaos testing simply isn’t. Which is exactly why, for AI, immutable infrastructure is bound more tightly to observability (1.58) than to chaos engineering (1.28, versus 2.22 for general backend).

The second surprise is remote procedure calls (RPC). In standard backend development, RPC is nearly invisible. For AI teams the connection between RPC and feature flagging jumps to 2.07 (against 1.16 for general). That tracks with how central RPC is to model inference APIs, distributed training, and feature store access.

So the practical takeaway for anyone building platforms for AI teams:

• Not every AI team needs production-scale complexity. Many legitimately stop at the experimentation or training stage.
• Feature flagging and immutable infrastructure are dual prerequisites for production AI. This is a key bottleneck.
• Service mesh, chaos engineering, and multicluster management need to be framed specifically for AI: traffic splitting for A/B testing models, resilience testing for model degradation, geo-distributed inference. Don’t use generic infrastructure benefits to sell it.

If your org runs both backend services and AI workloads, then your platform team is quietly building toward two completely different definitions of “good” all at once.

What didn’t make the report#

I asked Liam whether anything interesting in the data got left on the cutting room floor. His answer turned out to be the most valuable bit of the whole conversation.

The report notes that 88% of developers work with some form of DevOps standardization, but the approaches swing wildly for organizational reasons. Liam flagged this as a personal interest of his. The shift-left and shift-right approaches to standardization.

A few specifics he gave me:

• Highly regulated industries (finance, healthcare) get aggressive about standardization.
• SaaS companies lean toward looser standardization.
• Developer density at a company is a major driver of which methods get chosen.

And here’s his core message to vendors:

“…most teams are working with extreme constraints on capital, people, or tool access. As such, I want to continually remind vendors and platform tooling companies that for many organisations it is heterogenous mess of a tech stack that is held together more by hope than a perfectly designed and architected system.”

— Liam Bollmann-Dodd

Sit with that one for a second. Conversations about “good engineering teams” love to get stuck in philosophy. Framework choices. Endless debates about architectural purity. Meanwhile actual teams are operating under brutal constraints. Their stack is whatever managed to survive three reorgs, two cloud migrations, and an acquisition.

That’s not a failure on their part. It’s the real operating environment of cloud native development in 2026.

I read engineering blogs, incident post-mortems, community Slack threads. Liam’s point checks out everywhere I look. Teams from scrappy startups to FAANG describe their stacks the exact same way. “It’s a mess, but it works.” The only thing that changes is how willing they are to say it out loud.

What I’m watching for in Q2#

When the Q2 report lands (usually June-July), here’s my list:

1. Will the backend cloud native percentage steady out? 52% in Q1, after 58% in Q3 2025. SlashData themselves say Q3 2026 reveals the true baseline. This is a leading indicator for the health of cloud native adoption.
2. Will feature flagging graduate from “predictor” to “default”? The report has now named feature flagging as a gateway. Will engineering leaders read that and actually move? If adoption spikes among mainstream teams, we’ll know industry research is genuinely steering decisions.
3. Will the gap between AI and backend paths get wider? Q1 showed AI teams using immutable infrastructure as a gateway rather than a destination, and RPC as critical for them. Q2 tells us whether that’s a stable pattern or just an artifact of where AI maturity sits today. My money’s on stable.
4. Will the advanced tier stay rare? It’s at 6-7% right now. If Q2 shows growth, something shifted in tooling accessibility. If it stays flat, we’re staring at a genuine industry ceiling, meaning most teams will never reach the advanced tier no matter how many conference talks get given on chaos engineering.
5. What new analytical trick will SlashData pull out? Q1 introduced association analysis with the lift metric and journey maps. That was a serious methodological leap. So what does Q2 add?

Practical takeaways for right now#

Don’t sit on your hands waiting for Q2. Q1 already handed us things to act on today:

• If your team is stuck in the mainstream tier, take a hard look at your feature flag tooling and discipline. The lift data says this is your most reliable bridge to the advanced tier. The backup route is through observability.
• If your developers can’t pop the hood on a container when it breaks, you’ve got a training gap. The report says it flat out: make sure infrastructure expertise actually lives inside your team.
• If your platform serves AI workloads, remember those teams are on a different path. Immutable infrastructure is their gateway, not their destination. And RPC matters more than you think.
• If your stack is held together by hope and stale Confluence docs, congratulations, you’re in the majority. That isn’t a failure. The only failure is pretending otherwise in roadmap meetings.

The Q1 2026 report gave us the data. Q2 will tell us what we actually did with it.

The State of Cloud Native Development Q1 2026 report was published by CNCF and SlashData based on the 31st wave of the Developer Nation survey (December 2025 — January 2026). 12,800+ developers across 100+ countries. Liam Bollmann-Dodd, Principal Market Research Consultant at SlashData and author of the report, provided exclusive commentary for this article.