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 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.
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.
> 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.
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.
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.
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.
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
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.
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.
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
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).
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.
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
[+] [-] vbernat|3 months ago|reply
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.
[+] [-] jjice|3 months ago|reply
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
[+] [-] pretext-1|3 months ago|reply
[+] [-] packetlost|3 months ago|reply
[+] [-] smithcoin|3 months ago|reply
[+] [-] atonse|3 months ago|reply
[+] [-] selkin|3 months ago|reply
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.
[+] [-] nsonha|3 months ago|reply
Common sense would be IBM mandating that branding, as opposed to Hashicorp.
[+] [-] roboben|3 months ago|reply
[+] [-] firesteelrain|3 months ago|reply
[+] [-] crimsonnoodle58|3 months ago|reply
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|3 months ago|reply
[+] [-] vanschelven|3 months ago|reply
That seems like rather short notice.
[+] [-] HashiCorps|3 months ago|reply
[0] - https://news.ycombinator.com/item?id=46192130#46198058
[+] [-] yearolinuxdsktp|3 months ago|reply
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|3 months ago|reply
[+] [-] mfornasa|3 months ago|reply
[+] [-] lillecarl|3 months ago|reply
[+] [-] kennu|3 months ago|reply
[+] [-] theknarf|3 months ago|reply
[+] [-] GardenLetter27|3 months ago|reply
[+] [-] an-engineer|2 months ago|reply
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
[+] [-] deadfece|3 months ago|reply
[+] [-] breakingcups|3 months ago|reply
[+] [-] NeckBeardPrince|3 months ago|reply
[+] [-] tonnydourado|3 months ago|reply
[+] [-] Havoc|3 months ago|reply
[+] [-] borisbanjo|3 months ago|reply
CDKTF stacks are great and the construct pattern gives you modularization without all the baggage.
[+] [-] nevon|3 months ago|reply
[+] [-] nijave|3 months ago|reply
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.
[+] [-] zer0-c00l|3 months ago|reply
[+] [-] leetrout|3 months ago|reply
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.
[+] [-] joeduffy|3 months ago|reply
[+] [-] here2learnstuff|3 months ago|reply
[+] [-] moltar|3 months ago|reply
[+] [-] rubenvanwyk|3 months ago|reply
[+] [-] callumgare|3 months ago|reply
[+] [-] moltar|3 months ago|reply
[+] [-] dev_l1x_be|3 months ago|reply
[+] [-] jpitz|3 months ago|reply
Also, for large providers like AWS, GCP, Azure, etc - these are often largely authored by the hyperscaler themselves, for better or worse.
[+] [-] lijok|3 months ago|reply
[+] [-] kbar13|3 months ago|reply
[+] [-] DangitBobby|3 months ago|reply
[+] [-] lijok|3 months ago|reply
[+] [-] lloydatkinson|3 months ago|reply