Hello. First off, I hope #getting-started is the right place for proof of concept talk. Feel free to forward this to general if needed. I’m working on a PoC for our team to adopt Pulumi. Currently, I’m looking for examples of the following: 1. Multiple region use - Specifically, is it recommended to have a stack per region or per SDLC deploy. Everything in the docs insinuates the latter, like dev, qa, and prod. But, having a large prod deploy to 20+ regions seems daunting. Or rather, a huge leap of faith to get everyone on board? 2. Blue/Green deployment - I currently don’t see how blue/green deployments can be achieved, without creating stacks for each of these. If that were combined with the stacks per region above, you see where our stacks proliferate and they become a whole other issue to manage. Any existing examples or thoughts are welcome. I’m hoping to get our project on the right track and migrate incrementally. Update: Maybe a better question to ask is how to treat existing infrastructure as immutable and use pulumi to deploy to a new region as a blue/green setup for future deployments.

For #1, you can deploy to multiple regions in a single stack if that would make more sense. For example, if your production environment normally encompasses resources in multiple regions, then put that into a single stack. The key in this case is that you have to multiple multiple providers, each configured for a region where you're deploying. Look up "explicit providers" and you'll see some examples of what I'm talking about. I think you'd have to use separate stacks for #2; I don't see any other way of making it work. You might need a third project that controls the routing between the "blue" and "green" stacks so that you can gradually cut traffic over, then run a

pulumi destroy

on the old stack once all the traffic is moved over. I hope this helps! Please continue to ask questions, and we'll do our best to help.

Thanks for the direction. So, in the case of the blue/green deployment, the third stack that you are referring to would be our prod networking infrastructure, such as route53, etc., correct? And, we would use these as shared resources, correct? Here is where things get fuzzy for me. 1. I want these stacks to be able to update things like CNAME per instance and add to the routing, but I don’t want them to be able to ever destroy that route53 instance. Making it mutable, but indestructible. Is that a thing? 2. So, let’s assume 3 stacks now;

blue

,

green

, and

backbone

.

blue

has v1 in it, with load balancers, app servers, CNAME updated in route53 from

backbone

, etc. all setup and deployed. When

green

runs

pulumi up

, it adds v2, route53, etc. Now…the doubt…sorry for being new and asking this ahead of time, if

green

runs

pulumi down

, does it properly remove solely the CNAME entires that it made and not try to tear down the whole route53 instance?

The devil is in the details (which I don't have), but based on what I do know: 1. It seems like this could be solved by letting

backbone

manage the hosted zone, but the zone entries themselves could be created by

blue

or

green

(and therefore could also be destroyed by

blue

or

green

) 2. If you follow the approach in step 1, then yes, you should be good to go. Obviously, you'll want to test all this to be sure it behaves as you expect (and as you want).

Just in case it's not obvious from the docs: the potential

backbone

stack should not be a stack in the same project. Since it has completely different resources than

blue

and

green

, the correct solution here is to use two projects: one for the backbone stuff, and one for your deployable instance (`blue`/`green`).

Yes, thank you for clarifying that @little-cartoon-10569! I thought I had referred to

backbone

as a project, so Paul's comments are absolutely spot on.