The future of Terraform CDK • Hacker News Board

Re: The future of Terraform CDK

#101

Post by raw_anon_1111 » Thu, Dec 11, 2025, 3:51 AM UTC

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 have used ChatGPT to generate perfect IaaC using the CDK and Terraform. I give it my labelled descriptive design diagram that I have to do anyway.

I am very detailed about all of the security group requirements, tell it that I don’t need Internet access and tell it which VPC endpoints. I don’t do “agentic coding”.

Re: The future of Terraform CDK

#102

Post by lokar » Thu, Dec 11, 2025, 4:00 AM UTC

here2learnstuff wrote: post #98

packetlost wrote: post #39

Earlier quoted context omitted.

I have absolutely nothing good to say about Pulumi. Stay far, far away.

Please expand on your experiences, because I've had great luck with Pulumi at my company since October 2021. No engineer liked HCL, our demographic was engineers who were familiar with programming languages who wanted to self service basic infrastructure (AWS SecretsManager, IRSA roles, Databricks Service Principals, etc). We were pretty easily able to shim in a RunAtlantis inspired system that displayed previews tha…

For me, the ideal is each team owns its own config/lifecycle mgmt, and does it in the language they wrote the rest of the system in.

Re: The future of Terraform CDK

#103

Post by lighthazard » Thu, Dec 11, 2025, 4:00 AM UTC

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.

Running SST with Pulumi and it's been a great experience. Infrastructure and maintenance has been pleasant and SST's pre-fabs really make things easy to spin up resources.

Re: The future of Terraform CDK

#104

Post by richardfontana » Thu, Dec 11, 2025, 4:08 AM UTC

firesteelrain wrote: post #96

richardfontana wrote: post #95

Earlier quoted context omitted.

Do you mean Red Hat identifies itself using the phrase "Red Hat, an IBM Company"? Because I don't see any use of this on redhat.com (including that website's corporate "about" content) and if any Red Hatters are using this phrasing (I'm a current Red Hat employee) I haven't been aware of it.

I have seen it in several articles. (I don’t work for HashiCorp or Red Hat subsidiaries so no idea what is said or done inside those subs) 1. https://business.adobe.com/customer-success-stories/red-hat.... 2. https://www.openpr.com/news/4100338/linux-operating-system-m...

You said "It’s how Red Hat identifies themselves too" but those two articles are not by Red Hat. So ... it's not how Red Hat identifies themselves, though it seems to be how Hashicorp identifies themselves.

Re: The future of Terraform CDK

#105

Post by rendaw » Thu, Dec 11, 2025, 4:26 AM UTC

GardenLetter27 wrote: post #6

Damn, what are the best alternatives here? For pure AWS I guess CDK directly is okay, but locks you in.

I made https://github.com/andrewbaxter/terrars ! It's great! You get more benefits if you're in a Rust project (obviously) but it has some things that make it a good alternative anywhere:

- More accurate types/type safety than the CDK (for static feedback on required parameters, etc)

- No CLI required - just plain Rust (provider definitions can be published as normal rust packages so you don't have to generate them yourselves, and I've published a bunch of common ones - docker, aws, etc)

- Simpler: Terraform CDK had this crazy flow where it (go code) generated typescript code then used some transpiler to generate target language code. The output wasn't pretty, and there were bugs. Your project directory would get filled with boilerplate generated files.

It generates tf json files and has a fairly safe way for handling variable interpolation and escapes - I haven't hit any weird bugs with it.

Re: The future of Terraform CDK

#106

Post by katdork » Thu, Dec 11, 2025, 4:28 AM UTC

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.

My experience is that by stealing providers from Terraform, they failed to properly handle statically typed languages (Go) with certain providers (HCloud); I had problems with their ID type and had to abandon my Pulumi setup.

Re: The future of Terraform CDK

#107

Post by rubenvanwyk » Thu, Dec 11, 2025, 4:32 AM UTC

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.

Re: The future of Terraform CDK

#108

Post by nsonha » Thu, Dec 11, 2025, 4:37 AM UTC

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.

"Hashicorp, an IBM company"

Common sense would be IBM mandating that branding, as opposed to Hashicorp.

Re: The future of Terraform CDK

#109

Post by rendaw » Thu, Dec 11, 2025, 4:48 AM UTC

scruff3y wrote: post #8

GardenLetter27 wrote: post #6

Damn, what are the best alternatives here? For pure AWS I guess CDK directly is okay, but locks you in.

Just use Terraform?

The value of CDK was always that it allowed you to write in a fully orthogonal language rather than the poor pseudo-language of hcl.

When writing stacks you need normal language features: loops, yes, but also if statements, reuse (functions), being able to do stuff like complex string parsing and re-formatting, etc etc.

HCL supports loops, modules can be kind-of used as functions with lots of footguns, there are awful hacks for some other things, and some stuff just couldn't be done.

Re: The future of Terraform CDK

#110

Post by roboben » Thu, Dec 11, 2025, 5:51 AM UTC

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.

They should have renamed it first to HashiCorp, an IBM Company CDK, then shut it down