Meaningful Network Automation Requires Distributed Sources of Truth

Enterprise networks are vast, intricate systems with multiple methods for storing configuration and state information. The configurations of those networks are also constantly changing as new applications, services or other updates are added. When you consider the complexity and dynamic nature of an enterprise network, it may be alarming to learn how much data – including most network configurations – is still updated manually or using ad-hoc, hand-executed scripts (often in the middle of the night). To make that process even less efficient, the people doing the updating are required to manually log those updates on spreadsheets or into a custom-built database.

Relying on manual processes to maintain and manage the state of an enterprise network not only leaves the door open for errors but can also lead to the network spreadsheets or databases being out of sync with the actual current state of the network. Is the network correct? Or is the spreadsheet correct? Should we make the network look like the spreadsheet? Or should we update the spreadsheet to reflect the network? What is the actual source of truth?

The good news is that the reality of modern networking has changed the paradigm. As programmable networks are deployed more broadly, manual CLI interfaces are no longer necessary. Reading and writing network configuration and reading network state can be accomplished quickly and easily with machines and automation.

Today, the vast majority of enterprise network teams engage in some level of automation. Often, teams begin their network automation journey with simple scripts. Individuals write scripts to handle repetitive tasks and execute them to perform those activities. But this is just the beginning — automation can deliver much greater business impact when embedded in every step of a change process in an orchestration strategy.

This is where many teams face a major challenge. If a network engineer is hand-executing a script, they query systems of record in the same way they would for a manual task. But how can teams ensure an orchestrated, zero-touch process can access authoritative data?

It’s here where automation and orchestration initiatives can expose the elephant in the room that teams often ignore: the fact that your sources of truth may not be as perfectly organized as you’d like.

This realization creates fear, and fear creates hesitation. How can we automate if we don’t have a definitive source of truth? Many enterprise networking teams feel they need to rely on a single source of truth to know the true state of the network. They believe that building a single system/server/database that can synchronize with the configuration and state information of all devices across the whole network is a viable solution.

This goal is, at best, misguided. Given the distributed nature of today’s networks, relying on a single source is both impractical and expensive.

Rather than asking “What is the single source of truth?” perhaps the better question is “how do we ensure automated processes can always access authoritative data?” In other words, how do we standardize and operationalize the ad-hoc, sometimes error-prone way we query systems of record when we perform manual changes today?

Instead of relying on a single source of truth, enterprises should focus on accessing multiple sources of truth to enable automation. Take a look at Itential Automation Architect Steven Schattenberg’s blog which explores the concept of a “Single Source of Trust” vs a source of truth — this is the kind of model network teams should build toward.

If you’re running a service provider network, for instance, your business is your network. If you’ve spent millions, or even a billion dollars on your network assets, it’s worth your time to have a system in place that accurately manages and maintains those assets.

Also, as the network scales in size and complexity, the time it takes to synchronize a source of truth to the network also grows, limiting how often you can synchronize and leading to a greater time delta between synchronization states.

Finally, the process of trying to create a single source also doesn’t address the real issue, which is that enterprises are still relying on manual processes that will almost always result in the source of truth databases and the actual network status being out of sync at some point. And that can have serious negative effects on a business as well.

With the continued expansion of programmable networks (“machines talking to machines”), the most current automation solutions can access multiple distributed sources of truth – different APIs and databases that are responsible for being the source of truth for different parts of the network – and federate and sync data from these systems in real-time, providing a truer window into the status of the network and more accurate, actionable data that delivers business value back to the enterprise.

So why are some enterprises still hesitant to commit to a full network automation project? There are various reasons for this, but clearly, there’s concern that not having a single source of truth for network data – or data that may not be 100% accurate – will compromise the automation process. It’s a classic “fear, uncertainty and doubt” thought process. But by choosing to wait until they finally have a “pristine” database, teams could lose months or even years of time, to the benefit of no one.

The solution is to take an incremental approach. Look at all the various network assets – programmable, cloud, legacy, etc. – and start the automation process in the areas where good data exists and where a source of truth doesn’t need to be built. In parallel, you can be cleaning up the other data and add automation when that data is ready.

Being able to utilize multiple sources of truth is better than worrying about having a “perfect” source of truth and holding back on an automation initiative. In the long run, it will be beneficial to both the network team and the business.

From the start, we built Itential for an API-first world in order to better enable teams to rapidly integrate to their ENTIRE ecosystem at no extra cost to our customers, thereby eliminating the so called “Integration Tax” that typically comes with trying to achieve a federated source of truth. Integration assets and pre-built workflows on the Itential Marketplace allow users to get started ASAP, without a single line of code. Our rapid integration capabilities work well alongside our capabilities to automate data transformations, preventing teams from swivel-chairing between systems and applications for data gathering and formatting.

Our approach delivers a method for network teams to access, view, and analyze all their key network systems (across any domain) in one unified federated view, and provides simplified capabilities to build automation that can increase efficiency to reduce time to market.

Key components of Itential’s solution:

• API-First
  The only way to integrate multiple sources of truth into a unified one is through an API-first approach, allowing systems to talk to each other.
• Data Federation & Transformation
  Having unified sources of truth is only impactful when teams can fully integrate the data together while ensuring it speaks the same language.
• Unified View
  An abstracted and federated view of the data, processes and logic from integrated systems enables a single pane of glass across an entire network, as well as management tools for simplifying automation across the organization.

At Itential we are strong believers that a federated source of truth is the pathway for scalability, accuracy, and efficiency in an increasingly complex network environment. To learn more about how Itential seamlessly integrates with any network and IT system to provide a unified, real-time federated view, click here.