AWS re:Invent 2018, best of show: CDK (Cloud Development Kit)

Aller Media Tech Blog author
Aller Media Tech blog
3 min readDec 20, 2018

As AWS re:Invent 2018 is over and jetlag has slowly been defeated, it’s time to reflect on the learnings. All total we flew 8 people to Las Vegas but to make it simple, here is my personal best of show.

There is too much infrastructure as code

As we are moving everything to DevOps model the common problem with Infrastructure-as-Code has reared it’s ugly head — CloudFormation templates that are pushing 500+ lines (dashboard JSON not included) aren’t really that easy to manage. Although, granted, it’s still far better than not having any.

Previously we have tried things like using sub-stacks, but that just made change sets pretty much impossible to read/track as it just listed the whole sub-stack as “changed”, regardless if it was everything or just one line. So that wasn’t really a viable solution.

Enter Cloud Development Kit (CDK)

The gist of Cloud Development Kit is simple — Make Infrastructure-as-Code great again by using actual code instead of Yet Another Markup Language. Sure, with plain CloudFormation, you can do simple logic structures but that’s pretty much the extent of it. Not to mention proper modularization.

CDK solves this by having the Infrastructure-as-Code as plain JavaScript (TypeScript, Java and .NET are supported as well), which is then transformed to CloudFormation templates upon execution. This means you can write your logic with real programming language and you can use the same exact module patterns as your code, down to having private npm modules for common pieces such as security groups or WAFs. Wow wow wow. For us, this would fix major pain point as we continue to scale our DevOps transformation through Nordics, as the modular and code-based approach would allow us to use npm to distribute the Infrastructure-as-Code as small JavaScript modules which all have clear update path.

However, there are still few problems that needs to be figured out — Fe. how does one (safely) migrate existing yaml stack to something based on CDK? I even asked this from CDK team and seems like there is not yet a clear answer to this as fe. dynamic naming is the preferred way of doing things (to avoid name collisions) and those can’t be easily translated to CDK code without having to name the resources (which would void the whole point). So basically you would need to re-create the whole stack, which would mean database migrations etc. Yuch.

Buuut, I’m sure there will (or already might be) be a solution to this, so this is something we definitely will be keeping our eye on to and down the line will be moving into. There is definitely a brighter future ahead for CloudFormation.

Note: CDK is currently in preview, so as the documentation puts it: “Do not use this version of the AWS CDK in production. Subsequent releases of the AWS CDK will likely include breaking changes.” Consider yourself informed.

Honorary mentions

Lambda support for ALB — Significant feature for application cost optimization. This will definitely find it’s way to our stacks come 2019.

Simple Beer Service —Alexa enabled beer tap. Do I need to say more?

SBS in AWS re:Invent 2018

— By Mikko Tikkanen, Technology Lead at Aller Media Finland

--

--