5 ms·

Yes. CDK is just another way of expressing the same things as terraform and cloudfront but using a framework which is opaque. Plus it's slow as fuck, buggy and

by gw98 4y ago

Yes. CDK is just another way of expressing the same things as terraform and cloudfront but using a framework which is opaque. Plus it's slow as fuck, buggy and difficult to debug when it goes wrong. Every attempt keeps trying to solve the same problems with a new abstraction but the problem is the underlying abstraction not the tools.

cube00 4y ago
This is what worried me when I see the marketing claiming how easy is it run up infra using AWS SAM. It's all great until something goes wrong and you have to peak behind the curtain to the nest of automatically generated Cloudfoundation scripts.
Hawxy 4y ago
> CDK is just another way of expressing the same things as terraform and cloudfront but using a framework which is opaque. It also involves writing many, many less lines of code than Cloudformation/Terraform thanks to the excellent abstractions it bundles in. Your example of writing "2 days' worth of YAML" is less than 120 lines of Typescript in CDK. You could even skip that and just npm install the AWS solutions construct for this scenario if you have literally no idea what you're doing: https://docs.aws.amazon.com/solutions/latest/constructs/aws-cloudfront-s3.html https://docs.aws.amazon.com/solutions/latest/constructs/aws-...
- gw98 4y ago
  We don’t know typescript. So we’d have to learn that first.
  - indymike 4y ago
    Do you know JavaScript?
    - gw98 4y ago
      Nope! Edit: not strictly true. I know JavaScript quite well but I wish to have nothing whatsoever to do with it and the ecosystem around it due to a number of reasons I would have to write a whole essay on.
      - fuckelonmusk 4y ago
  - Hawxy 4y ago
    CDK also works with Java or Python.
- irjustin 4y ago
  To be absolutely fair the CDK is non-trivial. If you know CloudFormation, you do _not_ know the CDK. The CDK is split in 3 versions, ver 1, ver 2 and v2-alpha. Knowing the difference between L1, L2 missing options between the two. Don't even get me started on docs. Docs in CloudFormation is KING. CDK's docs are a simplification at BEST. Most of the time I have to drop down into CF's docs to see what the actual constraints on a key are. Given all my complaints, I'm not going back to CloudFormation. It is wayyyyy less code. Separated files. And, it's too hard to do complex stuff in CF. CDK has a lot of nice magic that takes away so much complexity esp dealing with cross region work.
indrora 4y ago
Hi, I work on (part) of the CDK at the moment. If you've found bugs, we'd love to hear about them with an appropriate reproduction over on github[0]. Thus ends my corp-speak. The following is my opinion alone: The thing that is hard for a lot of people to understand, it feels like, is that the CDK is both a library (nee runtime) and CI system in one. The runtime produces, at the end of the day, a CloudFormation template that gets shoved into the right places. The CDK happens to make generating those easier. One of the core issues with working with CloudFormation is that it's limited in what the services support it doing. Services introduced before CloudFormation was really launched have the worst, but it wasn't until 2015 or so that most services really had "OK" support for CFN. CloudFormation is also brittle, and this causes a lot of headaches. CloudFormation can't handle serial operations that require "create & permute" sequences -- where two things have to be set up in order, then glued together later after some kind of configuration. The way the CDK does this is by deploying lambdas that get invoked after your stack is shipped out that make the relevant API calls. Terraform does this by having the code that Terraform runs make the API call. The difference here gets to be that the CDK can synthesize a change long before it is actually effected, allowing for things like second order permutations. Terraform does everything in-situ, standing up infrastructure and taking the place of both the CDK and CloudFormation. This has upsides and downsides on both, but a large upside (IMO, again) of the CDK approach is that you can code-wise validate certain things ahead of time before they're deployed, whereas with Terraform it's a little harder. Terraform's big upside is that it handles things that are Hard to do with CloudFormation alone by letting you figure out how to actually create/destroy that bit of infrastructure and hook up the relevant parts as one action in one codebase, rather than having to write Lambda handlers (the CDK calls these handlers "Custom Resource", which are different from Constructs) that get deployed and called when you need to setup/teardown/change the relevant parts. Both Terraform and the CDK are opaque wrappers around AWS as a whole, the difference being that Terraform wrote their own DSL to describe things that gets then attached to their own SDK (which appears to be JS?) with varying levels of integration, whereas the CDK allows you to use whatever language you're already using to build the primary structure of your application, but where you have fully atomic (not just rollback-able) changes via CloudFormation. [0]github.com/aws/aws-cdk/issues/new

by gw98 4y ago

cube00 4y ago

This is what worried me when I see the marketing claiming how easy is it run up infra using AWS SAM. It's all great until something goes wrong and you have to peak behind the curtain to the nest of automatically generated Cloudfoundation scripts.

Hawxy 4y ago

> CDK is just another way of expressing the same things as terraform and cloudfront but using a framework which is opaque. It also involves writing many, many less lines of code than Cloudformation/Terraform thanks to the excellent abstractions it bundles in. Your example of writing "2 days' worth of YAML" is less than 120 lines of Typescript in CDK. You could even skip that and just npm install the AWS solutions construct for this scenario if you have literally no idea what you're doing: https://docs.aws.amazon.com/solutions/latest/constructs/aws-cloudfront-s3.html https://docs.aws.amazon.com/solutions/latest/constructs/aws-...

gw98 4y ago
We don’t know typescript. So we’d have to learn that first.
- indymike 4y ago
  Do you know JavaScript?
  - gw98 4y ago
    Nope! Edit: not strictly true. I know JavaScript quite well but I wish to have nothing whatsoever to do with it and the ecosystem around it due to a number of reasons I would have to write a whole essay on.
    - fuckelonmusk 4y ago
- Hawxy 4y ago
  CDK also works with Java or Python.
irjustin 4y ago
To be absolutely fair the CDK is non-trivial. If you know CloudFormation, you do _not_ know the CDK. The CDK is split in 3 versions, ver 1, ver 2 and v2-alpha. Knowing the difference between L1, L2 missing options between the two. Don't even get me started on docs. Docs in CloudFormation is KING. CDK's docs are a simplification at BEST. Most of the time I have to drop down into CF's docs to see what the actual constraints on a key are. Given all my complaints, I'm not going back to CloudFormation. It is wayyyyy less code. Separated files. And, it's too hard to do complex stuff in CF. CDK has a lot of nice magic that takes away so much complexity esp dealing with cross region work.

indrora 4y ago

Hi, I work on (part) of the CDK at the moment. If you've found bugs, we'd love to hear about them with an appropriate reproduction over on github[0]. Thus ends my corp-speak. The following is my opinion alone: The thing that is hard for a lot of people to understand, it feels like, is that the CDK is both a library (nee runtime) and CI system in one. The runtime produces, at the end of the day, a CloudFormation template that gets shoved into the right places. The CDK happens to make generating those easier. One of the core issues with working with CloudFormation is that it's limited in what the services support it doing. Services introduced before CloudFormation was really launched have the worst, but it wasn't until 2015 or so that most services really had "OK" support for CFN. CloudFormation is also brittle, and this causes a lot of headaches. CloudFormation can't handle serial operations that require "create & permute" sequences -- where two things have to be set up in order, then glued together later after some kind of configuration. The way the CDK does this is by deploying lambdas that get invoked after your stack is shipped out that make the relevant API calls. Terraform does this by having the code that Terraform runs make the API call. The difference here gets to be that the CDK can synthesize a change long before it is actually effected, allowing for things like second order permutations. Terraform does everything in-situ, standing up infrastructure and taking the place of both the CDK and CloudFormation. This has upsides and downsides on both, but a large upside (IMO, again) of the CDK approach is that you can code-wise validate certain things ahead of time before they're deployed, whereas with Terraform it's a little harder. Terraform's big upside is that it handles things that are Hard to do with CloudFormation alone by letting you figure out how to actually create/destroy that bit of infrastructure and hook up the relevant parts as one action in one codebase, rather than having to write Lambda handlers (the CDK calls these handlers "Custom Resource", which are different from Constructs) that get deployed and called when you need to setup/teardown/change the relevant parts. Both Terraform and the CDK are opaque wrappers around AWS as a whole, the difference being that Terraform wrote their own DSL to describe things that gets then attached to their own SDK (which appears to be JS?) with varying levels of integration, whereas the CDK allows you to use whatever language you're already using to build the primary structure of your application, but where you have fully atomic (not just rollback-able) changes via CloudFormation. [0]github.com/aws/aws-cdk/issues/new