Our GitOps repository needed Go templates, Kustomize overlays, CUE schemas, and Python scripts just to make configuration changes reasonably safe. Even then, removing a redundant override could briefly trigger a downgrade. We decided to rethink how we assembled our Argo CD applications, using KCL to generate and validate their definitions before they reached the cluster. In this post, I walk through the component model we built, how it changed our review workflow, and where the additional machinery earns its keep.

Over the last couple of months, I have been more involved in contributing to open source again. Helping maintainers improve their products is such a rewarding and eye-opening experience. It is an opportunity to learn how others solve complex problems and work on projects that tend to be significantly more mature than most enterprise software regarding engineering practices and automation.

I was quite hyped when assigned a task to implement a small feature with actual end-user impact. It was nothing fancy: essentially, adding a flag to a CLI command to slightly modify user-facing behavior.

Author’s Note: I have contributed to the KCL project and have run thousands of KCL programs while exploring the language and executing its test suite. These insights and benchmarks come from hands‑on experience. While I currently do not use KCL in production, I've focused on solving real platform engineering challenges with it.

The Pain of YAML Sprawl

As teams adopt Kubernetes and GitOps, they wrestle with thousands of YAML files. YAML is human‑readable but offers no abstraction, so companies build their own templating and validation tools, leading to fragile, hard‑to‑validate manifests that drift over time.

The result? A monolithic repo full of brittle YAML that breaks at deployment. Teams use Helm, Kustomize, or custom Python scripts, but validation still happens at runtime, creating a painful "write → validate → deploy" cycle. When was the last time you updated a Helm values file to realise after deployment that the change has no effect because you have a typo in the YAML structure and Helm silently ignored the entire thing? Or even better: you created a Kustomize patch that lead to an invalid Kubernetes resource definition, leading to a ArgoCD sync failure?

I have seen this firsthand on a project. We use Go templating in ArgoCD ApplicationSets with dig expressions for lookups and default values. However, as our platform definition is pure YAML, we felt the need to introduce CUE for schema validation and custom Python scripts to ensure dig expressions resolve. At this point, we are using more than three complex technologies just create abstractions in a relatively safe manner.

KCL tackles this head‑on. It "compiles" KCL source files into plain YAML. While doing so, it validates schemas, enforces constraints, and guarantees correct abstraction usage.

This article was originally posted on InfoQ.

Digital sovereignty isn't about building everything yourself; it's about having a valid "Plan B". What would your "Plan B" be if your vendor for a critical system suddenly decided to quadruple its price tag or if it decided to abandon product development and suddenly communicated a product "end-of-life" deadline? How would you feel if your government were utterly reliant on another geopolitical entity in order to sustain basic (digital) operations? What if your access to a SaaS provider were suddenly revoked due to international sanctions?

In this article I will dive into three aspects of digital sovereignty and illustrate how architectural choices and constraints can help address the scenarios described above. I will share some insights into the benefits and risks of building "sovereign systems", and illustrate high-level examples why this architectural choice might be more challenging than most people expect. As a software architect working for various large enterprises, I share insights into open standards as one of the main pillars to achieve sovereignty. It should, however, be noted that sovereignty is a much larger topic overall.

Over the past few months I have invested some time to contribute to an open source project I find fascinating: wasmCloud. As a platform engineer and architect, I am very familiar with how software platforms are typically built in practice. However, with the ubiquity of Kubernetes, you run the risk to being stuck in the "doing it the Kubernetes way" line of thinking. But then again, are there any better ways? This is where wasmCloud caught my attention. A modern platform building on proven concepts from Kubernetes, but with some significant differences. In this article I want to introduce wasmCloud, how it compares to Kubernetes, what its internal architecture looks like, and what ideas are, in my humble opinion, a step up from "the Kubernetes way of things".