The problem Ansible solves
Summary: when a team goes from 5 to 500 servers, manual management collapses. Every manual intervention introduces a divergence — one server with an extra file, another with a different version. After six months, no server is identical to any other anymore. Ansible was created in 2012 to solve this problem, called configuration drift.
1. The nightmare that grows with the number of servers
Look at what happens in a typical company as the number of servers increases.
1.1 · Stage 1 · A single server
No problem at this stage. A human being can connect via SSH, type 30 commands, check that everything works. It is craftsman's work.
1.2 · Stage 2 · Ten servers
The company grows. Now ten identical servers must be configured to support the load.
It starts to hurt. A full day devoted to repeating the same 30 commands. Fatigue increases mistakes. Two servers out of ten are already no longer rigorously identical to the others.
1.3 · Stage 3 · One hundred servers
Success strikes. The infrastructure must now contain one hundred servers.
At one hundred servers, manual management stops being an option. No human is capable of maintaining consistency across 100 machines. The company must automate, otherwise its infrastructure turns into a minefield.
1.4 · Stage 4 · A thousand servers and more
At the scale of a Facebook, a Netflix, an Amazon, we are talking about tens to hundreds of thousands of servers. The question is no longer even "should we automate" but "how do we keep the system running".
2. Configuration drift — the silent scourge
The worst problem is not the time consumed. It is configuration drift.
This is not a caricature. Every team that has managed servers manually for more than 6 months has lived through this scenario. The most horrible bugs to debug are those that appear only on certain servers, without anyone understanding why.
Configuration drift costs:
- Hours of investigation on production incidents.
- Weeks of delay on projects, when everything must be re-verified before each production release.
- Security holes — a patch applied to 90% of the servers leaves 10% vulnerable.
- Fear of touching anything — nobody dares to modify the existing setup anymore.
3. The attempted solutions before Ansible
The problem was well known, and the community had tried several approaches — each bringing progress but none was really satisfying.
The cultural turning point: Puppet and Chef paved the way for Infrastructure as Code — describing the infrastructure in versioned code rather than by hand. But their learning curve put off system administrators, who were not necessarily developers.
What was missing was a tool that was easy to pick up, fast to deploy, and above all without an agent to install everywhere.
4. February 2012: the birth of Ansible
In February 2012, Michael DeHaan, an engineer who had already worked at Red Hat and created the Cobbler project, publishes a small Python tool on GitHub. He calls it Ansible — a word taken from science fiction, designating an instant communication device across distances in the novels of Ursula K. Le Guin.
Three radical choices, going against the grain of Puppet and Chef:
Success is immediate. Within three years, Ansible overtakes Puppet in GitHub popularity. In October 2015, Red Hat buys Ansible for 150 million dollars. In 2026, Ansible is the most used configuration management tool in the world.
5. What Ansible made possible
In 13 years, this small Python tool changed the way infrastructure is operated.
In 2026, without Ansible or an equivalent (Puppet, Chef, SaltStack, or more recently: Terraform + cloud-init), a team managing more than 20 servers falls structurally behind its competitors.
Remember in 30 seconds
- Manual server management collapses beyond 10 to 20 machines.
- Configuration drift is the silent scourge that kills manually managed infrastructures.
- Before 2012, Puppet and Chef existed, but their learning curve remained steep.
- Ansible (February 2012) brings three key innovations: agentless, YAML, idempotence.
- Red Hat bought Ansible in 2015 for 150 million dollars — a sign of its strategic value.