Live data from Hacker News

Converting Full Terraform Programs to Pulumi

pulumi.com

51–60 of 66 posts

Re: Converting Full Terraform Programs to Pulumi

#51
We use Terraform but mostly because of its ecosystem. I was always tempted to use Pulumi, especially because they got something right from the beginning: pure declarative code is an illusion.

You always need loops, control structures, etc. and this is automatically a feature in Pulumi as it is in the language you use it with.

Terraform users hack it all the time (think of the "count" as if/else, for instance) precisely because it's never a purely a declarative config what you need, and the level of dynamism you need is not been semantically supported by Terraform.

So, we are stuck with hacks...

Re: Converting Full Terraform Programs to Pulumi

#52

Honest question, if you're locked in to AWS why not just use the CDK? I've used Terraform and Pulumi in the past and the "platform agnostic" is only true for trivial builds. Once you get into medium sized infra you're writing so much AWS specific code it stands better to go 1st party. I can't speak for GCP, but this is what happened to us. We kept fighting 3rd party code we ended up going CDK. While there are still i…

I absolutely love the CDK's typed approach. Having said that, I still would choose Terraform over CDK mainly because of the way they handle drift detection / drift resolution. Basically, with CDK and the underlying CloudFormation, you can get told that there's a drift. And that's it; now you have to go and fix it manually. Someone deleted half your infra? Well, have fun rebuilding it by hand. With terraform, you just apply again, and it fixes the drift.

There are a number of other subtler topics as well. In my experience, Terraform tends to be noticeably quicker to run (when the limiting factor is not some AWS service that's spinning up for ages - but usually that is not the case after the first run). And just because you're mostly vendor locked, doesn't mean you don't have a few 3rd party vendors to also integrate; it's nice to have a wider support for these providers. While the CDK's types are more consistent than the Terraform ecosystem and generally lead to faster prototyping, the type system itself only protects you from a small subset of errors. You can still wire things together that will never work, and you'll only find out at deploy time. Lastly, I've often found the CDK's versioning to be fairly odd. I get the idea behind stable and experimental packages, and the need to be explicit about these. However, it seems odd that certain packages spend _years_ in experimental, despite being absolutely mainstream from the very beginning (I am looking at you, API Gateway V2 - though it's been a few months since I last checked).

(OK, so this was a bit more tongue-in-cheek than I normally go for. I'm somewhat frustrated by CDK because it has so much going for it, that when it disappoints me, it really hurts.)

Re: Converting Full Terraform Programs to Pulumi

#53
post #48

If devs write and maintain their own IAC then Pulumi is a good choice since they can write it in a familiar language. If however a dedicated devops team has to manage it eventually, and there are multiple dev teams who all use different languages, then Terraform is better, since it’s practically impossible to learn all these languages. Terraform will give you a dumbed down enough lingua franca. Also Terraform gives y…

> If however a dedicated devops team has to manage it eventually, and there are multiple dev teams who all use different languages How is this a disadvantage? If you can mandate Terraform and HCL across the org you can mandate Pulumi and a language eg Typescript. What’s the difference? You can also use Terraform with a programming language ie CDKTF so the Terraform choice doesn’t make it simpler.

Under the case that “there are multiple dev teams who all use different languages” as stated, they have the advantage with TF that it’s an easier to learn DSL than Typescript.

CDKTF is totally optional and besides the point. Could as well say you can use Pulumi with Makefiles so the Pulumi choice doesn’t make it simpler.

Re: Converting Full Terraform Programs to Pulumi

#54
post #43
post #35

Earlier quoted context omitted.

When I switched from Azure to AWS I just had to learn AWS specifics and then could use my existing TF knowledge to put it in code. No need to learn CDK as well. If I ever end up working in GCP, it will hopefully be the same. If you solely work with one cloud and don't intend on switching cloud providers or working in a context where multiple cloud providers are used, then by all means specialise. Personally I'm worki…

If you were using CDK you’d switch to bicep which also uses code instead of config files.

For anyone else out of the loop, that appears to be:

https://learn.microsoft.com/en-us/azure/azure-resource-manag...

Re: Converting Full Terraform Programs to Pulumi

#55
post #17

I really dislike pulumi's pricing structure. I absolutely hate the idea of paying credits for each resource that I create - it creates resistance to experiment and just create a bunch of resources that don't cost anything on the cloud provider yet somehow costs me money for the tool to manage them. It's funny because I believe they used to have a per seat licensing and then people complained that they were paying too…

I like Pulumi a whole lot, but my org did end up needing to move to hosting our statefiles on our own S3 backend and managing that ourselves when the cost became prohibitive. We were a small org (<20 folks) with tens of thousands of resources, and we just couldn't justify the costs even though we liked the Pulumi hosted app quite a bit.

Re: Converting Full Terraform Programs to Pulumi

#56

I've been happy with Hashicorp Terraform Cloud and HCL except for the very recent price hikes which may force us to leave them so we are keeping our eyes out for alternatives. The AI assistant seen here is a very good idea. I will actually share this with my team. I imagine the terraform conversion doesn't work when you use in-house written providers (in golang), is this correct?

We're building our new infrastructure with Terraform - and experimenting with postgresql for state. So far so good, but we have only a handful of resources.

Bit of a catch-22 to setup managed postgres for state, tailscale network with a vm as exit-node (to access postgres via VPN/lan - not Internet) - via Terraform - and then switch state from local (initial setup) to postgres.

But nice to be able to eg: interact with a different provider for DNS, supplying IPs from other resources.

Re: Converting Full Terraform Programs to Pulumi

#57
post #17

I really dislike pulumi's pricing structure. I absolutely hate the idea of paying credits for each resource that I create - it creates resistance to experiment and just create a bunch of resources that don't cost anything on the cloud provider yet somehow costs me money for the tool to manage them. It's funny because I believe they used to have a per seat licensing and then people complained that they were paying too…

Note that terraform have the same pricing structure now: https://www.hashicorp.com/products/terraform/pricing

Re: Converting Full Terraform Programs to Pulumi

#58

If devs write and maintain their own IAC then Pulumi is a good choice since they can write it in a familiar language. If however a dedicated devops team has to manage it eventually, and there are multiple dev teams who all use different languages, then Terraform is better, since it’s practically impossible to learn all these languages. Terraform will give you a dumbed down enough lingua franca. Also Terraform gives y…

Can Terraform be used in place of ansible? I've seen way to much "logic" in ansible playbooks.

Re: Converting Full Terraform Programs to Pulumi

#59
post #48

Earlier quoted context omitted.

> If however a dedicated devops team has to manage it eventually, and there are multiple dev teams who all use different languages How is this a disadvantage? If you can mandate Terraform and HCL across the org you can mandate Pulumi and a language eg Typescript. What’s the difference? You can also use Terraform with a programming language ie CDKTF so the Terraform choice doesn’t make it simpler.

Under the case that “there are multiple dev teams who all use different languages” as stated, they have the advantage with TF that it’s an easier to learn DSL than Typescript. CDKTF is totally optional and besides the point. Could as well say you can use Pulumi with Makefiles so the Pulumi choice doesn’t make it simpler.

> CDKTF is totally optional and besides the point.

Eh? Then Terraform is optional too? You can do the reverse and say HCL is optional. Who decides? You're thinking from a Terraform 1st perspective.

> Could as well say you can use Pulumi with Makefiles so the Pulumi choice doesn’t make it simpler.

Except Pulumi doesn't support makefiles? It does support yaml.

So yaml is a simpler DSL that people know than HSL, so it still wins by your logic? Makes no sense. UI is simpler to learn than Terraform. Might as well do ClickOps?

> “there are multiple dev teams who all use different languages” as stated

And so you can't pick a language that is used more often? It doesn't have to be Typescript. So if >30% of the devs use 1 language it already has that advantage over HCL.

Re: Converting Full Terraform Programs to Pulumi

#60
post #59

Earlier quoted context omitted.

Under the case that “there are multiple dev teams who all use different languages” as stated, they have the advantage with TF that it’s an easier to learn DSL than Typescript. CDKTF is totally optional and besides the point. Could as well say you can use Pulumi with Makefiles so the Pulumi choice doesn’t make it simpler.

> CDKTF is totally optional and besides the point. Eh? Then Terraform is optional too? You can do the reverse and say HCL is optional. Who decides? You're thinking from a Terraform 1st perspective. > Could as well say you can use Pulumi with Makefiles so the Pulumi choice doesn’t make it simpler. Except Pulumi doesn't support makefiles? It does support yaml. So yaml is a simpler DSL that people know than HSL, so it s…

>You're thinking from a Terraform 1st perspective.

You can use Terraform without CDKTF.

>Except Pulumi doesn't support makefiles?

Everything and nothing support Makefiles ;-)

> So yaml is a simpler DSL

Yaml isn't a DSL. It's just that 5000 different projects use it in 5001 different ways to express something randomly (e.g. Ansible) INSTEAD of creating a DSL.

> pick a language that is used more often

I would argue that Terraform is among devops people the most widespread tool for this purpose, so you'll have an easier job finding staff searching for people who know terraform than to find people knowing Pulumi + your mandated choice of language. Remember this is for the "central devops team supports multiple dev teams" scenario - for the other scenario of devs running their infra code themselves I've already said Pulumi makes a lot of sense, and then you don't need to mandate anything, and everyone will be able to reinvent their square wheel independently - until they're bought by a bigger company which has a dedicated SRE team that takes over Prod responsibility from the devs, and you'll find them searching for a tool to convert Pulumi into TF ;-) .

Post reply on HN