[HN Gopher] The future of Terraform CDK
___________________________________________________________________
The future of Terraform CDK
Author : mfornasa
Score : 59 points
Date : 2025-12-10 19:14 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| vbernat wrote:
| 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 wrote:
| We use OpenTofu it's pretty seamless
| benatkin wrote:
| 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!
| Hamuko wrote:
| Does it do ephemeral values yet?
| cube2222 wrote:
| Yep, as of yesterday's 1.11 release it's supported!
|
| That also includes a new "enabled" meta argument, so you
| don't have to hack around conditional resources with count
| = 0.
|
| [0]: https://opentofu.org/blog/opentofu-1-11-0/
|
| Disclaimer: affiliated with the project
| lijok wrote:
| How do you migrate from count/for_each to `enabled` ?
| cube2222 wrote:
| You can just switch from `count = 1` to `enabled = true`
| (or vice-versa, works back-and-forth) for a resource and
| tofu will automatically move it next time you apply.
|
| It's pretty seamless.
| lijok wrote:
| Amazing. Good work !
| joombaga wrote:
| That's cool! We'll still need to change all of the
| references to `resource[0]`, right? Or does tofu obviate
| that need as well?
| cube2222 wrote:
| I'm not sure I understand. You refer to the conditional
| resource fields normally - without list indices. You just
| have to make sure the object isn't null.
|
| There's some samples in the docs[0] on safe access
| patterns!
|
| [0]: https://opentofu.org/docs/language/meta-
| arguments/enabled/
| Hamuko wrote:
| Damn, might finally be able to use it. The lack of
| ephemeral values was a major blocker.
| atonse wrote:
| I was thinking the same thing about the "an IBM company". My
| guess is that it's a lazy find/replace.
| Pet_Ant wrote:
| I assume it's a matter of branding and making IBM look more
| modern by associating with the Hashicorp brand.
| cr125rider wrote:
| It's one thing to say it once but 3 times in the same
| paragraph seems weird for sure!
| jjice wrote:
| > 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
| firesteelrain wrote:
| It's how Red Hat identifies themselves too
| packetlost wrote:
| I have absolutely nothing good to say about Pulumi. Stay far,
| _far_ away.
| jen20 wrote:
| Strange, I have a lot of good things to say about both it and
| Terraform.
|
| Probably some specifics might be more useful there...
| mfornasa wrote:
| please expand on this, I am interested (for real!)
| weakfish wrote:
| Why? I've had nothing but good experiences, but I don't run
| it and the team that does is extremely competent
| selkin wrote:
| > 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.
| GardenLetter27 wrote:
| Damn, what are the best alternatives here? For pure AWS I guess
| CDK directly is okay, but locks you in.
| scruff3y wrote:
| Just use Terraform?
| cholantesh wrote:
| Yeah I'm struggling to see the value here.
| stackskipton wrote:
| The value for TFCDK was Developers don't have to learn
| another language, they can just continue to use existing
| language they already know.
|
| Downsides are doing infrastructure in a programming
| language was always problematic unless developer was
| skilled at Ops which most who used TFCDK were not.
| sshine wrote:
| Terranix? ;-)
| madjam002 wrote:
| 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
| lillecarl wrote:
| Yes, the NixOS module system is so much more composable than
| the TF one
| mfornasa wrote:
| Probably Pulumi
| srmatto wrote:
| If you want maximal complexity use Crossplane. :P
| tapoxi wrote:
| 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 wrote:
| 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.
| emoII wrote:
| 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
| tetha wrote:
| 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.
| zer0-c00l wrote:
| 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
| leetrout wrote:
| 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.
| yearolinuxdsktp wrote:
| 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 wrote:
| Kubernetes has a few things, including cdk8s. Yoke looks
| promising too.
| mfornasa wrote:
| Rug pulls on infrastructure components seem even worse than other
| rug pulls as they can hit your entire infra codebase at once
| lillecarl wrote:
| This is why infrastructure people are conservative by nature,
| it's so damn much gruntwork to migrate without downtime
| mfornasa wrote:
| And it happens while we are all very enthusiastically
| dedicated to migrating off Kubernetes ingress-nginx. Just as
| planned.
| deadfece wrote:
| At least they gave us some notice, that's much appreciated.
| dev_l1x_be wrote:
| 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?
| lijok wrote:
| It does. What are you looking for in a more advanced AWS
| provider?
| jpitz wrote:
| 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 wrote:
| Hashicorp, an IBM company
| tonnydourado wrote:
| Hashicorp,an IBM company
| lloydatkinson wrote:
| What was the point of it? Terraform supports AWS anyway.
| crimsonnoodle58 wrote:
| 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..
| lijok wrote:
| The lack of expressiveness of HCL is the point and what makes
| it so good
| crimsonnoodle58 wrote:
| 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.
| lijok wrote:
| 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
| crimsonnoodle58 wrote:
| Yet said language continues to add imperative-inspired
| constructs to make up for its limitations..
|
| The end result is still declarative, your just using an
| imperative language to keep your IaC DRY.
| lijok wrote:
| Good move. They clearly didn't have the resources they needed.
| The design of the CDKs was atrocious.
| kbar13 wrote:
| 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 wrote:
| "Will be sunset on Dec 10"... commit date: Dec 10.
|
| That seems like rather short notice.
| callumgare wrote:
| 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
| moltar wrote:
| 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.
| moltar wrote:
| This is so sad. It's a great project. Needs to be forked and
| maintained. If anyone forks please email me I'll contribute.
___________________________________________________________________
(page generated 2025-12-10 23:00 UTC)