Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future of Terraform CDK

github.com

Post reply on HN
Print view View original

111–120 of 140 posts

Re: The future of Terraform CDK

#111

Post by purpleidea »

packetlost wrote: post #39
vbernat wrote: 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 have absolutely nothing good to say about Pulumi. Stay far, far away.

Have a look at https://github.com/purpleidea/mgmt/ and tell me what you think. We don't have enough docs though. Tough being an open source thing that you want to keep open.

Re: The future of Terraform CDK

#112

Post by stingraycharles »

jjice wrote: post #5
vbernat wrote: 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.

> It's odd to always say "Hashicorp, an IBM company". Looks like they want to assign blame. All their branding does this now, including the HashiCorp logo on their website [0]. There's gotta be a name for this specific branding pattern, but I don't know it. [0] https://www.hashicorp.com/en/blog/products/terraform

It’s endorsed branding. Basically when a parent company “endorses” its subsidiaries’ brands, but keep their own name (as opposed to renaming everything to IBM, like eg Google would do).

Re: The future of Terraform CDK

#113

Post by solatic »

everforward wrote: post #78
lijok wrote: post #56

Earlier quoted context omitted.

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

The problem is they did an exceptionally poor job at designing their language. A reasonably large Terraform codebase is almost universally hard to read for one of two reasons: it's either unexpressive (read: verbose to the point it's hard to read) or modularized but hard to read because it's fragmented into a bajillion reusable modules. SQL is also declarative, but incredibly expressive. A thousand character query co…

> reasonably large

Anyway you shouldn't have too many resources in a single Terraform workspace, for performance reasons. The real issues with Terraform come when you start to want to orchestrate different workspaces triggering each other, and trying to write that orchestration language, which itself would be declarative.

Terraform built a Stacks feature, but support is Terraform Cloud-only. OpenTofu has issues in the area that have been open for years: https://github.com/opentofu/opentofu/issues/931 https://github.com/opentofu/opentofu/issues/2860 and progress is slow, in part (IMO) because a genuine solution requires server-side evaluation (i.e. triggering applies as Kubernetes Jobs) and the open-source implementation of Terraform Enterprise/Cloud is a completely separate project with a completely different group of maintainers, Terrakube.

Re: The future of Terraform CDK

#114

Post by thayne »

ryandvm wrote: post #29
tapoxi wrote: 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.

AWS's native tooling is Cloudformation, and CDK is actually just a wrapper around that that generates cloudformation code (as CDKTF is a wrapper for terraform). And I like to avoid cloudformation as much as possible.

Re: The future of Terraform CDK

#115

Post by thayne »

rubenvanwyk wrote: post #107
moltar wrote: post #54

This is so sad. It’s a great project. Needs to be forked and maintained. If anyone forks please email me I’ll contribute.

OpenTofu is already the de facto fork.

OpenTofu is a fork of terraform, not CDKTF.

Although, I would hope a fork of cdktf would target opentofu instead of terraform.

Re: The future of Terraform CDK

#117

Post by darkwater »

cube2222 wrote: post #44
lijok wrote: 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.

And you don't get the annoying array form for the resulting resource with the `enabled` syntax, right?

EDIT: Oh just realized the sibling asked the same, but the doc doesn't state that clearly, although it seems to me that the doc implies that yeah, it doesn't use the array form anymore.

Re: The future of Terraform CDK

#118

Post by kennu »

Sad to see it go. The philosophy of CDK has been to offer a shared ecosystem between IaC, backend code and frontend code, allowing to share configuration, data structures and libraries between all of them. It has made development more unified and have less redundancy and manual work. Personally I don't want to repeat some stuff in a special Terraform language, if I can find a way to manage the whole application in TypeScript.

Re: The future of Terraform CDK

#119

Post by manishsharan »

manquer wrote: post #91
tapoxi wrote: 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.

IaaC code is one of those use cases just throwing LLM is painful for a refactor. In my experience claude/codex to wrangle CDK constructs be complicated, it frequently hallucinates constructs that simply do not exist, options that are not supported etc. While they can generate IaaC component mostly okay and these problems can be managed, Iterations can take a lot of time, each checkpoint, goes the deploy/ rollback cyc…

I had Gemini ingest our huge aws cloudformation repo . I had it describe each infrastructure component and how it related to others and creation hierarchy and IAM.

I got a nice and comprehensive infrastructure requirement document out of this.

Now I am using it to create Terraform repo , deploying it via OpenTofu and comparing it to my existing AWS cloud formation . This part is still a WIP .

Re: The future of Terraform CDK

#120

Post by nevon »

borisbanjo wrote: post #76

CDKTF works beautifully, all the complains here seem to be from salty devops who got pissed the developers wanted something more powerful than the garbage HCL with its even more garbage module system. CDKTF stacks are great and the construct pattern gives you modularization without all the baggage.

Not stated in the most diplomatic way, but I do agree. Having used CDK (not cdktf) and now being forced back to Terraform feels like going back to the stone age. It is absolutely obvious to me that generating infrastructure definitions from a regular, testable language using all the same tools, techniques and distribution mechanisms that you use for all your other software development is the superior way. Being able to piggyback off of the vast ecosystem of Terraform providers was a really clever move, although I understand it led to some rough edges.
Post reply on HN