Why I Stopped Saying 'Cloud Native'
The phrase has become noise. Here's what to say instead.
Cloud native used to mean something specific. After a decade of dilution, the term means whatever the speaker wants it to mean. I've stopped using it, and I think you should too.
I stopped using the phrase "cloud native" about two years ago, and almost nobody has noticed. That's actually the point. The phrase has become noise. It either means everything or nothing depending on who's saying it, and that makes it useless in technical conversation.
What it used to mean
The original CNCF definition is reasonable: applications that scale dynamically, are resilient to failure, run on commodity infrastructure, and embrace declarative APIs. It was a real answer to a real question in 2015.
Twelve apps that were cloud-native in 2015: Kubernetes, Prometheus, Envoy, Istio, the early CNCF projects. They had a coherent worldview.
What it means today
Today "cloud native" is used to describe:
- Apps that run on AWS Lambda. (Serverless, distinct from CNCF's original framing.)
- Apps that run in Kubernetes. (The original framing.)
- Apps that use a managed database. (Almost every app today.)
- Apps that have a CI/CD pipeline. (Almost every app today.)
- Anything new that the marketing team wants to make sound modern.
When a phrase covers everything, it stops carrying information. "Cloud native" is now in that bucket along with "AI-powered" and "enterprise-ready". They're filler.
What I say instead
When I want to be specific, I'm specific:
- "Runs on Kubernetes" or "runs on managed compute".
- "Stateless behind a load balancer" or "stateful with a managed database".
- "Multi-region active-active" or "single-region with regional failover".
- "Horizontally scalable" or "vertically scaled, not designed for horizontal".
Each of these is a concrete architectural claim. Each one can be wrong. That makes it useful.
Why this matters in client conversations
When a CTO tells me their stack is "cloud native", I learn nothing. When they tell me "Spring Boot on EKS, Postgres on RDS Multi-AZ, Redis ElastiCache, deploys via ArgoCD", I learn the actual architecture. I can ask sharper questions. I can spot risks. The conversation moves from marketing to engineering.
I now actively redirect when clients use vague language. "When you say cloud native, do you mean Kubernetes, or serverless, or just running in AWS?" Half the time, they don't know, and that itself is a finding.
Other phrases I've stopped using
- "Best in class", because every product has self-described itself this way.
- "Enterprise grade", because nobody can define it and everyone uses it.
- "AI-powered", because at this point everything is, including the toaster.
- "Microservices" without a specific count and a reason. Almost every codebase I see calling itself microservices is actually a distributed monolith.
- "Serverless" without a specific runtime. Lambda, Cloudflare Workers, and Vercel Functions have very different operational profiles.
What good technical language looks like
I'd rather a CTO say something specific and slightly wrong than something vague and correct. A specific claim that's slightly wrong leads to a productive conversation. A vague claim that's correct leads nowhere.
When I write a doc or talk to a client, my rule is: every sentence should be falsifiable. If you couldn't disagree with what I just said, I haven't told you anything.
A small experiment
For the next two weeks, count how often you hear "cloud native" in meetings, podcasts, and on LinkedIn. Then count how often, in the same conversation, the speaker said anything specific about the actual architecture.
The ratio is usually striking. The phrase is doing very little work.
What replaces buzzwords
Concrete examples. Numbers. Architectures. Trade-offs. Failure modes.
If I'm describing a system to a CTO, I'd rather say "we run 200 RPS sustained, p95 latency 150ms, on three c6i.large instances behind ALB, primary Postgres with two read replicas" than "it's cloud native". The first sentence is specific enough to disagree with. The second is a placeholder.
The sharper insight
The vocabulary you use determines the questions you can ask. When a team's working language is full of vague terms, the questions they ask each other are also vague. When the language is specific, the questions sharpen. Buzzwords feel professional. They're actually a tax on communication. The teams I've seen do the best engineering work share a habit: they speak about specifics, even when it sounds blunt.
Try it for a sprint. Replace one buzzword every retrospective. Your decisions will get tighter and faster, and you'll stop having to translate between team members who use the same word to mean different things.
For a related take on what specifics matter, see my piece on observability stack.