Boring Infrastructure Is the Goal, Not a Compromise

Updated: October 5, 2026 (7531-10-15 in the Bulgarian calendar)

Back to Strategic Approach · Infrastructure as Code · Capacity Planning · Service Offerings

The best outcome of an engagement is that nobody thinks about the infrastructure afterwards. “Boring” is not what you settle for when the budget runs out — it is the thing worth aiming at from the start. A system that produces no stories is a system that produces no incidents, and the flat, uneventful graph is the deliverable, not a consolation prize.

1. What “Boring” Actually Means

Boring is a precise property, not an insult. A boring system is one whose behaviour you can predict without reading its source, whose failure modes are already known and already handled, and whose on-call history is short because there is little to tell.

• Fewer moving parts. Every component is a thing that can break, a thing to monitor, patch, and reason about at 3 a.m. The cheapest component to operate is the one you did not add.
• Proven over novel. A technology that thousands of teams have already run in production has had its sharp edges found and documented by other people. A brand-new one makes you the person who finds them.
• Legible over clever. A configuration your team can read and change beats one that is elegant but understood by nobody who still works here.
• Predictable over optimal. A setup that is 15% slower but behaves the same way every time is usually worth more than a faster one that occasionally does something nobody can explain.

2. Why It Is a Goal, Not a Budget Compromise

The compromise framing has it backwards. Complexity is rarely bought on purpose for its benefits; it accumulates — a queue added for one feature, a cache for one slow page, a second datastore for one report — until no single person holds the whole picture. Boring is the harder thing to achieve, because it requires saying no to additions that each looked reasonable on their own.

• Operational cost is the real cost. Software is paid for mostly after it ships — in attention, in on-call hours, in the time to onboard the next engineer. A boring system is cheap on exactly the axis that a spreadsheet at purchase time ignores.
• Reliability compounds from simplicity. You cannot test your way to confidence in a system with more interactions than anyone can enumerate. Fewer parts means fewer interactions means fewer surprises.
• The resume-driven temptation is real. Infrastructure is sometimes chosen for how interesting it is to build rather than how quiet it is to run. That is a cost paid by whoever operates it next — often the client, after the exciting part is over.

3. Boring Does Not Mean Primitive

This is the usual objection, and it is a misunderstanding. Aiming for boring is not refusing to use capable tools; it is refusing to use them before the workload demands them.

• A well-tuned single host beats a half-understood cluster for the large majority of workloads that will never outgrow one machine. We reach for more capacity when the measurements call for it, and say so plainly when they do not.
• Kubernetes, queues, sharded databases and multi-region deployments are the right answer to the specific problems they solve — and dead weight when adopted for problems you do not yet have. The question is never “is this tool good?” but “does this workload need it today?”
• Boring scales by being changed when evidence arrives, not by being over-built in advance against growth that may never come.

4. How We Keep Things Boring

• Add a component only when something concrete requires it, and write down what that something was — so a later reviewer can tell whether the reason still holds.
• Prefer the platform you already run: a feature of your existing database over a new datastore, a cron job over a scheduler service, a file over a message broker, until the simple version actually hurts.
• Make it legible. Infrastructure as code over undocumented manual steps, so the system is the documentation and nothing depends on one person's memory — the opposite of the clever configuration nobody else can read.
• Count the moving parts honestly in any design review, and treat each new one as a cost to be justified, not a free capability.
• Remove, not just add. The boring system gets that way partly by retiring the queue that is no longer used and the cache that no longer helps, instead of leaving them to rot as load-bearing mysteries.

5. The Payoff Is Invisible On Purpose

The reward for boring infrastructure is an absence: no incident channel at midnight, no “only Dani knows how that works,” no migration that cannot be attempted because nobody understands the current state. It is a hard thing to put in a status update precisely because its success looks like nothing happening.

That is also why it has to be a stated goal rather than an accident. If nobody is aiming at boring, complexity wins by default — every pressure in a project pushes toward adding, and almost none push toward keeping it simple. The flat line on the hero above is not luck. It is what you get when simplicity is the thing you were trying to build.

How We Approach It

1. Start from the simplest thing that could work for the actual load, measured, not imagined.
2. Justify every component against a concrete need, and record the need so it can be revisited.
3. Choose proven, widely-run tools over novel ones unless the novel one solves a problem the proven ones genuinely cannot.
4. Keep it legible — as code, readable by the team, with no single-person dependencies.
5. Scale on evidence, adding capacity or components when the measurements demand it and not before.
6. Prune, so the system stays boring as it ages instead of silting up with unused parts.

What You Get

• An architecture with a component count you can justify line by line.
• Technology choices biased toward what is proven and widely operated, with the exceptions argued explicitly.
• A system legible enough to run, change, and hand over without us.
• Fewer incidents, shorter on-call, and a quieter graph — the measurable shape of “boring.”

The question worth asking of any proposed design: which of these parts does the workload actually require today, and what does each of the rest cost to operate for the years after it ships?

← Back to our Strategic Approach