---
title: "Infrastructure Purism"
canonical: "https://wiki.patientsknowbest.com/space/api/4641685674/Infrastructure%20Purism"
format: markdown
---
The evolution of programming cultures seems to mirror what's happening in (application) infrastructure. In programming, we've moved through these phases:

- Early on, most programmes were built from scratch (often just using a standard library, plus a few extras).
- Framework/dependency maximalism: avoid building your own when something else already exists, because:
  - Third-party solutions are often more mature and better supported.
  - You can focus on your core business.
  - You don’t reinvent the wheel.
- This led programmers to shift away from writing code to “plumbing.” Soon, many felt uneasy about coding at all, resulting in libraries like is-odd on npm.
- Eventually, people realised that when everyone is just plumbing, components come from other plumbers. Simple tasks can end up with overly complex solutions. That complexity seeps in at the worst times, leaving no one sure what's going on.
- We started valuing actual programming again (at least in certain niches) until LLMs arrived, but that’s another story.
- Crucially, dependency maximalism created enormous value through fast progress, albeit with more obscure edge cases. Dependency purists need highly skilled coders; dependency maximalists need people who engage with the community, follow trends, pick libraries with strong support, and so on.

In infrastructure, the pattern is similar:

- At first, computers and servers were right under our desks or in a data centre, and we knew exactly what they looked like.
- Then hyperscalers invented what hyperscaling required, and we ended up taking not just the essentials (monitoring, health checks, automated deployments) but a bunch of other stuff in the name of “resilience”—though my apartment’s server has better uptime than some “resilient” data centres (looking at you, europe-west2). If it catches fire, I can walk down, extinguish it, swap the hardware, restore from backup, and still come out on top.
- Once again, we plumb together things we barely understand, and it usually works fine.

I see companies having two choices, with Kubernetes as the dividing line:

- Everything at Kubernetes level or below is “infrastructure purism.” Some say Kubernetes is too complex already, but I think it’s a solid tool.
- Lambda, Vercel, Fly , etc., represent “infrastructure maximalism.” They offer quick gains but can surprise you with tricky edge cases when you’ve already committed. These commitments rarely get undone; major rearchitectures are uncommon.

What matters is that knowledge and skill are necessary in both approaches. Purists need people who understand everything down to the hardware. Maximalists need people who recognise when an AWS Lambda might choke or when cross-region data transfer will blow up your budget—possibly forcing layoffs when you can’t meet payroll.