Table of Contents
A New Way To Run Networks
Traditional networks are often configured by hand, device by device. An engineer logs in to a router, types a series of commands, saves, and hopes everything is correct. This approach can work for a few devices, but quickly breaks down when networks grow, change frequently, or must be highly reliable.
Automation and Infrastructure as Code describe a different way to think about networks. Instead of treating each device as a unique snowflake, you treat the entire network as a system that can be described, versioned, tested, and deployed through software and repeatable processes.
From Manual Clicks To Repeatable Processes
In a manually managed network, almost everything depends on human memory and habit. Configuration snippets are often kept in personal notes, email threads, or copied from old devices. If a router fails, an engineer might scramble to remember how it was configured.
Automation starts by turning those human steps into repeatable procedures that a computer can follow. Typing the same 20 commands on 50 devices becomes a script that runs once and applies the change everywhere. Copying and pasting from a text file becomes a structured process that knows which device needs which settings.
The important shift is that the steps move out of an engineer’s short term memory and into code and tools that can be run repeatedly with the same result. This consistency is the foundation for more advanced practices such as Infrastructure as Code.
What “Infrastructure as Code” Really Means
Infrastructure as Code, often abbreviated as IaC, is the idea that you describe your infrastructure in a form that can be managed like software. Routers, switches, firewalls, and network policies are no longer only “inside the devices.” They are also expressed in files that can be stored, reviewed, and tracked.
At a high level, Infrastructure as Code has three key aspects. First, configuration is written down in a structured way, for example in text formats such as YAML or JSON, or in domain specific languages provided by tools. Second, these descriptions are treated as the single source of truth, which means the files describe the intended state of the network. Third, tools read these files and apply the desired state to the actual devices so that reality matches the description.
This approach changes the daily work of a network engineer. Instead of logging in and changing an ACL directly, the engineer updates a configuration file that defines that ACL. A tool then updates the devices. The devices become the result of the code, not the place where the configuration is invented.
Infrastructure as Code means the code and configuration files are the authoritative description of the network, not the individual device sessions or ad hoc changes.
Declarative Versus Imperative Thinking
Automation and Infrastructure as Code encourage a more declarative way of thinking. With an imperative approach, you describe how to perform each step. For example, an imperative script might say “connect to router A, enter interface configuration mode, set IP address X, then save.” The script is a long list of actions.
A declarative approach instead describes the desired end state. You might write that “interface on router A should have IP address X and be enabled.” A tool then figures out the exact steps needed to reach that state. This is closer to how humans think about designs: you focus on the design outcome, not on every keystroke needed to produce it.
Many Infrastructure as Code tools favor declarative descriptions because they make it easier to compare current and desired state, detect drift, and apply only the necessary changes. However, imperative scripts still play an important role for certain tasks, such as data collection or one time migrations.
Treating Network Config As Source Code
Once network behavior is described in files, those files can be handled with the same practices that software developers use. This is often called using “software development practices” in networking, but for beginners it is enough to understand the following ideas.
First, you store your configuration and automation code in a version control system. This is typically a Git repository. Each change becomes a commit, with a description, an author, and a timestamp. If a change introduces a problem, you can see exactly what was changed and when, and you can roll back to a previous version.
Second, you can use branches to work on experimental changes without touching the running network. When you are ready, you merge those changes back into the main branch after review. This makes collaboration and auditing far easier than sharing loose text files.
Third, version control creates a history of your network design. Over time, you can answer questions like “when did we open this port” or “who changed this routing policy” by simply browsing the history. This history is invaluable during troubleshooting and security investigations.
Idempotence And Predictable Outcomes
Automation in networking must be safe to run more than once. A script that accidentally adds duplicate entries every time it runs can quickly create chaos. A central concept that helps avoid this is idempotence.
Idempotence means that applying the same operation multiple times results in the same final state after the first application, without producing additional side effects. In the context of network automation, an idempotent playbook or configuration ensures that if you run it twice, the second run does not introduce new changes or errors.
An automation task is idempotent if running it once or many times leaves the network in the same correct state, with no unintended repeated effects.
Many Infrastructure as Code tools are designed to be idempotent by default. They compare the desired state with the current state and perform only the required changes. This reduces risk, since you can safely reapply configurations to ensure consistency, for example after device replacements or partial failures.
Detecting And Managing Configuration Drift
In an ideal Infrastructure as Code world, all changes go through the code and tools. In practice, people sometimes log in and make emergency changes directly on devices. Over time, this leads to configuration drift. The actual device configuration drifts away from what your files say it should be.
Drift is dangerous because it breaks the link between design and reality. The files in your repository no longer accurately describe what is running. Automation can then behave in surprising ways, or overwrite important hot fixes made under pressure.
Detection of drift typically involves comparing the running configuration on devices with the stored, intended configuration. Once drift is detected, you decide whether to adopt the device’s current state into your source of truth, or to reapply the intended configuration to bring the device back into line.
A mature automation and Infrastructure as Code practice acknowledges that drift will happen, but provides routine ways to detect it, understand it, and resolve it. This keeps the network predictable and reduces unpleasant surprises.
From Scripts To Pipelines
Many engineers begin automation with simple scripts, for example a Python script that logs into several switches to collect interface statistics. As Infrastructure as Code practices grow, these isolated scripts are often assembled into larger systems known as pipelines.
A pipeline is a sequence of automated stages that handle changes from start to finish. A typical sequence might start when a configuration file is modified. The change is then checked for syntax errors. Next, automated tests are run to validate the change against rules or simulated environments. If all checks pass, the change is scheduled for deployment to the production network.
Although the details depend on specific tools that are discussed elsewhere in this section, the main idea is that human action occurs at the design and approval stages, while repetitive checking and deployment are handled by machines. This reduces human error and shortens the time between design and implementation.
Benefits And Tradeoffs For Beginners
For someone new to networking, automation and Infrastructure as Code can feel like learning a second discipline: on top of networking concepts, you must also learn basic coding, text formats, and tools. It is useful to understand why this extra effort is worthwhile.
The primary benefit is consistency. When the same process is applied in the same way, you avoid subtle differences between devices that are hard to debug. Alongside consistency, you gain speed. Routine changes that once took hours of manual work can be completed in minutes with a reliable tool.
Another significant advantage is visibility. With configurations in version control, the network’s design is no longer hidden behind device logins. It is visible to the whole team, which improves collaboration and learning.
There are tradeoffs. Automation that is poorly understood or hastily written can spread mistakes quickly. An error that would affect one device in a manual workflow might affect dozens in an automated one. This is why practices such as review, testing, and gradual rollout are so important. They are not optional extras. They are essential safeguards.
How This Fits With The Rest Of The Course
Automation and Infrastructure as Code do not replace the need to understand routing, switching, IP addressing, or protocols. Instead, they build on those foundations. To automate a network safely, you must already understand what the network should do and why.
In the rest of this section, individual chapters introduce specific tools and approaches that help turn the principles described here into practical workflows. As you encounter those tools, it can help to keep the big picture in mind. The goal is always the same: describe the network clearly, store that description in a reliable place, and use automation to keep reality aligned with that description.