5 ms·

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

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.

Aeolun 2y ago
> 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.
- liveoneggs 2y ago
  so like every other aws "solution"
LunaSea 2y ago
The biggest hurdle I've encountered is cross-stack resource sharing, especially in case of bidirectional dependencies like KMS keys and IAM roles.
- 8note 2y ago
  The biggest hurdle is when you want to refactor your stacks, and you pretty well just can't, without risk of deleting everything
  - irjustin 2y ago
    > 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.
    - wcchoi 2y ago
      +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 https://github.com/mbonig/cdk-logical-id-mapper however it does not work in every case
    - nuker 2y ago
      > 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.
  - LunaSea 2y ago
    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.
yieldcrv 2y ago
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
- hinkley 2y ago
  mmm, I wonder how hard that would be to fix in a PR.
  - yieldcrv 2y ago
    actually good idea, didnt think about it
- Tehnix 2y ago
  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-ov-file#initial-setup 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 https://github.com/codetalkio/bun-issue-cdk-repro
x0x0 2y ago
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.
- otterley 2y ago
  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.
  - x0x0 2y ago
    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.
    - otterley 2y ago
      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.
roncesvalles 2y ago
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.
- deleted 2y ago
  [deleted]
- nuker 2y ago
  > 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.

Aeolun 2y ago

> 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.

liveoneggs 2y ago
so like every other aws "solution"

LunaSea 2y ago

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

8note 2y ago
The biggest hurdle is when you want to refactor your stacks, and you pretty well just can't, without risk of deleting everything
- irjustin 2y ago
  > 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.
  - wcchoi 2y ago
    +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 https://github.com/mbonig/cdk-logical-id-mapper however it does not work in every case
  - nuker 2y ago
    > 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.
- LunaSea 2y ago
  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.

yieldcrv 2y ago

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

hinkley 2y ago
mmm, I wonder how hard that would be to fix in a PR.
- yieldcrv 2y ago
  actually good idea, didnt think about it
Tehnix 2y ago
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-ov-file#initial-setup 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 https://github.com/codetalkio/bun-issue-cdk-repro

x0x0 2y ago

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.

otterley 2y ago
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.
- x0x0 2y ago
  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.
  - otterley 2y ago
    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.

roncesvalles 2y ago

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.

deleted 2y ago
[deleted]
nuker 2y ago
> 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.