Dispelling 3 Common Network Automation Myths
May 22, 2023

Rich Martin
Itential

Share this

As with any journey we embark on, before we get started, we often think about what we need to begin the journey, what we may need along the way and how long it will take us. When it comes to the network automation journey, it really is no different.

Before network engineers even begin the automation process, they tend to start with preconceived notions that oftentimes, if acted upon, can hinder the process. To prevent that from happening, it's important to identify and dispel a few common misconceptions currently out there and how networking teams can overcome them. So, let's address the three most common network automation myths.

Myth #1: A SINGLE Source of Truth & Standardized Data Are Prerequisites for Meaningful Automation

Most network engineers simply don't trust the systems that store network data because of the many failed attempts they've experienced trying to maintain accurate information. Why do these systems lack accurate data? Simply put, the spreadsheets and databases tracking the data are "offline," which means they are "in" the configuration change process but "outside" the process of requiring updates after all changes.

Secondly, the updating processes are human-centric and oftentimes managed by inexperienced engineers during maintenance windows — which typically fall between the hours of 12am-5am — or they're the result of emergency fixes performed on the fly without timely documentation. This lack of timely data updates erodes confidence that these systems are accurate.

This is where the role of DDI platforms comes in. DDI is a unified solution that combines three core networking elements — domain name system (DNS), dynamic host configuration protocol (DHCP), and IP address management (IPAM). These platforms serve as reservation and tracking systems for IP addresses and DNS records which must be unique and accurate for the network to behave properly. Despite this, what can still happen is the DDI data and the actual network configurations can still get out of sync, providing incorrect DDI data.

Some tools were built to put automation on top of a specific source of SoT, tightly coupling automation with Source of Truth (SoT) data within that database. However, there are other sources of truth within the network that the automation code doesn't operate on or integrate with, leading to incomplete or incorrect data and the automation is limited to automating tasks and not an entire process. I believe the SoT is the configuration of the network itself — not an offline copy of the system data that may or may not reflect updated information.

Source of Truth is important to the automation journey but having a single source of truth can quickly lead to inaccuracy. So how do you decide when to apply SoT and when not to apply it?

First, it's always a good idea to apply a source of truth for parts of the network that aren't programmable, for example, port assignments.

Second, some programmable network infrastructure is the SoT, for example, anything in the cloud and SD-WAN. Amazon Web Services (AWS) is the source of truth for AWS. A SD-WAN controller is the source of truth for SD-WAN. These systems are programmable and always accurate which means you don't need an offline copy. Copies are the source of discrepancies which drive error in automation. Multiple sources of truth and "fresh" data will enable better automation.

Myth #2: Network Scripts as a Strategy

When network engineers identify activities they want to automate, they usually turn to network "scripting," since many don't consider themselves developers. Two platforms have become the go-to platforms for network scripting — Python and Ansible.

Python, which has been around since 2010, has become the default programming language for network operations and has many network-friendly libraries.

Ansible has also become a crowd favorite for two reasons: first, it has simplified/limited the functionality towards automation and leverages YAML as a description language for automation. Secondly, it has broad support for command line interfaces (CLIs) for most network vendors.

However, both options have limitations. Ansible is often only viable for task-based automations. It's not a full-fledged programming language like Python because it still requires a knowledge of YAML and how it is applied in Ansible Playbook.

It also isn't truly usable at scale. Ansible tries to be simpler than writing code, but this comes at the expense of some serious limitations with respect to integration and scale. For example, if you're stringing multiple playbooks together and exchanging data between them, custom code is required, which brings you back to learning Python and using a programming language.

Whether you use Ansible or Python to fulfill a script strategy, the fundamental challenge is that there is very little collaboration and awareness of everyone's different scripts. So, what ends up happening is a lack of awareness of who has what scripts and how to use them, and very little version control to ensure people are using the correct version.

Myth #3: Mapping and Modeling of the Network Are Needed Before Automating: If I Can't See It, I Can't Automate It?

Oftentimes, network engineers believe modeling and/or mapping the entire network is a prerequisite before beginning the automation journey. However, this isn't a feasible plan, especially when we're talking about larger networks with many devices.

Why isn't mapping the network feasible?

What many don't realize is that the process of completely mapping an entire network can take several months. When mapping the network, changes are constant, resulting in a process that never really ends before automation can begin. Additionally, requiring modeling of different network devices as a prerequisite to automation comes with some severe downsides.

First, your network automation software vendor must support a particular network vendor, model, and operating system version in their application before any automation can be done. So right from the start, network teams are faced with only being allowed to buy software based on what it's able to support, or buying something that hasn't been modeled and simply going without automation until the vendor supports it.

Also, network vendors who use modeling as the basis for automation must create models for every CLI command and feature supported in the OS. This requires time and resources which forces the vendors who model like this to support a very limited number of vendors/models/operating systems.

While mapping and modeling are important to the automation journey, they should not be viewed as prerequisites, simply because doing so can waste too much time. Rather, both mapping and modeling should be seen to support automation.

At the end of the day, we see more enterprises embracing network automation because of the efficiencies it delivers. But if you're going to automate your infrastructure, your automation solution will need to gather authoritative information using multiple sources of truth.

With today's programmable networks, relying on a single source of truth is based on a flawed assumption that we can always have a synchronized database. With network automation, organizations can adopt a distributed source of truth solution by enabling the multiple systems of record, and their collective data, to act as the source of truth.

Rich Martin is Director of Technical Marketing at Itential
Share this

The Latest

June 20, 2024

The total cost of downtime for Global 2000 companies is $400 billion annually — or 9% of profits — when digital environments fail unexpectedly, according to The Hidden Costs of Downtime, a new report from Splunk ...

June 18, 2024

With the rise of digital transformation and the increasing reliance on applications for business operations, the need for application performance management (APM) has become more critical ... This blog explains what APM is all about, its significance and key features ...

June 17, 2024

Generative AI (GenAI) has captured significant attention by redefining content creation and automation processes. Despite this surge in GenAI's popularity, it's crucial to highlight the continuous, vital role of machine learning (ML) in underpinning crucial business functions. This era is not about GenAI replacing ML; rather, it's about these technologies collaborating to supercharge intelligent automation across industries ...

June 13, 2024

As organizations continue to navigate their digital transformation journeys, the need for efficient, secure, and scalable data movement strategies has never been more critical ... In an era when enterprise IT landscapes are continually evolving, the strategic movement of data has become a cornerstone of maintaining agility, competitive edge, and operational efficiency ...

June 12, 2024

In May, New Relic published the State of Observability for IT and Telecommunications Report to share insights, statistics, and analysis on the adoption and business value of observability for the IT and telecommunications industries. Here are five key takeaways from the report ...

June 11, 2024
Over the past decade, the pace of technological progress has reached unprecedented levels, where fads both quickly rise and shrink in popularity. From AI and composability to augmented reality and quantum computing, the toolkit of emerging technologies is continuing to expand, creating a complex set of opportunities and challenges for businesses to address. In order to keep pace with competitors, avoiding new models and ideas is not an option. It's critical for organizations to determine whether an idea has transformative properties or is just a flash in the pan — a challenge tackled in Endava's new 2024 Emerging Tech Unpacked Report ...
June 10, 2024

The rapidly evolving nature of the industry, particularly with the recent surge in generative AI, can catch firms off-guard, leaving them scrambling to adapt to new trends without the necessary funds ... This blog will discuss effective strategies for optimizing cloud expenses to free up funds for emerging AI technologies, ensuring companies can adapt and thrive without financial strain ...

June 06, 2024

Software developers are spending more than 57% of their time being dragged into "war rooms" to solve application performance issues, rather than investing their time developing new, cutting-edge software applications as part of their organization's innovation strategy, according to a new report from Cisco ...

June 05, 2024

Generative Artificial Intelligence (GenAI) is continuing to see massive adoption and expanding use cases, despite some ongoing concerns related to bias and performance. This is clear from the results of Applause's 2024 GenAI Survey, which examined how digital quality professionals use and experience GenAI technology ... Here's what we found ...

June 04, 2024

Many times customers want to know why their measured performance doesn't match the speed advertised (by the platform vendor, software vendor, network vendor, etc). Assuming the advertised speeds are (a) within the realm of physical possibility and obeys the laws of physics, and (b) are real achievable speeds and not "click-bait," there are at least ten reasons for being unable to achieve advertised speeds. In situations where customer expectations and measured performance don't align, use the following checklist to help determine the reason(s) why ...