Why Data Integration & Federation is Critical for Scaling Network Automation

As automation becomes pervasive in organizations, users are starting to recognize the impact that automation can make in saving time and money as well as improving accuracy. Due to this, automation use cases are evolving from simple changes to more complex operations. By automating the more complex processes, organizations can recognize significantly greater savings in both effort and in time to complete the process.

The Challenge: Automation for Scaling Networks

The challenge that many organizations face is how to utilize their automation tools to be as effective in automating complex, multi-domain use cases as they were in automating simple changes. The challenges are in two dimensions – complexity and scale. As complexity increases, a single tool may lack the ability to perform automations consistently across domains. For example, across traditional IP infrastructure (CLI-based), cloud infrastructure, and application layers. As scale increases, techniques like scripting become more challenging to use effectively. This is becoming clear in scenarios where the number of devices and controllers is skyrocketing, such as SD-WAN or Mobile Edge Computing (MEC). With the growth of these technologies, and others such as SDN, NFV, and orchestration – organizations have deployed a wide variety of systems, controllers, and functions to interact with the network.

While it may be possible to connect to all of these systems, the problem becomes how to organize the data that comes from these systems so that users (humans) and other systems (machines) can interact with the network in ways that are simple, predictable, and repeatable. For example, information about a single device, such as a network switch (we’ll call it Switch1) could be represented in multiple places, such as an EMS, an SDN controller, a fault management system, an inventory system, and an ordering system. To each of these systems, Switch1 is a unique separate entity than all of the other representations of Switch1, but to the operations team member, all of that data is related to one switch (Switch1). Software based systems, on their own, typically are not smart enough to know that each of the systems is actually talking about the same network switch. In order to treat Switch1 like a single entity, and not a collection of separate views of that entity, some mechanism needs to be implemented to link all of those views together.

There is another aspect to the same problem – there may be multiple EMSs, controllers, and orchestrators that are managing the same types of network entities.  Going back to the previous example, in a large network environment there could be multiple systems responsible for managing switches, such as an orchestrator, an OpenStack instance, an EMS, or an SDN controller. All of these systems are managing the same type of entity (a network switch), but each one represents the data about that switch in a unique way. As the number of controllers grows, the complexity of managing the network by logging in to each controller to make changes becomes significant.

The Solution: Data Federation

Data federation is the ability to provide aggregation and harmonization of data from multiple sources, such as network controllers, orchestrators, inventory management systems, and performance systems.

The method that a federated system aggregates data is different than the way traditional management systems collected information; which typically relied on copying massive amounts of data to create a master database. The problems associated with this older approach included timeliness of the data, data quality issues, and ongoing synchronization challenges.

Federation overcomes these issues and accommodates the rapid changes to the network by creating a meta-map of the systems and then querying those systems in real-time during execution of workflows or other business logic.

Without federation, the NetOps team must contend with a growing, massive disorganized list of elements. Instead of focusing on how to automate the changes, they need to have a reliable method on how to find the right resource and reach it, along the correct path and syntax to communicate through the scripting system, controller, or EMS.

Itential’s Unified & Abstracted View

The Itential Automation Platform (IAP) was designed to address the challenges of complex, multi-domain automation scenarios by implementing a federation layer within the platform.

With federation, users and systems can utilize the federation system to easily do things like:

• View and interact with a global list of device types (switch, router, etc.), regardless of the underlying controller, orchestrator, or EMS. This eliminates the need for multiple screens, swivel chair-type interactions.
• Provide a single Network API to applications and OSS to simplify interactions from those systems. The OSS does not need to understand which controller, or which type of controller, it can simply name the device it wants to make the change on, and the federation system will determine the best way to route and execute the request.

We’ve seen customers leverage Itential’s Automation Platform to go far beyond simple automation cases and deploy automations for complex use cases that address large, multi-domain environments (100,000+ devices) by utilizing the data federation capabilities of the platform. As new technologies move beyond our customers’ labs and into production, we are looking forward to further benefits that federation will provide.

To learn more about the automation capabilities of Itential and see how functionality like federation can greatly simplify the operational challenges associated with large, distributed multi-domain and multi-vendor networks, download the white paper, “Itential Automation Platform: Network Integration, Federation & Automation.”