The Single Source of Truth for Network Automation
How a single source of truth, expressed as an elegant data model, can operate an Internet business' process and network automation. Many automation presentations t …
Talk Title | The Single Source of Truth for Network Automation |
Speakers | Andy Davidson, Asteroid |
Conference | NANOG73 |
Conf Tag | |
Location | Denver, CO |
Date | Jun 25 2018 - Jun 27 2018 |
URL | Talk Page |
Slides | Talk Slides |
Video | Talk Video |
How a single source of truth, expressed as an elegant data model, can operate an Internet business' process and network automation. Many automation presentations to date have considered programming skills/languages a network engineer starting an automation project needs. They concentrate on vendor automation features. The audience learns the Arista/Juniper integration options. Little presented to date explains how an engineer can integrate software relevant business processes or product design. If a network concentrates only on the automation platform facing their network, though the instruction set to manage the network is automated, can the company be said to be automated without integration into the products and rest of the business? When a company extends the scope of the automation project into the product set, sales process, monitoring there are many efficiencies realized: Freedom to provide services by nontechnical teams The speed of deployment of customer services (reduce time to bill!) The accuracy of monitoring systems More customer self-service options Rich API that customers can deploy into their software SLA and outage validation The presentation shows lessons learned to network companies (ISPs, IXPs, content) looking to embark upon an automation project: Why and how to build a data model that can describe your customers, products, and network, teams What normalization is, and why/how to use it Why and how to abstract different layers of technical systems to allow vendor changes/flexibility How and why to use the data model to build systems configurations and monitoring templates How and why to abstract between functional elements (like “ports”) and all matters relating to the service on those technical elements How and why to expose parts of it to customers to provide an extra layer of transparency and benefit to your end users How to integrate with data which is in third-party databases The mistakes I made and had to refactor out after launch