I'm completely done with configs written in YAML. Easily the worst part of Github Actions, even worse than the reliability. When I see some cool tool require a YAML file for config, I immediately get hit with a wave of apprehension. 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…
> 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 gen…
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 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