Idiomatic Confusion

Constructive Community

I've been spending a lot of time in the Network Automation Forum (NAF) community, as of late. I've been really inspired by the really active & helpful community. It makes me really excited to attend the upcoming conference, in one of the holy cities of beer, Prague.

One of the main projects I believe in, and am actively trying to contribute to, is the NAF Comprehensive Infrastructure Automation (CIA) framework. It's essentially a community driven document with the goal of helping everyone, for every network of every size, automate their network.

Below you can see Sensei Dinesh discuss the problem set and the vision.

Confusing Terms

Another one of our community's leaders, and perhaps the community leader I agree with the most, Claudia De Luna, recently blogged about how we seem to be lost in the weeds, with the very discussion around "What is Network Automation?" . Claudia masterfully lays out that there is an obvious wedge between the term "Network Automation" from the way we've always discussed it, and approached it, to the way we're discussing and approaching it in our communities lately.

This is a problem we have to solve because someone might suddenly be tapped by their manager – if not out of their own whim and anger – to get on the Network Automation train. They crack away with some kind of tooling and take a previously manual task, and turn it into a smooth & enjoyable automated task. They should be proud; however, they find themselves at a loss when someone tells them "what you did is not real network automation". Huh – say what?! They took a task involved in managing their network and automated it? So what gives? As I read Claudia's post, I couldn't agree more with what she's said. So why is what she says below the case?

Conventional wisdom tells us that all of those things ARE network automation. In fact necessary for network automation.

I spent 11 days in sunny Mexico and the concept finally broke through to me, as I compared the past to the present. I believe the disconnect can be broken down to the following definitions:

Network Automation - the concept of taking a network operational task and automating it.

Automate your Network - a tech community idiom considering the entire spectrum of what it takes to do a particular design or operational task for your network and adding as much automation to that process as possible.

That's it. Automating your Network involves creating Network Automation & gluing it to existing systems automation or building/utilizing existing APIs in your environment, to end-to-end your network process.

Let's look again at Claudia's chart and compare:

You Maniacs! You blew it up!

This is a tough thing to consider, as many of my mentors did great work in various forms of Network Automation. For example, a long time ago, some colleagues of mine made an excellent "CLI Wrapper" to make a Linux Firewall appliance act 1:1 with a Cisco ASA Firewall, at 1/10th the cost of ownership. That was, and still is, network automation. In fact, VyOS is yet another successful project – they're taking obscurely managed linux daemons & functions and giving operators a familiar domain specific language (DSL). That's network automation.

But why did all those excellent scripts and network automation efforts wither away into obscurity. Why did they not move the notch ever closer to "Full Network Adoption", as is the tagline question of NAF?

Because managing a Network is so much more than configuring prefixes on 1, 50, or even 10,000 devices. Other portions of our tech industry figured this out long ago, when they went from cron, bash, and perl scripting and went to systems design. Consider this Signal Driven Workflow example I presented to the community, to define something as simple as a point-to-point pseudowire going down in my environment:

Take notice that perhaps only one square is the actual device itself. To automate this process to completion, you would have to integrate your network automation with, and perhaps write automation for, the following:

• Your ticketing system
• the data stores that have definitions and information on the service itself (think SLAs, intended bandwidth, is the circuit decommissioned, planned, redundant, has no overdue fees, is leased from another provider)
• Your inventory & infrastructure data stores (IPAM, CMDB, Rack Layout diagrams, facility datastore)
• Your escalation data store (who is on-call based on: the time of day, the severity, the geographic location, the amount of people you need – what if it's a two person lift or a risky job?? )

All of that really likens more to systems design or automation. You might find yourself completing the 10% or 20% of YANG / Netconf / TextFSM parsing, only to be neck deep in SOAP/XML, dataframe or CSV data engineering, Rest & GraphQL tinkering, and SQL syntax kung-fu'ing, to reach a autonomous process without human intervention. That really sucks to admit, because you're probably pretty proud about finishing the 20% of the process that gave you and your team 80% of the value.

But did it really accomplish 80% of the value? If you walked the "assembly line" that is this workflow, what if the NOC actually measured that finding spare parts and getting tech(s) on the road is the biggest point of friction? Perhaps then you could prioritize that part of the workflow and come back to the actual Network Automation later.

What's to be Done?

In my opinion, it's your choice what you do with this theory. You can either try to tackle the whole signal driven workflow by yourself, or you can consider that maybe your knowledge & expertise is best in your domain of Network Automation. For example, Gall's Law (whom I found out from Eyvonne Sharp on The Hedge Podcast)

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

With this in mind, you should perhaps build network automation that works. Because you know the data model & paradigms of the networking domain better than any Sysadmin or Developer in your org, I would imagine. I would only suggest you make one big change: you add a robust API, such as FastAPI, to your automation, then nerd snipe a dev or sysadmin to help you integrate it with the other tools in the Signal Driven Workflow. When you team up with them, you might learn more about existing automation systems and tools in your environment – that are both likely simple, and already work – and gain the skills to help lead the Signal Driven Workflow automation yourself, the next time around.

You'll then become the Master of Glue; Silo'ed to none.

As Claudia said in her post:

Maybe we need a new term?

Yes, maybe we do. Developers went from Agile -> DevOps -> SRE - > Platform Engineering -> Laid Off. (Sorry, Tech Oligarchs are responsible for that last one, not me). Why can't we move to at least one new term? Maybe we really should just call it Comprehensive Infrastructure Automation, as we're simply just lifting the network up into the blood stream of existing infra automation.

If you liked this concept, or disagree, let me know. This is the first in a series of thoughts I've scribbled under Mexican sunshine themed:

I've proposed to the organizers of Autocon3 that we have a Bird of a Feather session on this topic. Which is to tackle, as a group, all the gotchas of automating your network that you can't find in a marketing post. That way we can build each other up and bring more people from the beginning to the middle section of the network automation landscape.