I know how CloudFormation behaves, and none of the wrappers have convinced me that translating through CloudFormation makes sense. ("through" because if you're using CDK, you're translating from imperative to declarative to imperative... why?!)
I tried it on a recent greenfield project, and now I’m kicking myself for not giving it a try in earnest earlier.
So all the core CDK code is written first in JS/TS and then stubs for the other languages are added
Unfortunately this is often done without consideration for how the other supported langs actually work, and artefacts of e.g. JS lack of support for kwargs leak through
This is why e.g. the typing in CDK Python is completely broken - pretty much uniformly the concrete types like "Resource" don't implement their corresponding interface like "IResource" (to a type checker)
(There are many other typing niggles like this but that's the most egregious and pervasive one)
At the end of the day, having to explicitly cast concrete types as their interface to satisfy type checker is a minor annoyance, albeit a stupid one that could have been avoided with more care in the core library.
I could live with that, but I encountered so many bugs and issues trying to use CDK on current project that it's now much clearer to me why every company I worked at previously was using Terraform.
Pretty sure some of those issues are ultimately CloudFormation ones. The cumbersome CF > CDK JS > CDK Python stack is great for obfuscating errors and making debugging hard or impossible though.
Pulumi do something similar, albeit with Go as the core language and Terraform underneath. From what I've seen with a little use they have a much more successful result though, Pulumi Python was not a complete mess, and deploys faster and more reliable with better error feedback. I guess they just took more care to get it right.
I would have been perfectly happy to use CF if they added the notion of higher level constructs at CF level, but for whatever reason they haven't. So I use CDK because it provides the ability to reuse service compositions from third party libraries as well as across different internal projects.
CDK is imperative but imperatively building the configuration is not at all the same as imperatively managing the infrastructure. Even if with CDK the configuration is imperatively built you retain all the benefits of having declarative infra - version control, selective auto update, rollback to previous state etc.
Yes, while CF is clunky and slow, and I am sure everyone who uses it has at times gotten stuck with rollback failures, but CDK does provide a somewhat better dx on top of it.