|
I have a few years of experience with terraform (pulumi is built on terraform), and moved to a place using CDK about a year ago. From what I've seen, CDK is worse than terraform, and I would expect it to be strictly worse than pulumi. I haven't seen a problem that CDK solves better than terraform, and it fails pretty hard at the core of its job. I genuinely want to find something to like (because I'm stuck with it), but I'm really struggling. CDK is bad at the core of its job; managing the state of resources in AWS. The two big ways this manifests with CDK are that you can't completely import existing resources into CDK, and CDK is bad at detecting changes made out-of-band. CDK has a way to "import" resources, but unlike terraform, it's not something you do once then forget about. When you "import" a resource in CDK you are doing that as an alternative way to define the resource, so the code will always need to 'remember' which resources to create and which ones to import. Imported resources can be modified, but there are restrictions on what modifications can be made so they aren't really interchangeable with native cdk built resources. Our CDK stacks are littered with "if STAGE" blocks that will never go away until we recreate those resources with CDK, and there is no clean way to do that. In general I would say making changes to CDK/terraform created resources out-of-band (ie, in the aws console) is a bad idea, but it happens sometimes. Maybe you aren't exactly sure how a parameter maps to a feature in the aws console, or there is an active outage and you need to make the change now, or the guy in IT that owns the root account decided to "fix" something for you. Whatever the cause, it's important to be able to run your IaC tool and 1) see the changes, 2) remediate them. CDK can detect some changes but not everything, and that's left me with very little confidence that things are actually setup correctly. No one's complaining, so I guess it's fine? There are a few other quality-of-life things I don't like about CDK, but I don't think they are as important. It's slow. I don't like the diff output format. We always see diffs and different devs see different diffs, and we have no way to debug/resolve it. I'm boggled that a bunch of resource types (it's not clear which ones) default to not being deleted when you delete them from cdk. Overall, I get the feeling that "it works" and "no one's complaining" is the quality bar CDK is trying to meet, and that just isn't good enough for me. The only reason I don't say terraform is strictly better than CDK is that terraform doesn't allow you to define your infrastructure with a 'real' programming language. I don't think that's an important feature, and it might tempt you into doing horrible things (like littering your codebase with "if STAGE" blocks). In general I think keeping infrastructure stuff simple and separate from application stuff is important, and HCL really encourages that. I've been bothered by the lack of programable logic in terraform, but honestly, I think that constraint has ultimately resulted in cleaner logic. If it's important to you, then pulumi is always there. Ugh, I took way to long writing this. To answer your question, IMHO, don't use CDK. |