09/25/2020, 7:18 PM
@lemon-agent-27707 the automation api looks awesome. With a bit more context on where i’m investigating to use it. We have built a BPaaS (blockchain platform as a service #buzzwordbingo) which is a large collection of microservices to create and manage k8s clusters on AWS/Google/Azure and deploy on top of this blockchain nodes, api’s, management ui’s etc. Currently it is all hand coded TS + Helmfile + Helmcharts. But we are reworking some of them and I kind of feel like i can ditch all my cloud provider code (and gain a lot more clouds) and helmfile with pulumi. All clusters are set up on demand and settings etc are stored in a database. I think i can cut thousands of lines of code by building on pulumi. Just one thing i need to investigate and that is state management. each cluster/services set can be a stack (we have a unique name for each). What are the benefits of using the could hosted TEAM PRO over an s3 backend?
🎉 1
Follow up question, how would I use your PR to try it out?


09/27/2020, 1:11 PM
Hey @proud-pizza-80589, glad to hear this is going to help solve some of your problems! Deploying infrastructure on the fly is exactly what we had in mind when designing the api, so your use case sounds perfect. Trying it out depends on what language you'd like to use. Go is published in alpha and available to use today. There is a full examples repo here that has multiple sample projects: If you're looking for typescript, we do have a branch but there will be a bunch of changes over the next few days before it goes out for final code review: I'd recommend waiting a few days for node if that's what you're interested in, but happy to help get you set up if you don't mind handling the incoming changes. The short of it is to: 1. enlist in that branch 2.
cd ...pulumi/pulumi/sdk/node
make build && make install
(this will yarn link the pulumi pacakge globally 4. Start a node project somewhere and run
yarn link "@pulumi/pulumi"
Python and .NET will be started once we finish up node.
There's a few key differences between S3 and the Pulumi hosted backend: 1. S3 has no concurrency control. This is a big deal for your use case as you run the risk of automated deployments colliding and potentially corrupting state/making simultaneous edits to your infra. If you want to use the S3 backend, you'll have to implement locking around your deployments to guard against this. The pulumi backend has locking and concurrency control built in. 2. The pulumi backend is designed for software teams, and has features like stack access contorl, RBAC, built-in concurrency control, etc. 3. The pulumi backend has some interesting state storage capabilities that aren't in the other backends. You can refresh config from the last deployment, meaning you don't have to worry about storing it yourself. I've created a temporary vm manager that queries that pulumi backend for all ephemeral stacks matching time based criteria. This just kinda works and doesn't require me to maintain any state myself. It will work either way, but the S3 backend will require more manual effort on your part.


09/27/2020, 4:09 PM
Hmm, the concurrency is indeed a good selling point!