Thanks for sharing. I’ll add the video to my queue.

The entirety of this research was about structure of directories.

Storing state in S3 or TFC or Spacelift or somewhere else is out of scope. S3 is where 90% of the world stores their state and writing those configuration lines is not in scope. You can find other resources on that.

I struggled to find an exhaustive list of how people manage their directory structures and hence the focus of this piece.

If you’d like to provide constructive feedback and avoid comments regarding scope creep, please share.

Sorry, I assumed this wasn't author-shared; I wouldn't have phrased it like that if I'd realised, or on a 'Show HN'.

It just struck me as a collection of ways you could split your configuration where none of them is something I would suggest. You could split your frontend/backend or services I guess sure, but then why are you assuming it's in the same repo, and why does that matter anyway, it has nothing to do with Terraform.

Why have dev & prod as different projects, assuming they're supposed to look the same? Use workspaces or different state or terra grunt. Ditto regions; use provider aliases.

If you say Well I'm not assuming they are the same, this is about structuring directories on the basis that they are already isolated Terraform configurations... Ok sure, but why does how you do that matter and what does it have to do with Terraform? It's the same as talking about structuring the directories for their application code isn't it?

Thank you for sharing. I’ve heard this module conundrum a few times and creates a proliferation of forked modules.

I mean when it becomes a bit larger and harder to manage so many modules we would split them into standalone repos which could be versiones And deployed. Then in the tfstate file get the env arns for example, but the complexity in the pipeline and environment becomes a bit more difficult to maintain strictly. It's tough

Thank you for sharing your example.

Thank you. I’ll dive into this when I have a chance next week.

Sorry it feels shallow and that you feel the need to troll.

If you read my first post related to this, I was giving myself a refresher to understand different dynamics that people think about.

I did not watch one YouTube video or spend 20 minutes on this or create with GPT.

The original source of inspiration came from me wanting to understand the examples our Eng team put together on how our config file correlates to what customers are actually using to find any gaps.

https://docs.resourcely.io/concepts/other-features-and-setti...

This is also a part 1 of the article and I clearly asked what was missing.

I think it's perfectly valid to voice an opinion of shallowness. That doesn't automatically make it trolling.

My mistake. Maybe the wrong use of the word.

And yes, it was a shallow article. It was not a deep dive and nor do I have the technical chops to write a deep dive.

If I was trying to troll you, I'd have mostly agreed with your article then made some outlandish accusation or completely incorrect statement. Then I'd defend that while continually moving the goalposts and getting people as invested, amused, and angry as possible.

Simply stating an opinion, by itself, is not trolling no matter how much you may disagree with the comment. If you're open to advice, I suggest that you look at a user's comment history to determine if they're the type of person who trolls others.

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?

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.

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.

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

"yes, ChatGPT can generate valid Terraform, but only in straightforward cases where your intent is totally unambiguous and does not depend on any referenced resources."

-What happens when it depends on the referenced resources?

Thanks for sharing the origin story.

"Given there is not enough time to react to a misconfigured cloud asset being breached, proactively securing configuration is the only way to protect against the risk of potential cloud data breaches."

This is the way!