The future of Terraform CDK

https://github.com/hashicorp/terraform-cdk

by mfornasa • 7 months ago

136 134 7 months ago

vbernat• 7 months ago

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.

smithcoin• 7 months ago

We use OpenTofu it’s pretty seamless

benatkin• 7 months ago

Now more will be using a combination of OpenTofu and Terraform, and there will probably be some tacit endorsement of OpenTofu by Hashicorp folks in their communication with those who are using both. Good to see!

Hamuko2• 7 months ago

Does it do ephemeral values yet?

atonse• 7 months ago

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

Pet_Ant• 7 months ago

I assume it's a matter of branding and making IBM look more modern by associating with the Hashicorp brand.

cr125rider• 7 months ago

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

jjice• 7 months ago

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

huddo121• 7 months ago

Metastatized branding

stingraycharles• 7 months ago

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

firesteelrain2• 7 months ago

It’s how Red Hat identifies themselves too

viraptor• 7 months ago

It's common when corps buy large enough companies that they don't want to kill the original brand. That's why you get hotels like "(something) by Hilton".

richardfontana2• 7 months ago

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.

packetlost• 7 months ago

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

jen20• 7 months ago

Strange, I have a lot of good things to say about both it and Terraform.

Probably some specifics might be more useful there...

mfornasa4• 7 months ago

please expand on this, I am interested (for real!)

weakfish• 7 months ago

Why? I’ve had nothing but good experiences, but I don’t run it and the team that does is extremely competent

willio58• 7 months ago

My experience with Pulumi is you can write bad pulumi code and good pulumi code and just like everything else, it's easy to end up in a codebase where one poor soul was tasked with writing it all and they didn't do the best job with it.

here2learnstuff2• 7 months ago

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.

lighthazard• 7 months ago

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.

katdork• 7 months ago

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.

purpleidea• 7 months ago

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.

selkin• 7 months ago

It's odd to always say "Hashicorp, an IBM company". Looks like they want to assign blame.

Or it's legal trying to preempt a risk.

If it was the author just wanting to point at IBM, they'd mention it just once or twice, but using that awkward phrase throughout the text makes me think it was an edit mandated by a careful lawyer.

pretext-1• 7 months ago

I was recently working for a company which got acquired by IBM and we had to do it too. It’s an IBM thing. I bet most people at HashiCorp hate it, at least that was the case for us.

dandellion2• 7 months ago

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?

nsonha• 7 months ago

"Hashicorp, an IBM company"

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

roboben• 7 months ago

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

GardenLetter27• 7 months ago

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

scruff3y• 7 months ago

Just use Terraform?

cholantesh2• 7 months ago

Yeah I'm struggling to see the value here.

rendaw2• 7 months ago

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.

sshine• 7 months ago

Terranix? ;-)

madjam002• 7 months ago

Not gonna lie Terranix has been working great for us, all our configuration is in Nix files anyway so it's so easy to just pass stuff in rather than using Tf variables etc

lillecarl2• 7 months ago

Yes, the NixOS module system is so much more composable than the TF one

mfornasa4• 7 months ago

Probably Pulumi

resonious• 7 months ago

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 quite that often))

srmatto• 7 months ago

If you want maximal complexity use Crossplane. :P

tapoxi• 7 months ago

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.

ryandvm• 7 months ago

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.

manquer• 7 months ago

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.

tetha• 7 months ago

Hm, we have a few very repetitive terraform projects to setup structured infrastructure clusters. For those, we just use ansible with a bunch of templating to generate a configurable, HCL-based terraform module and version that.

It's a bit of an "Caveman solve problem with rock" approach, but for very regular projects it's great. A new cluster is some group vars, larger changes to the structures can be easily reviewed - and if you really really have to, you can also just modify the generated code by hand to fix something your generation code can't deal with right now.

rendaw2• 7 months ago

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.

theknarf2• 7 months ago

Normal Terraform, Pulumi or OpenTofu

rweichler• 7 months ago

As a complete noob to the space, as an individual, who doesn't care about being "hireable" or whatever, which one has the highest ROI? OpenTofu?

exidy• 7 months ago

but locks you in

Not picking on you personally but having had this conversation many times over many years with many clients I find it confounding. Oftentimes TF itself was heavily promoted as a way of "avoiding lock in".

Well guess what? Now you're locked-in to IBM, whose motivations may not be perfectly aligned to you goals of simply and efficiently using your cloud provider of choice to deliver your business outcomes.

What we refer to as lock-in is simply an expression of risk, with one axis being the cost of getting off $solution and the other being the likelihood of needing to do so. Having stepped through this exercise a few times, the cost of rewriting your e.g. AWS API Gateway + Lambda + SQS + RDS + CloudWatch etc architecture invariably vastly dwarfed the cost of changing the IaC language it is expressed in.

Anytime you feel the urge to overbuild on a cloud provider's services, stop, and do a really rigorous cost/benefit analysis. If you truly have unique drivers the data should tell the story.

zer0-c00l• 7 months ago

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

leetrout2• 7 months ago

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.

Duologic2• 7 months ago

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.

joeduffy• 7 months ago

[Pulumi founder here] Sorry to hear you don't particularly like Pulumi---any/all feedback welcome. If nothing else, we do listen and we do try to get better. -Joe

here2learnstuff2• 7 months ago

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

yearolinuxdsktp• 7 months ago

That’s a real shame. It seems like Pulumi is the only alternative for internal DSLs for IaaC? I always found HCL to be quite terrible, slowly becoming less painful, but not really refactoring-friendly.

Terraform CDK had promise as a blessed infrastructure-as-actual-code solution from the official maintainer of Terraform, so easier to sell internally rather than something from a new vendor like Pulumi. I feel sorry for those teams who have migrated to TF CDK.

Internal vs external DSLs explained in the middle of this page: https://martinfowler.com/bliki/DslQandA.html

chuckadams• 7 months ago

Kubernetes has a few things, including cdk8s. Yoke looks promising too.

mfornasa4• 7 months ago

Rug pulls on infrastructure components seem even worse than other rug pulls as they can hit your entire infra codebase at once

lillecarl2• 7 months ago

This is why infrastructure people are conservative by nature, it's so damn much gruntwork to migrate without downtime

mfornasa4• 7 months ago

And it happens while we are all very enthusiastically dedicated to migrating off Kubernetes ingress-nginx. Just as planned.

deadfece2• 7 months ago

At least they gave us some notice, that’s much appreciated.

breakingcups• 7 months ago

Define "some"

deadfece2• 7 months ago

Oh I don't know, 2? or 3?

dev_l1x_be2• 7 months ago

It would be great to have an alternative to Terraform that uses a bit more advanced provider (at last for AWS). Does OpenTofu use that same provider?

lijok7• 7 months ago

It does. What are you looking for in a more advanced AWS provider?

dev_l1x_be2• 7 months ago

Have you ever debugged what goes on with lets say the aws provider during a tf apply?

jpitz• 7 months ago

The providers for tofu are by design the same as for terraform.

Also, for large providers like AWS, GCP, Azure, etc - these are often largely authored by the hyperscaler themselves, for better or worse.

NeckBeardPrince• 7 months ago

Hashicorp, an IBM company

tonnydourado• 7 months ago

Hashicorp,an IBM company

chickensong• 7 months ago

Hashicorp, an IBM company

lloydatkinson• 7 months ago

What was the point of it? Terraform supports AWS anyway.

crimsonnoodle583• 7 months ago

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

lijok7• 7 months ago

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

crimsonnoodle583• 7 months ago

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.

pizza234• 7 months ago

That's very subjective. Concepts like iterations are inevitable, and they don't look great in a declarative language like HCL.

I also find refactorings considerably harder in a declarative language, since configurations have a rigid structure.

lijok7• 7 months ago

Good move. They clearly didn't have the resources they needed. The design of the CDKs was atrocious.

kbar13• 7 months ago

we're using cdk since 100% of our stuff is in aws but will soon need to hook up some external resources like cloudflare. looked at tfcdk a while back but didn't think it was a good idea (glad). still trying to figure out a good way forward and hoping it's not to rip the bandaid and migrate everything to terraform / pulumi

vanschelven• 7 months ago

"Will be sunset on Dec 10"... commit date: Dec 10.

That seems like rather short notice.

HashiCorps• 7 months ago

As I said here [0] there's more of this coming.

[0] https://news.ycombinator.com/item?id=46192130#46198058

callumgare• 7 months ago

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

moltar2• 7 months ago

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.

ptdorf• 7 months ago

Terraform CDK is basically TypeScript transpired to HCL

transpiled to JSON

moltar2• 7 months ago

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

rubenvanwyk• 7 months ago

OpenTofu is already the de facto fork.

thayne2• 7 months ago

OpenTofu is a fork of terraform, not CDKTF.

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

DangitBobby• 7 months ago

Well that sucks for me.

borisbanjo• 7 months ago

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.

nijave• 7 months ago

I kind of like it but I always found it kind of clunky how it's ultimately just generating JSON/HCL anyway. For instance, you can't data source then use code to transform and send it to a resource since it has to transpile first.

That also means you end up with things like the language's native JSON not doing what you expect and having to use a special Terraform function call.

nevon• 7 months ago

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.

Havoc• 7 months ago

As far as corporate mercy killings goes archived under mozilla license is better than a pivot to "you now pay per core" or whatever

kennu2• 7 months ago

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.

theknarf2• 7 months ago

Pulumi

kennu2• 7 months ago

Thanks, will definitely look into it. I first used Pulumi when it was just a cloud platform but seems it is a more general devops tool now.

an-engineer• 7 months ago

There are active discussions in the https://cdk.dev/ Slack channel #terraform-cdk about building community-driven forks of the existing Hashicorp/IBM CDKTF repositories. A number of developers who work at organizations that are heavily reliant on CDKTF have offered to pitch in.

There is currently a live proof of concept fork of the main cdktf repository that one developer made: https://github.com/TerraConstructs/terraform-cdk

And one Open Tofu developer said he and some other Open Tofu developers would be happy to collaborate with that community-driven effort to keep CDKTF alive: "The OpenTofu maintainers are happy to collaborate with that project once it's up and running, but we will not be directly involved." https://github.com/opentofu/opentofu/issues/3585

The future of Terraform CDK

Related Stories