You don't just want to run a process. You probably want to run several, across several different machines, such that they'll scale automatically in response to load, restart if they become unhealthy, load balance, failover across hardware, and admit zero-downtime deployments. You may want to do all of this across several parallel clusters with different configurations (staging, production, production-europe, etc).

You also want to worry about all of the above as little as possible, which is why an abstraction like holos could be useful. I've been hoping to see an ergonomic application of CUE to k8s manifests for a while now.

My guess is you haven't been at the scale where it starts to make sense. If you always approach these tools with the mindset of running a single process on a server somewhere, they are always going to appear as over complicating things. It's not a fair comparison.

Could you clarify what process you're speaking of as the end goal?

Holos is designed to produce configuration for Kubernetes. That configuration can be as small as a 10 line yaml file, but in larger operations it often ends up being multiple millions of lines of yaml spread over multiple clusters across the globe.

Once Holos produces the configuration, we stop. We leave it up to you to decide what to do next with it. For example we pass it to ArgoCD to deploy, others pass it to Flux. In development I pass it directly to kubectl apply.