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

20 million cloud native developers#

The headline number: the cloud native community has grown to 19.9 million developers, up from 15.6 million in Q3 2025. That’s roughly 39% of the entire global developer population. Almost four in ten.

But there’s a nuance in the backend data that a lot of recaps will miss. Among backend developers, 52% are classified as cloud native. That’s a drop from 58% last quarter, though still higher than the 49% we saw a year ago. SlashData is honest about this: either the 58% in Q3 2025 was inflated, or we’re seeing a real quarter-on-quarter correction. Q3 2026 will show us where the true baseline is.

Another number to keep in mind: 71% of backend developers use at least one cloud native technology, but only 52% pass the classification threshold (meaning they use 3+ technologies). That 19-percentage-point gap represents people in the early stages of adoption — using one or two tools but not yet running a mature stack.

Cloud native is no longer an emerging technology. It’s become what git became a decade ago: the default baseline skill.

Containers became invisible#

Container usage in the survey dropped from a steady 60%+ down to 40%. At first glance, you might think containers are dying.

But they aren’t. They just became infrastructure.

Part of the drop comes down to methodology. SlashData expanded the definition of a backend developer to include web backend devs who work through higher-level services. If you model it using the historical definition, container adoption is actually at 58%, not 40%. So the shift in who was surveyed mechanically lowered the number.

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

Platform engineering teams built internal developer portals. You hit “deploy,” and under the hood, there’s Kubernetes, containers, and orchestration. But you don’t see it. You don’t write a Dockerfile. You don’t SSH into a cluster.

Here’s a striking example from the report: 39% of backend developers use microservices, but only 27% explicitly state they use Kubernetes — even though microservices usually run on it. The report asks a very direct question: when a developer deploys a containerized app through an IDP without writing a single Dockerfile, do they even consider themselves a “container user”?

Containers haven’t disappeared. They’ve become like the electrical wiring in your office: critically important, but invisible until something breaks.

And here is my concern, which the report’s authors share. They explicitly state: organizations need to make sure infrastructure expertise still exists within teams to manage, troubleshoot, and optimize the platforms that enable productivity. When the platform breaks, who in your team actually knows what’s under the hood?

I follow the discussions across DevOps communities — Reddit, Hacker News, K8s Slack — and over the last six months, a clear pattern has emerged. More and more mid-level developers are asking very basic questions about kubectl. These aren’t juniors. These are people who have been deploying via an internal portal for three years and have never seen raw Kubernetes.

Feature flagging — the report’s biggest surprise#

This is the finding that makes reading the entire report worth your time.

For the first time, SlashData used association analysis — looking at which technologies are used together more often than chance would dictate. The metric is called “lift”: a value above 1.0 means the technologies are connected; above 1.7 is a strong connection.

The data revealed 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%).

The question is: what moves a team from mainstream to advanced?

You might think it’s more Kubernetes or an advanced service mesh. That sounds logical. But the data says otherwise. The answer is feature flagging.

The specific lift numbers from the report show why. Feature flagging has a strong connection to both mainstream and advanced practices simultaneously:

• 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

Feature flagging is literally the bridge between tiers 2 and 3. For those who haven’t worked with it: feature flags allow you to deploy code to production without showing it to users immediately. You roll a feature out to 5%, watch the metrics, and proceed. Or you roll it back without redeploying.

The report explains why this acts as a gateway: feature flagging teaches teams two things — decoupling deployment from release, and incremental testing on a subset of traffic. These mental models translate directly to advanced practices like chaos engineering (controlled failure injection) and immutable infrastructure (deployments as disposable experiments).

When I asked Liam about these findings, he gave me the context that didn’t make 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

An important nuance here: there are two paths to the advanced tier, not one. You can get there through experimentation maturity (feature flagging) or through operational visibility (observability tools, which have a 1.33 lift with immutable infrastructure). But feature flagging is the more accessible entry point.

Why does this matter practically? Because you can implement feature flagging without re-architecting your entire system. It’s not a months-long migration. For teams stuck in the mainstream tier, the data provides a specific, actionable answer.

One more detail: the strongest connection in the entire dataset is immutable infrastructure + chaos engineering, at 2.22. This means teams that reach the advanced tier don’t adopt these practices one by one; they adopt them as a package. The advanced tier isn’t a gradient; it’s a cluster. You are either there, or you aren’t.

AI teams are taking a different path#

This is where the data gets genuinely fascinating. AI teams are not following the same maturity path as backend teams.

For standard backend developers, immutable infrastructure is an elite-tier destination (the 2.22 lift with chaos engineering). For AI teams, immutable infrastructure is a gateway technology that they adopt early.

Why? Reproducibility. The report explicitly states that for AI teams, immutable infrastructure ensures reproducible training environments and consistent deployment artifacts. Many AI teams stay in the experimentation phase, where reproducibility is critical, but chaos testing is not. That’s why, for AI, immutable infrastructure is connected more strongly to observability (1.58) than to chaos engineering (1.28, compared to 2.22 for general backend).

The second surprise is remote procedure calls (RPC). In standard backend development, RPC is almost invisible. For AI teams, the connection between RPC and feature flagging hits 2.07 (versus 1.16 for general). This reflects the centrality of RPC for model inference APIs, distributed training, and feature store access.

The practical takeaway here for anyone building platforms for AI teams:

• Not all AI teams need 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 organization runs both backend services and AI workloads, your platform team is building toward two completely different definitions of “good” at the same time.

What didn’t make the report#

I asked Liam if there was anything interesting in the data that didn’t make the final cut. His answer turned out to be the most valuable part of the conversation.

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

Some specific examples he gave:

• Highly regulated industries (finance, healthcare) are more aggressive about standardization.
• SaaS companies prefer looser standardization.
• Developer density at a company is a major driver of the methods chosen.

And here is 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

That is worth thinking about. Discussions about “good engineering teams” often get stuck in philosophy — framework choices, debates about architectural purity. Meanwhile, real teams are operating under extreme constraints. Their stack is whatever survived three reorgs, two cloud migrations, and an acquisition.

That isn’t a failure on their part. It’s the actual operating environment of cloud native development in 2026.

I read engineering blogs, incident post-mortems, and community Slack discussions. Liam’s point is validated everywhere. Teams from startups to FAANG describe their stacks the exact same way: “it’s a mess, but it works.” The only difference is how willing they are to admit it publicly.

What I’m looking for in Q2#

When the Q2 report comes out (usually June-July):

1. Will the backend cloud native percentage stabilize? 52% in Q1 after 58% in Q3 2025. SlashData themselves say Q3 2026 will reveal the true baseline. This is a leading indicator of the health of cloud native adoption.
2. Will feature flagging move from a “predictor” to a “default”? Now that the report has named feature flagging as a gateway, will engineering leaders read this and take action? If adoption spikes among mainstream teams, we’ll know that industry research is actually influencing decisions.
3. Will the gap between AI and backend paths widen? Q1 showed that AI teams use immutable infrastructure as a gateway, not a destination, and that RPC is critical for them. Q2 will tell us if this is a stable pattern or just an artifact of the current stage of AI maturity. I’m betting on a stable pattern.
4. Will the advanced tier stay rare? Currently at 6-7%. If Q2 shows growth, something has changed in tooling accessibility. If it stays flat, we’re looking at a genuine industry ceiling, meaning most teams will never reach the advanced tier regardless of how many conference talks there are on chaos engineering.
5. What new analytical approach will SlashData introduce? Q1 introduced association analysis with the lift metric and journey maps. That was a serious methodological leap. What will Q2 add?

Practical takeaways right now#

Don’t wait for Q2 to act. Q1 gave us actionable items today:

• If your team is in the mainstream tier and feels stuck, evaluate your feature flag tooling and discipline. The lift data says this is your most reliable bridge to the advanced tier. The alternative path is through observability.
• If your developers can’t look under the hood of a container when something breaks, you have a training gap. The report explicitly warns: make sure infrastructure expertise actually exists within your team.
• If your platform serves AI workloads, remember that AI teams are on a different path. Immutable infrastructure is their gateway, not their destination. RPC is more critical than you think.
• If your stack is held together by hope and outdated Confluence docs, you are in the majority. That is not 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 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.