Hello all!
I hope you have had a great week so far!
There is a new article published on the Tidy Cloud AWS website about migration from CloudFormation to AWS CDK, which I will talk a little about here. I also put some thoughts around AWS CDK usage after reading a blog post from Corey Quinn.
Enjoy!
CloudFormation to AWS CDK
I have just published the first articles in a series of articles which cover migration from AWS CloudFormation to AWS Cloud Development Kit (AWS CDK)
It may be interesting and exciting to use the higher level components that AWS CDK provides. However, unless you have just started your cloud journey, chances are that you already have a bunch of infrastructure in place.
Most times, these cannot simply be replaced with an entirely new infrastructure. You still need to maintain this infrastructure!
The aim of these articles is to take a step-by-step approach to using AWS CDK, assuming that you already use CloudFormation.
You can read the first part here: How to migrate from CloudFormation to AWS CDK - part 1
The code examples are currently in Typescript and Python. Future updates may include other languages as well. Have a look and tell me what you think!
Corey and AWS CDK
Recently, I read a blog post from Corey Quinn of Duckbill Group/Last Week in AWS/Screaming in the Cloud fame, where he talked a bit about a few first steps in using AWS CDK.
There were not that much details about the struggles Corey had with AWS CDK in Python, but I think I can guess some of the pain points where it was not clear. I might be completely off though…
Requirement for node.js + npm to get the command-line tool. If you live in Node.js/Typescript/JavaScript land all day, this is likely just fine. For many others, this is a hurdle. It was for me as well when I started out with it. I really wish the command-line tool was just a single binary to run.
You will probably have to deal with the runtime environment set-up of a different language, if Typescript is not your primary cup of tea.
Corey wrote also that AWS CDK was very particular about the directory structure. I do not agree with that, besides the location of the cdk.json file, you can have any structure you want, almost. It is, however, easy to think there is a certain required structure when you use the cdk init command, for example.
Sometimes if you use any other languages than Typescript, you may still see errors that expose Typescript-specific code of the underlying libraries. I think this is an additional mental burden on the AWS CDK user, if you do not wish to work with Typescript.
The concern Corey raised about having a bunch of one-off project in several places is a general problem. I think that is better in AWS CDK than some other infrastructure-as-code tooling, since it by design encourages to include information about the target environments for each target solution.
I think he is right in that AWS CDK can feel that it expects you to be a pretty good developer. You should not have to be that. I think a key value AWS CDK can provide is to make infrastructure easier for occasional programmers as well. I think that it can be simplified further and there is perhaps a bit too much boilerplate in some examples, which can discourage users.
You can find the contents of this bulletin and older ones, and more at Tidy Cloud AWS. You will also find other useful articles around AWS automation and infrastructure-as-software.
Until next time,
/Erik