Evolving Infrastructure
More than a few years ago, I read Scott Ambler’s Agile Modeling, which fundamentally changed how I approached software development. The book’s central insight proved revelatory: software could evolve incrementally rather than requiring exhaustive upfront architecture.
The book emphasizes a principle that resonated deeply:
Your first responsibility is to make the code work for the problem you are solving now. The second one is the problem you are solving next.
Today, incremental software development is nearly universal among competent organizations. However, infrastructure thinking remains stuck in waterfall methodologies, despite modern DevOps tools enabling dynamic provisioning and automated deployments.
A Better Approach to Infrastructure
Rather than predetermining architecture, infrastructure should evolve alongside applications:
- Deploy your application as a single process on one server to real users
- Increase user load until hitting performance bottlenecks
- Address bottlenecks through optimization — additional processes, servers, or specialized services
- Repeat iteratively
Common Objections
“We’ll create low-quality infrastructure”
This mirrors outdated software arguments about needing UML diagrams before coding. Simplicity doesn’t mean poor quality; unnecessary complexity introduces fragility. Simple solutions remain more reliable and robust.
“We know our performance requirements”
New software projects inherently contain uncertainty. Pretending infrastructure needs are predetermined ignores reality.
“We must meet SLAs”
SLAs resemble software regulations — sometimes useful, sometimes justifications for unnecessary spending. Meet your SLA requirements simply; don’t add CDNs or other features “just in case.”
The Core Principle
Infrastructure code is code. Treat it identically to application code, applying the same evolutionary principles.