The Tool That Pays for Its Team

I was watching a tech-lead talk on YouTube the other evening. Half-listening, the way you do when someone you respect is walking through a setup you’ve seen variants of for ten years. Then the line landed:

“Kubernetes saved us so much money we can almost afford the team that runs it.”

I rewound it. He delivered it as a joke — a self-aware one, the kind a senior engineer drops when the room is full of people who already know. But the almost did something to me. The savings argument, the one that’s been pitched to procurement and CTOs and architecture review boards for the better part of a decade, summed up by its own advocate as: it nearly pays for the department it required.

I sat with that for a while. Then I started writing this.

What the line is really saying

The line is honest, which is why it works. It’s not the marketing version of Kubernetes. It’s the operator’s version, said out loud at a conference because the people in the room have lived it and there’s no point pretending.

But strip the joke off and the structure is uncomfortable. A tool was adopted on a promise of savings. The savings materialized — partly. They paid for a team that wouldn’t have existed otherwise, that has to keep existing as long as the tool does. The net is somewhere between break-even and “we’re committed now.”

That’s not a tool, by the time you get there. A tool is something you reach for to do a job. When the thing requires a permanent staff to operate, when its complexity creates the role that justifies it, when removing it would mean disbanding a team — that’s an organizational dependency. It might still be the right one. But calling it a tool, or measuring it in savings, undersells what was actually traded.

I’m not saying Kubernetes is wrong. Kubernetes is excellent at what it’s for. If you’re running thousands of containers across hundreds of nodes for an application whose traffic genuinely requires that, the tax it imposes pays its own way. The line in the talk wasn’t pitched at those teams. It was pitched at the rest of us — the operators who walked into a Kubernetes adoption because it was on the diagram, and who are now reconciling the bill.

The honest question the line opens is: for the work I’m actually doing, what’s the equilibrium between what the tool gives me and what it asks of me? That question used to get asked at the start of an adoption. Somewhere along the way it became impolite to ask it at all.

The other thing the line did to me

Here’s the part that’s been sitting with me longer.

When someone asks me what I do for a living, the conversation occasionally goes like this. “What do you do, exactly?” — DevOps, architecture, platform work, fifteen years of it. “Oh, so you do Kubernetes?”

It’s not malicious. The person asking is being polite, trying to map an unfamiliar word to something they’ve heard. But the substitution lands somewhere. Fifteen years of practice get reduced to one piece of YAML-driven infrastructure. The reasoning, the trade-offs, the conversations with developers about what their service actually needs, the on-call shifts at three in the morning, the postmortems where blame got refused and the system got fixed — all of it collapses into one word, and the word isn’t even the discipline. The word is the tool.

This is the smaller version of what the savings line points at. The larger version is industrial: a tool became so dominant that it absorbed the discipline. The smaller version is conversational: a discipline became so identified with one tool that practitioners get described by the tool. You can’t say I do DevOps in casual conversation anymore without people picturing a control plane.

I’m not bitter about this. Tools win mindshare; they always have. But there’s a quiet erosion that happens when the language for a craft gets replaced by the language for one of its possible implementations. The next generation walks in believing the implementation is the craft. The conversations that used to happen — about culture, about ownership, about what a team should and shouldn’t automate — get displaced by conversations about node pools and ingress controllers. Not because anyone decided that was a good trade. Because nobody noticed it happening.

Fifteen years ago, we were sold the cloud

It’s worth holding this up against the longer arc.

Fifteen years ago, the pitch was cloud for everything. Lift and shift. Get out of the data center. Stop running hardware. Pay only for what you use. The economics looked unanswerable on a slide.

Fifteen years on, the picture is more honest. Plenty of workloads are happily in the cloud and should stay there. Plenty of others have come back — re-internalized, rebuilt on bare metal, or hosted on what’s now called private cloud, which is on-premise wearing a cloud hat and charging cloud margins. The industry didn’t reverse the cloud. It found an equilibrium the original pitch had skipped over: some things, sometimes, for these reasons. That equilibrium took ten years of paid lessons.

I don’t want to over-extend the parallel. Kubernetes isn’t the cloud — different scope, different vendors, different forces. But the shape of the wave looks familiar. A general-purpose answer pitched as the answer for everything; a decade of adoption; a slow, public, uneven walk-back to it depends. The savings line in the talk feels, to me, like a marker on that walk-back. A senior engineer is willing to say in front of a camera that the math is closer to break-even than the diagram suggested. I’m not sure the same line would have landed as a joke a few years ago — it might have come out more defensively, in a room less ready to hear it.

The walk-back is healthy. It’s also expensive. The bill for the cloud walk-back was paid by ten years of teams who built things they didn’t need. If there’s a Kubernetes walk-back coming — and the talk’s joke suggests there is — it’ll have its own bill, and someone will pay it.

A small confession, near the end

This question — what does my stack actually require of me, in time and attention and headcount? — is part of why I built lithair. Not as an answer for anyone else. As a tool for me, for the projects where I’m the entire team, where I want to know the whole stack end to end, where I don’t want a control plane I have to maintain on top of an application I have to maintain.

That’s not a recommendation. It’s a confession. Lithair exists because I wanted control over a smaller surface, and I was willing to accept everything I gave up by choosing that. For a team of thirty running a real product, the calculus is completely different and I wouldn’t pitch them lithair. For me, alone, building things on a VPS, lithair is what not paying for a team I don’t have looks like.

I notice that’s a small answer. The line in the talk deserves a small, honest answer, not a framework pitched as a solution.

What this is not

It’s not “Kubernetes is bad.” It’s a strong tool for the problem space it was built for. The talk’s speaker said as much himself.

It’s not “DevOps engineers are wasted on Kubernetes.” Plenty of them aren’t. Plenty are running infrastructure that actually needs that complexity, and doing it well.

It’s not “everyone should self-host on a VPS.” For most teams, the tax of operating their own platform end-to-end is higher than the tax of paying for someone else’s.

It’s: when a tool’s savings barely cover the team it required, that tool isn’t a savings story. It’s an organizational decision dressed up in spreadsheet language. And when one tool’s name starts standing in for an entire discipline, the discipline quietly stops being discussed. Both of those are worth noticing, even if neither has a clean answer. The savings argument, fifteen years on, deserves the same scrutiny the cloud argument finally got.

That’s the question the line left me with. I don’t have the answer. I’m not sure anyone does yet.