> Candidly, to describe CDK/Terraform as "essentially API wrappers" betrays the fact that you didn't really try to use them seriously. Yes, they call AWS APIs under the hood; but if you're only using them as a drop-in replacement for boto3 calls, you are missing out on a lot of the power they provide.
Well I actually reviewed the code as part of my evaluation, and even made the initial version with terraform that I contributed a patch for, so it's an accurate description. CDK is a wrapper for cloudformation...
> Either way, I feel extremely confident claiming that a bug in CDK code is significantly less likely than making a mistake when attempting to reimplement-in-boto3 all the wiring and dependencies of a complex stack.
If you were to actually compare CDK and boto3 examples, you would find they are very close in practice with the major difference being that you _may_ need to diff existing resources before performing updates with boto3. Not hard to do in practice and gives you the opportunity to choose exactly how to handle different scenarios, which I see as a plus. You still need to learn AWS concepts and have a strategy for error handling.
I'm glad CDK it works for your use case! I'm provisioning entire build and runtime environments as a service, and chose the API wrapper that is clearly given first priority at AWS.
These are certainly fair points.
Thank you for your civility - I re-read my previous comment and am not proud of the tone that I struck.
You are once again assuming that the existence of feature requests implies that the existing tool is not fit for purpose. This simply isn't the case. The boto3 SDK "only" attempts to provide a client for the AWS API - feature requests are essentially meaningless until/unless a new AWS Service is launched. The nature of CDK (or Terraform), however, is that "higher-level" constructs can be created - Constructs defining patterns, rather than just one-to-one mappings with AWS Resources. These can be imagined and requested essentially infinitely; but those requests doesn't mean that the existing L1/2 Constructs are incomplete or flawed.
Candidly, to describe CDK/Terraform as "essentially API wrappers" betrays the fact that you didn't really try to use them seriously. Yes, they call AWS APIs under the hood; but if you're only using them as a drop-in replacement for boto3 calls, you are missing out on a lot of the power they provide.
> A lot of operations also don't fit nicely into the declarative model
Cool, in which case, boto3 is indeed the correct choice. But that's because it's the right tool for the job, not because CDK or Terraform are inherently flawed.
> I would love to see CDK become less buggy though!
I've been using it professionally for over 5 years and have encountered a single bug, which arose due to version mismatches in different libraries (and so was easily resolved). I certainly won't claim that _no_ bugs exist - though, skimming the Issues page, the considerable majority appear to be Feature Requests. Either way, I feel extremely confident claiming that a bug in CDK code is significantly less likely than making a mistake when attempting to reimplement-in-boto3 all the wiring and dependencies of a complex stack.