3 ms·

Terraform is also declarative but I don't see how that negates the issues. I learned first-hand that the Terraform plugin and CDK being riddled with more than 3

Terraform is also declarative but I don't see how that negates the issues. I learned first-hand that the Terraform plugin and CDK being riddled with more than 3.7k and 1.7k bugs/tasks respectively was highly relevant. That's a mountain of work to be done for what are both essentially API wrappers! A lot of operations also don't fit nicely into the declarative model, so Terraform in particular doesn't even support a lot of operations. boto3 being procedural does mean an added step for checking existing state when updating resources, but that's a minor tradeoff for stability in mission-critical code. I would love to see CDK become less buggy though!

scubbo 3y ago
> That's a mountain of work to be done for what are both essentially API wrappers! 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.
- evantbyrne 3y ago
  Hand waving away a more than 10x increase in issues won't make them go away. That's a pretty clear indication things are wrong. CDK/cloudformation is objectively buggy compared to boto3/the standard API. Terraform is unusable for all but the most basic tasks, with issues like not being able to get private IPs for certain resources, and seemingly no plans to support the many inherently procedural operations that one may need to perform on AWS. > 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.
  - scubbo 3y ago
    > 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. 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.
    - evantbyrne 3y ago
      No worries. I just saw it as being challenged on my opinions, which is a good thing.

scubbo 3y ago

> That's a mountain of work to be done for what are both essentially API wrappers! 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.

evantbyrne 3y ago
Hand waving away a more than 10x increase in issues won't make them go away. That's a pretty clear indication things are wrong. CDK/cloudformation is objectively buggy compared to boto3/the standard API. Terraform is unusable for all but the most basic tasks, with issues like not being able to get private IPs for certain resources, and seemingly no plans to support the many inherently procedural operations that one may need to perform on AWS. > 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.
- scubbo 3y ago
  > 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. 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.
  - evantbyrne 3y ago
    No worries. I just saw it as being challenged on my opinions, which is a good thing.