Learn Ansible - History, Background & Why You Need Ansible

#Introduction

After episode 0, where we discussed and prepared all the prerequisites — from Linux CLI, SSH, and YAML skills to installing Ansible on the Control Node — in this episode we will take a break from the hands-on work and dive into why Ansible exists. We will trace its history, understand the real problems that triggered its creation, and see why Ansible has become one of the most popular tools in the DevOps and SRE world.

Why is understanding the history and background important? As an engineer, you don't only need to know how to operate a tool, but also why that tool was designed a certain way. This understanding will guide you in making architectural decisions in the real world: when to use Ansible, when to use Terraform, when to write plain shell scripts, and when all three should work together. Without this context, you will only become a tool operator — not an infrastructure engineer.

#The Evolution of Automation: From Manual Scripts to Infrastructure as Code

To understand Ansible, we have to look at the long journey of how humans managed servers throughout the ages.

#Era 1: Manual Setup (One by One)

Before the automation era, managing servers meant logging in one by one via SSH and typing commands manually. Want to install nginx on 5 servers? Log in to server 1, install, log in to server 2, install, and so on. Not to mention the configuration drift problem — the condition where each server "drifts" from its ideal state because commands are typed manually and forgotten to be recorded. Server 1 might have nginx version 1.2 installed, while server 3 is still on version 1.0 because someone forgot to update it.

The main problem is clear: an undocumented process cannot be reproduced, cannot be audited, and cannot be scaled. A single server can still be handled, but what about 50 servers, 500 servers, or thousands of servers?

#Era 2: Shell Scripting & SSH Loop

The next logical step was partial automation using shell scripts. Instead of typing manually, we write a bash script and run it on many servers with an SSH loop.

#!/bin/bash
# install_nginx.sh - the painful old approach
SERVERS=("10.0.0.11" "10.0.0.12" "10.0.0.13")
 
for server in "${SERVERS[@]}"; do
    echo "=== Processing $server ==="
    ssh devops@"$server" "sudo apt update && sudo apt install -y nginx"
    if [ $? -eq 0 ]; then
        echo "OK: $server"
    else
        echo "FAILED: $server" >> errors.log
    fi
done

At first glance this approach seems to work. But let's break down its weaknesses, because it is precisely from these weaknesses that Ansible was born:

1. Not idempotent: running the script twice will install nginx twice (or even error out). We have no way to declare "make sure nginx is installed" declaratively.
2. No state tracking: the script doesn't know the server's current state, whether a package already exists, or whether a service is already running.
3. Manual error handling: we have to write if [ $? -eq 0 ] at every step. The longer the script, the more fragile it gets.
4. Messy and hard to review: long shell scripts are imperative code — hard to read, hard for others to review, and hard to test.
5. No portability abstraction: the apt command on Ubuntu differs from dnf on Rocky Linux. The script has to branch out for each distro.

#Era 3: Infrastructure as Code (IaC) & Configuration Management

Out of that frustration was born the Infrastructure as Code (IaC) paradigm — treating infrastructure configuration as code that can be versioned in Git, reviewed, tested, and re-applied consistently. One of its manifestations is the Configuration Management (CM) tool: software that describes the desired state of a server, then ensures the server always stays in that state.

It was in this era that a generation of tools appeared: CFEngine (1993), Puppet (2005), Chef (2009), SaltStack (2011), and then Ansible (2012). Each offered an answer to the same problem, but with different architectural philosophies — and this is where Ansible found its differentiator.

#Ansible's History: Michael DeHaan and a Different Approach

Ansible was created by Michael DeHaan in 2012. Before Ansible, DeHaan was the creator of Cobbler — a Linux provisioning automation tool — and had worked at Red Hat. His experience managing many servers and seeing how complicated the existing agent-based solutions were led him to a simple yet revolutionary question:

"Why do we have to install a daemon/agent on every server just to manage its configuration? Why can't we simply use the SSH that's already there?"

From that question, Ansible was born with an agentless architecture. In 2015, Ansible was officially acquired by Red Hat, which then developed it into the Ansible Automation Platform (AAP) product. Red Hat's presence brought enterprise weight: official support, certifications, a vast Collection ecosystem, and even a web interface (AWX/Tower) for large-scale organizations.

#Why Choose Ansible?

Now that we understand its history, let's discuss why Ansible has won the hearts of so many engineers. There are three main pillars that set it apart.

#1. Agentless: Just SSH + Python

This concept is Ansible's biggest differentiator. Tools like Puppet and Chef require you to install an agent (daemon) on every managed server. That agent runs continuously, communicates with a master server, and becomes part of the system that must be maintained, updated, and monitored.

Ansible works the opposite way: no agent, no daemon, no extra ports opened. Ansible simply uses SSH (or other already-existing protocols) to get into the server, execute commands, and leave.

The practical implications are huge:

• Easy to get started: nothing to install on the managed node. Every new server just needs Python 3 and an SSH server.
• Smaller security footprint: no extra processes running, no extra ports for the firewall to open, no secrets stored on the target.
• Less to maintain: no agent that needs periodic upgrades across thousands of servers.

#2. Idempotency: The Same Result, No Matter How Many Times You Run It

Idempotency is the property where an operation executed repeatedly produces the same end result without additional side effects. It's a mathematical concept that became a core principle of Configuration Management.

Let's compare it with a plain shell script:

useradd devops

Run it once → succeeds. Run it twice → error user 'devops' already exists. An imperative script doesn't know the server's state; it just executes commands blindly.

Now compare that with how Ansible does it:

- name: Pastikan user devops ada
  ansible.builtin.user:
    name: devops
    state: present

Ansible's user module checks the server's state first. If the user already exists, the module reports ok and does nothing. If it doesn't exist yet, the module creates it and reports changed. The end result is always the same: the devops user exists on the server.

This idempotency is what solves the configuration drift problem we discussed at the beginning. Run the playbook in the morning, at night, or after a server rollback — the result is always consistent with the desired state we wrote.

#3. Human-Readable Declarative YAML

Try comparing the two ways of describing "install nginx" below:

sudo apt update
sudo apt install -y nginx
sudo systemctl enable nginx
sudo systemctl start nginx

- name: Pastikan nginx terinstall dan berjalan
  ansible.builtin.apt:
    name: nginx
    state: present
  ansible.builtin.service:
    name: nginx
    state: started
    enabled: true

YAML describes what we want to achieve (desired state), not how to do it (step-by-step procedure). The consequences:

• Easy for non-programmers to read: technical stakeholders, juniors, and even auditors can understand what is being configured.
• Easy to review in pull requests: configuration diffs become clear and meaningful.
• Easy to collaborate: YAML reduces the "sacredness" of code — anyone can contribute to the infrastructure repository.

#Comparison with Other Tools

So that you can position Ansible correctly, let's compare it with similar tools in the automation ecosystem.

#Ansible vs Puppet/Chef: Agentless vs Agent-Based

The choice between agentless and agent-based is a fundamental architectural decision:

• Agentless (Ansible): easier to adopt, no extra daemon, great for ever-changing environments (ephemeral cloud instances, containers) and for pushing configuration on demand.
• Agent-based (Puppet/Chef): the agent runs continuously and can periodically pull configuration from the master, forming a self-healing system — if something drifts, the agent automatically fixes it. Best for very large static environments that need continuous compliance.

#Ansible vs Terraform: Config Management vs Provisioning

This is a difference you must hold on to firmly:

• Terraform: manages the infrastructure lifecycle — creating, modifying, and deleting cloud resources (VPC, EC2, RDS, etc.). It focuses on infrastructure provisioning and maintaining infrastructure state.
• Ansible: works on top of existing infrastructure — installing packages, copying configuration, managing services, deploying applications. It focuses on configuration management and application deployment.

The analogy: Terraform is the contractor who builds the house (structure, walls, ceiling), while Ansible is the interior decorator who fills the house (furniture, lights, decorations). Both are needed to produce a livable home.

#A Real Example: The Manual Script Problem vs the Ansible Solution

Let's close with a concrete case study showing why Ansible wins. The scenario: we have 3 web servers that must always have nginx, curl, and htop installed.

With the SSH loop approach, every time there's a new server we have to run a script, monitor the output, and hope nothing errors halfway through. Now with Ansible, we just write a playbook once:

---
- name: Konfigurasi dasar web server
  hosts: webservers
  become: true
  tasks:
    - name: Update apt cache
      ansible.builtin.apt:
        update_cache: true
 
    - name: Install package wajib
      ansible.builtin.apt:
        name: "{{ item }}"
        state: present
      loop:
        - nginx
        - curl
        - htop

Then run it against all servers at once:

ansible-playbook -i inventory.ini webserver.yml

PLAY RECAP *********************************************************************
10.0.0.11 : ok=4    changed=3    unreachable=0    failed=0    skipped=0
10.0.0.12 : ok=4    changed=3    unreachable=0    failed=0    skipped=0
10.0.0.13 : ok=4    changed=3    unreachable=0    failed=0    skipped=0

Notice a few things that changed drastically compared to the manual script:

1. One file for all servers — no need for a manual loop; Ansible handles parallelism.
2. Structured results — every task reports its status (ok/changed/failed), making auditing easy.
3. Idempotent — run the same playbook again and all tasks become ok with no changes (changed=0).
4. Part of the codebase — this file can go into Git, be reviewed, tested, and rolled back.

This is the essence of the paradigm shift from imperative scripting to declarative automation that Ansible brings.

#Conclusion

In episode 1 we traced the journey from manual server management, through painful shell scripting, to the birth of the Infrastructure as Code and Configuration Management paradigms. We also understood why Ansible — with its agentless philosophy, idempotency, and declarative YAML — has become such a popular choice since Michael DeHaan created it in 2012, up to today under Red Hat.

Key takeaways from this episode:

• The main problems of pre-Ansible automation were drift, non-idempotency, and scripts that weren't easy to review.
• Ansible chose agentless: just SSH + Python on the target, no extra daemons.
• Idempotency guarantees consistent execution results no matter how many times you run it.
• Declarative YAML describes the desired state, not a step-by-step procedure.
• Ansible fills the configuration management & deployment space, while Terraform fills infrastructure provisioning — the two are complementary.

In episode 2, we will go deeper into Ansible's internals: core concepts and main architecture. We will dissect how Ansible actually works behind the scenes, from the Control Node and Managed Nodes, to module execution flow over SSH, to key components like Inventory, Playbook, Tasks, Modules, and ansible.cfg. Keep your enthusiasm up, because starting next episode we will be touching real command lines and configuration files more and more! 😄