A growing number of network engineering teams are adopting network source of truth tools. What are they? And how should you go about setting one up? Enterprise Management Associates (EMA) has published new research on this subject that answers these questions. For this research, EMA analysts conducted long-form interviews with 17 network engineers about their approaches to establishing and maintaining a network source of truth.
A network source of truth (NSoT) is fundamentally an authoritative repository of network data that engineers will reference while managing infrastructure. More notably, it is a repository that network automation tools will reference when making changes to a network. There are two general classes of network data one might think of as an expression of network truth
In the context of network automation, EMA believes that intent data should be documented in an NSoT, since it ensures that any change made by network automation solutions will be based on an organization’s intent for the network. Network state data is useful as a reference for validating that intent and state are aligned.
“For us, the source of truth is our intended state for not only what devices we have, but what their configuration should be and how they should be connected,” said a network automation engineer from large North American university. “It is the system in which we have declared our intent for the network, and then everything should be based off it.”
Historically, network intent data has been scattered across multiple systems of record that vary in terms of quality and authority. An NSoT starts as a project that identifies this data, verifies that it is accurate, and then consolidates it. Fundamentally, network automation is about creating and manipulating network configurations. Thus, NSoT tools should contain all the intent data that an engineer might need when working with configuration files.
“Anything that you might need to generate a config file needs to be abstracted into some form of model and stored in that source of truth,” said a network engineer, multi-billion dollar media company
EMA research has identified three general classes of network data that network teams typically integrate into an NSoT.
Network teams may include other information in an NSoT, depending on the use cases they are tackling with their NSoTs and the nature of the networks they manage. For example, a WAN engineers would document WAN circuits, service provider SLAs, and customer support contact information. A data center network engineers might document infrastructure that is connected to the network, such as servers, storage, power, and cooling.
Once you know what data is going into a NSoT, you need to select tool. EMA’s research found an exhaustive list of requirements for NSoT solutions, but here we will focus on two core components that serve as the essential foundation.
The data that lives in an NSoT will be sourced from multiple tools, including spreadsheets, proprietary network controllers, Visio diagrams, wikis, and more. Thus, an NSoT must be flexible enough to model all this data in one place. The data model should be able to evolve over time as network teams identify new types of objects they need to document.
“Ideally you want a system that allows you to extend the schema so you can evolve your network. You should evolve [an NSoT] over time to accommodate newer topologies, new technologies,” said a network automation architect, multi-billion dollar gaming company
With open APIs, network teams can customize their NSoTs and integrate them with other systems. This integration facilitates the import of intent data from other repositories, which helps with building and maintaining an NSoT. Moreover, network automation tools need programmatic access to NSoT data to reference network intent when executing automated operations on the network.
Some network teams are going further, integrating their NSoTs with network observability tools. This allows them to build integrated workflows across intent data and state data. They can correlate fault and performance information with network intent, for example.
“If I navigate to a site in a source of truth, it would be good to be able to see the health of the devices at that that site. And then that would take you to more granular details in the [observability] system,” said a network engineer, multi-billion dollar media company
The market for NSoT is in its infancy. Many network teams use open source software. There are a handful of NSoT specialist vendors that have emerged over the last few years. Many other vendors are evolving their products to fulfil NSoT requirements. For example DNS, DHCP, and IP address management (DDI) vendors, IT asset management vendors, and network automation vendors are adding capabilities for their products to support NSoT use cases.
Your own NSoT should be guided by several factors, including.
EMA’s full NSoT research report is now available. It explores why enterprises are adopting these tools, how they establish them, the challenges they are encounter, and what they need from NSoT vendors.