Getty Images/iStockphoto
Network automation success begins with a source of truth
A network source of truth is essential for automation strategies. Organizations must know what data an NSoT contains and which tools to integrate for successful network automation.
A network source of truth, or NSoT, is an essential element of any network automation strategy. Its true definition continues to elude professionals, however.
A new report from Enterprise Management Associates (EMA) titled "Enterprise Network Automation: Emerging from the Dark Ages and Reaching Toward NetDevOps" surveyed 354 IT professionals and found that only 18% of network automation strategies are completely successful. The research found that those organizations with successful automation strategies had an effective NSoT.
Though network professionals agree fundamentally about what an NSoT is, many are unsure whether it should derive from network state or network intent. Once an organization determines the source of its NSoT, it needs to invest in tools to store all the data. With proper NSoT storage, automation is easier to implement.
What is a source of truth?
NSoT is a repository of data about the network. One network automation engineer at a large university described NSoT as a snapshot of the network's operating state. For example, a network discovery tool could pull current configuration data from every device and present that as the source of truth. Network pros might combine this with device health and performance metrics, as well as traffic flows collected by a network monitoring tool to assemble a full understanding of the network.
An NSoT in network automation should contain all the data network administrators need to implement network changes with confidence. But what kind of data does that include?
"That's been a source of debate for a while," the university automation engineer said. "If the network is set up the way it should be, the source of truth should be the network itself. We're still working on the best way to rectify this problem."
Note the caveat in that engineer's statement: "If the network is set up the way it should be."
How do you know if the network is set up the way it should be? Many people argue that network intent is the real source of truth for any network. Network intent data includes configuration standards rather than live configuration. Further source of truth data derived from network intent includes the following:
- An abstract standard for network design.
- Application requirements.
- Security policies.
- IP address space information, including current and available addresses for new devices and services.
At a fundamental level, network intent is about network standards. Automation doesn't work without standards.
"Standardization is the biggest obstacle [with network automation]," said a network tools engineer at a Fortune 500 retailer. The engineer added that when the network and data are not standardized, problems arise in the network. "You can't automate at scale because you're forced to automate one device at a time without standardization."
Whether an NSoT derives from network state or intent, the NSoT should contain inventory data about all physical and logical devices on a network. Inventory data aids in identifying which devices are available to be automated.
Establishing a source of truth
EMA considers a source of truth to be a complete record of network intent. A source of truth offers additional value if it compares network intent with network state to identify discrepancies. This helps network engineering teams troubleshoot problems and enforce network standard compliance.
Given all the data involved, it's rare if not impossible for one tool to hold it all. EMA asked research participants to describe the repositories that contain the data they consider to be their network's source of truth. Only 22% held it in a single, centralized platform. Another 62% described their source of truth as multiple systems of record integrated directly or via a central federated tool. The remaining percentage of respondents had multiple siloed systems of record. This means they had to manually gather data to get a full picture of network truth. This latter group reported having an ineffective NSoT.
"No matter how hard you try, you're not going to have one tool that has all this information," said an IT tools architect at a Fortune 500 media company. "You have to get good at aggregating and integrating things from multiple places. For automating devices, we have to pull data from ten different places."
Because federation is the norm with an NSoT, EMA recommends having a central tool that integrates with other data repositories. It can maintain a central store of certain data classes and query other systems when needed.
For example, a network engineer who needs to change the configuration of a group of branch office firewalls can pull device inventory data, IP address information and configuration standards from the central tool. However, the engineer might also need the most current security policies defined by the cybersecurity team. The central tool queries the cybersecurity team's policy management tool for the relevant data and presents it to the engineer, who now has everything needed to push a configuration change.
EMA's research pinpointed the following best practices for establishing an NSoT:
- Automate all workflows associated with gathering data required to execute a network change.
- Design an NSoT to support a multivendor network.
- Integrate an NSoT with IT service management, security monitoring and DevOps automation tools.
- Look for network intent repositories, including network discovery as well as analysis and reporting on intent and state variations in an NSoT product.
Shamus McGillicuddy is the vice president of research for the network management practice at Enterprise Management Associates (EMA). He has more than 15 years of experience in the IT industry and has written extensively about the network infrastructure market. Prior to joining EMA, McGillicuddy was the news director for TechTarget's networking site.
