Thinking about Network Automation after AutoCon1

Posted on by Claudia de Luna

I love Space! (BTW..guess what happened 55 years ago Saturday!)

Imagine my delight at the synchronicity of finding Joseph Klibansky's The Thinker. when walking around Rembrandt Square in Amsterdam on the last day of NAF's AutoCon1 Conference.

Space and one of my favorite sculptures all rolled into one at the end of a conference that inevitably makes you think, re-think, and refine your understanding of network automation!

NAFs AutoCon is designed to both help you do and understand the role of network automation in your organization. From the provocative opening keynote by Dinesh Dutt to the "spirited" discussion after Peter Boers closing keynote between and Dinesh Dutt and other though leaders in this space, to every session in between, the conference provides much to think about.

Here is what I've been thinking since the conference...

I was a bit harsh in my assessment of AutoCon0. I failed to see the broader play. I expected answers and missed that AutoCon0 was the catalyst.

Taking all of the material during and after AutoCon0, adding their vision for not just keeping the conversations going but starting to focus them, the NAF Team, Scott Robohn and Chris Grundemann in particular, did an amazing job of putting together an AutoCon1 conference agenda that I truly believe will lead to substantive improvements in the adoption of network automation. In point of fact, Chris and Scott have established a community to tackle the advancement of network automation. That's us folks!

The first achievement will be understanding how to talk about Network Automation and what we mean by that overused term. After that, we can focus on how to "sell it" to the business and build solutions around it.

I am starting to see that we've been framing the discussion incorrectly or at least incompletely!

Its not just the transmission!

We talk about network automation as the thing itself. That has to stop. Its like we've focused on the transmission and forgot about the rest of the car. It is the car we need to move to get to a particular destination. The transmission is a key component but we won't get anywhere if all we ever have or talk about is the transmission.

  1. First gear! check it out I Jinja-ized my configuration templates
  2. Second gear! I pushed configuration to a network device!
  3. Third gear! I pushed specific configurations to multiple devices and did some verification
  4. Fourth gear! I triggered a fully automated workflow across multiple network devices.
  5. Fifth gear! DevOps

You get the idea. In all the talk about how great second gear is, we forgot that the transmission is part of a much bigger system.

A transmission without the rest of the car stands still...kinda like the adoption of network automation.

Second gear is great..but, as the NAF Team said...Now What?

So now we can start to talk about Network Automation as a strategy or technique - yes a tool or part - which will help us achieve business goals (move the car at the desired speed to the desired destination).

It all needs to start with - where are we going? (what problem are we trying to solve)

I hope you have time to listen to the AutoCon1 sessions now available in the YouTube NAF Channel.

So many of the talks were framed just that way...here is the problem I was trying to solve and here is how automation helped me solve it efficiently, quickly, consistently, etc.

I doubt that was by accident!

I must stop now or I'll just provide you with an index of every session at the conference. In fact, here it is. These sessions are spectuacular examples of this theme of

  1. identify problem
  2. develop solution which includes automation components and features

There is a third layer to this and that is organizational context or organizational capability/maturity and this brings me to another realization.

How applicable is DevOps?

We spend too much time talking about 5th gear or DevOps.

Are there great lessons to be learned from a fully automated virtual infrastructure? Absolutely

Does that apply to everyone? Absolutely Not!

...and so we've alienated a large part of our community with all this talk of DevOps because we didn't consider that third layer. Slapping a "NET" prefix to it doesn't help a network engineer understand it any better.

A better conversation

If we start with those layers, we start to understand what to study next, what skills gaps we actually have, which tools are better suited for the solution.

With this knowledge we can start to clear a path through the bamboo.

Of course, this is obvious. Its all starts with requirements. Requirements provide clarity and direction and yet it is so easy to skip that crucial step because it hard. It requires you to THINK and talk to your USERS and understand your INTERFACES (yes talk to other silos)! There is absolutely nothing new here. We just have to do it.

My formative professional years were spent in an engineering organization where that was drilled into me. Since moving to other verticals, it still disturbing how often projects proceed without that crucial step and "network automation", whatever that means to you, is no exception.

So back to basics for me! I don't want to have a conversation about network automation that does not start with "what business goal are we trying to achieve?"

Do I need DevOps? No idea.
Are there DevOps principles that I can use to solve this problem. Probably.

AutoCon1 left me with some questions

A good conference teaches you, exposes you to new people and ideas, and leaves you with unanswered questions to ponder.

For me, these are the topics which will require further study and contemplation.

What role will standards bodies play in Network Automation?

I think its encouraging that the IETF has been represented at both AutoCon0 and AutoCon1. There is even a BoF channel for IETF and Automation (NAF Slack Channel).

I think helping to frame how the IETF can help (and I am not talking about a one size fits all data model which vendors may or may not adopt) would be a worthy task for this community.

What role will AI play in Network Automation?

Peter Boers concluded the conference with a perspective on the future and the role of AI in our discipline. It was in fact, a challenge to move into AIOps.

I have spent zero time in this space. My first thought was, "Are we going to have a choice, whatever it actually means?" Almost every product out there purports to be or use AI.

My second thought was "If all network automation and operations used AI and AI is always right why do we need AIOps to solve problems? Will there be any?"

I am sure these are the parochial questions of the uneducated and uninformed around this topic and that is on me. That is my call to action from Peter's closing keynote. What do I do with this AI stuff in Network Engineering?

My team mates have already figured out that while ChatGPT can tell them quite accurately how to configure a vlan or a static route it can't tell them if they should.

My first step will be to chat with my former colleague from NASA/JPL, Peter Scott who hosts a weekly podcast "AI and Me"! How timely and aptly named! (its actually Artificial Intelligence and You and he has been talking about AI since 2020).

Peter is brilliant and entertaining and I am looking forward to the education!
Example:
Empathetic AI: Unlocking Trust Between Humans and Machines | Peter Scott | TEDxRoyalRoadsU

Observations

Finally, some observations about the conference.

Failure IS an Option

In this discipline in particular, we undervalue Failure (or pretend to). We listened to several sessions around "failure" and those lessons are invaluable.

A few years ago, I was asked to contribute to the "Expert Insights" chapter of Nicolas Leiva and Michael Kashin's book "Network Automation with Go". I shared my 10 "lessons learned" (at the time) and lesson #4 is about the value of failure.

Commercial and Community conference format

The "automation journeys" interspersed with product briefs was inspired. Talk about the best of both worlds, literally!
I found the interspersing of commercial products with the community stories, very powerful. Commercial solutions interspersed with real problems lets us start evaluating those commercial solutions in context! I hope there is more of this at AutoCon2!

Common Themes Emerging

We are seeing some common themes emerging that I think will be pivotal to moving the discipline forward.
If we can start to categorize these common themes then maybe we can start to put some solutions around them. These could then be leveraged by community members to jump start their own network automation initiatives.