Whilst attending AWS Initiate in Perth this week I was made aware of the AWS CDK. Never has ‘infrastructure-as-code’ been so literal.
In my earliest forays with infrastructure automation I made a mistake many have made: defining and deploying entire solutions using AWS SDKs. I would not have been the first to justify this as avoiding the CloudFormation learning curve but, of course, when you are 3000 lines of Python into a beautifully-coherent infrastructure that is actually a re-write of CloudFormation Stack management logic, this justification is proven wrong.
So what makes CDK different? Is it not still using your language of choice to define your infrastructure? Indeed, it is … but what it is not doing is using your language of choice to deploy your infrastructure. For this, the CDK ‘synthesises’ your infrastructure-as-code as CloudFormation templates and provides a simplified command line syntax for deploying these as multiple environments via the CloudFormation API.
The most immediate potential benefits of the CDK that come to mind are the enhanced possibilities for defining infrastructure patterns for re-use. Preparing function-enabled markup (i.e. CloudFormation templates or even Serverless scripts) for re-use still seems a chore but using the packaging and module management capabilities of our full-featured programming languages to bundle infrastructure assemblies (referred to in the CDK as Constructs) and expose their parameters offers the possibility of reducing re-use friction.
However, it is this same full complement of control structures in our programming languages that is the source of my most immediate concern about the CDK. It increases the risk of what ThoughtWorks have referred to as Leaking Encapsulation Boundaries. That is, in the transition to an everything-as-code world “… logic that should reside within a system boundary leaks out into orchestration tools, configuration files, and other plumbing.” I would argue the awkwardness of injecting logic into markup-based configuration (a la CloudFormation) acts as a brake that limits this leak. Conversely, replacing markup languages with programming languages provides greater opportunity to leak domain logic into configuration. It also reduces the visible distinction between configuration and domain logic.
I don’t want to overemphasise Black Hat Thinking but it is worth being vigilant. We can mitigate the risk by avoiding the injection of logic to configuration wherever possible or by perhaps maintaining smaller, decoupled Stacks. If we do need to inject logic into configuration, ThoughtWorks also suggest we keep “… such code in places where developers adhere to testing, version control, continuous integration, and other good engineering practices.”
Enough said until we can trial CDK by fire.