Everything You Need to Know About *CDK - The Internals: From CDKTF to CDK8s

Now that we're a few years into the IaC revolution, we've started to witness the growing sentiment that writing YAML and HCL is hard. While, it has become a standard, many times it seems like more of a compromise than a solution. To combat the friction of writing thousands of lines of IaC config, organizations created mythological DevOps teams to master these abilities, and even these eventually became a bottleneck in the deployment process. So what comes next? In order to overcome this known bottleneck, and to enable DevOps teams to truly delegate the IaC writing process to the developers in a way that is native to them, the community has introduced CDKs. This growing promise in the world of config management, that now makes it possible to write IaC in your programming language of choice, while removing friction and breakdowns in the deployment process. The benefits of CDKs are numerous, and the syntax easily explainable so a DevOps peer reviewer doesn't need to master all programming languages, and still can enforce best practices, all without requiring any code changes in the CI for IaC deployment processes. Aside from the improved handoff between dev and ops, CDKs have their own unique benefits of extensibility and flexibility, in including: the ability to leverage (complex) conditionals, building custom configurations and complicated logic have never been easier to implement, once you have a programming language to write your infrastructure with. In this talk, we'll walk through a real-world CDK example of two of the most common CDKs today - CDKTF for Terraform and CDK8s for Kubernetes, but will also cover some of the universal practices and capabilities available in your CDK of choice, what a migration process looks, and when this is the right choice for your engineering organization.

Now that we're a few years into the IaC revolution, we've started to witness the growing sentiment that writing YAML and HCL is hard. While, it has become a standard, many times it seems like more of a compromise than a solution. To combat the friction of writing thousands of lines of IaC config, organizations created mythological DevOps teams to master these abilities, and even these eventually became a bottleneck in the deployment process.

So what comes next? In order to overcome this known bottleneck, and to enable DevOps teams to truly delegate the IaC writing process to the developers in a way that is native to them, the community has introduced CDKs. This growing promise in the world of config management, that now makes it possible to write IaC in your programming language of choice, while removing friction and breakdowns in the deployment process.

The benefits of CDKs are numerous, and the syntax easily explainable so a DevOps peer reviewer doesn't need to master all programming languages, and still can enforce best practices, all without requiring any code changes in the CI for IaC deployment processes. Aside from the improved handoff between dev and ops, CDKs have their own unique benefits of extensibility and flexibility, in including: the ability to leverage (complex) conditionals, building custom configurations and complicated logic have never been easier to implement, once you have a programming language to write your infrastructure with. In this talk, we'll walk through a real-world CDK example of two of the most common CDKs today - CDKTF for Terraform and CDK8s for Kubernetes, but will also cover some of the universal practices and capabilities available in your CDK of choice, what a migration process looks, and when this is the right choice for your engineering organization.