[revel]

In my opinion kubernetes is fundamentally hamstrung by the overly simplistic operator model. I really like the general idea, but it's not really possible to reduce the entire model down to "current state, desired state, next action." It means that an entire workflow ends up in the next action logic, but with so many operators looking at the same system state it's not really possible to know how the various components will interact. The problems with helm are a subcase of this larger issue.

By analogy, this is the same issue as frontend programming faces with the DOM. Introducing a VDOM / reducer paradigm (like react) would go a long way towards solving these problems.

[ants_everywhere]

> it's not really possible to reduce the entire model down to "current state, desired state, next action."

This is basically how control theory works in general though. You have a state, a goal, and a perturbation toward the goal. I think this is the right level of abstraction if you want a powerful and flexible tool.

> it's not really possible to know how the various components will interact....Introducing a VDOM / reducer paradigm (like react) would go a long way towards solving these problems.

I think the problem here is that the physical characteristics and layouts of the machines makes such a huge difference that it would be prohibitively costly to virtualize or simulate this in a meaningful way. So instead, people use subsets of the physical structure to verify that configuration states work. You do this by having `dev`, `staging`, `prod` environments, using colored deployments, canary analysis, partial rollouts etc.

[lucianbr]

> I think this is the right level of abstraction if you want a powerful and flexible tool.

This says nothing about ease of use. And for software development, ease of use matters. Otherwise we would all use assembler, or at most C++. They're very powerful and flexible.

If anything, too much power and flexibility is a problem.