Network Automation 101: Your Journey Starts with Ansible
Part 1: Ansible Guide for Network Engineers
The Problem: Manual Configuration Management (sys-admin vs net-engineer)
In the early days, System administrators worked separately from the developers and users who used the systems. They had to do everything by hand: installing software, adjusting settings, and managing services on each server one at a time. This way of working was slow and didn’t work well as things grew.
As data centers got bigger and applications became more complicated, Server virtualization changed everything. Suddenly, administrators were expected to manage ten times more servers than before. Instead of handling each server individually, they needed ways to bring up new servers quickly with minimal effort.
From Sys-admin Perspective
Imagine you're a system administrator at a medium-sized company. Your virtualization platform or datacenter team handles the physical hardware and creates virtual machines, but you're responsible for everything that happens after the base operating system is installed.
Your day typically starts with a queue of tickets: requests for software installations, configuration changes, and troubleshooting. For each new server, even after it's provisioned with a basic OS, you still face hours of manual work:
Installing specific versions of packages and their dependencies
Editing dozens of configuration files with environment-specific settings
Creating user accounts with appropriate permissions
Setting up monitoring agents and backup clients
Configuring security policies and firewall rules
Applying the latest security patches
This manual approach to configuration created several specific challenges:
Configuration inconsistency became a constant headache: Despite your best efforts to follow documentation, tiny differences inevitably appeared between servers. One application server might have a slightly different Java version than another, or a slightly modified Apache configuration. These differences led to "works on server 1 but not server 2" problems that were difficult to troubleshoot.
Documentation quickly became outdated: You might carefully document the 27 steps needed to configure a database server, but when an emergency arose and pressure mounted, someone might skip step 18, or apply a quick fix without updating the documentation. Over time, the actual server state and the documented configuration would drift apart.
Knowledge silos threatened business continuity: When you configured a specialized application server following undocumented tribal knowledge, that information lived only in your head. If you were unavailable during an outage, recovery could be significantly delayed.
Security compliance became increasingly difficult: Every time a security audit occurred, you'd spend weeks manually verifying configurations across hundreds of servers, often finding inconsistencies that needed immediate remediation.
Mass updates became a nightmare.: When a critical OpenSSL vulnerability was announced, you faced the daunting task of updating thousands of servers within days something simply not possible through manual methods. You'd work 20-hour days and still fall behind.
Development environments multiplied: Developers now requested complete multi-server environments for testing, requiring you to configure identical sets of servers repeatedly. Each configuration needed to match production exactly to be useful.
Configuration drift accelerated: With more servers being managed by the same number of admins, keeping track of which servers had which configurations became practically impossible. Servers that started identical would gradually become unique snowflakes through ad-hoc changes and emergency fixes.
From Network Engineers Perspective
Meanwhile, network engineers faced their own version of configuration issues, in the same company, managing a big corporate network. Instead of servers, your world revolves around routers, switches, and firewalls. Your days are spent:
Manually SSH-ing into hundreds of devices to configure VLANs, ACLs, or routing/switching protocols.
Making configuration changes through the CLI, device by device
Maintaining different command syntaxes for different vendors (Cisco, Juniper, HP)
Managing firmware upgrades across hundreds of switches and routers
Documenting configurations in spreadsheets that no one updates.
A network engineer supporting a campus network with 200 switches would spend days implementing a new VLAN across the network, manually connecting to each device, entering the same commands with slight variations, and documenting each change.
Sound familiar? The pain mirrors sysadmins’ struggles, but with networking twists:
Inconsistency: A typo in a VLAN ID on one switch could break the entire network segment.
Knowledge silos: Only you knew the magic bug to fix that legacy Cisco 2960’s spanning-tree loop.
Scaling nightmares: Adding 50 new switches for a branch office? That’s 50 CLI sessions, 50 config files, and 50 chances to fail.
Disaster recovery: A failed core switch meant rebuilding its 100-line config from memory at 3 AM.
Common Pain Points: System and Network Configuration
system administrators and network engineers faced nearly identical challenges, despite working on different infrastructure:
Shared Pain Points
Human Error: One typo = hours of troubleshooting.
Inconsistency: No two devices/servers stayed identical.
Scale Limits: Managing 10 devices manually worked. 100? Impossible.
Knowledge Silos: Tribal knowledge = business risk.
Compliance Chaos: Audits required weeks of manual checks.
Early Automation: Cheff & Puppet
Before Ansible emerged in 2012, Chef and Puppet were revolutionary tools that transformed how system administrators managed servers. These tools arrived when data centers were growing rapidly and manual configuration was becoming impossible to scale.
For System Administrators:
Chef, or Progress Chef, is a configuration management tool that effectively manages your infrastructure. The Chef allows you to use Ruby to create system configurations, which are called recipes, describing the optimal state of your infrastructure, such as which server should be running what service, what software should be installed, what files should be written, and so on. With these configurations, Chef will ensure your infrastructure is configured correctly and automatically fix any resources not running at the optimal state.
Puppet is another popular server configuration management tool allowing you to configure and monitor many servers at the same time. It uses its own declarative language for describing system configurations.
Chef and Puppet allowed administrators to version control their infrastructure configurations, track changes over time, and roll back problematic updates. They also enabled consistent server setups - a server configured through automation would be identical every time, eliminating the "works on my machine" problem.
Perhaps most importantly, these tools allowed administrators to manage hundreds or thousands of servers efficiently, something that would have been impossible manually.
Puppet works on a client-server model. A central server (Puppet Master) stores all the configuration rules. Client machines (Servers) run Puppet agents that regularly check in with the master to get their configurations. Puppet uses its own declarative language to define how systems should be configured.
Chef also follows a client-server architecture. It stores "recipes" written in Ruby on a central server. These recipes describe exactly how systems should be configured. Chef clients regularly download and apply these recipes. Chef relies heavily on Ruby for writing configurations.
Key Issues with Chef and Puppet
Agents Everywhere: Required installing Puppet/Chef software on every serve fine for Linux/Windows, but impossible for network gear.
Steep Learning Curve: Puppet’s custom DSL and Chef’s Ruby recipes felt like learning a new programming language.
Server-Centric Blindspots: No concept of routers, switches, or firewalls. Network automation? “Not our problem.
For Network Engineers: Limited Automation Options
While system administrators were making strides with tools like Puppet and Chef, network engineers faced a much more limited set of options. The landscape for network automation was fragmented and immature:
Vendor-Specific Tools: Each networking vendor offered their own management platforms that only worked with their equipment. Cisco had tools that only worked with Cisco devices, Juniper had tools that only worked with Juniper devices, and so on. This created siloed automation that couldn't span a multi-vendor environment.
Homegrown Scripts: Many organizations relied on custom scripts written in Expect, Perl, or shell scripts to automate repetitive tasks. These scripts were often fragile, poorly documented, and maintained by a single engineer. When that engineer left the organization, the scripts often became unusable.
Expensive Commercial Solutions: Enterprise-grade network management platforms existed but were prohibitively expensive for many organizations and often had limited flexibility to adapt to unique environments.
These barriers meant that even if organizations partially automated their server infrastructure often left their network infrastructure managed through traditional manual processes.
The Stage Set for Ansible
In 2012, Michael DeHaan, who previously worked on tools like Cobbler at Red Hat, created Ansible with a radical approach: what if we could have powerful automation without all the complexity? DeHaan founded Ansible, Inc. with a clear vision of making automation accessible to everyone, not just specialized teams.
This fragmented landscape helps explain why Ansible had such a profound impact when it arrived in 2012. Ansible addressed many of these fundamental limitations:
Agentless Architecture: Using existing SSH infrastructure meant no new security concerns
YAML-Based: Writing automation in YAML made it readable even for non-programmers
Push-Based Model: Instead of agents polling for changes, control nodes push changes when needed
Idempotency: Running the same playbook multiple times produces the same result
These unmet needs created the perfect environment for Ansible's emergence. With its agentless architecture, simple YAML syntax, and push-based model, Ansible would address many of the limitations of first-generation automation tools. Most importantly, it would begin to bridge the gap between server and network automation, bringing these traditionally separate domains under a common framework.
The transition wasn't immediate, early network support in Ansible was limited, but the foundation was there for a unified approach to automation that would finally bridge the gap between different infrastructure domains and different vendors' equipment.
This historical context is crucial for understanding why Ansible's approach was so revolutionary. It wasn't just an incremental improvement on existing tools; it represented a fundamentally different philosophy toward automation that would gradually transform how network infrastructure was managed.
Final Thoughts
The arrival of Ansible in 2012 marked a turning point for network automation. For the first time, network engineers had access to a tool that offered the simplicity and flexibility needed to automate multi-vendor environments without requiring specialized programming knowledge.
Today in 2025, Ansible has become the de facto standard for network automation across a wide range of organizations. Its ecosystem has expanded to include modules for virtually every major networking vendor, and its capabilities have grown far beyond basic configuration management.
But perhaps most importantly, Ansible has helped break down the traditional silos between networking and other infrastructure teams. The same tool that manages your servers can now manage your network devices, enabling truly integrated automation workflows that were impossible a decade ago.
As networks continue to evolve toward software-defined approaches, the skills you develop with Ansible today will remain relevant and valuable. Whether you're automating traditional CLI-based devices or working with modern API-driven platforms, the fundamental principles of Configuration as code that Ansible embodies will serve you well.
In my upcoming posts, we'll take a closer look at how Ansible works under the hood and set up a basic environment for network automation. Until then, I encourage you to explore the Ansible documentation and consider what repetitive network tasks in your environment might benefit from automation.