Hacker News Reader

Comment by turtlebits | Hacker News Reader

I wish CDK was fully baked enough to actually use. It's still missing coverage for some AWS services (sometimes you have to do things in cloudformation, which sucks) and integrating existing infra doesn't work consistently. Oh and it creates cloudformation stacks behind the scenes and makes for troubleshooting hell.

View on HN

> sometimes you have to do things in cloudformation, which sucks

All of CDK does things in cloudformation, which made the whole thing stillborn as far as I’m concerned.

The CDK team goes to some lengths to make it better, but it’s all lambda based kludges.

so like every other aws "solution"

CDK is an abomination and I'm not sure why AWS is pushing it now. A few years ago all their Quick Starts were written in CloudFormation, now it's CDK that compiles to CloudFormation. Truly a bad idea.

Just write CloudFormation directly. Once you get the hang of the declarative style and become aware of the small gotchas, it's pretty comfy.

> Just write CloudFormation directly. Once you get the hang of the declarative style and become aware of the small gotchas, it's pretty comfy.

Exactly this. And don't make huge templates, split stuff logically to several stacks and pass vars via export/importvalue.

The biggest hurdle I've encountered is cross-stack resource sharing, especially in case of bidirectional dependencies like KMS keys and IAM roles.

The biggest hurdle is when you want to refactor your stacks, and you pretty well just can't, without risk of deleting everything

> you pretty well just can't, without risk of deleting everything

This is one hyper annoying area.

It is possible to get around it, but it's ugly, drop to L1 and override logical id:

   let vpc = new ec2.Vpc(this, 'vpc', { natGateways: 1 })
   let cfnVpc = vpc.node.defaultChild as ec2.CfnVPC
   cfnVpc.overrideLogicalId('MainVpc')

You have to do this literally for every resource that's refactored.

For us, we run 2 stacks. One that basically cannot/should-not be deleted/refactored. VPC, RDS, critical S3 buckets - i.e. critical data.

The 2nd stack runs the software and all those resources can be destroyed, moved whatever w/o any data loss.

+1 CDK refactoring is annoying and ugly

in my experience you'd need to read the CDK source code to find the offending node and call `overrideLogicalId`

there is a library to do it in nicer way: https://github.com/mbonig/cdk-logical-id-mapper

however it does not work in every case

> we run 2 stacks. One that basically cannot/should-not be deleted/refactored. VPC, RDS, critical S3 buckets

Why, dear god, you put VPC and RDS in one stack? They are much better off as separate CFN stacks.

There are deletion protection flags that can be enabled.

But circular dependencies can also lead to issues here where CDK will prevent you from deleting a resource used or referenced by a different stack.

I also had a really rough go with cdk. I personally found the lack of upsert functionality -- you can't use a resource if it exists or create if it doesn't -- to make it way more effort than I felt was useful. Plus a lack of useful error messages... maybe I'm dumb, but I can't recommend it to small companies.

Upserting resources is an antipattern in cloud resource management. The idiom that works best is to declare all the resources you use and own their lifecycle from cradle to grave.

The problem with upserting is that if the resource already exists, its existing attributes and behavior might be incompatible with the state you're declaring. And it's impossible to devise a general solution that safely transitions an arbitrary resource from state A to state A' in a way that is sure to honor your intent.

Hmm.

If you don't mind sharing, suppose (because it's what I was doing) I was trying to create personal dev, staging, and prod environments. I want the usual suspects: templated entries in route53, a load balancer, a database, some Fargate, etc.

What are you meant to do here? Thank you.

If they're all meant to look alike, you'd deploy the stack (or app, in CDK parlance) into your dev, staging, and prod accounts. You'd get the same results in each.

Cant use bun to deploy CDK, CDK fails as it looks for package-lock yarn-lock or pnpm’s exclusively

So dumb. Trying to move to SST for only that reason

but if you add cdk to the path, you can still deploy, its just that your cicd and deployment scripts are not all using bun anymore

mmm, I wonder how hard that would be to fix in a PR.

actually good idea, didnt think about it

Hmm, beyond a bug they had in bun between version 1.0.8 and 1.1.20[0] bun has otherwise worked perfectly fine for me

You have to do a few adjustments which you can see here https://github.com/codetalkio/bun-issue-cdk-repro?tab=readme...

- Change app/cdk.json to use bun instead of ts-node

- Remove package-lock.json + existing node_modules and run bun install

- You can now use bun run cdk as normal

[0]: https://github.com/codetalkio/bun-issue-cdk-repro

Reply on news.ycombinator.com