Comment by falkensmaize
2 days ago
This was my first thought too. We already have terraform for repeatable, source controlled service provisioning and we have the relatively straightforward aws cli for ad hoc management. I don’t know that I really need another layer, and it feels quite risky.
cdk bro
Terraform CDK is just a layer on top of terraform to avoid writing HCL/JSON.
It's also deprecated by Hashicorp now.
CDK on AWS itself uses CFN, which is a dog's breakfast and has no visibility on what's happening under the covers.
Just write HCL (or JSON, JSONNET etc) in the first place.
Not sure what's a dog breakfast, but why care about what's happening under the cover? You can't know what's happening anyway in AWS.
I thought that was deprecated?
cdktf is, not AWS CDK. The former allows you to use Terraform without HCL, the latter is a generator for CloudFormation.
Am I the only person that despises CDK? Why would I use a cloud specific language instead of something like opentofu?
CDK's twin problems are that it compiles down to CloudFormation and that AWS did a terrible job at supporting languages other than TypeScript. The latter is theoretically fixable with a native FFI library that is called from each language, but the former is too leaky of an abstraction.
1 reply →
Considering all the downvotes I got I guess you're not the only one. I'm surprised because I really like cdk. It makes creating an AWS stack really easy, and for having dealt with terraform configurations that were trying to deal with multiple cloud platforms I'd rather have a per-platform eDSL