TL;DR

Linus Torvalds warned us about splitting a kernel into fifty chatty pieces. He never warned us about Kubernetes. That critique is about how you decompose an application, not about the scheduler you run it on. Every “Kubernetes exit” in the latest doom post either never ran Kubernetes or kept its core idea. Kubernetes isn’t Linux’s rival. It’s Linux’s amplifier.

Originally published at portfolio.hagzag.com.

Two Gifts, One Misquote

I owe Linus Torvalds two things I use every working day: Linux and git. So when a post titled “Kubernetes is officially doomed, and Linus warned us” crossed my feed this week, I read it twice. Then I went looking for what Linus actually said about Kubernetes.

The answer is almost nothing. At Open Source Summit China in 2024, he described himself as a kernel person. He wants to support cloud, Kubernetes and AI, but isn’t interested in the end result. He called clusters and clouds useful, just not his problem. He joked that the kernel is the only thing that matters, and Dirk Hohndel shot back that it would be taken out of context.

It was. The doom post reaches back to 2001 instead.

The Quote Is Real. The Target Is Wrong.

In Just for Fun (Torvalds & Diamond, HarperBusiness, 2001), Linus explains why he rejected microkernels. Split a kernel into fifty independent parts and each looks like a fiftieth of the complexity. But the communication among the parts ends up more complicated than the original system. His verdict:

“The simplicity you try to reach is a false simplicity.”

Note what he doesn’t say: that small is good. In a 1999 LKML reply to Eric Raymond, he asked what the correlation between “small” and “good” even is, and answered that it’s seldom strong and often negative. For Linus, simple never meant small.

That’s a sharp argument, and I agree with it. It is an argument about decomposition: how many pieces you cut your system into and how chatty they get. Applied to software, it’s an argument against slicing a working application into fifty microservices.

Kubernetes didn’t make anyone do that. You can run one container on Kubernetes, and plenty of teams do. Blaming the scheduler for a team’s microservice sprawl is like blaming ext4 for a messy home directory.

What Kubernetes Actually Is to Linux

Here’s where I part ways with the “complexity tax” framing. Kubernetes didn’t replace anything in the kernel. It orchestrates kernel features that already existed: cgroups, namespaces, seccomp, the network stack. It does that across many machines, through a declarative API.

You can see it in one Pod spec:

# A Pod spec is a declarative request for kernel features.
resources:
  limits:
    memory: "256Mi"   # becomes memory.max in the container's cgroup (v2)
    cpu: "500m"       # becomes cpu.max: 50000 100000 (50ms per 100ms period)
# On the node, the kubelet + runtime wrote exactly what you'd write by hand:
cat /sys/fs/cgroup/kubepods.slice/.../memory.max
# 268435456

No magic. Kubernetes is a reconciliation loop that keeps asking the kernel for what you declared. That’s why I call it the kernel’s amplifier: it’s what turned Linux from a server OS into a cluster OS.

And it borrowed the one Linus rule that matters most. “We don’t break userspace” has a direct descendant in Kubernetes’ API deprecation policy: a GA API version isn’t removed within a major version. That stability contract is the product.

Every “Exit” Kept the Idea

The doom post offers three receipts. I read the primary sources.

Prime Video never left Kubernetes. Its audio/video monitoring service moved off Step Functions and Lambda. The cost came from per-state-transition billing and S3 round-trips. The team landed on EC2 and ECS. They escaped serverless choreography onto a container orchestrator.

Gitpod left Kubernetes for one workload: cloud development environments. Their replacement, Flex, keeps Kubernetes-style control theory and declarative APIs, and its control plane is openly inspired by Kubernetes. They also said Kubernetes remains a fine choice for application workloads. They left the product, not the idea.

37signals left the cloud. The driver was the AWS bill and egress, with Kamal as their deploy tool. The $7M figure was DHH’s early-2023 projection over five years, later revised toward $10M. It is not a reported Kubernetes saving.

Even the post’s proposed replacements prove the point. Cloud Run and Fargate aren’t the end of orchestration. They’re orchestration someone else runs for you.

Declare Once, Keep Running

My own position is simple, and I hold it after a lot of client work: I have never moved a customer from Kubernetes back to ECS or VMs, and I wouldn’t recommend it.

Yes, it’s complex to stand up. But once a workload runs on a given version, it keeps running for as long as the API it uses is supported. You declare it once and the control loop keeps it true. That’s why I fell for Kubernetes, and why I built courses around it.

The 40-person startup the doom post pities is exactly who I’d put on Kubernetes. Two developers on k3d, my personal favorite, get the same declarative contract they’ll use in production. There’s no second mental model at scale, and no “rewrite the deploy story” project at Series B.

What It Actually Costs

None of this makes Kubernetes free.

Stateful workloads are genuinely hard. Most of my customers run their databases on RDS or Cloud SQL rather than in-cluster, and you won’t find me arguing with them. The doom post’s “eviction corrupts your primary” scenario is overstated for anyone using Guaranteed QoS, PodDisruptionBudgets and a real operator. The underlying instinct is still sound: don’t own state you don’t have to.

“Keeps running” carries an asterisk. It holds until an API you depend on is removed. Teams that ignored deprecation warnings learned this the hard way: Ingress extensions/v1beta1 disappeared in 1.22, and PodSecurityPolicy in 1.25. Kubernetes keeps its promises, but only to people who read the release notes. Budget for upgrades the way you budget for kernel updates.

Decomposition is still your call. If you cut a monolith into fifty services, Linus’s critique applies to you, on Kubernetes or off it.

Conclusion

Linus warned us about false simplicity, and he was right. Fifty chatty microservices are false simplicity. A scheduler that turns kernel primitives into a stable, declarative cluster API is the opposite: the same “don’t break userspace” discipline that made Linux last, applied one layer up.

Before you delete your cluster because of a 2001 quote about microkernels, ask whether your problem is the orchestrator, or the fifty pieces you handed it.