3 ms·

So what is a good take?

scarlson 3y ago
Whoa, you expect someone to drop an inflammatory opinion AND offer a reasonable alternative? What's next, real world data to back up their claims? Research papers offering corroborating evidence? This is the internet, we don't do that here.
- lijok 3y ago
  Haha, you're on point
- intelVISA 3y ago
  I'll also accept a peer reviewed HN comment chain in lieu of academic journals.
Dave3of5 3y ago
I'd say dont do any layering and stick with the standard naming convention of "stacks". Start with a common stack with all your common stuff and application stacks with stuff that specific to some application say all the resources for a microservice or everything for a BI system ...etc. Avoid splitting this up as it introduces too much complexity. The IAC code should be very simple such that any dev can pick it up just coming off the tutorials. Company I'm in has 3 layers and dozens of stacks and it's made the whole thing impossible to reason about. No one wants to touch it anymore which means we now have a Platform team that screws around with this chap for months on end. Note: Lee Briggs works for Pulumi as a Principal Platform engineer so its in their interest to make this too complicated.
- intelVISA 3y ago
  > Note: Lee Briggs works for Pulumi as a Principal Platform engineer so its in their interest to make this too complicated. ding ding: we have a winner
- jen20 3y ago
  > I'd say dont do any layering > Start with a common stack with all your common stuff > application stacks with stuff that specific to some application So... layers! Right then.
windowsworkstoo 3y ago
Global namespace shared resources, regional namespace shared resources, then each app provisions its own bit, consuming/linking the two aforementioned layers. Everyone gets here eventually and you can just fight over stuff like “is an alb shared regional or app specific”
SirensOfTitan 3y ago
Put stateful resources in one bucket, non-stateful in another, and then do that until it causes obvious issues then revisit later. Infra should be simple as possible, and the simple infra should inform simple app design.

Whoa, you expect someone to drop an inflammatory opinion AND offer a reasonable alternative? What's next, real world data to back up their claims? Research papers offering corroborating evidence? This is the internet, we don't do that here.

lijok 3y ago
Haha, you're on point
intelVISA 3y ago
I'll also accept a peer reviewed HN comment chain in lieu of academic journals.

Dave3of5 3y ago

I'd say dont do any layering and stick with the standard naming convention of "stacks". Start with a common stack with all your common stuff and application stacks with stuff that specific to some application say all the resources for a microservice or everything for a BI system ...etc. Avoid splitting this up as it introduces too much complexity. The IAC code should be very simple such that any dev can pick it up just coming off the tutorials. Company I'm in has 3 layers and dozens of stacks and it's made the whole thing impossible to reason about. No one wants to touch it anymore which means we now have a Platform team that screws around with this chap for months on end. Note: Lee Briggs works for Pulumi as a Principal Platform engineer so its in their interest to make this too complicated.

intelVISA 3y ago
> Note: Lee Briggs works for Pulumi as a Principal Platform engineer so its in their interest to make this too complicated. ding ding: we have a winner
jen20 3y ago
> I'd say dont do any layering > Start with a common stack with all your common stuff > application stacks with stuff that specific to some application So... layers! Right then.

windowsworkstoo 3y ago

Global namespace shared resources, regional namespace shared resources, then each app provisions its own bit, consuming/linking the two aforementioned layers. Everyone gets here eventually and you can just fight over stuff like “is an alb shared regional or app specific”

SirensOfTitan 3y ago

Put stateful resources in one bucket, non-stateful in another, and then do that until it causes obvious issues then revisit later. Infra should be simple as possible, and the simple infra should inform simple app design.