Is AWS CDK Ready?

Short answer: no

Not quite as short answer: you can make it work especially for simple use cases

Long answer: well... Buckle up...

I've recently had the opportunity to use AWS CDK quite a bit at work to help support parts of our data pipeline. This has afforded me the opportunity to use many parts of AWS CDK. While I haven't used all of it and I cannot claim to be an expert with it, I think my experience with it could shed some light on the tool and help you know more about it before diving in yourself.

AWS CDK

AWS Cloud Development Kit, or CDK, is a toolkit developers can use to define their AWS stack using actual code. Instead of being a YAML file developer, you can be a stack developer in one of the languages they support (as of writing that's JavaScript, TypeScript, Python, Java, and C#). For some, that may be reason enough to switch to CDK, but CDK isn't all rainbows and butterflies. Let's dive in and talk about the good and the bad as it currently stands.

The Good

Code!

That's right, actual code! While I'm personally relatively new to the AWS world, I've heard many people mention how they feel more like YAML file editors rather than software engineers. It's a sad truth with most of the current tooling out there. Since CDK has entered the arena, you now have the option of writing code (that generates a JSON template, but more on that later) instead of YAML files. This fact alone comes with a few benefits that make creating stacks even easier.

One of the major benefits of CDK being code is that you can take advantage of coding constructs like functions, loops, encapsulation, and anything else available in your language of choice to create your stack. Need a lot of IAM Policies? No problem. Create a function and maybe a loop and you're in business. Have a large stack? Want to organize it into different files? Go for it! Separate your concerns and organize your stack however you'd like!

Testing

Another benefit of CDK being code is that it's more testable than straight YAML files. CDK offers some support for testing some basic aspects of the resulting stack. Using these constructs, you can quickly check if the resulting template matches what you would expect. There is also some basic support for testing that the resulting constructs will behave as they should and prevent invalid states in your stack. This is quite helpful as you can run these unit tests before deploying the stack to make sure the stack is as you expect.

The Bad

The good I've identified in CDK may not look like a lot, but it's hard to overstate how beneficial the code aspect is to it. Even still, CDK is not without it's downsides.

TypeScript Rules

While you can use CDK in other languages, TypeScript is the only truly supported version of the tool right now. If you want to use another language, get ready to read a mix of the language you choose and TypeScript. I chose to use Python. While there is some pretty good documentation for Python, it doesn't always show you want you want to know and there are times where it flat out doesn't talk about what you need. It takes some digging and some translating between TypeScript and your chosen language to figure out exactly what it is you need to do.

This leads to two related drawbacks. The first is that the documentation in general leaves a bit to be desired. Add to that the fact that the documentation in other languages is even further behind, and you'll find yourself wanting more. Whether it's knowing exactly how to implement the services you need or figuring out exactly why your resource isn't valid even though it looks like everything is correct, there will be times when you want more from the documentation and it's either unobvious and you have to bounce between multiple documentation sources or it's simply not there and you have to guess or apply patterns from other areas to the part you're working on to figure out the right way of doing it.

ID's

When using YAML or JSON, you have complete control over the ID's for the different resources you're creating. In CDK, you don't have the same fortune. This is one of the ways where CDK seems similar to a WYSIWYG editor and the messy code they normally generate. Instead of nice clean ID's like you provide, CDK adds a key to each ID. This makes the resulting template a bit messier than you might desire, though it does get the job done.

Testing

Testing is another aspect that leaves a bit to be desired. CDK only really supports template testing. So, you can ask if something exists in the template and if it has the right settings, but there are no further tests that they seem to support especially in languages other than TypeScript. So, you're essentially testing if CDK is doing it's job and if you're creating the template you think you're creating. As you do this, you may think, "why don't I just create the template myself?" and that's a good question that you may want to spend some time thinking about. If you want to do any meaningful testing, you'll likely need to use the AWS SDK to test that the stack (once it's deployed) behaves as you expect.

Is AWS CDK Ready?

The answer to this question is a solid, "it depends." Here are some things to think about as you consider using AWS CDK:

• How complex is the stack I'm deploying?
• The more complex the stack, the more likely you'll run into parts of CDK that are still under development. You may need to rely more on the Cfn* functions which you will likely want to rewrite as CDK matures.
• How sensitives is the data my stack will be handling?
• The more sensitive the information, the more likely it is you'll need some of the resources that aren't fully supported by CDK yet. You'll still be able to use the Cfn* functions but that is usually met with poor documentation.
• Am I okay updating often?
• The development of CDK is highly active with frequent updates. You may find yourself needing to update to new versions often as things are fixed and features are added. For some this is a huge plus. For others this may create undesirable overhead.

Conclusion

AWS CDK is a huge improvement over straight YAML or JSON. Being able to write code that defines your stack is a huge improvement. It makes defining a stack much more enjoyable than before. Being able to leverage abstraction, functions, loops, and other coding structures makes defining a stack in CDK easier. This fact alone may be enough to use CDK over anything else. If you do decide to use CDK, you will need to be prepared to wade through the mediocre documentation and deal with the inadequate testing and other drawbacks to using CDK. But, if you decide to use CDK, you can enjoy writing actual code to help you define your stack.

So, is CDK ready? The answer is different for each project. For enterprise applications, I'd lean more towards the "not yet" side of the debate. For smaller projects and less intense stacks, CDK could be a great tool to use that easily meets your needs. Either way you do it, there will be issues to deal with.