5 ms·

Well... It's just my own personal opinion, but writing Pulumi code (be it Go or Python) feels like I'm writing a program that emits some Terraform-like code (co

Well... It's just my own personal opinion, but writing Pulumi code (be it Go or Python) feels like I'm writing a program that emits some Terraform-like code (conceptually, not the actual shape) under the hood and runs an interpreter afterwards. I've used that mode of operation because I needed to continuously update infrastructure to match database updates - there's another and probably more mainstream option is that Pulumi runtime runs a language runtime for me which feels even weirder as my program is not really a program but just an oddly-linked library. I haven't really looked under the hood but I strongly suspect I'm not that far away from truth. At some point I've seriously considered a question why I'm not just templating HCL directly rather than dealing with all those Pulumi oddities. Either way it feels very different and pretty much alien.

stavros 5y ago
Isn't that what Terraform does now too, with their JSON intermediate language and CDK?
hardwaresofton 5y ago
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/ https://vadosware.io/post/setting-up-ses-with-pulumi/ [1]: https://www.hashicorp.com/blog/announcing-terraform-0-12 https://www.hashicorp.com/blog/announcing-terraform-0-12 [0]: https://www.hashicorp.com/blog/announcing-terraform-0-12 https://www.hashicorp.com/blog/announcing-terraform-0-12
jen20 5y ago
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.

stavros 5y ago

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

hardwaresofton 5y ago

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/ https://vadosware.io/post/setting-up-ses-with-pulumi/ [1]: https://www.hashicorp.com/blog/announcing-terraform-0-12 https://www.hashicorp.com/blog/announcing-terraform-0-12 [0]: https://www.hashicorp.com/blog/announcing-terraform-0-12 https://www.hashicorp.com/blog/announcing-terraform-0-12

jen20 5y ago

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.