I'm not sure the analogy with types is at all helpful in explaining this. If I understand the author right, the critique is that Kubernetes wants to present a

I'm not sure the analogy with types is at all helpful in explaining this. If I understand the author right, the critique is that Kubernetes wants to present a unified, declarative model for arbitrary orchestration behavior. To do this, it uses controllers/operators/CRDs/etc, but the code within these controllers is often some of the imperativiest-imperativing stuff you've ever seen. This is "fine" for some core primitives, but as you demand more complex orchestrations out of k8s it's more likely you have to write these yourself, and it's messy and "hard", beyond what most teams can or want to invest, because of that. (Up to this point, I agree fully.) But then the "types" analogy comes to the fore, and we end up with a system that's even more complex, a kind of HKT for declarative behaviors. I'm not sure it really solves the implementation problems to begin with, but even if it does - I predict the teams struggling to implement custom operators are going to slam into this new wall even harder trying to model their operational processes like this. How long until we finally admit a lot of things an operator (human) does are imperative, and therefore the k8s "declarative only" model is fundamentally broken? What we need is more carefully-chosen imperative escape hatches, not more API options.