Damn, what are the best alternatives here? For pure AWS I guess CDK directly is okay, but locks you in.
If you want maximal complexity use Crossplane. :P
The future of Terraform CDK
11–20 of 140 posts
Re: The future of Terraform CDK
#12That’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
Re: The future of Terraform CDK
#13Damn, 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.
Re: The future of Terraform CDK
#14This 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.
Re: The future of Terraform CDK
#15Re: The future of Terraform CDK
#16Rug pulls on infrastructure components seem even worse than other rug pulls as they can hit your entire infra codebase at once
Re: The future of Terraform CDK
#17It'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.
We use OpenTofu it’s pretty seamless
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!
Re: The future of Terraform CDK
#18At least they gave us some notice, that’s much appreciated.
Re: The future of Terraform CDK
#19It 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?
Re: The future of Terraform CDK
#20It'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. [0] https://www.hashicorp.com/en/blog/products/terraform
[deleted]