3 ms·

> These same feelings extend to other proprietary config languages like HCL for Terraform, ASL for AWS Step Functions, etc. It's fine that you want a declarativ

> These same feelings extend to other proprietary config languages like HCL for Terraform, ASL for AWS Step Functions, etc. It's fine that you want a declarative API, but let me generate my declaration programatically. Yeah, I've had the same sort of opinion since the bad old AWS CloudFormation days. I wrote an experimental CloudFormation generator 4 years ago where all of the resources and Python type hints were generated from a JSON file that AWS published and it worked really well (https://github.com/weberc2/nimbus/blob/master/examples/src/nimbus_examples/s3bucket.py https://github.com/weberc2/nimbus/blob/master/examples/src/n...). > Config declared in and generated by code has been a superior experience. It's one of the things that AWS CDK got absolutely right. Is that how CDK works? I've only dabbled with it, but it was pretty far from the "generate cloudformation" experience that I had built; I guess I never "saw the light" for CDK. It felt like trading YAML/templating problems for inheritance/magic problems. I'd really like to hear from more people who have used AWS CDK, Terraform's CDK, and/or Pulumi.

bilalq 3y ago
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. TL;DR: Infrastructure-as-code-as-code
- throwaway894345 3y ago
  > 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.
  - bilalq 3y ago
    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 https://github.com/hashicorp/cdktf-aws-cdk

bilalq 3y ago

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. TL;DR: Infrastructure-as-code-as-code

throwaway894345 3y ago
> 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.
- bilalq 3y ago
  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 https://github.com/hashicorp/cdktf-aws-cdk