He left out Cfengine. That's a big gap. It's been around since 1993. He also focused on package management and the provisioning process. I feel like there is more to automation than that. Continuous deployment, process management and distributed scheduling come to mind. As a plus, he does seem to get that just using system images (like Amazon AMI's) can be pretty limited.
I think the complexity of automation is more a symptom of the problem space than the tools. It's just a hairy problem. Computer Science seems to largely focus on the single system. Managing "n" systems requires additional scaffolding for mutual authentication and doing file copies between different systems. It also requires the use of directory services (DNS, LDAP, etc…)
I like the analogy of comparing the guitar player to a symphony orchestra. When you play the guitar alone, it's easy to improvise, because you don't need to communicate your intent to the players around you. When a symphony does a performance, there is a lot of coordination that needs to be done. Improvisation is much more difficult. That is where Domen is right on target, we can do better. Our symphony needs a better conductor.
He left out Cfengine for the same reason everyone who has used Puppet/Chef/Salt/Ansible leaves it out. Its utterly atrocious. Combining global booleans as a weird sort of declarative flow control to make up for the lack of explicit dependencies between objects that everything else has is horrific.
Thousands and thousands of these:
(debian_6|debian_7).(role_postgres|role_postgres_exception)::
And ordering? Nah, just run it 3 times in a row. :\
There is some truth to what you are saying, but this is just one way of writing a CFEngine policy, and a fairly confused one. CFEngine lets you abstract classes that makes things much more readable. Furthermore, you can create explicit ordering in CFEngine using the depends_on attribute, similar to Puppet.
As for the run 3 times in a row, this is an explicit design decision in CFEngine, because the state of the machine changes as you operate on it, so you cannot assume your plan remains valid during agent execution.
You can create atrocities in a lot of programming languages, and CFEngine is no exception to this rule. CFEngine is highly dynamic, but with great power comes responsibility.
>And ordering? Nah, just run it 3 times in a row. :\
I'll take a stab at this one too. I'll try another music analogy. I have a guitar with big frets. When I press the strings down too hard while playing chords, it causes the notes to bend out of tune. Playing in tune, requires a light touch.
Procedural programming is really familiar, even in the OO world where you attach these nouns to your verbs called "instances" of a "class". You call a procedure and it has a side effect or returns some kind of value. Familiar right?
Converging to a desired state is just different, because you focus on the outcome instead of the order of operation. If you get caught up on debugging the order of operation instead of the desired end state, it will take longer to troubleshoot a convergence failure.
In other words, loosen up your "procedural" grip on convergence. Playing in tune, takes a light touch ;)
It sounds like you've been using CFEngine 2. CFEngine 3 class (boolean) scope is limited to the bundle it's called from in the bundle sequence. The bundle sequence provides procedural flow control if you need that. Convergent programming does take some getting used to.
>He left out Cfengine for the same reason everyone who has used Puppet/Chef/Salt/Ansible leaves it out.
Actually, most people don't know it exists. Poll your average "devops" person and most will believe that chef or puppet created the concept of configuration management. Cfengine is less terrible than puppet and chef, but it is still not close to good enough.
Exactly. This is a deeper problem than commonly appreciated, and the cfengine author has written at length about that. http://markburgess.org/certainty.html
I think the complexity of automation is more a symptom of the problem space than the tools. It's just a hairy problem. Computer Science seems to largely focus on the single system. Managing "n" systems requires additional scaffolding for mutual authentication and doing file copies between different systems. It also requires the use of directory services (DNS, LDAP, etc…)
I like the analogy of comparing the guitar player to a symphony orchestra. When you play the guitar alone, it's easy to improvise, because you don't need to communicate your intent to the players around you. When a symphony does a performance, there is a lot of coordination that needs to be done. Improvisation is much more difficult. That is where Domen is right on target, we can do better. Our symphony needs a better conductor.