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.
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.
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.
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.