The Great Divide In How Teams Manage IaC

Hey folks,

This is a good LinkedIn thread about separate configurations! If you deal with IaC every day, I suggest checking it out and thinking about these alternative patterns.

I know a lot of teams and people I respect follow a different line of thought than my team and I. They like "Single-Instance Root Modules", which means when they want a new instance of a root module, they copy the full directory.

However, at Masterpoint, we're big fans of "Multi-Instance Root Modules", where you have a single copy of the code and when you want to instantiate that root module, you provide a data file (tfvars) that creates a new instance of that same code.

For me, this is logical for a lot of reasons:

1. It treats IaC as software and "Infrastructure as Data". IaC is software. Full stop. I inherently disagree with the idea that we should treat it as less than, like "config". Do folks copy their application code three times to create dev/stage/prod? Hell no. Why would we do the same with our infra code?

2. It avoids a critical bad practice: you can't add a resource to one environment and not have it show up in your other environments WITHOUT explicitly coding that environment divergence. This creates a clean interface for reviewing what an environment actually is made up of instead of a nightmare of diffing separate directories.

3. It avoids "Find/Replace Development". What happens when you copy a "network/*" folder ten times, but then you want to change how you authenticate your provider across all of them? You've gotta fire up the old find and replace to do that work. That's not a sustainable method of maintaining IaC or software.

AI makes this distinction less important. I personally don't believe a single-instance root module is a huge dealbreaker anymore.

But I do have a preference. It comes from seeing a handful of client or prospect IaC environments where they did the single instance root module pattern, but those instances diverged. They created a mess for themselves.

Lots of folks believe the opposite, and there are reasons for that divergence in thinking. To name a few:

• Terraform did a poor job implementing workspaces (they even bash on the feature in their docs)

• people not understanding, when something is checked into git, if it's "config" or "code"

• Terragrunt being the biggest proponent of single-instance early on when it was the only viable TF framework for years

• decades of SysAdmins who thought copying configs left and right is sustainable (who then started to write TF)

No one is wrong here, yet it's a great divide in how teams manage IaC. Maybe if there were better “best practices” early on, this question would have a single answer.

May the messes you create for yourself be minimal,

Matt @ Masterpoint

PS If you want to chat about the Multi-Instance Root Module pattern, grab some time on my calendar here. Here’s the archive of all my newsletters. Maybe you can find one that addresses a current problem of yours to share on your company slack.