Ansible seems to have a clear advantage over competition like chef and puppet because it is agent-less and saves a certain degree of overhead.
I have read several comparisons of the various configuration tools and while each tool has its own strengths and weaknesses, I realize that much of it is down to personal preference.
The benefit of being agent-less is a no-brainer but are there any advantages of the master/agent architecture with respect to configuration management tools?
I've found an interesting discussion on the topic configuration management pull vs push topology
One contributor writes that pull systems (master/agent) offer more flexibility and are easier to scale.
IMHO the only advantage of a master/agent pull architecture is that it can be used in a firewalled network (when the actual configuration is located outside that network) without opening up holes in the firewall, while the push architecture cannot.
In terms of flexibility, I think the most important issue is the minimal setup required on a node to become remotely manageable. Once this requirement is met both architectures can handle updates. A master/agent architecture needs the agent installed, configured and running. On one hand Puppet and Chef aren't (yet) by default installed on most systems, while sshd (needed by Ansible) is. On the other hand even Ansible needs sshd running and credentials configured on the node to be accessible, so I'd say there's not much of a difference from this perspective - especially if the minimal setup is achieved via customized system images.
In terms of scalability, I'd consider the master/agent architecture less scalable (but just a bit):
if the master attempts to actively keep a live system state (i.e. the map of all the agents and their states) that would chew up some time/resources. Without a master, Ansible isn't susceptible to such scalability issue. Granted, even master/agent architectures can offer a scalable approach to providing an overall system state similar to Ansible's (and probably they all do nowadays).
in the old days, when the master would actually drive the agent configuration tasks (as mentioned in the post you referenced in your answer), the scalability of such architecture could suffer a lot. But this is not a big deal anymore since for all the tools mentioned in your question the configuration is just transferred to the local node which then performs the tasks.
when it comes to transferring the configs to the local nodes, a pull architecture is limited only by the capacity of serving those configurations (common to both architectures), but a master/agent one needs to also run the logic driving transfers and actually making the transfers, if applicable (it's possible to just instruct the agents to pull their own configs), which limits how fast the master can propagate configs to a large number of agents.
IMHO, the idea of having an agent or master or both boils down to this:
A mechanism to continuously manage states of the nodes.
If such a tool allows this, then "self-healing" capability is the obvious benefits.
In the case of Ansible, as far as I'm concerned, there are no built-in a mechanisms to provide the self-healing capabilities (because no daemons are running continuously to fetch the states and to react to them.)
That said, self-healing doesn't sound like the problem a configuration management tool should solve so maybe it's not something one might consider "advantage" of other tools against Ansible.
