3 ms·

Why? Do you have something specific to say about why you dislike it? I think it’s pretty good.

re-thc 4y ago
Cross region/account usage is terrible. It's also 1/2 baked. Some things have higher level constructs but some don't. Lots of things have to be "escaped" to get it to work. If you're just on a single region/account then yes it's better than alternatives.
- scubbo 3y ago
  I suspect that you're not deploying with a CDK-defined Code Pipeline (starter article[0], in-depth example[1]), which makes cross account/region deployments so ludicrously smooth and simple that it often has newbies refuse to believe that it can have worked _that_ easily. It is true that _some_ resources don't have L2 constructs, but there's pretty damn good coverage of the most popular services - and, even when you have to drop back to L1, that's still better than hand-written CFN templates or abandoning IaC entirely! [0] https://docs.aws.amazon.com/cdk/v2/guide/cdk_pipeline.html https://docs.aws.amazon.com/cdk/v2/guide/cdk_pipeline.html [1] https://pipelines.devops.aws.dev/ https://pipelines.devops.aws.dev/
scubbo 4y ago
Oddly I'm not able to reply directly to re-thc, so I hope you don't mind me commenting here that - I suspect that they're not deploying with a CDK-defined Code Pipeline (starter article[0], in-depth example[1]), which makes cross account/region deployments so ludicrously smooth and simple that it often has newbies refuse to believe that it can have worked _that_ easily. It is true that _some_ resources don't have L2 constructs, but there's pretty damn good coverage of the most popular services - and, even when you have to drop back to L1, that's still better than hand-written CFN templates or abandoning IaC entirely! [0] https://docs.aws.amazon.com/cdk/v2/guide/cdk_pipeline.html https://docs.aws.amazon.com/cdk/v2/guide/cdk_pipeline.html [1] https://pipelines.devops.aws.dev/ https://pipelines.devops.aws.dev/
- emodendroket 4y ago
  If the reply link doesn't appear you can still reply by clicking on the timestamp. I don't know why it works that way.
  - scubbo 3y ago
    Odd - it's showing up now. I'll remember for next time. Thanks!
Aeolun 4y ago
It’s just… half baked. It feels like the CDK team constantly has to work circles around the lacking functionality in CFN. Want to upload a docker image to ECR, use this hacky lambda function. Want to create an object in an S3 bucket? Use this other hacky lambda function. Then a lot of the resources depend on each other in funky ways, but they’re not always implicitly defined, so whether everything will be created in the right order is anyone’s guess and you often have to define the dependencies manually anyway. Then when it fails to bring up/modify a stack you get the helpful message that resource x failed to create, but nearly never why. Like, CDK is marginally better than plain CF, but something like Terraform or Pulumi is so much better that it’s hard to imagine anyone would want to use anything else. Also, like someone else said, the stacks are directly bound to specific accounts/regions. When I bring domething up that is my QA environment, I’d enjoy it if I didn’t have to split every stack in twain (cloudfront certificates that can only be in us-east-1 or something). Oh, and when you finally work through all these issues and work on your app for a few months, the dreaded message will come up… “Maximum of 500 resources in stack reached”. Now enjoy splitting it all up.
- scubbo 3y ago
  > It feels like the CDK team constantly has to work circles around the lacking functionality in CFN. Want to upload a docker image to ECR, use this hacky lambda function. Want to create an object in an S3 bucket? Use this other hacky lambda function. It feels like you have a different boundary of what constitutes "infrastructure" than the CDK team do. I'd call both of those examples content _within_ an infrastructure component. Would you expect CDK to initialize an SQS Queue with a message on it? Or a DynamoDB table with data in it? I guess you could make that argument, but to me _populating_ your infrastructure is a very different task from _making_ it - it's an application-level task, not a infrastructure-level one. Most of the rest of your comments are pretty subjective - I can't say I agree with most of them or have experienced them, but I also don't disbelieve you that they've happened to you. Not sure what you mean by having an issue with "stacks [being] directly bound to specific accounts/regions", though. Why is that an issue? Why would you _want_ a stack that spans multiple account/regions? I just successfully created and validated a Certificate in us-west-2, so I'm not sure what your parenthetical means.

Cross region/account usage is terrible. It's also 1/2 baked. Some things have higher level constructs but some don't. Lots of things have to be "escaped" to get it to work. If you're just on a single region/account then yes it's better than alternatives.

scubbo 3y ago
I suspect that you're not deploying with a CDK-defined Code Pipeline (starter article[0], in-depth example[1]), which makes cross account/region deployments so ludicrously smooth and simple that it often has newbies refuse to believe that it can have worked _that_ easily. It is true that _some_ resources don't have L2 constructs, but there's pretty damn good coverage of the most popular services - and, even when you have to drop back to L1, that's still better than hand-written CFN templates or abandoning IaC entirely! [0] https://docs.aws.amazon.com/cdk/v2/guide/cdk_pipeline.html https://docs.aws.amazon.com/cdk/v2/guide/cdk_pipeline.html [1] https://pipelines.devops.aws.dev/ https://pipelines.devops.aws.dev/

scubbo 4y ago

Oddly I'm not able to reply directly to re-thc, so I hope you don't mind me commenting here that - I suspect that they're not deploying with a CDK-defined Code Pipeline (starter article[0], in-depth example[1]), which makes cross account/region deployments so ludicrously smooth and simple that it often has newbies refuse to believe that it can have worked _that_ easily. It is true that _some_ resources don't have L2 constructs, but there's pretty damn good coverage of the most popular services - and, even when you have to drop back to L1, that's still better than hand-written CFN templates or abandoning IaC entirely! [0] https://docs.aws.amazon.com/cdk/v2/guide/cdk_pipeline.html https://docs.aws.amazon.com/cdk/v2/guide/cdk_pipeline.html [1] https://pipelines.devops.aws.dev/ https://pipelines.devops.aws.dev/

emodendroket 4y ago
If the reply link doesn't appear you can still reply by clicking on the timestamp. I don't know why it works that way.
- scubbo 3y ago
  Odd - it's showing up now. I'll remember for next time. Thanks!

Aeolun 4y ago

It’s just… half baked. It feels like the CDK team constantly has to work circles around the lacking functionality in CFN. Want to upload a docker image to ECR, use this hacky lambda function. Want to create an object in an S3 bucket? Use this other hacky lambda function. Then a lot of the resources depend on each other in funky ways, but they’re not always implicitly defined, so whether everything will be created in the right order is anyone’s guess and you often have to define the dependencies manually anyway. Then when it fails to bring up/modify a stack you get the helpful message that resource x failed to create, but nearly never why. Like, CDK is marginally better than plain CF, but something like Terraform or Pulumi is so much better that it’s hard to imagine anyone would want to use anything else. Also, like someone else said, the stacks are directly bound to specific accounts/regions. When I bring domething up that is my QA environment, I’d enjoy it if I didn’t have to split every stack in twain (cloudfront certificates that can only be in us-east-1 or something). Oh, and when you finally work through all these issues and work on your app for a few months, the dreaded message will come up… “Maximum of 500 resources in stack reached”. Now enjoy splitting it all up.

scubbo 3y ago
> It feels like the CDK team constantly has to work circles around the lacking functionality in CFN. Want to upload a docker image to ECR, use this hacky lambda function. Want to create an object in an S3 bucket? Use this other hacky lambda function. It feels like you have a different boundary of what constitutes "infrastructure" than the CDK team do. I'd call both of those examples content _within_ an infrastructure component. Would you expect CDK to initialize an SQS Queue with a message on it? Or a DynamoDB table with data in it? I guess you could make that argument, but to me _populating_ your infrastructure is a very different task from _making_ it - it's an application-level task, not a infrastructure-level one. Most of the rest of your comments are pretty subjective - I can't say I agree with most of them or have experienced them, but I also don't disbelieve you that they've happened to you. Not sure what you mean by having an issue with "stacks [being] directly bound to specific accounts/regions", though. Why is that an issue? Why would you _want_ a stack that spans multiple account/regions? I just successfully created and validated a Certificate in us-west-2, so I'm not sure what your parenthetical means.