4 ms·

> So returning to the original question: why doesn't Terraform use an existing language? So far, I've not yet encountered an existing language runtime which con

> So returning to the original question: why doesn't Terraform use an existing language? So far, I've not yet encountered an existing language runtime which contains the building blocks Terraform uses in order to keep the plan-related promises. That sure does sound like the author believes "pulumi preview" shouldn't ever work

fitzoh 5y ago
Yep, definitely disappointed that Pulumi was not mentioned.
threatofrain 5y ago
Does anyone have any experiences with Pulumi to share?
- thuringia 5y ago
  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.
- JamesSwift 5y ago
  I've just started using it for personal stuff and I'm impressed. Its a better CDK in my opinion, as its cloud agnostic.
- mdaniel 5y ago
  I don't mean this in a snide way, but https://hn.algolia.com/?q=pulumi https://hn.algolia.com/?q=pulumi makes for good reading about that question as it comes up a lot
x3n0ph3n3 5y ago
I want so badly to use pulumi's tools, but relying on them as a 3rd party service is just not acceptable to me.
- x3n0ph3n3 5y ago
  Just found out they do support alternative state backends like Terraform does.
  - andrewSC 5y ago
    Correct. For my team we leverage S3 for state storage and with a recent upstream change, there is no longer a need to explicitly set a lock on the state as the lock is now set for you by default. EDIT: Should mention that enabling bucket versioning here is also a little cherry on top (to me).
    - x3n0ph3n3 5y ago
      Can you tell me more about the state lock or link to some relevant details?
drdaeman 5y ago
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
jpgvm 5y ago
It's called Jsonnet and it definitely exists.

fitzoh 5y ago

Yep, definitely disappointed that Pulumi was not mentioned.

threatofrain 5y ago

Does anyone have any experiences with Pulumi to share?

thuringia 5y ago
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.
JamesSwift 5y ago
I've just started using it for personal stuff and I'm impressed. Its a better CDK in my opinion, as its cloud agnostic.
mdaniel 5y ago
I don't mean this in a snide way, but https://hn.algolia.com/?q=pulumi https://hn.algolia.com/?q=pulumi makes for good reading about that question as it comes up a lot

x3n0ph3n3 5y ago

I want so badly to use pulumi's tools, but relying on them as a 3rd party service is just not acceptable to me.

x3n0ph3n3 5y ago
Just found out they do support alternative state backends like Terraform does.
- andrewSC 5y ago
  Correct. For my team we leverage S3 for state storage and with a recent upstream change, there is no longer a need to explicitly set a lock on the state as the lock is now set for you by default. EDIT: Should mention that enabling bucket versioning here is also a little cherry on top (to me).
  - x3n0ph3n3 5y ago
    Can you tell me more about the state lock or link to some relevant details?

drdaeman 5y ago

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

jpgvm 5y ago

It's called Jsonnet and it definitely exists.