The best infrastructure is the kind nobody talks about. No incidents, no surprises, no 2am pages. Getting there isn't about using the right tools — it's about making a deliberate, ongoing choice to be boring.
What boring looks like
Boring infrastructure uses managed services instead of self-hosted where the trade-off makes sense. It uses the same three deployment patterns across every service. It has runbooks that actually work because someone ran them last month, not last year.
It also means saying no to interesting things. A new database engine, a custom caching layer, a clever optimization — all of these are interesting problems. Most of them are also unnecessary. The interesting problem you take on today is the incident someone else is debugging at 3am next year.
The cost of interesting
Every non-standard component in your stack is a component someone has to understand under pressure. Interesting choices compound: each one adds cognitive overhead to everyone who touches the system, raises the floor for new hires, and creates another thing that can fail in a novel way.
The question I ask before adding anything to the stack: "Is this interesting because it's genuinely the right tool, or because I find it interesting?" The answer is usually the second one.
How I keep things boring
Default to managed services. Choose the boring option when options are otherwise equal. Document decisions — not what you chose, but why, so the next person knows what you ruled out. Run your own runbooks on a schedule. Keep the alert threshold high and the on-call rotation short.
The product should be interesting. The infrastructure should not.