This document discusses the challenges of network automation and proposes moving from a Python-based approach to platform engineering. It argues that previous attempts at network automation through abstractions, standardization, and single sources of truth have failed because networks are more complex than other IT domains. The document advocates separating automation and orchestration domains to allow for specialized tooling in each area. It also suggests that networks will evolve through exposing programmable interfaces without restrictions rather than top-down standardization. The document outlines how Itential supports these goals through its focus on network automation, integration of cloud and traditional networks, and partner ecosystem.

1. Your logo
here
Evolving the Network
Automation Journey from
Python to Platforms
Chris Wade
CTO & Co-Founder, Itential

2. Network Automation & How to Think
About the Challenge
We can put our challenges under a standard definition of
market and product maturity.
Idea Custom/DIY Product Commodity
Undefined
Different
Unstable
Forming
Emerging
Learning
Growing
Common
Feature
Difference
Mature
Standard
Essential
*Wardley Maps

3. Let’s View Other Parts of IT/Cloud
Infrastructure
We generally believe Public Cloud IaaS and Compute/Storage
has been more successful moving toward commoditization.
Idea Custom/DIY Product Commodity
Most AI Use
Cases
Infrastructure as
Code
Platform
Engineering
Serverless
Service Mesh
K8
Compute (VMs)
Storage
(Block/Object)
Containers
*Wardley Maps

4. How Do We Think About the Challenge?
Our focus can be on opportunities to commoditize
components to unlock innovation.
Idea Custom/DIY Product Commodity
Most AI Use
Cases
Infrastructure as
Code
Closed Loop
Automation
Platform
Engineering
Ansible
Jinja2 Templates
Network Telemetry
NETCONF
Swagger APIs
Pipelines
Code Repository
Python
*Wardley Maps

5. How do we standardize this complexity?
We don’t.
Branch
Office
Branch
Office
Branch
Office
Internet Data Center

6. Why is Networking Stuck on its
Evolution?
CLI still dominant for
device by device configs
Systems not in place to
manage via APIs
Data models are
unique
NETCONF/YANG not
ubiquitous
Cloud operating model not in
alignment with Network
operations
EMS/NMS – Networking ‘tools’
built for swivel chair /
manual operations

7. Previous Attempts: Abstractions
Abstractions are generally a good thing when the items being abstracted are
similar. When we are abstracting VLANs for Cisco and Arista things are simple(r).

8. Previous Attempts: Abstractions
But they become problematic when we add cloud and programmable concepts…
We move from abstracting and apple and a pear to an apple and a shoe J

9. Previous Attempts: Single Source of
Truth
When you have spreadsheets and sticky notes, a database with APIs is a
great idea!

10. Previous Attempts: Single Source of
Truth
But when we add programmable networks with existing sources of truth…
Anyone logged onto AWS and thought the console was incorrect? How about
your CMDB..

11. Previous Attempts: Standardization
When Ethernet services are offered wholesale…

12. Previous Attempts: Standardization
Attempts to standardize SD-WAN, SASE, and Cloud services doesn’t make sense
as these vendors are working diligently to differentiate.
Do SD-WAN vendors care?

13. Standardization is Not Uniquely a
Network Challenge
We had a CMP (Cloud Management Platform) market that attempted to build
abstractions across Public Cloud vendors.
The desire to differentiate does not allow for abstractions. Or the abstractions are
worthless to the point that everyone builds custom extensions – sound familiar?

14. Separate Automation & Orchestration
We have mashed Automation and Orchestration together in ways which create global choices
suboptimized for each domain. This adds to ‘cultural challenges’ in adopting automation mindset.
Orchestration
Recommend viewing automation domains as loosely coupled to use best
tooling and strategies while harmonizing with central orchestration.
CDK AVD
SD-WAN
Controller
Terraform Python

15. Automation Domains
● Networking technology
● Method of execution
● Data structure
● Source of truth
Attempts to drive single automation strategy across automation domains
leads to suboptimization of tooling and friction between teams.
Data Center
Example
Cloud
Example

16. Python to Platforms
Obfuscation of domain specific SOT, tooling, data models allow for standard
‘network products’ to be exposed via APIs, ITSM systems, to LOB & application
teams.
(CNCF Project)
Orchestration

17. Attempts to Support Network
Programmability & Automation
IETF – Internet Standards,
RFCs (NETCONF & relevant
automation protocols)
IEEE – Networking Standards
(Ethernet, WiFi)
MEF – Ethernet Services +
Sonata (LSO)
TMF – OSS/BSS APIs + eTOM
Data Models
USNUA – Local Meetups
NANOG – IXC, Operation
Excellence
OpenSource – Linux
Foundation
OpenConfig – Network Models

18. So, What Do
We Need
from NAF?
● How to get started
● How to get funded
● What partners really
support my vision
● Vendors who work
together to grow the
community
Let’s all join in demanding infrastructure providers publish their APIs and interfaces
publicly without paywall or IP restrictions so we can get on with automating their stuff!

19. How Itential is Supporting
NAF & This Vision
● NetDevOps automation focus. High-Code.
Support your IaC efforts.
● Integration with cloud and traditional
networks.
● OOTB platform to orchestrate your
automation.
● Partner ecosystem – no one goes alone.
● Self-service and platform engineering
capabilities to engage with your
customers.
● SaaS delivery for ease of use.

20. Questions?
The best way to get started with
automation is to automate anything.

21. Thank You!