Blueprints
June 9

Everything you need to know about CDK - the internals: From CDKTF to cdk8s

Now a few years into the IaC revolution, we have started to witness the growing sentiment that writing YAML & 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 and platform teams, but this has also broken down. In this talk we'll explore why.
Talk abstract

So what comes next? In order to overcome this known bottleneck, and to enable DevOps and platform teams to truly delegate the IaC writing process to developers in a way that is native to them, the community has introduced CDKs. This growing promise in the world of config management 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 is easily explainable. This means 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 developers and Ops, CDKs have their own unique benefits of extensibility and flexibility including the ability to leverage (complex) conditionals. Building custom configurations and complicated logic has 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 example of two of the most common CDKs today: CDKTF for Terraform and cdk8s for Kubernetes. We will also cover some of the universal practices and capabilities available in your CDK of choice, what a migration process looks like, and when this is the right choice for your engineering organization.