Hacker News new | ask | show | jobs
by OJFord 488 days ago
This is terrible. All options seem to assume state is stored locally (not, say, in S3). Many options are just the same as others but only one environment, or with some project-specific difference like 'there is a backend and a frontend' or 'a few services' which has nothing to do with how you structure the terraform side of it.

All of them either don't address or use multiple directories to handle multiple environments (and assume a static list). What?! No, use terraform workspaces, or a single module that you instantiate for each environment. Or terragrunt if you really want. TFA is just a blogspam mess from either AI or someone that's spent about 20 minutes with a Youtube video to learn terraform & push out their latest deep dive content guys.

3 comments

Agreed on the quality of the article, it feels very shallow.
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.

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?

Why do you think the article assumes statefile is local? I don't think that assumption was made.
#2 splits the configuration into 'dev' & 'prod' duplicates, describes it as 'with separate state files', and from there they're all different ways of splitting the project for some reason.

If the state isn't local, then if you want that split in order to apply them separately, there would be no reason to physically separate & duplicate them into different directories.