6 ms·

The CDK has made managing IAM so much easier for applications. It’s one of the main reasons we moved from Terraform to CDK.

theideaofcoffee 4y ago
We did the opposite because there was so much obfuscation about what exactly CDK was doing behind the curtains with respect to "small" things like IAM. We needed to know exactly which role was created or modified, etc, and we just couldn't get that with the basic interfaces that CDK provided. Writing those roles, users, groups, policies, attachments out explicitly into their own resource statements made things so much more clear, especially with respect to the relationships to other resources, and less risky
- bsjaux628 4y ago
  You can be pretty granular in CDK, just skip the L3 constructs and build everything using the L2 one or if you hate yourself go for the L1 which is manipulating the Cloudformarion template withing CDK
- digianarchist 4y ago
  Why not both? https://github.com/hashicorp/terraform-cdk https://github.com/hashicorp/terraform-cdk
- indrora 4y ago
  You can, but it takes a little bit of wringing your hands. You can inspect the entire construct tree that is created (minus anything created by Custom Resources, which are opaque to the CDK) via the Aspects visitor pattern. It allows you to audit the entire tree of resources. The Annotations framework allows you to add flags (notes, warnings, and errors) to any object in the construct hierarchy.
dangus 4y ago
How does CDK compare to Pulumi? It looks like a similar concept. I haven’t tried out either.
- alwaysanon 4y ago
  CDK 'compiles' CloudFormation templates basically making it much easier to write using TypeScript/Python/Java/C# instead of JSON/YAML. The real thing is does though is give you higher-level object-oriented constructs with best practices baked in. It has much more sensible defaults baked in and, almost ironically, the fewer parameters you pass to these classes the more opinionated CloudFormation comes out. The example that blew my mind is if you don't specify a password for RDS it provisions an AWS SecretsManager Secret, generates a random password and puts it in there and then tells the RDS to use that Secret. If you do specify a password it doesn't do that stuff. Lots of stuff like that - it turns encryption on by default and creates the keys if you don't specify, it creates private subnets and a NAT gateway for VPCs if you don't specify. It was basically "its too hard to fix the service APIs or their CloudFormation so we'll fix the problem outside of / on top of them with a tool users run on their laptops or in their pipelines to deal with generating the thousands of lines of CF boilerplate that are required to really do the right thing these days. Of course you can be very explicit in most of these constructs and the more explicit you are about what you want the less of its opinions happen.
  - abraxas 4y ago
    Unfortunately, a large problem with this lipstick on a pig approach that Amazon took with CDK is that the moment something fails to work you are right back to combing through Cloud Formation scripts. The abstraction is so leaky that I don't recall a single CDK project that I worked with where I didn't have to inspect the CF output and painstakingly map back to the CDK sources.
  - dangus 4y ago
    Thanks for that info. Apparently, I'm falling behind enough that I didn't even realize that Terraform had its own CDK as well. I personally agree with you about CloudFormation. I dislike everything about it. I think the people who build the Terraform and Pulumi ecosystems are plain and simple better architects than AWS employees. I make that relatively blind assumption because I've done an interview for AWS. They optimize their hiring process for hiring blindly loyal drones. They want you to memorize company values and relate everything you've ever done to each and every value. They make you read them off a list one-by-one. It felt so dystopian to me. AWS seems like the last place a creative, talented developer would want to go. The phone screen would scare most of them off.

theideaofcoffee 4y ago

We did the opposite because there was so much obfuscation about what exactly CDK was doing behind the curtains with respect to "small" things like IAM. We needed to know exactly which role was created or modified, etc, and we just couldn't get that with the basic interfaces that CDK provided. Writing those roles, users, groups, policies, attachments out explicitly into their own resource statements made things so much more clear, especially with respect to the relationships to other resources, and less risky

bsjaux628 4y ago
You can be pretty granular in CDK, just skip the L3 constructs and build everything using the L2 one or if you hate yourself go for the L1 which is manipulating the Cloudformarion template withing CDK
digianarchist 4y ago
Why not both? https://github.com/hashicorp/terraform-cdk https://github.com/hashicorp/terraform-cdk
indrora 4y ago
You can, but it takes a little bit of wringing your hands. You can inspect the entire construct tree that is created (minus anything created by Custom Resources, which are opaque to the CDK) via the Aspects visitor pattern. It allows you to audit the entire tree of resources. The Annotations framework allows you to add flags (notes, warnings, and errors) to any object in the construct hierarchy.

dangus 4y ago

How does CDK compare to Pulumi? It looks like a similar concept. I haven’t tried out either.

alwaysanon 4y ago
CDK 'compiles' CloudFormation templates basically making it much easier to write using TypeScript/Python/Java/C# instead of JSON/YAML. The real thing is does though is give you higher-level object-oriented constructs with best practices baked in. It has much more sensible defaults baked in and, almost ironically, the fewer parameters you pass to these classes the more opinionated CloudFormation comes out. The example that blew my mind is if you don't specify a password for RDS it provisions an AWS SecretsManager Secret, generates a random password and puts it in there and then tells the RDS to use that Secret. If you do specify a password it doesn't do that stuff. Lots of stuff like that - it turns encryption on by default and creates the keys if you don't specify, it creates private subnets and a NAT gateway for VPCs if you don't specify. It was basically "its too hard to fix the service APIs or their CloudFormation so we'll fix the problem outside of / on top of them with a tool users run on their laptops or in their pipelines to deal with generating the thousands of lines of CF boilerplate that are required to really do the right thing these days. Of course you can be very explicit in most of these constructs and the more explicit you are about what you want the less of its opinions happen.
- abraxas 4y ago
  Unfortunately, a large problem with this lipstick on a pig approach that Amazon took with CDK is that the moment something fails to work you are right back to combing through Cloud Formation scripts. The abstraction is so leaky that I don't recall a single CDK project that I worked with where I didn't have to inspect the CF output and painstakingly map back to the CDK sources.
- dangus 4y ago
  Thanks for that info. Apparently, I'm falling behind enough that I didn't even realize that Terraform had its own CDK as well. I personally agree with you about CloudFormation. I dislike everything about it. I think the people who build the Terraform and Pulumi ecosystems are plain and simple better architects than AWS employees. I make that relatively blind assumption because I've done an interview for AWS. They optimize their hiring process for hiring blindly loyal drones. They want you to memorize company values and relate everything you've ever done to each and every value. They make you read them off a list one-by-one. It felt so dystopian to me. AWS seems like the last place a creative, talented developer would want to go. The phone screen would scare most of them off.