News for hackers. Stuff that matters.
Re:The future of Terraform CDK by tapoxi on Wednesday December 10, 2025 @02:44PM (#46222632)
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.

Re:The future of Terraform CDK by ryandvm on Wednesday December 10, 2025 @03:15PM (#46223109)
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.

Re:The future of Terraform CDK by emoII on Wednesday December 10, 2025 @04:36PM (#46224214)
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 by raw_anon_1111 on Wednesday December 10, 2025 @05:58PM (#46225200)
I always hated this meme. Using Terraform no more makes you “cloud agnostic” than using Python to script AWS services and calling boto3 than using bash and calling the AWS CLI.
Re:The future of Terraform CDK by thayne on Thursday December 11, 2025 @03:03AM (#46228822)
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 by GuinansEyebrows on Thursday December 11, 2025 @11:35AM (#46233562)
writing HCL is so much more enjoyable than writing CF, even if HCL is fairly verbose (hey, it's not as bad as XML!). CF feels like a series of PM requirements dutifully codified with no dogfooding whereas HCL/TF feels like a tool that was developed by people who actually wanted to use it.
Re:The future of Terraform CDK by manquer on Wednesday December 10, 2025 @08:31PM (#46226573)
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 cycles in CF. CloudFormation is also not particularly fast, other IaaC frameworks are not that different.

Running an agent to iterate until it gets it right is just more difficult with IaaC refactor projects. Hallucinations, stuck loops and other issues, can quickly run the infra bill up not to mention security.

Re:The future of Terraform CDK by raw_anon_1111 on Wednesday December 10, 2025 @10:51PM (#46227431)
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 by manishsharan on Thursday December 11, 2025 @08:36AM (#46231189)
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 .