AWS Cloud Development Kit — The Bad Parts
I’m a big fan of the CDK. It has already simplified the life of many cloud engineers and opened new perspectives on how to define AWS cloud infrastructure.
If you’re new to the AWS CDK or it’s the first time you read about it, it is an imperative approach to designing infrastructure as code (IaC).
Simply speaking, you can create your Lambdas, Buckets, CloudFronts, and gazillion other things in one of the available languages, e.g. TypeScript, Python, JavasScript, or .Net.
The best place to start tinkering with it is the https://cdkworkshop.com. If you’re Polish speaker, feel free to read my previous post about AWS CDK: https://medium.com/cloudaemons/subiektywne-spojrzenie-na-aws-cloud-development-kit-1e5f21f464b8
Well, probably you wonder what are the bad parts, huh?
Disclaimer: The below points represents my own perspective and are not presented to discourage you from using the CDK, but to share my concerns.
First
Just go here https://github.com/aws/aws-cdk/releases. You see it right? The core team does not follow SemVer, they tend to introduce breaking changes and update only a minor part of the version. Why it’s bad? As it is published on NPM, it is normal to expect correct semantic versioning. If you are creating a module that has CDK as a dependency, you are screwed. Each time there is a new release from the CDK team, you will end up with your own release. I’m not saying it is impossible, it is just a cumbersome process.
Second
There’s no built-in mechanism to deal with cross-account setups. Of course, there is no OOTB solution for that in plain Cloud Formation either, but with access to higher-level languages, it is definitely feasible. For now, you have to write your own piece of logic to orchestrate cross-account deployments (which is btw. cool to see how powerful and flexible this tool is when you have to create such logic ;)).
Third
Poor integration with SAM local. Really, logical names in the generated cloud formation templates are kind of random, so it is hard to get the proper name of lambda which we would like to ask SAM local to run for us.
Next, If you will try to create API Gateway, possibly you will define your API in a form of OpenAPI, which makes your code clean and readable... In that case, you will not be able to run the API locally as that is not supported by SAM.
Also forget about MockIntegration, as it is another not supported feature.
Well, this one is not exactly issue of the CDK, but you will have hard times finding the root cause of the issue :)
Fourth
There’s no public API that you can use to trigger to deploy your app. You must use the CLI. Why it’s a bad part? Think of creating orchestration around it to programmatically deploy your stacks, in Node.js you have to rely on process API.
Fifth
This one is more about the lack of proper standards and guidelines. If you’re going to create sophisticated constructs within other constructs within other constructs, you might be surprised by the implicit CloudFormation limits.
E.g. It is very easy to reach limits of resources per stack, it is also easy to reach a limit of a resource name, as each resource is prefixed with its parent construct name.
All the points above are quite subjective, and I will not argue if you say, those are not really bad parts, but missing features or known limitations. Actually, some of those limitations, shows how flexible AWS CDK is. Those issues can be addressed (aside from lack of SemVer, CDK team… really?)!
Knowing those issues before, would I still use CDK in my projects?
Definitely, YES!
What is your experience with CDK? I bet there are other bad parts that you have encountered, If so please, leave the comment below!
