Unknown Values: The Secret to Terraform Plan

I have used it in greater scale at the previous client. Working with multiple providers was much easier than with the Terraform setup the current client runs. The integrated secret handling feature is also something I miss, because it allowed for a very clean setup of GitHub configuration using Pulumi. I also prefer Pulumi‘s custom component abstraction to terraform modules, you don’t have to declare inputs and outputs manually, and don’t require complete teardown and recreation for every change. Also, you don’t even have to write custom components, you can simply write a function that create the resources you need, in that case you may have to handle unknown values a bit more manually, which wasn’t so bad, as it’s essentially Promise-based code.

Personally, I see the landscape like this: If you like CloudFormation templates, then Terraform is a better version of that. Especially as it’s workflows are very similar. If you like, or want, CDK then Pulumi will make you very happy, as it’s a much better version of that. Pulumi in particular makes some alternate patterns possible, e.g. using the integrated secret management, that give you more flexibility with how you approach your project.

As a side note, Pulumi is actively working with the community, accepting PRs, etc. and new provider APIs generally are available when they release. This may influence your decision, or not.

I've just started using it for personal stuff and I'm impressed. Its a better CDK in my opinion, as its cloud agnostic.

I don't mean this in a snide way, but https://hn.algolia.com/?q=pulumi makes for good reading about that question as it comes up a lot

Just found out they do support alternative state backends like Terraform does.

Isn't that what Terraform does now too, with their JSON intermediate language and CDK?

I use pulumi to write infra code and I like it better than TF because I can do things "in the middle" like bring input from external files and write out values to files and it's far more natural to me than contorting myself to TF's DSL. I have an example up where I do some SES work[0].

Terraform's 0.12 release[0] was the shining light realization for me that Pulumi's was absolutely the better paradigm. When you start adding expressions, type systems, and ad-hoc iteration primitives to a DSL, you probably should be using a fully powered programming language.

As far as what is kind of offputting to you, I argue that of the two of them Pulumi is the only one with a shot of not doing it the write-it-out-to-text way. Building a representation of desired state is necessary to achieve the goals of both tools -- Pulumi gives you exposure to the objects that make up the tool in your programming language of choice, before they get serialized.

Another key innovation of Pulumi is that you can build those objects and abstractions much easier (IMO) than with TF (i.e. writing a provider), and you can build them with the tooling you're familiar with -- if you're using a supported pulumi language.

[0]: https://vadosware.io/post/setting-up-ses-with-pulumi/

[1]: https://www.hashicorp.com/blog/announcing-terraform-0-12

[0]: https://www.hashicorp.com/blog/announcing-terraform-0-12

A Pulumi program executes effectively as a coroutine with the Pulumi engine, which calls providers and resolves future values in the program which allows more resources to proceed. The fundamental difference here is that in Terraform the graph must be known up front to produce a plan, whereas in Pulumi the graph is constructed on a more ad-hoc basis. Both approaches have merit in different situations.

Yes, Pulumi has the concept of `Input` and `Output`. You need to unwrap an `Output` to inspect the computed value, but that unwrap only exists because Pulumi allows you to.

EDIT: and note that Pulumi has language targets in C#, Typescript, golang, and Python