Infrastructure as Code isn't a metaphor. It's literal.

The code you write to define infrastructure is software. It has dependencies. It has state. It has bugs. It requires testing, versioning, and collaboration.

And because it's software, the same architectural principles that transformed software development—separation of concerns, bounded contexts, service orientation—apply directly to infrastructure.

This isn't controversial. These patterns have been proven over decades. And yet, when it comes to Terraform, we sometimes forget that the rules haven't changed.

Infrastructure Is Software

Think about how we build applications today.

We don't debate whether applications should use frameworks. We don't argue about whether CI/CD pipelines are necessary. We don't question whether code should be modular, testable, and maintainable.

These are settled questions. The patterns exist because they work.

Why would infrastructure be any different?

It isn't. The same principles apply. And when we treat Infrastructure as Code like the software it is, we get the same benefits: maintainability, scalability, and governance.

Why We Decompose (It's Not Just About State)

There's a temptation to think that breaking Terraform into smaller components is a workaround for tooling limitations—state file performance, lock contention, plan times.

Those are real concerns. But they're not the primary reason we decompose.

We break things apart for the same reasons software architects have always broken things apart:

Even with perfect storage primitives, even with infinitely fast plans, you'd still want bounded contexts.

Because the value of decomposition isn't just performance. It's organizational alignment.

When your infrastructure boundaries match your team boundaries, magic happens. Teams move independently. Ownership is clear. Governance becomes possible.

The Real World Has Constraints

Beyond architectural principles, there are practical realities that reinforce the need for decomposition.

These aren't Terraform limitations. They're physics.

• Provider rate limits exist. If you manage hundreds of GitHub repositories using the factory pattern in a single root module, you will hit API rate limits. Guaranteed.
• Memory limits exist. We've seen Terraform plans consume 25GB of RAM when factories grow too large. That's not a bug—it's a signal.
• API timeouts exist. Large plans mean more API calls, longer refresh times, and more opportunities for transient failures.
• Human attention limits exist. No one can meaningfully review a plan that touches 2,000 resources.

Here's the insight: These constraints are guardrails, not bugs.

Terraform's design nudges you toward patterns that scale. The "limitation" of not being able to iterate over providers? That's a feature. It prevents you from creating ungovernable complexity that would collapse under its own weight.

Consider what happens if you iterate over providers across multiple regions in a single root module. In a disaster recovery scenario—when one region is down—your entire plan fails. The whole point of DR is regional independence. If your infrastructure code couples regions together, you've defeated the purpose before you've even started.

When the tool makes something hard, ask: Is it protecting me from a mistake I'd regret later?

Often, the answer is yes.

The Monolith Trap

None of this means you should start with a complex, decomposed architecture.

"Premature optimization is the root of all evil." — Donald Knuth

Monoliths are fine. For small teams, limited scope, and early-stage projects, a single Terraform deployment is the right choice. It's simple. It's fast to iterate. There's no coordination overhead.

But monoliths hit a wall.

We've written extensively about this in Terraliths vs Componentized Terraform, but the short version is: it's not if, but when.

• Plan times stretch to hours
• Teams collide in the same codebase
• Governance becomes impossible—who can change what, when?
• Blast radius grows with every resource
• API rate limits and memory pressure increase

The wall isn't just about state or performance. It's about governance, team velocity, and organizational scale.

At some point, you stop asking should we break this apart? and start realizing we have no choice.

What Service-Oriented Terraform Looks Like

So what does it mean to apply service-oriented architecture to Terraform?

It means your infrastructure components reflect how your organization actually works:

This is exactly how we've structured our 160+ Terraform components. Not because it's trendy, but because it's how enterprise infrastructure actually needs to work.

Each component has a single responsibility. Dependencies are explicit. Teams can own their components end-to-end. Governance happens at boundaries, not everywhere.

The result? Faster delivery, clearer ownership, and infrastructure that scales with your organization.

Engineering, Not Philosophy

The patterns that transformed software development—that gave us maintainable, scalable, governable systems—apply to infrastructure.

These aren't opinions. They're proven engineering principles. Separation of concerns. Bounded contexts. Service orientation. We didn't invent them for infrastructure. We inherited them from decades of software engineering wisdom.

And when your tools nudge you toward these patterns? That's a feature.

If this sounds like what you need, our purpose-built commercial reference architecture is ready for enterprise scale today—even if you're not there yet.

Talk to an engineer — we'd love to help.

Or if you want a tool that embraces these patterns wholeheartedly, check out Atmos.