Live data from Hacker News

Converting Full Terraform Programs to Pulumi

pulumi.com

41–50 of 66 posts

Re: Converting Full Terraform Programs to Pulumi

#41
post #38

I love the idea of IAC as actual code . Too many times I've looked at yet another over engineered templating engine and thought, why couldn't this just be code?

The reason for not doing a full programming language for that is that you can prove the infrastructure is finite with a simple template language, but you can’t if your template language can do conditional branching. Or something like that. My CS-fu is admittedly weak. OTOH, I think Lisp would be the perfect choice for IaC.

It's a valid point. Although I think most of these templating languages are probably Turing complete anyway. We should make better use of Turing limited languages.

I think reinventing the wheel every time a for loop is needed in a resource spec makes things unnecessarily tedious for everyone.

Re: Converting Full Terraform Programs to Pulumi

#42
post #24
post #18

Earlier quoted context omitted.

You can use Pulumi for free. Also, the incremental cost for each resource is minuscule. Unless your experiments require thousands of resources, it really shouldn't be a big deterrent. Just clean up when you're done experimenting.

Sort of. You can use Pulumi for free as an individual. As a team you'd have to use a backend for your state other than Pulumi cloud, and your responsible for your own concurrency control [1]. In a team environment that's such a big foot gun I don't really consider it usable. That limitation makes Pulumi a nonstarter for me. Even if I am paying for it, this is super sensitive data and I want control over how it's stor…

That’s wrong, you can use Pulumi as a team for free so long as you stay under the 150k free credit limit. You don’t have to manage your own state backend.

I’m using the free Pulumi tier at work, we have three EKS clusters, 3 RDS instances, about 6 ECRs, probably 10-12 EC2 instances, various k8s resources, VPCs etc and aren’t paying anything yet.

I do love the product and will be happy to pay when we reach that level.

Re: Converting Full Terraform Programs to Pulumi

#43
post #35

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…

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.

Re: Converting Full Terraform Programs to Pulumi

#44
post #38

Earlier quoted context omitted.

The reason for not doing a full programming language for that is that you can prove the infrastructure is finite with a simple template language, but you can’t if your template language can do conditional branching. Or something like that. My CS-fu is admittedly weak. OTOH, I think Lisp would be the perfect choice for IaC.

It's a valid point. Although I think most of these templating languages are probably Turing complete anyway. We should make better use of Turing limited languages. I think reinventing the wheel every time a for loop is needed in a resource spec makes things unnecessarily tedious for everyone.

IIRC, Terraform was not Turing-complete at the start, but users demanded features and that’s how it ended.

The idea to start from a programming language is that, since you are going to end up Turing-complete anyway, at least you make sure you don’t end up with a programming language with an awkward syntax.

Re: Converting Full Terraform Programs to Pulumi

#46
post #5
post #3

Do these guys need a state file like terraform does? It's great that you can use a normal programming language, but that's nowhere near as big a pain point as state files getting out of sync. Not even close.

I'm pretty sure they do, which is a feature, IMO. We're coming up on 10000 resources in our main Terraform repository and while there is definitely some friction, it's overall much better than having to hit the cloud API's to gather each of those states which would probably take at least an order of magnitude longer. We also just recently started setting up a periodic drift detection build to help identify and addres…

> We're coming up on 10000 resources in our main Terraform repository and while there is definitely some friction, it's overall much better than having to hit the cloud API's to gather each of those states which would probably take at least an order of magnitude longer.

I don't think that's necessary true. Most cloud API's actually can return hundreds of records with 1 API calls, e.g. https://docs.aws.amazon.com/elasticloadbalancing/latest/APIR... has a maximum page size of 400.

If I manage the cloud resources via some custom tools and/or with some ansible-fu, I can decide to batch the API calls when it makes sense.

With terraform, it is not possible to do so (https://github.com/hashicorp/terraform-plugin-sdk/issues/66, https://github.com/hashicorp/terraform-provider-aws/issues/2...).

Re: Converting Full Terraform Programs to Pulumi

#47
post #22

Isn't pulumi aws just terraform under the hood still? Why wouldn't I just use terraform's CDKTF instead?

CDKTF feels like a giant hack (yes, used it).

No everything is available vs TF HCL, it uses CDK from AWS CDK and tries to bridge things to TF have codegen. There’s a lot of weird corner cases and inconveniences. It even uses React under the hood.

Pulumi at least takes care of it better. Maybe not perfectly but better.

Re: Converting Full Terraform Programs to Pulumi

#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.

Re: Converting Full Terraform Programs to Pulumi

#49
post #22

Isn't pulumi aws just terraform under the hood still? Why wouldn't I just use terraform's CDKTF instead?

>Isn't pulumi aws just terraform under the hood still?

It depends.

The AWS "Classic" provider uses the terraform provider [1].

The AWS "Native" provider does not, and instead uses the AWS Cloud Control API [2].

[1]: https://github.com/pulumi/pulumi-aws

[2]: https://github.com/pulumi/pulumi-aws-native

Re: Converting Full Terraform Programs to Pulumi

#50

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…

Because you can use Terraform not only for infrastructure. In our case, we use it also to setup GitLab and other services.
Post reply on HN