Agentless and idempotence: the two founding principles
Summary: two radical choices made Ansible succeed against its competitors. Agentless: nothing to install on the managed servers. Idempotence: running the same playbook several times always gives the same result. This lesson dissects these two principles and compares Ansible to Puppet, Chef and SaltStack to understand why they are strategic, not just technical.
1. Agentless — the principle that changed everything
Ansible is agentless: it installs nothing on the machines it drives. For many, this is the main reason for having chosen Ansible over its historical competitors.
1.1 · How Ansible connects
What is necessary on the target machine:
| OS or equipment | Ansible prerequisites |
|---|---|
| Linux, macOS, BSD | SSH enabled + Python 3 (already present on all modern distributions) |
| Windows Server | WinRM enabled (native feature) or SSH enabled |
| Cisco, Juniper, Arista equipment | Network API enabled (native) |
| AWS, GCP, Azure cloud APIs | Nothing at all — it is the cloud API that is queried |
No Ansible software resides on the targets. Ansible temporarily transfers Python code at each execution, runs it, retrieves the result, and erases it. No agent, no permanently running service, no updates to manage.
1.2 · Concrete benefits of the agentless model
Strategic point: these benefits are not just technical. They are political. A team proposing Ansible to its security department obtains the green light much more easily than a team proposing Puppet or Chef.
1.3 · The honest downside of agentless
Let us not hide the drawbacks — they exist.
In practice, these limits are largely offset by the benefits — hence the massive adoption. But they explain why some very large infrastructures keep Puppet or combine Ansible with other tools.
2. Idempotence — the scholarly word, the simple concept
Idempotence is a word that comes from mathematics and is intimidating at first. In reality, the concept is simple.
Definition: an operation is idempotent if executing it once or several times gives exactly the same result.
2.1 · A non-idempotent example (to avoid)
A traditional bash script installing nginx:
apt-get update
apt-get install -y nginx
useradd webadmin
What happens if you run this script twice?
- First
apt-get install: installs nginx. OK. - Second
apt-get install: nginx is already there. Small warning, but not serious. - First
useradd webadmin: creates the user. OK. - Second
useradd webadmin: error — the user already exists. The script stops.
This script is non-idempotent. It cannot be safely re-run.
2.2 · The same code in Ansible, idempotent by default
The equivalent Ansible playbook:
- name: Web server configuration
hosts: web
tasks:
- name: Install nginx
apt:
name: nginx
state: present
update_cache: true
- name: Create the webadmin user
user:
name: webadmin
state: present
What happens if you run this playbook three times?
This is idempotence in action. You describe the desired state ("nginx must be installed"), not the steps to get there ("execute apt install nginx"). Ansible takes care of comparing the current state to the desired state, and acts only if necessary.
2.3 · Why it is revolutionary
Idempotence fundamentally changes the way infrastructure is managed.
Compare with a classic bash script: every re-run becomes a game of Russian roulette. With Ansible, every re-run is a safe and predictable operation.
3. Push vs pull — the Ansible model compared to the others
There are two major models for propagating configuration to servers.
Advantages of push (Ansible):
- Immediate control — you launch and see the result right away.
- Zero agents to install and maintain.
- Simple to understand for a sysadmin.
Advantages of pull (Puppet, Chef):
- Scalable — a master server can drive tens of thousands of agents.
- Continuous self-correction — the agent applies the configuration every 30 minutes, even without any admin action.
- Resilient — a server that reboots automatically applies its config.
In 2026, Ansible's push model dominates for one-off configurations and application deployments. The pull model remains relevant in very large fleets and for automatic drift correction.
Some combine both: Ansible Pull also exists — each target server periodically downloads its own playbook from Git and applies it locally.
4. Ansible against its competitors in 2026
Comparison table of the major configuration management tools.
| Criterion | Ansible | Puppet | Chef | SaltStack |
|---|---|---|---|---|
| Release year | 2012 | 2005 | 2009 | 2011 |
| Model | Push (agentless) | Pull (with agent) | Pull (with agent) | Push and pull |
| Description language | YAML | Proprietary DSL | Ruby | YAML |
| Linux target prerequisites | SSH + Python | Puppet agent | Chef agent | Salt agent (optional in SSH mode) |
| Learning curve | Low | High | Very high | Medium |
| Windows support | Good (WinRM or SSH) | Good | Good | Good |
| Enterprise adoption | Very strong, growing | Historical, stable | Declining since 2020 | Niche, strong community |
| Main publisher | Red Hat / IBM | Perforce (acquired 2022) | Progress Software | VMware / Broadcom |
| Ideal use case | Versatile configuration, deployment | Large fleet with continuous self-correction | Ruby/dev-first environments | Fast event-driven automation |
2026 verdict:
- Ansible is the default choice for most teams getting started.
- Puppet still makes sense in historical large companies with a massive fleet.
- Chef has been declining since 2020 — its acquisition by Progress Software did not revive the momentum.
- SaltStack is in a niche position — powerful but with a smaller community.
5. The magic answer in interviews
Recruiter's question: "Why Ansible rather than Puppet?"
Good 3-sentence answer:
Ansible is agentless, which eliminates the maintenance of Puppet agents, reduces the attack surface and eases adoption in teams with security constraints. Its YAML syntax is very readable, which allows system administrators to write infrastructure as code without developer skills, unlike Puppet's DSL or Chef's Ruby. Finally, idempotence is native in all Ansible modules, which makes every execution safe and allows the same playbook to serve as living documentation and as an automatic drift corrector.
This answer demonstrates that you understand the foundations, not just the keywords.
Remember in 30 seconds
- Agentless: Ansible connects via SSH or WinRM, no agent is installed on the targets.
- Idempotence: running the same playbook several times gives the same result, without breaking anything.
- Push: the control machine initiates everything — no agent pulling like in Puppet and Chef.
- Ansible dominates Puppet, Chef and SaltStack in 2026 for modern projects.
- The two principles (agentless + idempotence) explain 90% of Ansible's success against its competitors.
Next: The Ansible ecosystem: Galaxy, AWX, Ansible vs Terraform →