How is everyone organizing their pulumi stacks? Ar...
# general
r
How is everyone organizing their pulumi stacks? Are you using monolith stacks? Are you using microstacks? Have you used one and changed to the other? What were lessons learned or advantages to the different approaches?
b
How would you define monolith stacks and microstacks?
r
For Monolith: ex. an entire application encompassing the different layers. For Microstacks: ex. Stack for app service or ec2s, Stack for Databases or storage etc. Kind of corresponding to what is described here: https://www.pulumi.com/docs/guides/organizing-projects-stacks/
b
Microstacks only make sense to me for microservices or resources that need to be shared by multiple projects
Which is effectively what we do where I'm at, we have separate pulumi projects for shared resources and application projects reference those shared resources that are deployed independently
💯 1
w
Other factors to consider are performance and blast radius. Currently only using multiple stacks for infra but considering a stack per microservice after that.
👍 1
o
My “monolith” stack just grew to a size when it takes pulumi solid 2 minutes to calculate the update, and I’m considering splitting it into “microstacks” or, at least, “ministacks”.
👍 1
r
Yeah the consideration for me comes because Pulumi is taking almost 30 mins to run each time. Splitting into microstacks to cut down on how long it takes to run and decoupling things sounds appealing.
w
Sounds like it would be worth capturing a trace and logging an issue
b
I’d be really interested to see what’s included in these stacks that are taking 2-30 min to run. Any way you can share?
o
For us, it’s just a lot of EKS/GKE clusters + surrounding resources. I’m guessing it just takes a ton of time to synchronize every resource’s state, and EKS API is, perhaps, particularly slow.
w
EKS is quite slow. How does it compare to GKE?
o
GKE clusters definitely get provisioned faster. I believe update operations on them are faster too, but I never measured precisely and we have quite a bit more EKS clusters than GKE so it’s hard to tell