It's an annoyingly OOP model with mutations and side-effects, but if you look past that, it's pretty nice. The core idea is you create an instance of a CDK "App" object. You create new instances of "Stack" objects that take an "App" instance as a context parameter. From there, resources are grouped into logical chunks called "Constructs" which take either a stack or another construct as their parent context param. The only things you should ever inherit from are the base Constructs for Stack, Stage, and Construct. Don't use inheritance anywhere else and you'll be okay.
The code then looks something like this (writing this straight in the comment box, probably has errors):
// Entrypoint of CDK project like bin/app.ts or whatever
import * as cdk from 'aws-cdk-lib'
import { MyStack } from '../lib/my-stack.ts'
const app = new cdk.App()
const stack = new MyStack(app, 'StackNameHere', someProps)
// lib/my-stack.ts
// Imports go here
export class MyStack extends cdk.Stack {
constructor(scope: Construct, id: string, props: MyStackProps) {
super(scope, id, props)
const bucket = new s3.Bucket(this, 'MyBucket', {
bucketName: 'example-bucket',
})
const lambda = new NodejsFunction(this, 'MyLambdaFn', {
functionName: 'My-Lambda-Fn',
entryFile: 'my-handler.ts',
memorySize: 1024,
runtime: Runtime.NodeJS_20X
})
bucket.grantRead(lambda),
tracing: Tracing.Active
})
}
The best part is the way CI/CD is managed. CDK supports self-mutating pipelines where the pipeline itself is a stack in your CDK app. After the pipeline is created, it will update itself as part of the pipeline before promoting other changes to the rest of your environments.
The equivalent CloudFormation for the above example would be ridiculously long. And that's putting aside all the complexity it would take for you to add on asset bundling for code deployed to things like Lambda.
> It's an annoyingly OOP model with mutations and side-effects, but if you look past that, it's pretty nice
I think I was getting hung up on the mutations and side-effects of it all. Thanks for putting words to that. I'll have to give it another try sometime. Have you used Terraform's CDK by chance? I assume it's heavily inspired from AWS's CDK, but my company has since moved to GCP/Terraform.
The mutations and side-effects only last until synthesis. You can imagine a CDK app as a pure function that runs a bunch of mutations on an App object and then serializes the state of that object in the end to static assets that can be deployed. The internals of it all are messy, but at a conceptual level, it's easy to think about.
CDKTF is really promising, IMO. When I last looked, it was still pretty new, but it's maturing, I think. One downside compared to regular AWS CDK is that the higher level constructs from the official AWS CDK can't be used in CDKTF. There is an adapter that exists, but it's one more layer between you and knowing what's going on: https://github.com/hashicorp/cdktf-aws-cdk
The code then looks something like this (writing this straight in the comment box, probably has errors):
The best part is the way CI/CD is managed. CDK supports self-mutating pipelines where the pipeline itself is a stack in your CDK app. After the pipeline is created, it will update itself as part of the pipeline before promoting other changes to the rest of your environments.The equivalent CloudFormation for the above example would be ridiculously long. And that's putting aside all the complexity it would take for you to add on asset bundling for code deployed to things like Lambda.
TL;DR: Infrastructure-as-code-as-code