Teaching an Old Dog New Tricks: My First Foray into the AWS CDK
Over the past few months, I’ve had the opportunity to lead teams using the AWS CDK to provision infrastructure. I’ve been using AWS since early 2016 and I have done projects that leveraged native CloudFormation and Terraform; however, this has been my first foray into the CDK universe and I wanted to share some tips regarding what I’ve learned. Specifically, I have two things that I have liked about the CDK and two things that aren’t necessarily bad, but did take me by surprise.
Two Things I Have Liked
As opposed to traditional templating languages, the CDK is a programmatic way to define cloud infrastructure. Given that, one of the key advantages to CDK based work is that you can do more robust unit testing of your infrastructure. Adding tests into a build pipeline are a great way to increase confidence and create faster feedback loops. For example, if I’m provisioning a VPC, I can explicitly test that the appropriate number of routes are added to my route table. Certainly runtime errors can still occur, but this is a welcome new feature.
Perhaps the feature I like even more is the ability to compare changes in your CDK code with what is currently deployed. This is done using the diff command. I’ve had many experiences over the years where I’ve deployed templates and unanticipated actions have occurred, such as the replacement of an existing resource. The diff command is an excellent way to sanity check oneself before deploying changes.
Two Things that Took a Moment to Realize
The CDK still uses native CloudFormation. Effectively the synth command will take the code that has been written and “synthesize” CloudFormation templates which the CDK will actually use to do the deployment. The templates, along with associated assets, are stored in the cdk.out directory and generated all at once. This slightly modifies the way that environment specific parameters are specified. Effectively, if I have a dev, test, and prod environment, each of those will generate their own specific templates. This effectively inverts parameterization from runtime to compile time. This isn’t inherently good or bad in my opinion… just different to what I’m used to.
Since the CDK converts code into templates… bad code can lead to bad templates. I’ve seen a few instances where the code was set up in a way that generated no resources in the template. As a result, if I deployed that template as a new version, the CDK would attempt to delete any resources that previously existed. As you can imagine, that would not be ideal to say the least. The best way to prevent this type of issue is to do sufficient unit testing and also use diff to validate changes to mission critical infrastructure before actually doing a deployment.
Overall, I’ve greatly enjoyed my time with the CDK so far. It provides a lot of excellent new functionality that was previously missing from templated infrastructure languages. That being said, it does have its quirks to be aware of that may be a bit jarring to those who have spent a lot of time using native CloudFormation and/or Terraform.
