Seems I have my answer after looking at github's i...
# automation-api
c
Seems I have my answer after looking at github's issues: https://github.com/pulumi/pulumi/issues/7219
@lemon-agent-27707 do you have any progress on this?
b
there is no progress.
c
I wanted to use pulumi to avoid the hack of shelling out to terraform. But if it's just a thin wrapper on top of the pulumi's cli, no point in using this.
l
@cuddly-book-2159 have you looked at #pulumi-deployments?
In some ways, it solves the problem of single binary automation api. We find many customers starting to build infrastructure APIs on top of deployments with substantially less code than automation api required
c
I will read the documentation, thank you.
b
But if it’s just a thin wrapper on top of the pulumi’s cli, no point in using this
to come back to this, you can argue semantics around what a thin wrapper is, but to compare to shelling out to terraform there are a lot of benefits: • your wrapper and infrastructure code are first class citizens in your language of choice, rather than the code and language being separate • automation API is a supported product by us, you don’t have to maintain or build your own integration And that’s before you just generally compare to Terraform in general: • Pulumi is faster • we have full coverage of most cloud provider APIs with native providers • providers are per resource, not global in scope • secrets are encrypted in state unlike Terraform’s plaintext storing of values • Pulumi’s async model allows for complex operations like running health checks on resources once the API results have returned • You get all the awesome benefits of a responsive community and engineers helping you 🙂 • languages are first class citizens so you get the full scope of the SDKs unlike Terraform’s CDK/functions
c
That's all fine
In the end, our usage is to simplify setup of some infrastructure components on tenant creation (SaaS). We'd like to automate this part and I'm trying to do it with as few "external" dependencies as possible.