Live data from Hacker News

The future of Terraform CDK

github.com

91–100 of 140 posts

Re: The future of Terraform CDK

#91
post #13

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

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

#92
post #56

Earlier quoted context omitted.

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

Declarative vs. imperative doesn't have anything to do with power or expressiveness. Some general purpose programming languages are declarative, and some declarative DSLs are Turing-complete.

I worry that comments like this lead the average newbie to overlook (or worse, avoid) declarative languages (both among DSLs and among general-purpose languages) because they will associate the term with hacky, confining, gotcha-ridden messes like Terraform's HCL, Azure DevOps' standards-breaking "YAML" DSL, etc.

Incidentally I agree that a language like Python is a terrible fit for this domain, but it's also plain to see that HCL is a shitty tarpit. It's not hard to understand why people want to get away from HCL.

And concretely, you can use Pulumi in a pure functional style with F# or Scala.

Re: The future of Terraform CDK

#94

Earlier quoted context omitted.

Probably Pulumi

I'll be honest Pulumi is pretty cool but I'm a little worried by how high on the stack it is. I wonder if the same thing won't happen to them that's happening to CDKTF here. Terraform is ugly but it works well enough for me and seems ingrained enough to be durable to this kind of thing (i.e. I bet for sure the community would pick it up (I wish I could say that I'm part of that community but I can't say I use it quit…

> I wonder if the same thing won't happen to them that's happening to CDKTF here.

This is clearly a business decision rather than technical.

Pulumi is meant to be semi-automated (in generating the bridges) so perhaps is slightly better off in maintenance.

Re: The future of Terraform CDK

#95
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 how Red Hat identifies themselves too

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.

Re: The future of Terraform CDK

#96

Earlier quoted context omitted.

It’s how Red Hat identifies themselves too

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

Re: The future of Terraform CDK

#97

Earlier quoted context omitted.

The often excluded option is dynamically generating JSON and feeding that to TF instead of HCL. You can combine it with tools like Dhall or my personal preference Jsonnet instead of imperative languages for an interesting experience for reusable pieces outside of module concepts.

Any particular libraries you use to generate TF-JSON from jsonnet? I wrote a generator a little while ago that can create jsonnet libraries from the TF schemas: https://github.com/Duologic/soysonnet Example lib here: https://github.com/Duologic/soysonnet-aws I only needed it for AWS so I didn't spend more time on it.

By hand :( But I like your project. Do you use Tanka?

Re: The future of Terraform CDK

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

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 that required explicit approval when a PR was raised, performed apply on merge to main, and ran drift checks periodically.

Re: The future of Terraform CDK

#99

This is a bummer. I don't particularly like Pulumi but use it anyways because for my use cases being able to write actual code is really impactful. Sucks to see fewer options in that space

What is it that you don't like about Pulumi? As I mentioned in another comment, my team of backend-engineers who took over an infra team went from Cloudformation -> CDK -> Terraform -> Pulumi and honestly find it the most approachable for other engineers familiar with normal programming languages (sorry HCL). We've been using it since 2021 and have a "what's on main is what's deployed" philosophy and adopted a RunAtlantis inspired workflow where previews are run as status checks on PRs and require explicit approvals, apply is run on merge to main and periodically, and drift checks run preview+refresh and alerts if what's checked in doesn't match what exists. We don't really use stacks, we just use a separate project for everything and write code to encapsulate modules (and luckily we can easily write unit tests and runtime assertions).

Re: The future of Terraform CDK

#100

Earlier quoted context omitted.

Makes IBM look really bad. Do they also force people to bow when the CEO of IBM enters the room, and address them as sir or your highness?

They used to have their employees sign songs praising the company... Granted, that was in the 1930s or something, but still.

I remember it being a part of the movie Pirates of Silicon Valley and thought it couldn’t be true. But apparently it was.

https://youtu.be/VyQEbLx6AEY?si=CwhqHQEdFGCsE33l

Post reply on HN