A few years ago I would read a release announcement and think we should try that. Now I read the same announcement and think good for them. I don’t know exactly when the switch flipped, but I can tell you it correlates very closely with the number of pages I’ve personally taken at 4am.
This is a small, unfashionable case for boring infrastructure — Postgres, cron, nginx, systemd, a single VM when a single VM will do — and against the reflex that says novelty is its own justification.
The argument
Every component in your stack costs you the same handful of things. Time to learn it. Time to operate it. A spot in your team’s mental cache. A row in the on-call escalation matrix. A vendor relationship to maintain, or an upstream community to follow.
The exciting components cost you those things more, not less, because:
- The docs are thinner.
- The failure modes aren’t catalogued yet.
- The Stack Overflow questions are mostly other beginners.
- The library ecosystem hasn’t decided which client to standardize on.
- The best-practices article you’d want to read hasn’t been written.
- The version you’re running will be deprecated before it’s been in production a year.
You pay for novelty in operational surface area. The bill comes due during incidents.
What boring buys you
Boring tech wins three things, and in this order:
- Predictability under load. When the wheels come off, you want a system whose failure mode you’ve seen, ideally personally, ideally more than once. Postgres has been making the same set of mistakes for thirty years. You know what they look like.
- A larger pool of people who can help you. When you hire someone who’s been doing this for a decade, what they bring is mostly the muscle memory for the boring tools. If your stack is exotic, you’ve thrown that advantage away.
- A smaller cognitive surface. Your team has a finite budget for “things they have to think about.” Spend it on the parts of the system that are unique to your business, not the parts that thousands of other teams have already solved.
The Dan McKinley framing — “innovation tokens” — is the one I keep coming back to. You get a small number per project. Spend them on the things where novelty is load-bearing for your product. Don’t spend them on the database.
Where to be boring
- Storage. Postgres until it physically can’t. Then still Postgres, with read replicas. Then maybe think about it.
- Job scheduling. Cron. Then a queue with one worker process. Then maybe a real scheduler. Most teams skip the first two and regret it.
- Web server. nginx in front of an application server. We’ve been doing this for fifteen years for a reason.
- Process supervision. systemd. It’s already on the box.
- Configuration management. Ansible if you can’t avoid it; better, immutable images and config-as-data.
Where to be interesting
The exciting tech belongs in two places:
- The product. If your product is, say, a graph traversal engine, then yes, use the bleeding-edge graph database. That’s the bet you’re making.
- The frontier of your operational pain. If you’ve been on-call long enough to know exactly where the boring stack is hurting you, then spend an innovation token on the specific thing that fixes it. Not on the general principle that newer is better.
The aesthetic case
There’s also a small aesthetic argument that I’ll make briefly because it doesn’t survive committee review.
Boring infrastructure has a dignity to it. The same tool, doing the same job, for years. The runbook hasn’t changed. The mental model hasn’t changed. The person who wrote the original deploy script left the company in 2019 and the deploy script still runs every Tuesday night and nobody has had to think about it in a long time. There’s a craft in building things you don’t have to think about.
The opposite — the stack where every quarter brings a new framework, a new orchestration layer, a new “this changes everything” — looks energetic from the outside. Inside, it’s exhausting. Most of the work is migration. Most of the migration is fixing things that worked fine before.
The recommendation
Pick the boring tool by default. Make the team explicitly justify any time you reach for the exciting one. Write down why you reached for it; revisit that note in eighteen months and see if the justification held.
Most of the time it didn’t. Most of the time the boring tool would have done the job.
That’s not a failure of imagination. It’s the entire job.