Cloud Native Is Dead: Long live Container Native, Code First
Oct. 15, 2025TL;DR
“Cloud‑native” has become a vibe, not a set of practices. Let’s bring CNCF back to containers and code, “Container Native, Code First”
So What’s The CNCF?
Depending on who you ask, the Cloud Native Computing Foundation is:
- Home of Kubernetes and hundreds of other tools
- A certification and training shop (CKA/CKAD)
- the Woodstock of tech conferences (KubeCon)
- Or the elephant everyone’s touching differently—governance, marketing, community, and even politics.
In plain english, it’s a gathering of the biggest tech companies with shared interests steering open-source together for everything related to deployments in production by building a community ecosystem around them.
But What’s Wrong With It?
I have two issues with such elephant-sized orgs.
Do OSS projects need a foundation?
Sometimes yes, sometimes not. RedMonk warns that “In the era of the open source rug pull, the role of open source foundations is more important than ever.” (source)
But sustainability is challenging. Former CNCF TOC member Matt Farina notes: “Over the past 3 years the CNCF has seen fewer contributors and committers each year.” (retrospective) When maintainers are concentrated in a handful of companies, you have to wonder if it’s really organic OSS. Here is for instance Kubernetes history by company, with 80% of contributions from paid committers.
It Has Never Been “Cloud Native” Anyway
Take a look at CNCF Landscape. It’s massive. Useful as a directory, sure—but it frames “cloud‑native” as everything from runtimes to databases and feature flags. But MySQL was deployed before cloud computing was even a term. Having that many names dilutes meaning and overwhelms practitioners. As Michael Levan puts it, “There are too many chefs in the kitchen.” (dev.to)
Looking at Wikipedia’s shared definition of “Cloud Native”, it says:
apps built as a set of microservices that run in Docker containers, orchestrated in Kubernetes and managed and deployed using DevOps and Git Ops workflows
Except these characteristics are not a take all or leave it: everything goes on the field, and the “YMMV” factor is a major driver. For instance “microservices” alone is a loaded buzzword. GitOps is also debatable. And DevOps… well don’t get me started on DevOps.
Takeaway: when everything is cloud‑native, nothing is.
Why Should I Care Though?
Naming things right actually matters
The language we use in tech should reflect not just what we’re doing but how and why. “Cloud Native” might tell you what’s excluded— no legacy monolith — but it doesn’t say a thing about design principles. Precision matters for budgets, architecture… and hiring!
Reality check: Containers are the common layer
- Containers: Use is >90% overall;(CNCF annual survey).
Translation: The keyword isn’t “cloud.” It’s containers + code. Containers are the primitive; Code is the principle, and cloud is left as an option for the team: on-prem, public or hybrid.
Then What Do You Suggest?
Change #1: Adopt container‑native by default
Good practice: Default to packaging apps as OCI containers. It’s buying your organization ubiquity superpower. With that, you can prioritize managed services where it’s rational, and keep orchestration proportional to your scale and team size. And if you need Kubernetes, use it; if you (most probably) don’t, please don’t cosplay a hyperscaler.
Change #2: Put code first, platform choices will follow
Driving Principle: Developer experience leads just behind product outcomes; only after will platform choices follow. Tooling galore is not your product.
Practices
- Provide a happy path: one‑command local dev (e.g.,
docker compose up), scaffolded CI, opinionated templates. - Treat security as a dev workflow: SCA, image scanning, policy‑as‑code.
- Prefer service contracts over infra DIY. If a managed service is good enough, it’s good.
PS: if you are interested in code first approach, there is more to grok in my previous blog post “If it’s not in Git, it does not exist”
About the author
I am a DevOps veteran, helping Dev and Ops making sense of the Cloud by applying DevOps principles to their processes and tooling. (let’s talk)
My last book “from Dockerfail to Dockerfile” heavily builds on git, please check it out if you are in Platform engineering, DevSecOps or Cloud Native deployments.
Bonus: Questions to take the conversation to your team
- Where did “cloud‑native” help the team ship faster—and where did it slow it down?
- What would it take for your org to adopt Container Native, Code First for new apps by default?
- Which CNCF project do you rely on today—and what’s your Plan B if its maintainer base shrinks? or a license change suddenly happens?
