Comment by davidjfelix | Hacker News Reader

Comment by davidjfelix | Hacker News Reader

Parent Full thread

I want to emphasize that I don't normally use counts, it's just one tool in the toolbox. Normally I try to isolate env specific apps to their own stack and I simply don't have a workspace for the env they're not deployed in. Assuming a traditional 3 tier env setup (which I don't do either -- I only have 2) it might look like:

Workspaces:

- PROD-us-east-1-All-the-VPC-stuff

  - NAT count = 3

- PROD-us-west-2-All-the-VPC-stuff

  - NAT count = 3

- PROD-us-east-1-Enterprise-Network-Tool

  - var instance count = 2

- PROD-us-west-2-Enterprise-Network-Tool

  - var instance count = 2

- STAGE-All-the-VPC-stuff (us-east-1)

  - NAT count = 3

- STAGE-Enterprise-Network-Tool (us-east-1)

  - var instance count = 1

- DEV-All-the-VPC-stuff (us-east-1)

  - NAT count = 0 (maybe since we don't have the network tool we're transit vpcing or something else in dev)

It's a little contrived but the idea is that normally workspaces align to these borders:

- Env

- Cloud region (not always -- and the cross region ones are usually called out)

- Loosely de-coupled app border

Workspaces provide really easy "manholes" for servicing your IaC quickly when there's a mistake. They don't encourage you to manually change resources, but rather work in a smaller area and reduce blast radius. The issue I see with a lot of teams is when they're not sure how to handle cross-stack references or what they should output. I think that's an area for training and leveling up in TF.

Yep, mostly agree here.

> The issue I see with a lot of teams is when they're not sure how to handle cross-stack references or what they should output.

Very much agree. What I try to do as much as possible these days is to not cross-reference. I find terraform remote state resources a code smell. Data sources are a better way to go. No code coupling and no terraform versioning dependencies between stacks.

I usually do data sources to get access to the attribute I might need and output arns or unique ids (that will allow people to use the data source reliably) but not guess every output they might need.

I think outputs are fine and are only a smell if you have many "peer" stacks that rely on each-others outputs. For stacks that have dramatically different cadences (IE - your vpc stack vs app stack) I don't see any issue with outputting something like VPC arn. We use a naming scheme to locate "peer" references that might be smells and try to resolve them.

As part of our DR plan, we regularly run all tf stacks from nothing to ensure they stand up without issue and that the instructions for stack order are actionable. This helped us sort out early cyclic cross-references and develop a tree/DAG style multi-stack approach. When workspaces start to settle down, we typically adopt an init-style naming system for the workspace, eg: 000-prod-vpc or 010-dev-my-web-app which allows us to ensure that we recognize which workspaces occur before and after a workspace. These names are kinda hard to predict while you're writing them, so we defer that process until it's stable since changing names is more process than it's worth. Typically we advise: xyz numbers where z increments if it's a peer but after y, y increments when it depends on a parent, x increments when there are human involved tasks. Most of our workspaces are named with the prefixes 000, 010, 011 or 020 with very rare exceptions being 012 or 021, 030 etc. This helps us identify bottlenecks or late-recovery items in our stacks as well as dependent stacks.

We're talking about deprecating this naming system with the pulumi automation api to manage deploy order when we move to pulumi, but I think the way we have it forward loads a lot of operational helpers and I'm not sure if the team will push back on pulumi or not.

Reply on news.ycombinator.com