Live data from Hacker News

The future of Terraform CDK

github.com

51–60 of 140 posts

Re: The future of Terraform CDK

#51
post #32

This is particularly frustrating as I've spent the last year writing many thousands of lines of CDKTF Python. HCL just does not have the modularity and expressiveness that Python, or other languages CDKTF supports. I guess I'll spend another year migrating to Pulumi now..

The lack of expressiveness of HCL is the point and what makes it so good

Being able to inherit from Ingress and add a parameter of say public=True/False and then it change annotations, middleware, etc and then being able to re-use that across 100s of stacks is very powerful. DRY is not something HCL is good at.

Re: The future of Terraform CDK

#53
post #23

Earlier quoted context omitted.

Does it do ephemeral values yet?

Yep, as of yesterday’s 1.11 release it’s supported! That also includes a new “enabled” meta argument, so you don’t have to hack around conditional resources with count = 0. [0]: https://opentofu.org/blog/opentofu-1-11-0/ Disclaimer: affiliated with the project

Damn, might finally be able to use it. The lack of ephemeral values was a major blocker.

Re: The future of Terraform CDK

#55

As an alternative is anyone considering https://sst.dev/ (which uses Pulumi under the hood)? We use it at work and I’ve been quite happy with it

It’s not an alternative at all. Terraform CDK is basically TypeScript transpired to HCL. You can codegen TypeScript bindings for any provider. And then write normal TypeScript.

Re: The future of Terraform CDK

#56
post #32

Earlier quoted context omitted.

The lack of expressiveness of HCL is the point and what makes it so good

Being able to inherit from Ingress and add a parameter of say public=True/False and then it change annotations, middleware, etc and then being able to re-use that across 100s of stacks is very powerful. DRY is not something HCL is good at.

Getting too clever with an imperative language in what is inherently a declarative domain, is an idea bad enough that they invented a whole new language to avoid you doing it. But some lessons have to be learned the hard way I guess

Re: The future of Terraform CDK

#57
post #38

Earlier quoted context omitted.

How do you migrate from count/for_each to `enabled` ?

You can just switch from `count = 1` to `enabled = true` (or vice-versa, works back-and-forth) for a resource and tofu will automatically move it next time you apply. It's pretty seamless.

That's cool! We'll still need to change all of the references to `resource[0]`, right? Or does tofu obviate that need as well?

Re: The future of Terraform CDK

#58
post #29
post #13

Earlier quoted context omitted.

I went with CDK, I'm locked into AWS already and it means my major dependency for IaC is my cloud vendor and not a third party. If I really need to migrate off of AWS at some point I'll throw an LLM at it.

Exactly. It's just so much cleaner to do it in the Cloud provider's native tooling. The impedance mismatch from Cloud-agnostic abstractions always just makes thing shitty enough that in the long run you spend more time dealing with weird edge cases. Besides, actual full-scale Cloud migrations are exceedingly rare.

Terraform is not an abstraction on top of multiple cloud providers, you work with aws, azure etc explicitly. It is , however, agnostic in the sense that you can provision aws, azure, gcp, etc resources within the same iac project

Re: The future of Terraform CDK

#60
post #4
post #2

It's odd to always say "Hashicorp, an IBM company". Looks like they want to assign blame. I did try Pulumi a while back, but the compatibility with Terraform modules was not great, so I've switched to CDKTF, which can handle unmodified modules. Dunno if I'll switch back to Pulumi or just use OpenTofu directly.

I was thinking the same thing about the "an IBM company". My guess is that it's a lazy find/replace.

It’s one thing to say it once but 3 times in the same paragraph seems weird for sure!
Post reply on HN