Earn It

Kubernetes, a second language, a message bus, a microservice. The impressive choice feels like seniority. Declining it until the workload forces your hand is the actual skill.

By Jason Waldrip, with Claude Opus 4.8

You’re in an architecture review for a product with a few thousand users and a roadmap that fits on an index card. Someone’s whiteboard has Kubernetes on it. A message bus. Three services where there’s currently one. The diagram is gorgeous. Boxes, arrows, a little cloud. Everyone nods, because the diagram looks like what a serious system is supposed to look like, and nobody wants to be the person who says the quiet thing: we don’t have the problem this solves yet.

I’ve been the person who says it. It doesn’t make you popular in the room. The elaborate plan reads as ambition and foresight, and the simple one reads as not thinking big enough. So the simple plan loses, and eighteen months later the team is spending half its week operating infrastructure that’s babysitting a workload a single Postgres box would have shrugged at.

The impressive choice is a tell

There’s a kind of design that’s optimized for how it looks on a slide, or on a résumé, instead of for the problem in front of it. You can usually spot it because the justification runs backwards. Instead of “here’s our constraint, here’s the cheapest thing that meets it,” it’s “here’s this powerful tool, surely we’ll need it eventually.” The tool comes first and the need gets reverse-engineered to fit.

I get the pull. Reaching for the powerful thing feels like seniority. It signals that you’ve operated at scale, that you know the patterns the big shops use. But pattern-matching to Google’s architecture when you have Google’s problems is wisdom. Pattern-matching to it when you have a CRUD app and four thousand users is cargo culting with extra steps. Ozan Onay made this point cleanly years ago in “You Are Not Google”: companies adopt the tools of giants without ever asking whether they share the giants’ constraints. The tool was a good answer to a question you don’t have.

When I did reach for it

This isn’t an argument for staying small or being scared of real infrastructure. I’ve made the expensive call plenty of times, when the workload earned it.

At CommercialTribe I migrated us onto GCP and Kubernetes. From the outside that’s exactly the move I’m warning about: a VP shows up and reaches for the heavyweight orchestrator. But it wasn’t résumé-driven. We had a split org, onsite engineers and a remote team in Argentina, a release cadence measured in weeks, and a stability problem that was costing us trust with every deploy. Kubernetes was the cheapest path to the thing we actually needed, which was a release process that collapsed from weeks to hours and held its footing under real load. The complexity paid for itself the first month, because the workload had already arrived. We were drowning. The orchestrator was the lifeboat, not the yacht.

That’s the distinction. Same tool, opposite decision, and the only thing that changed was whether the problem was real yet.

Complexity is rent, not a purchase

Here’s the part the architecture review never accounts for, because the cost shows up on a different day than the decision. When you choose the complex thing, you don’t pay for it once at the whiteboard. You pay rent on it for as long as it runs.

Every service you split out is a deploy pipeline, a set of dashboards, an on-call surface, a place where the network can fail between two things that used to be a function call. Every additional language is a second toolchain, a second hiring profile, a second set of idioms your team has to hold in their heads at 2am. Every message bus is a new failure mode nobody had to reason about before. None of that shows up in the demo. All of it shows up in the year you spend operating the thing.

Dan McKinley framed the budget for this better than anyone in “Choose Boring Technology.” His idea: a company has a small number of innovation tokens, and every shiny, unproven, operationally-hungry choice spends one. Boring tech, the stuff with a decade of war stories and a flat learning curve, costs you nothing to run and frees the tokens for the places where novelty is actually the point. Spend them on your differentiator. Don’t burn one on a queue when a database table would have done it.

This is why “just use Postgres until it hurts” is the same argument wearing different clothes. One engine that moonlights as your queue, your cache, your search, and your document store is one thing to operate, one thing to back up, one thing to reason about when it’s 2am and the pager goes off. Five specialized engines, each individually defensible, add up to a system no one person can hold in their head. You reach for the second engine when the first one genuinely buckles. Not before, on the theory that you might.

Earn it

So here’s the handle: earn it. Don’t take on complexity before the workload forces it. Name the property you actually need, the real constraint, throughput or fault-isolation or types-as-guardrails, then pick the cheapest thing that delivers exactly that and nothing more.

When GigSmart needed a backend, I chose Elixir, and that’s a less common bet than Node or Rails. But a real-time gig marketplace is a concurrency problem at its core, fault isolation isn’t a feature you bolt on later, it’s the shape of the thing. The constraint was real, so the choice was earned. Same year I’d have told you not to touch it for a CRUD app. At Brandfolder, Ruby was crashing generating multi-gigabyte zip files, the wrong tool for heavy IO, so we carved that one piece out into Go and left the rest of the monolith alone. We didn’t rewrite the app in Go because Go is fast. We moved the one workload that demanded it. The scalpel, not the bulldozer.

The verdict on every one of those tools, on my own choices page, carries a “when I don’t” right next to the “when I reach for it.” The honest “when I don’t” is half the credibility. Anyone can list a stack. Knowing what to leave off it is the work.

The era that makes this harder

This used to be self-limiting. Complexity was expensive to build, so the cost of construction was a natural brake on how much of it you took on. You felt the weight of the elaborate plan in the weeks it took to stand up, and sometimes that friction talked you out of it.

That brake is gone. Generation is free now. Point a fleet of agents at “scaffold me a microservices architecture with a message bus and per-service pipelines” and you’ll have it by lunch, plausible config and all. The thing that used to take a quarter to build wrong now takes an afternoon to build wrong. And here’s the trap: the cost of building it collapsed, but the cost of operating it didn’t move an inch. A system is just as hard to run at 2am whether a human typed it or an agent did. You get the complexity at a discount and the rent at full price.

Which means the discipline matters more than it ever has, not less. When the impressive thing is nearly free to produce, the only thing standing between you and a system you can’t afford to operate is the judgment to not reach for it. That’s the whole game now. Volume is free; deciding what’s worth running is the moat. An agent will never tell you that you didn’t need the thing it was perfectly happy to build you.

So next time the gorgeous diagram is on the whiteboard and everyone’s nodding, ask the unpopular question. Not “can we build this.” Of course you can, that’s never been cheaper. Ask what workload, here, today, makes this the cheapest path and not the most expensive one. If the answer is “we might need it someday,” you haven’t earned it yet. Put it back on the shelf and come find it when the problem shows up. It’ll still be there. It always is.