In the very beginning…
Whether you are an administrator, an engineer, or an architect, the moment you are asked to automate the network, you are stepping into a new world. A world full of possibilities, but also challenges. The first question that often comes up is simple: where do I even start?
For an administrator dealing with tickets and day-to-day changes, the idea of automation can feel overwhelming. For an engineer, it might immediately become a question of tools and languages. For an architect, it’s about designing a system that can scale, adapt, and remain maintainable over time.
The beginning of an automation journey for an individual or for an organization is critical. It sets the tone for everything that follows. It’s where you lay the foundation, define the direction, and establish the mindset that will guide your efforts.
A perfect blueprint of failing an automation project is starting without direction. No clear understanding of the problem, no defined goals, and no real plan. It may feel productive at first, but over time the lack of clarity turns progress into complexity and control into confusion.
Which questions to ask?
Regardless of your role, the first question is always the same: why?
Starting to look at use cases first is a common instinct. It’s natural to want to jump into solving problems right away. But without a clear understanding of the underlying motivations, you risk building solutions that don’t actually address the real issues.
Several use cases where automation is needed:
- The workload is growing, and manual work is no longer sustainable.
- The risk of human error is increasing, and automation can help reduce it.
- The amount of time spent on projects is being consumed by operational overhead.
- An audit or compliance requirement is driving the need for more consistent and repeatable processes.
- Personnel shortages or skill gaps are making it difficult to keep up with demand.
- The network infrastructure needs to be integrated with other automation processes.
- Device lifecycle management is becoming more complex with multiple vendors.
The second question is: what?
Before we dive into any tools or any type of approach, it’s important to define what we want to automate. What is the real problem we are trying to solve? What are the specific pain points that automation can address? What are the goals we want to achieve with automation?
Examples of what we want to automate:
- Automating CLI tasks: out-of-band ACL changes.
- Automating GUI tasks: firewall rule management.
- Zero-touch provisioning: onboarding, configuration, and testing.
- Source of Truth: knowing the state of the network at any given time.
- Compliance and audit reporting: golden configuration checks, change tracking, etc.
- Integrating network changes with other systems: ticketing, monitoring, etc.
The third question is: how?
After we know why and what we want to automate, we can start thinking about how. This is where the technical decisions come in.
For the tech lovers among us, it’s very tempting to choose a tool, a language, or a framework right away and skip the first two questions.
But there is a hidden layer that is often forgotten: the role of the subject. Instead of immediately thinking about a tool that will solve a use case, it’s important to understand what role that component is supposed to play.
Examples of how we can automate:
- Using programmatic scripts to automate CLI tasks.
- Using orchestration tools to trigger workflows that involve multiple steps and systems.
- Using programmable interfaces to integrate network changes with other systems.
- Using appliances or controllers that determine and manage the state of the network.
This might sound a bit far-fetched, but jumping straight into choosing Bash, Python, Ansible, or any other tool without understanding its role and constraints can easily lead to overusing it.
Understanding scope
Every network infrastructure landscape is different, just like most use cases. Which is important is to look and understand scope what is needed to be automated. Now that we have established the why, what, and how, we can start looking at the scope of the automation initiative. The scope is critical because it defines the boundaries of the project and helps us focus on what is important.
After we understand the scope, we can start looking at the technical implementation. In the concept of why, what, and how, the scope is the bridge between the what and the how. It’s where we take the high-level goals and start translating them into specific technical solutions.
Let’s dive in a few use cases and how to approach them from a scope and implementation perspective.
Automating CLI task: NTP servers
This is a common use case for network administrators. The task is to update the NTP servers on a large number of devices. This is a perfect example of a task that can be automated with a simple script. The scope is limited to a specific task, and the solution can be straightforward.
Implementation Considerations:
- Git repository: To store scripts and track changes.
- Python: To write scripts that can interact with the CLI and automate the process.
Integration network controller with ticketing system
This is something more complex and involves network engineers. The task is to integrate the network controller with the ticketing system to automate the process of creating tickets for network changes. This is a more complex use case that requires a deeper understanding of both systems and how they can interact with each other.
Implementation Considerations:
- Design pattern: Create a Northbound and Southbound design pattern to decouple the ticketing system from the network controller.
- AWX: To receive webhooks from the ticketing system and trigger ansible playbooks.
- Ansible playbooks: To automate to respond to ITSM tickets and making changes to the network.
- Investigate: Which ansible or python libraries can be used to interact with the network controller and it’s network devices.
Scaling the network infrastructure ecosystem
This scope is more relevant for network architects. The task is to design a network infrastructure ecosystem that can scale and adapt to changing needs. This is a much broader use case that requires a deep understanding of the network infrastructure, the tools available, and the organizational dynamics. The outcome of this use case effects what kind of tooling would be relevant.
Implementation Considerations:
- Design patterns: Northbound and Southbound design patterns to decouple different components of the ecosystem.
- Data models: Infrastructure as code data models defined via Terraform, YAML or JSON.
- Source of Truth: Decide which systems are going to be the source of truth, and which one is going to be the master of source of truth.
- Domain boundaries: Define clear domain boundaries to avoid creating a monolithic system that is difficult to maintain and scale.
- Vendor-agnostic design: Design the system to be vendor-agnostic to avoid being locked into a specific vendor or technology.
Compliance state infrastructure
In this use case, the adminstator, engineer and architect are all involved. The task is to design and implement a compliance state infrastructure that can track the state of the network and ensure that it is compliant with the defined policies. This is a complex use case that requires a deep understanding of the network infrastructure, the compliance requirements, and the tools available.
Implementation Considerations:
- Source of Truth: Nautobot for the state of the network.
- Reporting: Nautobot Golden Config App to report on the compliance state of the network.
- Monitoring: Grafana to monitor the compliance state of the network and alert when there are deviations from the defined policies.
- Version control: Git repository to track changes and maintain a history of the compliance state.
- Configuration enforcement: Use python or ansible to enforce the compliance state and make changes to the network when necessary.
Ready to start?
Reading all this can be a lot to take in, and it’s easy to feel overwhelmed. My honest take is that there is no perfect way to start. Most of the work is finding the right solution with the right set of tools.
I’ve been in a lot of situations that the steps that I outlined here were not followed, not properly done or rushed just because of reaching a target deadline to please an return of investment reasoning. Which in the end was more costly than doing it right in the first place.
If i could go back in time, I would have spent more time on the why, what, and how before jumping into the technical implementation. I would have taken the time to understand the organizational dynamics, the human factor, and the edge cases before starting to build solutions.
So are you ready to start? Start with the why, then the what, and finally the how. Take the time to understand the scope of your automation initiative, and don’t be afraid to ask questions. The journey of automating the network is not a straight path, but with the right approach, it can be a rewarding one.
In the next posts that will come, i will write about using the tools for use cases similar to the ones mentioned here, and how to approach them from a design and implementation perspective. Stay tuned! ⚡