AWS CDK a.k.a. Cloud Development Kit is a toolkit that allows you to code your infrastructure from the comfort of your favorite programming language. AWS CDK promotes an imperative paradigm to define your infrastructure code at design time. It transcompile the code at build time and deploys it as a Cloudformation stack (declarative) to provision the desired infrastructure. Thus AWS CDK brings the best of both imperative and declarative paradigms to develop & manage our infrastructure.

Motivation
As a lead engineer, I often build POC’s to try out new tools and services; deploy them and get them load-tested in cloud infrastructure to come up with a right recommendation. I prefer to manage my infrastructure as a code to bring up the stack on-demand and teardown when not in use. It gives me the convenience to recreate and retest on cloud to revisit my recommendations.

However, I do not find provisioning an infrastructure via Cloudformation or Terraform make sense to me anymore. The declarative tools such as Cloudformation, Terraform expects the infrastructure defined using their proprietary DSL which requires a continuous investment in learning to keep our knowledge updated. In addition, the declarative infrastructure configuration is often tailor made for a given stack and has limited flexibility to make it generic for reuse. To circumvent this limitation and demand, I have decided to give AWS CDK a chance.

CDK Ecosystem
The CDK ecosystem consists of Construct Library and CDK Toolkit. CDK toolkit is a command-line tool that provides utility functions to setup, compile, synthesize, diff and deploy your CDK app. Among the utility functions, diff helps you to compare the code state vs the deployed state and synthesize converts the code to a cloudformation template. CDK toolkit definitely makes the application setup simple and seamless across all the supported programming languages.

Construct library contains one or more opinionated modules/constructs for each AWS service. The constructs are designed to take minimal inputs for AWS service creation and supplements with convenient defaults. The constructs also make the integration between AWS services straightforward and less verbose. Having said that constructs come in different types, ranging from low-level to higher-level to patterns.

• Low-level (L1) constructs have a direct mapping to Cloudformation resources. It gives you a fine grained control over your resource creation.
• Higher-level (L2) constructs falls into opinionated constructs type.
• Patterns (L3) constructs are even more higher-level constructs which may compose one or more constructs to create common tasks e.g. QueueProcessingFargateService

CDK: AWS & Beyond
We must be thankful to the effort made by AWS to extend CDK style of infrastructure coding to Terraform & K8s. This is indeed a great initiative as it standardizes infrastructure coding across cloud platforms & Kubernetes (k8s). CDKtf and CDK8s are toolkits for Terraform and Kubernetes respectively. They are part of CDK ecosystem, fully open-source and independent toolkits but shares CDK design principles and patterns to give us one experience. Learn more at cdk.dev.

I do think learning CDK is a worth investment of our time. It can’t be any better.