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
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.
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
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.
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.
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.
We had to move to Pulumi from CDK. CDK's reliance on Cloudformation makes it unusable because CF is not a production ready service - it is extremely slow and its failure modes are absurd.
Pulumi does less "magic" than CDK, though they're working on higher level constructs, but ultimately it's just the better technology.
Well, I disagree. I've seen CF get into bad states that can't be recovered without support going in. It shouldn't be controversial to say that it's much slower than alternatives as well.
The difference is that AWS support can recover them and will help you. In that way it is a service not a tool. They are also the support team for the services that are being provisioned/managed so it is "one throat to choke".
On the contrary, I have seen many many destructive terraform applies that really messed everything up - without a helpful support team to call (unless you are paying Hashicorp) that can just get you out of the jam.
Yes it is a bit slower and often you need to wait for it to rollback when something goes wrong - but 9 times out of 10 that rollback succeeds. I'll take that trade-off...
CDK makes Cloudformation easy to use. Tight integration between cdk and services. Lots of reusable bits and parts. Forces you into component (construct) mindset to handle complexity.
Pulumi bypasses CF by making and breaking the resources directly. The focus on cross cloud and multiple cloud means you're thinking in higher order abstraction but you lose the finer knobs unless you break the indirection.
CDK has ways to integrate directly into CodePipeline and use its own abstractions directly (such as with ecr or s3 deployments). Pulimi half expects you to have solved your CI/CD on your own.
Reliability is a different problem. System shits its pants halfway through a cdk deployment? CDK rolls back and figures out the issues. Crash during Pulimi? Unknown state but you can rerun it and usually get back up and running.
