Why I’m migrating everything to AWS CDK
Now the infrastructure really is code, and it’s a game changer
I believe AWS CDK is a game-changer.
I’ve been using CloudFormation on AWS since it was first introduced, but it never felt like code. Terraform and Serverless are just more specialised (or cross-platform) versions of the same.
With CDK the infrastructure really is code. With loops, and reusable constructs, and unit tests, and all the other goodness that comes with real programming languages. This is a good thing. Some of the modules and microservices I’ve migrated to CDK require CloudFormation templates of more than 1000 lines of code (although a lot of it will be repetitive copy-pasted blocks). The same templates in CDK are a third of the size and can be written in half of the time (after you get used to the quirks and the lack of documented examples — more on that later).
There’s plenty of rough edges right now though, and getting started has proven to be a challenge.
My specialty is infrastructure, not software. Of course since AWS starting eating the world, these things are now one and the same. Writing code has always been a hobby, but over the last few years it’s increasingly become part of the day job.
For anyone wanting to be a cloud infrastructure expert now, coding is an essential skill. Until recently, it was reasonably simple scripting in bash or powershell, and declarative templates like CloudFormation. The starting point for CDK is Javascript or Python.
Similarly, developers historically have learnt enough about infrastructure to be able to test locally, and fire up a cloud based server or container to deploy into when ready. In the last few years serverless technologies like Lambda, Step Functions, and SQS have required developers learn a little more about the environment the code is running in, and Serverless has allowed them to easily deploy both code and the underlying services. But that’s very different to setting up an ECS cluster, load balancers, CloudFront distributions and so on.
While most developers these days know how to use AWS infrastructure, very few understand all the underlying concepts. CDK makes it easy for a developer to configure and deploy the whole network from end to end, but that may not be a good thing. Building robust and secure infrastructure is a specialty, and getting the best out of AWS at a reasonable cost requires in-depth knowledge of the services.
It’s a bit different at the big end of town, but the companies I work with there’s a clear separation of infra and dev skills. CDK is the catalyst for a merger, and it’s going to be interesting to see how it plays out.
For me, it’s an opportunity to learn some new tricks and share the experience. I’m coming at CDK primarily from an infrastructure perspective, and I’m finding that the documentation and lack of examples are a major challenge. I’m also finding the prescriptive nature of the constructs, and some of the assumptions they make are a double-edged sword — they certainly make it easier to create an environment, but it’s not always the environment you want or need. Adding CDK deployed resources into existing environments built using CloudFormation or Terraform can take some shoehorning.
But I think it’s worth it. AWS are obviously putting a lot of work into CDK, and it’s usage will absolutely grow over time. If you are starting fresh with an AWS environment, or a new project in an existing environment, I think CDK must be considered as a form of future-proofing.
Terraform has it’s place, particularly for organisations that are deploying cross-cloud into AWS, Azure or GCP, but for pure AWS environments I can’t see any reason not to switch to CDK.
Right now there are some limitations in CDK that need to be worked around, but I haven’t found anything yet that can’t be done.
The primary issue is the documentation. While the constructs themselves are well documented, finding help can be very difficult and frustrating, particularly in the form of examples. I’m hoping I can help out with that here.
While you can use many languages to write CDK code, there’s just three in my opinion that are important.
Typescript is the language used to create CDK itself, and the documentation and examples are most available and clearest in Typescript itself. I’m not going to use it for two reasons — I don’t see the need for the additional complexity over Javascript, and developer skills for Javascript and Python are far more readily available.
Python skills are reasonably easy to find, and it’s a simple language to use, but there are good reasons I’m not using that either. The documentation conversion from Typescript to Python isn’t straightforward, and there seems to be far fewer examples about for it.
For me, Javascript is the obvious choice. There are fewer examples around than there are for Typescript but the conversion is simple. It’s also the language I prefer (and the projects I’m working on use) for Lambda functions — where it’s primary advantage is we can use the same language for front and back end work.
I think the only reason you would consider Java or Go is if you were already building everything else in those languages, and your development team are also building the infrastructure.
I’ll share examples here when I can, as well as any lessons learnt in converting existing projects and firing up some new ones using CDK.
About the Author
Mark is a 20+yr IT industry veteran, with technical expertise and entrepreneurial experience in a range of fields. For many years now his passion has been building on AWS, and he holds certifications including Solution Architect Professional and the Advanced Networking Specialty. He wants you to know that he is an infrastructure and architecture expert who writes code, not a professional software developer — just in case you spot something odd.
Mark has spent the last few years in the banking industry, were he is currently building and leading a team focused on using AWS serverless technologies to reduce costs and speed up the time to market for new services and products.
You can also find Mark on:
GitHub — https://github.com/markilott
LinkedIn — https://www.linkedin.com/in/markilott/
Twitter — https://twitter.com/mark_ilott
