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 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.
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.
"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?
"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."
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.