Hello all!
In this issue of the bulletin, we will talk a bit about CDK8s, the CDK-style tool for defining Kubernetes configurations, and why use a CDK-style tool in the first place instead of YAML configurations. There will also be a few notes about an upcoming article series to get started with the AWS CDK.
I hope you find this useful!
Conference reminder
First, a quick reminder about two conferences next week which is interesting for infrastructure-as-code:
- The Cloud Engineering Summit 2021, hosted by Pulumi. The summit takes place on October 20-21 2021. You can do registration, view agenda and speakers at Cloud Engineering Summit 2021.
- HashiConf Global 2021, hosted by Hashicorp. The conference runs over two days, October 19-20 2021. You can handle registration, agenda and other things on the HashiConf website.
I hope to catch a few of the presentations during the actual summit/conferences myself, although due to time zone differences I might watch some recordings later.
CDK8s is generally available
An interesting recent announcement was the general availability of CDK8s. This tool package belongs to the AWS CDK and CDK for Terraform family of tools, but the focus is on Kubernetes. You can find the announcement here, and you can visit the CDK8s website. What CDK8s essentially provides is a way to generate Kubernetes configuration files using programming languages, which include Typescript/Javascript, Python, Java and Go.
Kubernetes is an open-source container orchestration platform, which uses configuration files in YAML format to describe the desired state of what you run on the platform - services, deployments, etc. Instead of creating these YAML configuration files directly, CDK8s allow you to use programming languages to describe the same desired state configuration.
You may ask, what is the point of that? Aren’t configuration files that describe the state more clearly than a piece of code? State is perhaps more clear in YAML, but intent may be harder to describe, as well as reusable patterns. Helm Charts is another approach to address this challenge with a templating approach. CDK8s leverages the expression capabilities of programming languages to handle these challenges. Last year, there was a Cloud Native Computing Foundation (CNCF) webinar about CDK8s.
I would agree that just a one-to-one mapping of desired state configurations in YAML to a programming language may be a double-edged sword. It makes it easier to manage settings that have to be in multiple locations, but it could obscure the readability of the configuration. Where a programming language can add value here is providing abstractions at a suitable level, something which YAML cannot do.
Thus, what I think is interesting here is the cdk8s+ package, which is part of CDK8s, which intends to provide such higher-level abstractions. This is where I think the value of CDK8s will come from, or any other toolset in the CDK family.
AWS themselves published a very good blog post last year about cdk8s+, which illustrates the value they see with CDK8s and cdk8s+ and the reason for its existence. It is a good read, check it out if interested in learning more.
Are you using CDK8s yourself? What do you think about it? Send me a comment and tell what you think!
Course work
I am working on a course to get started with infrastructure-as-code with AWS CDK. I will publish this as a series of blog posts on the Tidy Cloud AWS website. The plan is to cover some basic to set up infrastructure with virtual machines, containers, and lambda functions. The course will also include deployment pipelines and unit testing of the infrastructure. There will be multiple programming languages in use - you follow the blog posts that cover your language of choice.
Stay tuned for more information!
You can check out Tidy Cloud AWS website for more articles and old bulletins. I do also post on dev.to, which is a quite nice developer community.
Until next time,
/Erik