https://pulumi.com logo
b

best-lifeguard-91445

05/13/2020, 8:22 PM
Good afternoon everyone! I'm new to Pulumi, and I'm looking for baseline / best practices for organizing stacks within a pulumi project. For example: should I have a "VPC" construct in a separate file, and export the values to be made available elsewhere? I guess I'm looking for a well-architected / modular starter project. (Typescript preferred) or blog/tutorial on organization and modularity.
I came across this: https://www.pulumi.com/docs/intro/concepts/organizing-stacks-projects/ https://www.pulumi.com/docs/guides/crosswalk/kubernetes/ However, I was wondering how you guys were handling this in the 'real world' so to speak.
f

future-barista-68134

05/13/2020, 9:10 PM
The highest-level quick answer is to start with a single project and only start to consider breaking up the project when it reaches a certain level of complexity. That complexity being the time when it becomes desirable to separate the deployment lifecycle for a subset of the infrastructure. For stacks, the recommendation is to have a stack per independent deployment of the same infrastructure. The most common layout being a stack per environment. Prod, staging, dev, etc. That way you can maintain a single Pulumi program and simple pass in configs to describe the difference in the environments. I agree it would be great to have the “best-practice” project and guide and have added an item to our list of blogs/guides 🙂 I’m sure there are others who have insight here as well.
👍 1
b

best-lifeguard-91445

05/13/2020, 9:21 PM
Thanks for the feedback!
l

little-cartoon-10569

05/13/2020, 9:48 PM
It can also be helpful to have multiple stacks per environment in cases where some infra is updated more frequently than others. For example, you might have a devVpc stack that sorts your VPC, subnets, NACLs etc and never changes, and a devWebApp stack that you can change as often as you need without risking the static network resources.
Also "ownership" can influence stack design in orgs that have multiple responsible groups. A stack per team or department might work. devKubes, devDbs, devCdn....
👍 1
a

ancient-megabyte-79588

05/14/2020, 4:50 AM
Just to add a small anecdote, I started doing my kubernetes development in a single monolithic stack. I soon discovered that the frequency in which I stand-up/teardown the actual k8s cluster is drastically less frequent than the frequency of of making changes to services in the cluster. So I broke the two apart into separate stacks. I'm writing a large series of blog posts that uses that technique now.
Also, as @little-cartoon-10569suggested, ownership (and by association deployment frequency) can certainly play a role in determining which approach.
Honestly, I understand why the tutorials are all monolithic stack examples, but it is so easy to do the microstacks with the platform, it should almost be the default as I expect that people doing anything more complicated than basic deployments of single apps are going to run up against the desire (or need) to break the stacks apart.
I think people need to avoid swinging too far in the other direction! You won't want a stack per "thing" to deploy. That would be crazy. So the guidance of start with one is sound, but there should be a next paragraph that says "When you encounter <condition>, consider doing a multi-stack approach by doing <insert guidance here>".
b

best-lifeguard-91445

05/14/2020, 2:46 PM
Dave - I'd love to read your blog/tutorial when you have it available.
👍 1
a

ancient-megabyte-79588

05/14/2020, 8:29 PM
I'll certainly post it here.
The pulumi parts start at the 8th post in the list