4 ms·

I don't really get these arguemnts on why CDK is bad. I've got around 3k accounts, 300k aws resources, 1k devs, all working fine on CDK... I've never seen where

I don't really get these arguemnts on why CDK is bad. I've got around 3k accounts, 300k aws resources, 1k devs, all working fine on CDK... I've never seen where functional / declarative change mattered. My issue with TFN is a half baked turing language that I fight a lot, and CFN is terrible for IFs or massifly repaeated. I talked with the team building CDK... their market analysis was essentially: SysDEs love CFN or declarative. Developers hate repeating themselves and lack of abstractions. I generally agree with the latter. The lack of real modules, dependency management, compilers, etc are a put off for CFN and TFN for me. I'm loving CDK.

fulafel 4y ago
You could have both abstractions and DRY without mixing it in imperative library calls and opaque state. You could then write eg tools that apply changes robustly across all your stacks, inspect for security risks, check against custom schemas and policies, reusable things that compose better, etc.
- grogenaut 4y ago
  I'm doing all of that actually... I don't see how "functional" and "declarative" is in any way helping... You're making statements without getting into the details. For instance we run a linter for security issues and best practices during the cdk build... We have tools applying changes across our abstractions and against our non-abstractions. In a declarative form the changes don't make it back into the declarative form unless you're pullling cfn state back into say git, or harder reversing it back into TFN state.
  - fulafel 4y ago
    Think for example how you would robustly check that resources of certain types are labeled in a way conforming to a given schema, or that would rewrite the label values in your stacks to a newer format. Linting CDK code can't get you this. It's possible of course that I don't know enough about CDK and these examples have CDK solutions. Imperative and declarative are not hard requirements for this but they make the domain easier to reason about and they are a good fit to the CF model of configuration-as-data instead (vs CDK's configuration-as-imperative-code).
    - grogenaut 4y ago
      Cdk linters can 100% do this. They can operate at the various construct levels including level 1 eg generated cloud formation. At this point it's just making a linter/visitor that says "if type is taggable then it must have this tag" and bob's your uncle. The l1 stuff is generated from the cfn schema and so will have tags correctly.

fulafel 4y ago

You could have both abstractions and DRY without mixing it in imperative library calls and opaque state. You could then write eg tools that apply changes robustly across all your stacks, inspect for security risks, check against custom schemas and policies, reusable things that compose better, etc.

grogenaut 4y ago
I'm doing all of that actually... I don't see how "functional" and "declarative" is in any way helping... You're making statements without getting into the details. For instance we run a linter for security issues and best practices during the cdk build... We have tools applying changes across our abstractions and against our non-abstractions. In a declarative form the changes don't make it back into the declarative form unless you're pullling cfn state back into say git, or harder reversing it back into TFN state.
- fulafel 4y ago
  Think for example how you would robustly check that resources of certain types are labeled in a way conforming to a given schema, or that would rewrite the label values in your stacks to a newer format. Linting CDK code can't get you this. It's possible of course that I don't know enough about CDK and these examples have CDK solutions. Imperative and declarative are not hard requirements for this but they make the domain easier to reason about and they are a good fit to the CF model of configuration-as-data instead (vs CDK's configuration-as-imperative-code).
  - grogenaut 4y ago
    Cdk linters can 100% do this. They can operate at the various construct levels including level 1 eg generated cloud formation. At this point it's just making a linter/visitor that says "if type is taggable then it must have this tag" and bob's your uncle. The l1 stuff is generated from the cfn schema and so will have tags correctly.