TSIA.
The main benefit of the CDK is that it allows developers to define their application infrastructure using "normal" code in their preferred programming language (we currently support JavaScript, TypeScript and Java and have a more language bindings in the pipe).
This means that now we can leverage the patterns, tools and best practices we are familiar with to model and define complex cloud architectures. For example, we can use constants, variables, conditions, loops, methods, classes, interfaces, enums... We can use our favorite IDEs or editors with built-in code-completion and refactoring capabilities, testing frameworks, code review tools, semantic versioning... All that good stuff we've been doing and perfecting with code in the past few decades can now be used to model complete cloud applications. That's what the CDK is about.
Similarly to [Terraform Modules], the CDK is based on a component model which allows anyone to publish high-level abstractions called "constructs", which can naturally be integrated into any CDK app as first-class citizens. For example, the [AWS Construct Library], which is shipped with the CDK is a growing set of such abstractions that expose the AWS surface area via a very rich and powerful API, which encapsulates much of the complexity in working with AWS.
The CDK is not attempting to be an infrastructure provisioning engine. CDK programs are executed during build and synthesize deployment artifacts like AWS CloudFormation Templates, code bundles (and potentially even Terraform Configurations).
Would love to answer any other questions!
Thank you for the well thought-out answer. Perhaps a "comparison with other tools" section would be appropriate to add at some point in the future -- I am sure I will not be the only person to ask this question :)
Thanks, that's a good idea.
Most helpful comment
The main benefit of the CDK is that it allows developers to define their application infrastructure using "normal" code in their preferred programming language (we currently support JavaScript, TypeScript and Java and have a more language bindings in the pipe).
This means that now we can leverage the patterns, tools and best practices we are familiar with to model and define complex cloud architectures. For example, we can use constants, variables, conditions, loops, methods, classes, interfaces, enums... We can use our favorite IDEs or editors with built-in code-completion and refactoring capabilities, testing frameworks, code review tools, semantic versioning... All that good stuff we've been doing and perfecting with code in the past few decades can now be used to model complete cloud applications. That's what the CDK is about.
Similarly to [Terraform Modules], the CDK is based on a component model which allows anyone to publish high-level abstractions called "constructs", which can naturally be integrated into any CDK app as first-class citizens. For example, the [AWS Construct Library], which is shipped with the CDK is a growing set of such abstractions that expose the AWS surface area via a very rich and powerful API, which encapsulates much of the complexity in working with AWS.
The CDK is not attempting to be an infrastructure provisioning engine. CDK programs are executed during build and synthesize deployment artifacts like AWS CloudFormation Templates, code bundles (and potentially even Terraform Configurations).
Would love to answer any other questions!