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.
That's a fair remark. I think the biggest scale I've operated at was maybe a few million customers, consumer and business, for Flight Centre, which is a travel agent that serves pretty much the entire of Australia and overseas too. A few big banks too. None of them used K8s at the time and operated fine. Might have drank the kool aide by now, though.
I think scale has less to do with how many customers you're serving and more to do with how much data you're processing. Streaming video to 10,000 people is much more data-intensive than exposing a CRUD interface to 1M.
Also k8s is not, in and of itself, a complication. You're going to have to worry about the same set of problems whether or not you use k8s. Deployments, load-balancing, self-healing, etc. It's not like ops teams didn't do anything before k8s came along.
Not necessarily true, the complication that k8s brings isn't the same that other implementations bring. More moving parts in a highly pluggable architecture brings with it more opinions and optimisations and overhead. Also managed services exist which means several specific issues don't exist. The ops teams simply do something else.
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.
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.