[carty7]

I spend a lot of time speaking with clients and have found myself partially understanding organizational structure so I dove in to collect my thoughts and put myself closer to the customer on what they are navigating.

This gave myself a refresher on how they are organizing their cloud infrastructure within their source control systems. I took a lense from the world of terraform since that’s mostly the world i live in today and the last few years.

I explored 10 different ways to structure your Terraform config roots, each promising scalability but delivering varying degrees of chaos. From single-environment simplicity to multi-cloud madness, customers are stuck navigating spaghetti directories and state file hell.

I probably missed things. Might have gotten things wrong. Take a look and let me know what you think.

What patterns are you using that I missed?

[jjayj]

We are multi-cloud, multi-region, multi-environment, multi-deployment with hundreds of AWS accounts.

This is split over hundreds of microservice repositories, each of which maintains its own Terraform.

We don't read state from other Terraform deployments, and use published reusable modules when convenient and a tfvars file for every deployment.

At this point I can't imagine doing Terraform any other way.

[unop]

Nice! We'll link to this for our internal consultancy work.

It'd be nice to show the other dimension of the git branching strategies to apply. Github flow/feature-branches vs per-env branches of main vs git flow. How and when to apply changes in different environments - before vs after PRs, etc.

[carty7]

This was out of scope for my research. Have you seen any good resources on this?