When searching this Slack space for

cdk8s

, zero matches are found. Is nobody considering generating k8s objects programmatically with this tool? What are you all using for that part of your platform? Or are you just providing standard tools so developers can commit their yaml (or kustomize/jsonnet/...) into git?

Hey Serge 👋

🤛

Time will come!

Issue @Serge van Ginderachter is that this is the free version of Slack

Sure, but still, have been searching for it a couple of times over the past weeks/months. Seems to never come up.

To play devil's advocate I'll bite; I'm curious as to the advantage of using a tool like this that essentially transpiles back to YAML anyways? If folks have to learn how to use cdk8s to create objects, and potentially have to learn some YAML for troubleshooting later, wouldn't it be easier to learn the YAML? My worry is that if you have teams that use multiple languages, they each have to learn their language-specific way to create things, plus you've now got a dependency on cdk8s to keep up-to-date with k8s releases for API changes (and introduce another abstraction that could break/requires testing)

My use case is to use cdk8s for the backend of a platform; the idea is not to have this used by the end-user. Having done a lot with kustomize, and falling quite quickly in the complexity of it, even with only a handfull of clusters/environemnts and applications, I have become to strongly dislike the various "yaml abstraction layers" like kustomize or things like jsonnet etc.

Ah if used in the context of an IDP I can see how that makes sense, was going to mention that having feature developers author these wouldn't necessarily make sense, but if it's config-driven/UI-powered I could see the advantages for sure. Thanks the the insight!

@Serge van Ginderachter Convo years ago: Newbie: I don’t know why everyone hates syntax. I love syntax!! Old Bat (me): How many OSs do you work on on a daily basis? Newbie: Well, one. Old Bat: Well, I work on five on a daily basis and you know what? I really hate syntax because they are all just a bit off from each other. (still true)

Yeah, it depends on the level of abstraction you're looking for, other requirements you may have like packaging and ofc. experience in the team to maintain the setup. We have a product that's also offered for on-premise installations, so we built a helm chart for it to ensure that on-premise installations are done similarly to our own SaaS version, as much as possible. We then use ArgoCD facilitate the helm chart installation. Also the "base plumbing" for all our clusters comes from an "app of apps", i.e. 1 helm chart that creates multiple ArgoCD apps that each manage a specific helm chart, e.g. storage controllers, load balancer controller, external DNS, etc. For us this works conveniently so far. As we've already been using Terraform for years, also to build managed k8s clusters, we don't really have the need to start managing e.g. databases via Kubernetes, that seems a bit "indirect" (i.e. unnecessary adding moving parts to the mix). Terraform syntax isn't super awesome, but most of our reasoning is at a slightly higher abstraction level anyway, so actually there's not much difference in preparing or staring at code that creates a database instance in terraform or, say, python (with cdk8s), since both wrap tightly around the cloud provider's api. In both cases you can make code reusable or combine multiple resources. But admittedly, if we'd start greenfield today, cdk8s might be a fair option.