The future of Terraform CDK

> 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

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.

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

We use OpenTofu it’s pretty seamless

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

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

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

It’s how Red Hat identifies themselves too

"Hashicorp, an IBM company"

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

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

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

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

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

Pulumi

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.

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

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.

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.

Just use Terraform?

Probably Pulumi

If you want maximal complexity use Crossplane. :P

Terranix? ;-)

Normal Terraform, Pulumi or OpenTofu

Hashicorp,an IBM company

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.

[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

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

OpenTofu is already the de facto fork.

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.

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.

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

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

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.

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.