Early this year amazon web services released the Cloud Development Kit (CDK) which is best summed up by a quote from the GitHub project.

The AWS Cloud Development Kit (AWS CDK) is an open-source software development framework to define cloud infrastructure in code and provision it through AWS CloudFormation.

Before I go recommending this new project to anyone I most certainly need to road test it myself. This post provides a bit of background on where I work, and why I am looking into CDK, and what I love to see in the future.

Background

I have been building applications in Amazon Web Services (AWS) for a number of years using as many of the services as possible to keep things lean and online, that said it doesn’t come without some overhead and many lessons learned. While working in AWS I have always chosen to stick to native tools, such as Cloudformation, augmented by a range of deployment tools, this has means I get all the power with the inherent complexity, which grows every AWS reinvent conference.

Hiring into an organization which works very closely with AWS comes with some challenges. New hires will typically find themselves learning a lot of new services, while also grappling with Cloudformation. This can really impact a new team members productivity, and more importantly their confidence, especially when the first few PR reviews call out security issues, and subtle pitfalls around resource naming the examples they build find on the internet.

For this reason I have been looking at ways to reduce risk of issues in production without falling into the trap of isolating infrastructure development to a small number of “experts”, this is why CDK popped up on my radar. It promises to allow developers to manage to assemble stacks using reusable patterns either developed by AWS, or internally using code not YAML, which in my view is a big plus.

In short I care more about people than I care about technology, I want it to empower those who use it, not hold them back.

Road Testing

As I was starting to road test CDK I was fortunate enough to catch up with some of my peers from AWS Partner Community and get some good tips and anecdotes on what to dig into. Based on this I have put together some points, these are grouped into the good, the bad and the ugly.

The Good

  • CDK enables developers to describe their infrastructure in code using an object model, then lets them synthesize it into Cloudformation templates.
    • VPC resources can be “connected” to each other, this automatically creates the required security groups, and entries in them.
    • Accessing a secret value will also update IAM policies, updating roles with the required policy changes.
  • CDK automatically creates policies that narrow access down to the least privileges required to operate based on your model. This is a boon as because it is one of the most complex and time consuming aspects of crafting a Cloudformation template.
  • The Cloudformation produced by CDK has sane defaults such as:
    • Enables deletion protection for Relational Database Service (RDS) instances to avoid accidental deletion during stack updates.
    • Enables orphaning of S3 buckets which leaves them behind when a stack update occurs, therefore avoiding deletion of all your data when messing with configuration of a resource in your stack.
  • Includes patterns which incorporate a range of best practices, helpers and security enhancements.
    • An example of this is the LoadBalancedFargateService which can deploy a build and deploy a local service using a Dockerfile without ever having to delve into the finer points of Elastic Container Registry (ECR), Elastic Container Service (ECS) or Application Load balancers (ALB).
  • Personally I feel a lot more productive with CDK, I am writing less code and producing more secure, consistent infrastructure.

The Bad

  • Although amazing, the patterns feel like black boxes, there is no way to click through into the source code of an underlying pattern and dig into how it works.
    • Personally I think these should illustrate how amazing this model is, and act as a spring board into developing your own modules, currently it feels like a black box.
    • Yes I can clone and dig into repositories but the whole point of this is to be here for a good time, not a long time.
  • It is really difficult to lock down the version of CDK in your NodeJS projects once a new release has come out. If there are changes I want to skip then I have to get a lock file from an older project, which breaks as soon as I add other CDK modules.
    • This is a less than ideal user experience for teams who aren’t moving as fast as the CDK development team.
    • Note work is happening to sort out semver usage in cdk packages issue #3711 which is great!
  • The whole multi language, cross compiled thing seems very limited at the moment, especially around the lack of support for sharing modules developed in languages other than Typescript.
    • For more information on how CDK deliver polyglot libraries checkout the aws/jsii project on GitHub
    • Some background on Python experience requiring NodeJS tooling.

The Ugly

  • In the current CDK I am encouraged, if not required to synthesize my templates in every AWS account I use, this is a big red flag for me.
    • If team member updates a service deployed a couple of month after it’s initial release there is NO guarantee the same code Cloudformation will be generated. To cover this operators will need to “stash” or archive templates for every account, before every deploy.
    • The NPM locking issues around pinning upgrades really restricts your power to ensure managed changes to Cloudformation.

This lack of reusable, easily reproducible artifacts is a bit of a show stopper for me, given the number of times I have been let down by tools which generate Cloudformation, I am loath to leap back into it for a production environment.

Summary

In short I will not be putting CDK between me and a production environment until some of the reproducible challenges are addressed. Like many of my peers, I have always advocated for solid, reproducible infrastructure tooling that is as simple as possible to recover and rollback.

That said I will most definitely be using CDK to quickly generate Cloudformation, especially generating IAM policies with least privileged, and harvesting some of the great ideas, and tricks from the patterns.

I would recommend using Typescript to develop CDK scripts, this will ensure you get the most reuse and enable harvesting directly from the CDK patterns!

Contributors

Thanks to Ashish Rajan @hashishrajan and Rowan Udell @elrowan for reviewing this post, Ian Mckay @iann0036 for starting a impromptu CDK discussion in Seattle and Aaron Walker @aaronwalker for being a great sounding board and walking me through some of his experience with CDK.

Example Project

My current work with CDK is mainly focused on providing infrastructure to a container based application called exitus which is hosted on GitHub with the CDK infra code exitus.ts. Ian Mckay