Is Network Automation Worth the Struggle?

Send us a text

Network automation remains one of the most polarizing topics in our industry. Despite years of being told it will revolutionize our work, actual adoption rates hover around a dismal 20-30%. Why the resistance? And is there finally a path forward that makes sense for everyday network engineers?

In this candid conversation with Jeff Clark and Colin Doyle, we dive deep into the psychological and practical barriers that keep most engineers firmly rooted in traditional networking practices. Jeff shares how his "selfish automation" approach transformed a tedious 15-minute ticket process into a 30-second task, while Colin explores how modern intent-based networking is fundamentally changing what network automation means.

The truth emerges that resistance isn't just about technical challenges—it's about cognitive biases like loss aversion and fear of job displacement. We confront the paradox that many engineers chose networking specifically to avoid coding, only to find programming skills becoming increasingly essential for career advancement.

What makes this conversation different is our focus on practical, accessible starting points rather than theoretical ideals. You'll learn why small, personal projects that solve your immediate problems are the gateway to building automation skills, and how communities of practice can provide the support and accountability needed to progress.

Whether you're automation-curious or automation-resistant, this episode offers a refreshing perspective on how to approach this inevitable shift in our field. The future of networking isn't about replacing engineers with code—it's about freeing engineers to focus on what matters most.

Find everything AONE right here: https://linktr.ee/artofneteng

Episode Transcript

Speaker 1 (00:00):
This is the Art of Network Engineering, where
technology meets the human sideof IT.
Whether you're scaling networks, solving problems or shaping
your career, we've got theinsights, stories and tips to
keep you ahead in theever-evolving world of
networking.
Welcome to the Art of NetworkEngineering podcast.
My name is Andy Laptev and thisepisode I am joined by two

(00:23):
friends, two smart gents.
I have worked with them both inthe past.
I work with one now.
I'm hoping to work with theother one soon.
Maybe I'm working with him nowand don't even know it.
Where are we going to start?
So let's start with formerguest of the show, jeff Clark.
How are you doing, jeff?

Speaker 2 (00:39):
No complaints.
I mean I'm glad to be here,it's exciting.

Speaker 1 (00:41):
Thanks for coming back.
I went back.
I don't know if your episodewas like 30 something or 40
something.
It was pretty early on Four toJeff and the.

Speaker 2 (00:47):
Ford camper.

Speaker 1 (00:48):
Yeah, how have things been?
Anything new?
You're still just four toeverything in the Ford camper
and everything's good.

Speaker 2 (00:55):
I feel like everything is different every
single day, but it's also kindof the same.
Everything's unexpected, butyou just start rolling with the
punches.
That's kind of just the SE gigin general, though, is it's a
lot of you're telling the samestory, but getting different
questions and getting to figureout how to answer differently.
But no, it's, it's good.
It feels like time's flying bythem.

(01:16):
2025.
I can't believe that 2024 isover.
It felt like it just started acouple of weeks ago.

Speaker 1 (01:20):
It ago.
It did Well, Jeff.
Thanks for coming back on.
It's great to see you again,Colin Doyle.

Speaker 3 (01:31):
Colin.
Hello friend.
Where do you work?
What do you do?
How are you?
I work at Nokia.
I'm a principal consultingengineer, which is just a jumble
of words.
That means I work in the datacenter practice.
As we start to buff and buildout that muscle.

Speaker 1 (01:40):
Principal, that sounds fancy.

Speaker 3 (01:42):
It did sound fancy, I remember when I got that title
and I'm like this is good.
I don't know, there's certainI've always felt like the
shorter your title, probably themore important you are.
But when you like, there arecertain words, like principal,
where I'm like ooh, that's neat.
That means I can suspendchildren from school now.

Speaker 1 (02:01):
All right, fellas.
Well, thanks for being here.
The real reason we're here.
Right, let's get into this.
Let's let these people into thefun.
We've been hearing about itforever, right?
Network automation it's goingto revolutionize networking.
It's going to make our liveseasier, right, we're going to
break stuff less.
We're going to eliminatemundane tasks.
We're going to free our peopleup to work on higher value

(02:23):
things.
If you can't sense the sarcasmin my voice, it's there.
And yet here we are.
Right, decades later, adoptionrates are low.
I forget the last time I lookedat the data, I don't know
somewhere around 20 or 30%, andof that it's minimal stuff.
It's like I don't know, otherthan the hyperscalers that have
automated everything, the restof the industry is pretty piss

(02:44):
poor as far as level ofautomation.
I mean, we're still managingour networks the old-fashioned
way.
In my 15 years managingproduction networks, I managed
networks the old-fashioned way,right?
But here we are still beingtold network automation it was
supposed to be the next bigthing, right?
There's always this next bigthing in tech.
You know what I mean.
I don't want to draw thisparallel because we've had an

(03:08):
IPv6 episode and my mind waschanged by the end of that.
But IPv6 global adoption we'reat like 37%.
20 years ago it was releasedand we better do it before the
internet breaks.
Maybe not right?
So that was the next big thingwe had to do.
Y2k all the planes are going tofall out of the sky, are they

(03:29):
really Okay?
So I'm going to say something,I guess provocative,
inflammatory, here to get theconversation started.
Network automation it's afailed passion project.
Right?
These DevOps nerds, thesecoders who for some reason
didn't go into networking,decided that they're going to
tell us and they're going toconvince vendors and they're
going to tell the world, likethese network people who have
been avoiding coding all thistime, they need to code, they
need to automate.
You know, aren't networks goodenough?
Right?
If we want to go fast, can't wejust go use the cloud?

(03:51):
So, guys like, prove me wrong.
I am the voice of the industry,the 70% of the industry that
refuses to automate anything in2025, right, prove me wrong.
Why are my beliefs twisted?
Where can we start?

Speaker 2 (04:04):
So I'll kick this off partly by saying I think what
ends up happening is, when wetalk about automation, I think
everybody kind of puts Python upon the pedestal.
Right, it's the, oh, it'sPython or Ansible, or it's this,
we've got to automate it thatway, and then everything has to
be automated.
What we fail to realize is thatautomation has happened around
us and we didn't even know it.
I spend at least 60, maybe 70%of my time in a GUI, and a GUI

(04:28):
is realistically just somebodyelse's automation tools.
Right, it's somebody else'smacros.
So I mean, I work for Fortinet,so I build a VPN.
Instead of going in andentering all the commands to
build a VPN manually, I'm usingsome semblance of a wizard
that's telling you hey, you know, you've got to remember that.
You know, in addition to thisbit and this bit, you need to
also know that you're going tobe doing this pre-shared key and

(04:49):
you're going to be doing thistype of encryption.
You're doing that and it's awizard that walks me through it.
In reality, that's networkautomation.
We don't call it networkautomation, we call it central
management, we call it singlepane of glass, but.
But in reality it's networkautomation.
It's just become so mainstreamthat we don't even look at it
that way, then I think we alsowe need to look at regular

(05:09):
automation tools like writingscripts, which is probably more
of what you're talking about.
You know scripting and thatkind of stuff.
We're also living in a timewhere it is easier than ever to
learn it.
I mean yesterday, when I foundout that we were doing this, or
the day before, I went into chatGPT and literally my prompt was
literally I don't know anythingabout Ansible.
I want you to function as anAnsible teacher and help me

(05:31):
write my first script.
And at the end of the day, Inow have a script that creates a
virtual machine in GNS3 for me.
It goes to the licensingsoftware that I use here at
Fortinet gets a license for me.
The licensing software that Iuse here at Fortinet gets a
license for me.
It finds the first available IPaddress on my network and it
adds a DNS entry for that hostname that I create for the
endpoint, and it does it inabout five seconds, and that was

(05:54):
something that used to take meabout three minutes.
So it's not like I changed theworld with this, but I learned a
bunch of stuff and it wasreally easy to do.
So my argument is automation isalready around us and it's
easier to learn than ever.
So I don't, I mean.

Speaker 1 (06:06):
So you created a playbook in Ansible, correct, I
did.

Speaker 2 (06:09):
Yeah, I didn't know what that was until yesterday.

Speaker 1 (06:11):
And how long?
What was the process of?
Because, honestly in the time,so 2025, right, like LLM's chat,
gpt just kind of kicked off andgot mainstream.
I don't even remember.
Was it a year ago?
Is it longer, shorter?
It seems like it's been hereforever, but it hasn't been that
long like year-ish.
So when I was in productiontrying to learn automation, that
wasn't an option.

(06:32):
So I actually liked that usecase.
I was trying to you know KirkByers Python thing, and then he
says, well, if you've nevertouched it, you got to do this
pre thing.
And that's 187 page book andlike 100 days of code.
Like there's just all thesepython courses.
And again me and a lot of mycolleagues struggled with, like
I think it's the layers ofabstraction that I've always
gotten lost in, like I get it.

(06:53):
Like when I see it and somebodywalks me through it, I I'm not
dumb, I understand what'shappening, but for me to sit
down and write it and get it allright and call the variables
and and get the logic right andknow where to pull and what
library to like it just.
And then, well, you know, do Iuse VS code?
And then, well, am I supposedto have this in GitHub?
And like what repository?
And oh, and then there's,there's, there's dependencies,

(07:13):
right, like you have to dosomething with.
Like I forget what the Thingscan break, and like.
So we say I'm not underminingwhat you just said, but we say
how easy automation is, at leastin Python.
The more you learn, the deeperyou go and the more kind of
harder it gets, at least in myexperience and opinion.
So I like Ansible becauseAnsible is a really easy entry

(07:35):
right, like it's not that hardto create a playbook and you
have a config file and you know.
Just tell it what you want itto do.
But I kind of like that To yourpoint.
So in the chat Daniel Pelfreysays Ansible is your friend, it
beats using expect scripts.
And then some guy AMW FilmAnsible is amazing.

Speaker 3 (07:55):
I've been using it on servers.
Next step is to use it on mynetworks, colin.
Well, I think that there's somedecision paralysis which you're
touching on now.
If somebody hasn't engaged inautomation, the tool landscape
is rather complex and if youdon't benefit from some sort of
reference, either within yourown organization or through your
own experience, it can beoverwhelming.
Python is an easy place tostart, but Python in and of

(08:16):
itself is just a languagelibrary that has a runtime, so
you still have to wrap aroundthat your own experience and
then set it up in a way that'sgoing to interact with your
network devices.
Even now, I'm considering whatthe problem in networking has
been.
Guys, I think the call iscoming from inside the house, I
think it's us, I think it isnetworks, and I think we're

(08:38):
starting to see a change nowwith some of the tooling that's
coming out things like Terraformand more intent-based
networking.
Some of the tooling that'scoming out things like Terraform
and more intent-basednetworking, the meaningful
automation, the ones thatactually get investment from
large organizations, like thevery large enterprises that
actually do automate are basedon treating the network not as
its own entity that exists forits own sake, but making it

(09:00):
centric to what the network isactually there to do and that is
provide services to hosts thatare connected to it and connect
those applications to each otherand back to those users.
So that's also, I think we seemore automation in a WAN
environment with serviceproviders, because it's a much
easier ecosystem to make senseof in terms of how you're doing

(09:22):
service delivery andprovisioning system to make
sense of in terms of how you'redoing service delivery and
provisioning, and in the datacenter, where the common
reference architecture that EVPNVXLAN offers is more homogenous
with the intent tools.
A lot of every DC control pointthese days has some form of
intent.
There's a rich conversation tobe had about what intent

(09:43):
actually means.
You need to be able to trustthe network to do what you tell
it to do.
If you're going to domeaningful automation, if you're
going to have the networkprogrammed in service of the
things that use the network, youneed to trust the network is
not going to break itself.
I know that there's statisticsin the data center.
If you take out power andtransceiver failures, we break

(10:04):
the network.
It's an unintended consequence.
So you think, about what amaintenance window is.
All a maintenance window isit's an amount of time you give
yourself to make sure that thething you're going to do didn't
break something else you didn'tmean to break and you fix it
before that window ends whateveryou broke right.

Speaker 1 (10:20):
Permission to break things and fix them in a certain
time period.
Real automation shouldn'trequire can't I would actually
say it can't require amaintenance window, it cannot
Hold on, hold on.
What do you mean?
Real automation, right I?

Speaker 3 (10:34):
say.
When I say I'm sorry, if you'reautomating something that is
programming the network and youneed to take a maintenance
window to do it, then I supposewhat I'm saying is that it's not
real automation, but it kind offalls into two categories.
There's procedural automation,which is the things like Ansible
, and if you're writing Pythonscripts and then if you play
with it long enough or you startwith the correct framework like

(10:55):
Terraform, there's declarativeautomation, and procedural
automation is just going to saveyou a lot of typing.
Generally I I've got somethingI'm going to do a hundred times.
I need to push this new VLANprovision of VLAN in a campus
network.
It's good for that becausehuman error is a real thing and
if I have to type something ahundred times, I'm probably

(11:15):
going to mistype it at leastonce or twice.
So there is value there.
When I'm looking at theenterprise no-transcript

(11:52):
talented resource pool butlimited resources like funding
or access to heart I'm talkingabout higher ed Let me just cut
to the end of the story here anda lot of their focus was how do
I turn a these common workflowsinto a self service workflow
that somebody can now go andself provision, a wireless

(12:16):
network for the SSID orsomething for their dorm right,
self provision, a temporary keyfor the wireless if they have
somebody sticking a stay.
So what's changing right now is,I think the tooling that allows
us to manage networks withdeclarative automation and
intent are getting better, whichmeans that any of the

(12:37):
automation we put over the topof network management can now be
rightly considered to be a farmore reliable source of truth.
And when that happens, you getto do some magical things where
you have the users or you havethe applications that use the
network, telling the networkwhat they need, instead of
somebody opening up a ticket andthen people having to work

(12:58):
together and try to build aworkflow which in and of itself
can be repetitive.
I feel like I've gone farafield, so I'm going to stop for
a second.
But this is just that's.
The inflection point I thinkwe're at right now is just the
tooling itself and theframeworks we're using are
starting to shift.

Speaker 1 (13:12):
I want to park there just for a second and then, jeff
, I'm going to, I'm going tohand it off to you because I see
you have something to say.
So I think something important.
You said no-transcript andthat's what we did, and then I

(14:07):
think, two maintenance windows,we banged it all out.
But I wanted to mention youwalk through the continuum of
something like that, likeautomate a thing, with something
that types faster for you andpushes it faster for you too,
the intent, declarative stuff.
And I guess you said source oftruth, right, what I keep going
back to in these conversations.
You ended at the promised landI of like push button, get

(14:31):
banana, the 80 percent, let'ssay 70 percent, of the networks
that haven't automated anything.
I think there's a culturalcomponent that you called out,
right the.
The people like me who failedcomputer science in the 90s
didn't want to go intoprogramming, got into networking
instead because there was noprogramming and the jokes on me,
haha, I have to learnprogramming.
So I avoided it as long as Icould until I couldn't anymore.

(14:53):
But in places I've worked, ourvlans are housed in spreadsheets
.
Our ipam may or may not beaccurate.
There is no source of truth foranything.
The ip address is discontiguouseverywhere.
We just had a merger and now wehave overlapping ip space and a
firewall in between us nettingtheir 10 dot to our 10.

(15:14):
Like you know, we're inmulti-cloud where everything's
everywhere.
Like these environments arecomplex, they're crazy, they're
nuts and it would be great to bestart at the end, state right,
build it all, greenfield pushbutton, get banana.
My experience and I don't knowif this is what's feeding into
why it's so slow to be adoptedis there's so much technical
debt out there.
You had mentioned we weretalking on the side like

(15:35):
automation will not fixtechnical debt and I was working
four maintenance windows a week.
I worked 26 Sunday maintenancewindows one year, which were
like six hour windows that spanSaturday night into late Sunday
and if anything broke I was onthe phone all day Monday, right,
like I was drowning in work andexhausted just keeping the
lights on.
Now I know that automation intheory can get us to.

(15:57):
I can be more efficient, Idon't have to work as many
maintenance windows, we can pushservices faster, but I don't
know how organizations get from.
I'm drowning in debt, I'mworking round the clock to keep
the lights on and now I have toautomate stuff.
I just.
For me it seemed like too much.
It was a straw that broke thecamel's back.
It was like I don't want towork in networking anymore

(16:17):
because I can't freaking believe.
Now I have to be a coder.
Jeff, I didn't mean to cut youoff.

Speaker 2 (16:21):
So actually, daniel, in the chat already hit upon it,
which is, I think you have tostart small.
I mean, colin, I agree withwhat he's saying, that the
ultimate goal is to automateeverything and have it all push
button, get banana.
But, um, this is.
I've been doing some semblanceof network automation or
automation, uh, for my entireprofessional career, but I
haven't been doing it with theintent of making everybody

(16:43):
else's job easier.
I've been doing it with theintent of making my own job
easier, because I I haterepetitive tasks and I could
never work in a factory.
Can you talk about the ticket?

Speaker 1 (16:51):
tool.
Yeah, so I you talk about theticket tool.

Speaker 2 (16:52):
Yeah, so I'll talk about the ticket tool.
Essentially, when Andy and Iworked at Comcast together, we
were working in the NOC and wewere working in what's called
cellular backhaul.
That meant that we monitoredall the cell towers for T-Mobile
, sprint, at&t and Verizon andwe monitored Comcast's equipment
at those cell sites.
A big part of our job was justsitting and waiting for stuff to

(17:14):
break.
You didn't have to wait long.
You're not the main tech guy?
Exactly, yeah, we're not themain tech guy there.
Someone snags aerial fiber withtheir truck or something like
that.
Next thing you know, you've gotfive towers down.
When we were there, the processto open up a ticket Comcast is

(17:34):
super process, heavy and superorganized.
I learned you know organizationreally well at Comcast.
But that process to create aticket was I'd have to go into
what was it Remedy?
I'd have to open up the.
You know I'd have to start theinitial ticket.
I'd have to say, okay, this iswho all is down.
Okay, well, I've got AT&T down.
I need to open up a ticket forAT&T.
All right, now I need tocontact AT&T's NOC.

(17:56):
And then I'd have to go findsome document that someone had
created somewhere with thecontact information for AT&T.
So maybe it was an emailaddress, maybe it was a phone
number, maybe if this tower wason the East Coast, it was a
different distro that we wouldhave to send the email to than
if it was on the West Coast.
And so it became this arduousprocess to open up a ticket

(18:17):
because you had to jump throughall these different hoops.
Well, I got really tired ofhaving to go and figure this out
every time.
I knew we had an entiredatabase of all the towers and
who they belong to, and I knewthat the options were pretty
limited.
If I choose AT&T East Coast,this is their Knox phone number,
this is their email address andso on.
So the first thing I did was Ijust dropped it into Excel and

(18:40):
started creating VLOOKUPs right,which was basically, if I put
in this cell tower, it wouldlook up in the database and say,
oh, that's an AT&T tower.
And then it would look up againand say, okay, well, an AT&T
tower on the East Coast is this.
Anyway, the long and short ofit was it was just an Excel
document.
I really got a little bit lazierand started figuring out with
macros.
I could actually control thekeyboard and mouse and do

(19:01):
essentially keyboard emulation,and so I even had it.
So I set it up where thecomputer would go and it would
open the ticket for me and thenit would take all the
information from there and itwould pop it into the ticket.
So I didn't even have to dothat, and then it would write
the template for the email thatI had to send to them, and so it
did all this stuff.
That just became repetitivetasks and it didn't start out as

(19:22):
one big project.
It started out as a bunch oflittle projects.
I need to be able to look up atower and know which carrier
that is.
I need to be able to look atthat carrier and know their
email address or their phonenumber.

Speaker 1 (19:33):
How did Excel send information to Remedy Like?
Was that an API call?

Speaker 2 (19:37):
It was using.
No, it was actually no man, Istill don't know how to do API
calls.
I just make stuff up as I go.
No, that was it was literallyusing.
It was a Visual Basic which isbuilt into Windows.
It was using Visual Basic to beable to control stuff and it
was as simple as it gets.
But what ended up happening wasthat I was creating tools that

(19:57):
were super consistent.
All of my notifications readexactly as the company wanted
them.
I never messed up and saidVerizon.
When I meant to say T-Mobile,all of my stuff looked so clean
that another engineer was likehey, what are you doing over
there?
And so I showed him my thingand he's like that's really
great.
And then he told our manager atthe time and our manager was
like that's amazing.

(20:17):
And the next thing you know,I'm running an Excel document
for the entire team and updatingthis thing and doing change
notifications to the team.

Speaker 1 (20:27):
For all three shifts.
It had to be used with that,but it saved so much time.
It took 15 to 20 minutesfighting Excel and spreadsheets
and documents and databases justto get a ticket open.

Speaker 2 (20:37):
The cell tower was on fire.

Speaker 1 (20:38):
And what was it like?
Two minutes, a minute 30seconds, I forget it was 30
seconds.

Speaker 2 (20:42):
We went from 15 minutes a ticket to 30 seconds
that it took to open up a ticketand that was because it was
Visual Basic and I wrotehorrible code, was Visual Basic
and I wrote horrible code.
I still write terrible code.
But I guess my point is I thinkwhat happens is, as engineers,
we get so focused on well, itneeds to be exactly this and we
OCD over it.
Sometimes it's just a matter ofcome up with some project for

(21:03):
yourself, Like the thing Italked about earlier that I did
in Ansible.
I knew that was a repetitivetask.
I'm constantly starting newvirtual FortiGates to build up
some lab, and some of them arelong-term labs and some of them
are just.
I need to build this thingright now to figure out
something for a customer and Iautomate it.
So now it happens in fiveseconds to build it.

(21:23):
That's for me.
It's a selfish script.
It does nothing but help me,but I learned something in the
process.
I learned Ansible.
I nothing but help me, but Ilearned something in the process
I learned ansible.

Speaker 1 (21:32):
I didn't know ansible before I actually thought of
the program.
I want to read a comment in thechat and then I'm sure colin
has um things to say.
So dan riley in the chat saysthe main resource jeff had here
was time.
If you're already drowning, youwon't be able to pull off
automation, right?
So again, harken back.
Well, okay, harken back to mytime in prod like drowning bro.

(21:53):
Drowning like I hate my life.
Drowning like why did I go intoyour?

Speaker 3 (21:56):
drowning was a little different than jeff's, though
right like jeff, you wereoverwhelmed by a process that
had a workflow that required youto do a lot of the same steps
over and over.
What andy?
was describing if I can take theaside.
Here is something that I thinkis a cautionary message to
anybody who's thinking aboutautomating, and that is if your

(22:16):
network's already on fire andwhen I say on fire, you were
using scenarios, andy, likeoverlapping address space, a
subnet.
Creep things were a mess, youdidn't have a source of truth.
Creep things were a mess, youdidn't have a source of truth.
Automation is a dangerous thingto use as a workaround for
foundational network designissues.

(22:38):
It can be, tempting and also itcan be somewhat discouraging if
you're a network engineerlooking at that landscape and
trying to figure out how do Iuse automation to abstract some
of these challenges.
I know, at least fromexperience doing other things
that are automation adjacent,that all you're going like don't
take a problem and make it morecomplex with automation just by

(23:01):
distracting things.
So I would say you want to fixthings first.
If you're looking for projects,some of the things that.
I'm thinking about doing areprobably going to be things at
my own house, with my ownswitches and stuff, to begin
with, because what am I going todo at nokia and I don't have
direct customers yet because I'mless than four months in.
So it's that was one of thethings we were talking about in

(23:21):
the discord leading up to thisis where do you what?
What is sort of the perfect,what's the description of?
Like the perfect firstautomation task, and not I also
accepting that you cannot lookaround at your org and say we
don't really need to automatesomething right now, and I think
that that's true for a lot offolks.
One of the things that was in mydecision making for leaving

(23:44):
Juniper and coming to Nokia wasthat I knew that the job was
going to force me to learnautomation, that I could
continue to work in the rolethat I had previous and still
continue not to touch it, and Ifelt that I needed that extra
torque.
I couldn't find stuff to doover there and I can find stuff
to do here, so you don't have toautomate every network, and if

(24:07):
you do, you should be carefulabout the things that you're
looking to automate, because,jeff, I'm also guessing that you
then became the owner of thatsoftware, right, correct?

Speaker 2 (24:16):
And that's the thing.
The software ended up saving metime, but it ended up eating a
ton of my time.
But I spent my time doingsomething where I was learning
something, as opposed to doingthe repeating thing.
And that's where it's like theargument that Daniel made, which
is Jeff had time.
It's true, I did have time, butit's only because I ended up
literally saving.
I ended up making that time formyself because I could learn a

(24:40):
V lookup command in 15 minutesand that V lookup saved me three
minutes every time I create aticket Right.
So once I figured out how toautomate the entire 15 minute
ticket process, it meantsomeone's like open up a ticket,
I push a button and I'm doneand that's a repeatable task.
But you're right, you can'tautomate everything, like I have
customers constantly asking meyou know how do we template

(25:01):
something where every site isdifferent?
And the answer is you don'tright.
You don't template somethingwhere every site's different.
It's impossible the same withauto template automate same
thing.
You know, if everything'sdifferent, you can't do it.
So you shouldn't automateeverything.

Speaker 3 (25:14):
It's a tool.
God help you.
If you build a tool that peopleuse, because it's going to be
like picking up cursed armor ina game, you're not going to be
able to put it down.

Speaker 2 (25:22):
Yep.

Speaker 1 (25:23):
Is it fair to say that networks are more complex
than they've ever been?

Speaker 2 (25:32):
In many respects.
I don't know that in every way,though, but I mean in a lot of
ways.
Take, take cisco.
Right, if you tell me that youhave a cisco network and I would
say, all right, well, uh, whatare you running?
Well, are you running cisco ios?
But, yeah, we're running ios.
You're running nexus?
Yes, are you running nexus withaci?
Yes, all right.
Are you running a firepower?
Yes, none of those are the sameoperating system and that's
just one vendor.
Right, it's like you could dothis with every vendor in the
world.
So in some ways they're morecomplex, but in other ways, like

(25:56):
Colin was saying, we do havesome tools that fix some of that
.

Speaker 3 (26:01):
I think that as bandwidth has increased and
infrastructure has paced that toprovide better I mean, it's
Moore's Law Things get cheaper,you can put higher bandwidth in
places that wouldn't havenormally gone.
That has allowed us to startshifting more services onto the
network.
So in the sense that we are nowlike the, the simpty, uh, a uh

(26:24):
audio video stuff that'shappening now, where now we're
doing 4k, 8k AV streaming over anetwork instead of on its own
discrete audio visual system, orthe upgrades that we're trying
to do right now to the criticalinfrastructure, where we're
seeing a convergence of ITOTsystems, which wasn't possible,

(26:49):
both for secure and forthroughput and connectivity
reasons, even 10 years ago.
So what a network does hasn'treally changed much, because
networks don't exist for theirown sake.
Networks exist as a tool tointerconnect resources and that
has not changed at all the typesof resources that we're now
putting onto networks and thedrag pull through effect of

(27:14):
requirements that that createsin terms of protocols that we
need to develop, ipv6 obviouslybeing developed in order to
address the yeah, oh, my god,we're gonna run out of v4 space,
remember that and the butthings like a VP to audio video
bridging, yeah, and EVp and vxland, which is sort of the end

(27:34):
state of what we've been tryingevery protocol that's ever run
in a data center has tried toaccomplish, which, in its heart,
is very simple, and it's justtrying to trick two services
that are geographically apartthat they're connected to the
same broadcast domain and rightnext to each other, but that's
that's it.
So everything we do is trying toget to that abstraction layer.
We're getting better at it, sothey're getting more complex in

(27:55):
terms of how we have to supportthe services.
But if you look at AI datacenter designs for training
networks, it's simple.
There's not a lot to them.
It's just throughput andlatency.
They're packet pumps.
Build it up, build a raildesign and run it to within an
inch of its life for eightmonths, six months, three months

(28:15):
, whatever.

Speaker 2 (28:17):
Yeah, a lot of problems are solved when you
have more bandwidth.

Speaker 3 (28:20):
That, I believe, has simplified some of the stuff we
had to do more relevant is we'reall getting a little bit more
comfortable with letting thoseservices that rely on the
network exercise a degree ofagency over the network and
program it.
To a certain extent, that iswhat most funded automation at

(28:44):
any organization that reliesheavily on automation is focused
on.
It's not making that one task alittle bit easier.
That might be a part of alarger platform or framework
that gets designed, but that'salmost always going to be
something that's driven by anintent, and that intent is never
expressed as a directnetworking configuration to a

(29:05):
certain device.
It is a description of whatservices need to communicate
using the network and wherethose services reside, and then
behind that is all theconfiguration that then gets
generated.
And I think it's fascinating,and I think it's cool that that
is kind of where we're at,because we now treat a network
as this gestalt entity asopposed to these collection of

(29:26):
nodes.
And when you do that, somereally cool things start to
happen.

Speaker 1 (29:29):
I think that, well, so we're talking about all these
reasons that people shouldautomate, right, and it reminds
me so where I'm going was likepsychological factors, right,
Like yeah.
I learned this from Mike Bouchonlike cognitive biases, right,
like so we think and we do this.
We do it with our kids, we doit with our spouses.

(29:50):
So we think and we do this.
We do it with our kids, we doit with our spouses.
We think by continuing to saythe same things over and over
again, louder and louder, if wesay it enough, we'll convince
people to see the world the waywe see it.
So, as I hear Jeff talk and asI hear Colin talk, I keep
hearing the automation drumbeatthat I've been hearing forever
and I don't know if justpresenting information more and

(30:11):
more louder and louder indifferent contexts, I don't know
if it addresses the cognitivebiases.
So, like Colin had mentioned,like loss aversion and
negativity bias.
So I thought they'd be like twoquick things because really, if
you're trying to changepeople's minds and that's, I
think, what we're trying to doin the networking industry is,
you know there are plenty ofbenefits of network automation.
I don't think anybody could, Idon't think anybody could look

(30:33):
and see what automation can do,like if it was easy, if a vendor
could figure out an easy button, if there was a way to take all
that complexity, and like ifthere were, you know, like so
culturally right, I mean, we'llget into the cognitive thing in
a second but I always felt andit wasn't my main constraint but
automation is going to take myjob.
They're trying to do more withless people.
People are expensive, right,but maybe that's loss aversion,
right.

(30:53):
I think that they're going totake my job, are they?
Or is this going to make my jobeasier?
Because then I see Jeff's storyabout the ticket tool.
I worked in that NOC for yearsand I spent my first year
spending 20 minutes per ticketopening it.
And then Jeff comes along andthe sun shines through the room
and he's like hey, check thisthing out, and you press a
button and in 30 seconds youhave what used to take you 20

(31:14):
minutes.
It didn't take my job.
We didn't lay people off at theknock.
I have proof, I mean, for me inmy life.
I kind of need proof thatrefutes my belief systems and my
core beliefs, to really look atthings differently.
And Jeff, that was just oneexample of like oh, the ticket
tool didn't take anybody's job.
I remember when you left theywere freaking out Like, oh, my
God, who's going to manage thetool, the biggest problem of

(31:34):
Jeff leaving the NOC was like ohno, who's going to do this?
And you spent your last twoweeks there trying to train
everybody on the ticket tool.
So, like, loss aversion is apsychological factor, right, and
I don't know how much of thisplays into people, but what's
the thing?
But what's the thing?
Like losses feel twice asimpactful as equivalent gains.

Speaker 3 (31:52):
So, like we do everything we can to like and
the number of negative scenariosare 10, outnumber the positive
ones 10 to one, when you'remaking a decision too, yeah.

Speaker 1 (32:00):
It's really stacked against so like, right, yeah, I
mean, am I going to lose controlover my network if I start
automating?
Are they going to get rid of meif I start automating?
Are they going to need less ofus if I start?
I don't know how many of thosedifferent cognitive biases are
in there, because you reallycan't and I don't want to draw a
parallel to IPv6, even though Ido and I keep saying it and I
don't know if it's the samething but when you see something

(32:22):
that makes so much sensetechnically, that solves so many
problems, that makes technicallife better, easier function
better, get rid of problems likeNat and V6.
And for us as an industry notto adopt it, there has to be
something else going on besides.
People haven't heard enoughpeople tell them they need to
automate, and that's what I wastrying to, that's what I wanted

(32:44):
to get to.
Tonight is like there seems tobe cultural and cognitive stuff
and psychological, like as anindustry, we have said no, leave
me alone, go away, I have abuddy, and then Kyle, and I'll
hand it to you.
I have a buddy who works in thepublic sector he works at I
won't even say where or whatstate he's in.
He works in the public sectorand there's six of them that

(33:05):
just spent I don't know if hesaid three weeks updating.
I don't know if it's SNMP or itwas some.
Oh, it was an IP helper address, so they had to dude.
They had $600,000 worth ofnetwork engineers spending three
weeks of their time doing itmanually.
That is the state of most ofnetworks, like that is how we
are managing networks.
Now it's bonkers.

(33:26):
But what he said was well, I'min the public sector, we're slow
to change, they're not makingus automate and honestly, bro,
I'm going to be retired by thetime they're making people
automate around here.
So that is the mindset I think.
I don't want to say he is arepresentation of the rest of
the industry.
But I was fine doing it the oldfashioned way, manually and slow
, because it was intimidating tolearn coding.

(33:47):
I was afraid and I also have myown cognitive biases.
I'm not smart enough to codebecause I failed out of computer
science in college.
It's not true, because, spoileralert I used the NetMeco
library to use Python to loginto a router and change a host
name, but that's after likeseven years of me bitching
publicly about all the badthings about coding.
So this has been a journey forme too, and I'm just now getting

(34:10):
to the point of like being opento these conversations, being
open to work on it.
Colin and I may announcesomething at the end of the show
, but I think we're going tolike issue a challenge to each
other and actually make eachother automate things in
networks.
Colin, you wanted to saysomething, but I think there's a
lot of psychological stuff anda lot of biases and it's really
I don't know how you I'vewatched people like Mike as a

(34:31):
wizard kind of change people'sminds.
I've watched people like Mikeas a wizard kind of change
people's minds.
I don't know if I have thatskill today and I don't know if
the three of us on this show canchange anybody's mind tonight
about how they feel aboutautomation, because the industry
just really sucks right now atadoption and telling them over
and over again how greatautomation is doesn't seem Like
the network automation forum isdoing great work.
I think it's amazing.

(34:51):
I haven't been there yet and Ihope it's not a bunch of people
who are automation zealots whoare telling each other how great
automation is, because thathasn't moved the needle in 20
years they had really good toolstutorials.

Speaker 3 (35:04):
I was at the last autocon and I hear.

Speaker 1 (35:06):
It's amazing.
I'm not trying to be up on them, right oh no, you're.

Speaker 3 (35:10):
I, I had the same concern, uh, and they?
What they did was very nano, Iguess, where somebody would
present a scenario and thentheir presentation was walking
through the tools and theoutcomes that they got and how
they got there.
Less of a evangelicalconversation and just more of a
practical application.
I wanted to say that I don'tnecessarily think it's just

(35:33):
individuals deciding not toautomate Companies, the
organizations that we all workfor.
It's not just automation.
How many times have the?
You know we, objectively, thisis the thing we need to do to
fix our network, just putautomation out of it.
This needs to be refreshed,this needs to.
We need to do X, y, z and itdoesn't get done right and it is

(35:54):
part of that decision matrixthat's so influenced by risk.
What I discovered in the timethat I was in SE is that what
status quo was really code forwas people that were really
comfortable with the predictablefailure, so much so that they
weren't willing to take a chanceon unpredictable success.

(36:14):
So, unless you have a supportsystem around you that's
encouraging and saying, hey,we're all going to learn this
together.
You know, this is an initiative.
Most of the appeals that we'regoing to have to make to try to
get people, or even ourselves,to learn something new and this
is true of everything Automautomation is no different is

(36:35):
really kind of that Maslow'shierarchy self-actualization.
What am I going to get out ofthis?
So you mentioned Mike and hisability to change hearts and
minds.
The superpower he has is beingvery aware of who his audience
is and being very good at makingreal-time personal appeals.
You don't tell your own story,you tell that audience's story

(36:56):
with you in it, right?
You make them.
What Mike would say is you makethem the hero of that story.
So getting people, I think,interested in automation is
painting a picture, and it'svery specialized.
So it might be very difficultin a forum like this to make
something that's bespoke enoughto actually get somebody excited
, which is why I'm hoping justgiving somebody something easy

(37:18):
to consume and showing themhere's the steps that I'm taking
and you can follow along clickby click might be helpful that
there needs to be something thatsays look at how good this is
for you personally at the otherend, because ultimately a lot of
folks that are going to startan automation journey are going
to have to do so without anyreasonable expectation that the
work that they do is going tomake a change to their material

(37:44):
existence.
Right, they're just going tohave to kind of do it for
themselves and then, as they getmore comfortable with it,
they're going to get better atdoing things more efficiently.
You actually one of theexamples you used at the
beginning was like we were gonnado this thing.
It was gonna take a long time.
So we sat down and we spent aweek building a automation tool
and the first thought I had wasif you had just worked eight

(38:05):
hours a day for five daysstraight, could you have done
what that tool did?
Maybe the answer is yes, maybethe answer is no.
It's hard to connect with thevalue of that automation
assuming it gets done correctlyanyway when you start with the
actual time that you invest intoit versus what you're actually
going to be automating.
So you kind of have to do itfor yourself.

(38:26):
And that's where I think justhaving some basic understanding
of the tools landscape, so youdon't get into that paralysis of
where do I start, uh, and whatdo I use, might be helpful,
because it is.
There's a lot out there andthat's git has been a blessing
and a curse, because git is likeoh, we have all this repo and
this collaboration and it'swonderful and it's like that's
so awesome.
What tool do I use?
I don't know.

(38:46):
This thing that I use has beenforked like 40 times, so I don't
know which version is best foryou like uh I think it.

Speaker 2 (38:54):
I think it's easy to come up with a lot of reasons
not to do something.
If you look at the chat rightnow, there's been the if
automation goes wrong,automation goes really wrong,
Absolutely legitimate.

Speaker 3 (39:05):
It's a megaphone.

Speaker 2 (39:07):
There's been the argument that you're going to
spend an hour troubleshootingsomething that maybe saved you
15 minutes 100% true.
There's the argument that it'snot in our makeup as network
engineers to be programmers, andsome of that's true.
Our brains don't necessarilywork that way.

(39:28):
But I guess the way I've alwayslooked at network automation,
the way I look at really anytask that I take on, is I can
spend hours doing repetitivetasks and get them done, and I
can do them pretty well.
I can do those repetitive tasks, or I can spend hours learning
how to automate that repetitivetask.
At the end, I actually learnedsomething with one of those two

(39:49):
choices.
The other one, I just repeatedsomething I already knew, two
choices.
The other one, I just repeatedsomething I already knew.
And so for me, I'm alwaysconstantly in a state of wanting
to learn something, because Ican't imagine wanting to do the
same thing over and over, whichis part of what got me into
network engineering in the firstplace.
Right, it's a job where we getnew problems and it's a job
where there's always a solution.
And for me, I just I like totry new things, I like to try

(40:12):
new things, I like to see newthings and I understand that
sometimes you don't have a tonof time on your plate to go and
learn new things, but we've gotthe stuff that's happening with
ai right now.
So many people are kind offeeling the same way about ai
that network engineers feelabout automation, like I'm
steering clear of that, I'm nottouching it.
What happens when it spits outwrong information?
And?
And the answer is absolutely itcan do that.

(40:34):
If you were not, I mean like Iwouldn't enter a command that a
network engineer I knew reallywell gave me if I didn't know
what that command did.
So it's about going andfiguring out you know what am I
doing?
Why is this doing it?
And you can do that with theautomation tools.
But start with you know, put inthe chat, start with show
commands.
We used to.

(40:54):
One of the biggest or the bestscripts I ever wrote was one
where we had to do bandwidthcapacity checks over at SunGuard
and what it was is we'd beturning up a new customer and
that customer would want a onegig circuit and I would have to
go and check all the LSPs ontheir MPLS circuit.
I'd have to check every hop byhop by hop to make sure that if
this guy wanted one gig service,we weren't going to create some
bottleneck and screw him upbecause it was an old network

(41:15):
and we were constantly having toupgrade it.
Well, that was a tediousprocess.
It took 15 minutes to go instep-by-step and check in the
bandwidth and we were able toautomate it.
But it took me weeks to writethe automation script.
But then what I got to do was Igot to take that automation
script and hand it off tosomebody who was not me and they
got to do that obnoxious,tedious job because they could
do it with a script and if theyonly had me doing the job, they

(41:36):
had another engineer doing thejob because they knew they could
trust us to get the rightanswer.
Once we wrote a script to do it, we could hand it off to
somebody else and our jobs weresecure.
So anyway, like I said, I thinkit's worth.

Speaker 1 (41:47):
I always think it's worth learning something and I
feel like that's the realadvantage of automation, because
I'm a selfish automator, youknow, I don't do it for
everybody else, I do it for me Iwonder if time is the lever
that you know, if that would bean effective lever to pull, and
I know this isn't a new idea,but, like if time is our most
precious resource, right in theolder I get, the more I that is
internalized.
Um, and I don't know if I wantto say it was daniel technia.

(42:09):
He's a guy in australia that wehad on and he's a big network
automator guy.
But he, you know, he said thathe would rather he would rather
spend time with his wife andkids.
He would rather spend timeplaying his guitar, riding his
bike, going fishing.
And the more he learns aboutnetwork automation and the more
he leverages network automationin his networks, the more time

(42:30):
he has to spend with his wife,with his kids, on his bike,
playing his guitar.
He's been able to stabilize hisnetwork work less maintenance
windows, the on-call.
He made a compelling.
He was like Andy, it's allabout time and I know you don't
want to do this, I know it'shard, I know it's scary.
You're telling me that time isyour constraint and I hear that

(42:52):
a lot.
I I'm drowning in work.
I can't do this one.
I'm going to do it and therealmost seems to be like I don't
know if I had time to study formy CCNA when I was working 55
hours a week as a Comcast Gableguy and doing my other stuff,
but like I needed to make achange in my life and try to
have a better life.
So I spent every spare moment Ihad during the workday and

(43:13):
hours every night and eighthours a weekend going to school
studying the stuff I put in thetime to learn route switch so
that I could become a candidateand get a job ultimately with
you, jeff.
So again, this is just moreproof in my own life of I have
spent time learning hard thingswhen I really didn't have time
necessarily, but I made it apriority because there was a

(43:35):
bigger, there was a biggerbenefit to that temporary,
temporary suck.
It almost reminds me of likeGoggins.
Like you got to embrace thesuck.
You got to do the things youdon't want to do and the things
that aren't fun or that don'tseem appealing now for a better
later.
You know what I mean and andthat.
So I don't know.
I kind of like that for myselfbecause again I have spent.

(43:56):
I can't imagine spending threeweeks, five maintenance windows
a week updating IP helperaddresses, like my buddy I
talked about.
But that's the decision they'remaking because that's the grind
they're in and that's just whatthey're going to do.
To your point and to Colin'spoint, you could probably spend
a week working on a tool andthen do that in a night or two.
Now you have just reclaimed twoweeks of maintenance windows

(44:17):
that you're no longer up for andtired the next day and grumpy
with your kids and less timewith your wife.
It's less maintenance.
Like you can do more work inless time.
Like that seems pretty good tome, right.
Like that couldn't.
It just doesn't seem like thenetworking industry sees the
value and how this is gonna maketheir life better.
It's going to take my job.

(44:37):
I don't want to do this.
I don't like coding.
Well.
I mean it's going to take yourjob.

Speaker 3 (44:42):
You would think it would be the motivator, but it
isn't.
That clearly didn't work, soit's going to.
It's going to sound like I'mbeing smart, but I actually I
had to Google this.

Speaker 2 (44:50):
It's going to sound like I'm being smart, but I
actually had to Google this.
I'm lying.
I chat GPG'd it, but then Idouble-checked it.
It was a guy named PeterDrucker.
I read this quote somewherePeter Drucker, he was a
management consultant and heused to have this saying that
said, managers must take thelead in making obsolete their
own products and services ratherthan waiting for a competitor

(45:10):
to do so.
I think there's a lot to besaid about that.
When it comes to automation,when it comes to AI, which is
could this thing someday takeyour job?
Yeah, but you better create thething that's going to take your
job rather than lettingsomebody else do it, because if
you are not the one that knowsautomation, they're going to
replace you with somebody thatdoes, if you're not the one
using the AI products they'regoing to replace you with

(45:35):
somebody is.

Speaker 1 (45:35):
So if you want to not lose your job to these things,
go be the guy that's using thetool.
I've said this before Icouldn't get my job at Fiserv
today that I got eight years ago, because now you must have a
modicum of Python knowledge toget that network engineering job
I had then.
I can't even get hired therewith my current Python skill
level for a job that I had.
So you're right, that needle ismoving and this is going to.
I mean, and this is alladditive I had Scott Robon, you

(45:56):
know.
I told him oh, my skills agedout and I don't know coding and
I'm on DevOps guy.
And he's like, try to reframethat.
Your skills didn't age out.
Route switch is always there,everything's running on a
network.
But this is additive.
You can, you can add it.
And he had another good point.
He said you know, programmingused to be done with punch cards
, andy.
He's like they found a better,more efficient way than putting

(46:17):
paper cards with holes in themto program computers.
The punch card people losttheir jobs, but the industry
became better as a result, right?
So I think this always happens.
There's always disruptivethings that come along and can
displace people.
So to your point right, youbetter learn the automation or
you're going to be out of a job.
And now with AI, it kind ofseems like that too.

(46:37):
Right, like you better try tofigure out what the hell is
going on with LLMs and AI andmachine learning.

Speaker 2 (46:43):
At least to be able to have a conversation.

Speaker 1 (46:45):
Well, right for you to keep a job.
I mean, I like to be employed,I like to keep a job, learn
something new, go learnsomething new.
Yeah, yeah, for sure.

Speaker 2 (46:53):
So we've been beating the same dead horse for 45
minutes.
What are we going to do aboutit?

Speaker 1 (46:57):
You know that was the point of this whole
conversation, right?
I don't know if anybody heardanything.
So for me, what I've beentrying to do recently is kind of
come in with that hot take inthe beginning, like network
automation is nonsense.
There's a reason the industryhasn't done it, sense, there's a
reason the industry hasn't doneit.
It's another next big thing,like V6 was, and nobody's
adopting it for that reason.

(47:17):
But you guys have made somecompelling cases for it and I
don't know.
Jeff, I'm kind of just fixatedon your time thing and your
example of that ticket tool.
And if you want to spend 20minutes a ticket and you're
opening 10 tickets a day andthat's how you want to live your
life, fine.
Or you could spend some timeand learn an automation or build
an automation tool and take 20minutes of work and make it 30
seconds of work.

(47:38):
I have just gained so much timein my life.
Again, maybe it's an age thing,but when you get to a certain
point in your life where yourealize or you lose some people
in your life, we're not hereforever, we only have so much
time, how do you want to spendit?
I don't want to spend itupdating 6,000 IP on purchases
in three weeks and make thisWindows right.

Speaker 2 (47:57):
Yeah, that's the thing.
I'm not saying you're going togain time back necessarily by
automation.
If you're the one writing thescript I mean someone in the
chat's like yeah, then you'rethe one that maintains it and I
spent as much time maintainingthat script as I did opening
those tickets.
I don't think that automationnecessarily is going to save you
time.
You were calling that, justsaid it's additive, right?
I mean, if I learn somethinghere, I've at least got some

(48:19):
knowledge that I can now buildon.
I can write Visual Basic or Ican read Visual Basic.
I can read Python, I can readBash, I can roughly read Perl.
I can't write efficiently inany of them, but I can read
other people's work and make itdo what I want, because I
learned from writing the basicstuff.

Speaker 1 (48:36):
Well, you said something the other day about
you felt like the networkingworld reached an inflection
point with automation.
Have you touched on that?
What do you mean by that?
Because it seems compelling tome.

Speaker 3 (48:47):
I think that the tooling is getting better and
while I'm no great fan of EVPN,vxlan, the campus network, the
idea that we're starting toimplement overlays and places
that they haven't traditionallybeen means that we are going to
have more network designs thatcan be easily viewed through the
lens of intent, where you havea distributed control.

(49:10):
What I'm saying is there's notreally a lot uniform networks
are writ large, and this is whydata centers are a great use
case for this, because there'sessentially a handful of
reference architectures and youjust kind of scale them
horizontally and then maybe youknow, three stage, five stage.
That is going to shift, likethe network control, the things
that you've described, theticketing integration ServiceNow

(49:31):
has got a ton of integrationsthat are just baked in.
A lot of this stuff that hasbeen historically automated is
now being put in a product, orproducts themselves are
addressing issues.
The thing that intent does isthat suddenly, if I have an
intent-based system, I don'tcare about that Excel
spreadsheet with IP addresses.
It's irrelevant, I don't needthat any longer.
The network is a single entity.

(49:53):
It's not this collection ofnodes.
I don't need to rely on eachnode's perspective of its local
space and what it's directlyconnected to.
And then do I mean this is thenetwork architect's job forever
was being able to look at thatmagic eye poster on the wall of
the network and blur their eyesuntil they saw the boat Except
in this case it was.
You know why is this ping notworking right?

(50:13):
And you've been relyinghistorically on collecting
information from individualnetwork devices and then using
your experience to infer whatcould be happening.
And an intent model says no, no,I just care about these
services.
Between these two points it hasa very different perspective.
What that means is that theinflection I'm talking about

(50:36):
with automation is that we'rethe skill set.
I think of the network engineerof the future.
Right, I'm not going to do theFuturama voice here, they're
Matic hands like a World Fairpresenter but is that network
engineer is going to be theperson responsible for the
network side integration of theapplication centric automations

(50:56):
that are being done?
So if you learn automation fornetworking and never, ever use
it to actually automate, it'sstill going to make you better
at interfacing with the otherpeople that run the higher
layers of the network model, thepeople that are in the
application layer, and the waythat they're thinking and the
way that they're building toolsand the way those tools interact
, because, ultimately, theydon't care about the network.

(51:18):
They care about therelationship between the
applications and servicesthey're delivering and
dependencies and the people thatneed access to them.
And the network to them is nodifferent than a water pipe in
their house, right?
They just want to turn on thefaucet and the water comes out
and we're plumbers and that's so.

(51:39):
I think we always have a job.
It's just we need to have aperspective on what that job is
going to grow into.
And it's now moving.
I think that when I said inflatelike specific pin in the
calendar, the adoption andinterest in Terraform, the
things that Red Hat Linux isstarting to incorporate with
some of their event, what istheir?

(52:01):
Nokia is using the same acronymfor something as them.
They have an EDA and we have anEDA.
There's a similar concept wherethey're starting to incorporate
more declarative andintent-based workflows into the
solution.
That's what's happening rightnow, that adoption, and there's
a long tail on it.
We all still have time, no needto panic.

(52:22):
But it is going tofoundationally change the way
that we manage networks and Ithink that's a good thing,
because what's changing is we'reshifting our focus towards how
they're delivering the services,and not just a collection of
access layer switches,distribution layer switches,
core switches, which is whatit's always been.
It's exciting.
I mean, I've been doing this fora long time and I'm excited

(52:42):
about it.

Speaker 1 (52:44):
You know, I think you're both right.
As you were talking, colin, I'mthinking about some of the
things I've done recently, inthe past 8 to 12 months.
That, like, I installed Linuxand I started messing around
with Linux, right.
And then, when I covered an NFTevent, I wanted to learn SR
Linux.
So the fact that I had Linuxrunning was good because I had

(53:06):
to install SR Linux in thatenvironment.
But I learned lab as code,right.
Like I think there was threeLinux commands and I had Docker
up and running, container Lab,sr Linux running and a YAML file
built a lab as code environment.
For me it took five minutesprobably.
Import the repo from Git, like.
So again, I'm saying thesethings out loud because a year

(53:29):
or two ago, if you were to toldme that I would know, like, how
to have Linux running in aserver, connect my VS code to it
, have be able to pull from aGitHub repo, get Docker and
container lab up with SR Linuxand then import the YAML file,
like this was all foreign to metwo years ago.
So, like, if an old dog like mewho's been bitching and

(53:50):
complaining about automation allthese years publicly, by the
way can can learn some of thesethings.
If I can change I think any ofus can and there are places,
like you said, that are creatingbetter tooling.
They're making it easier, thedocumentation's easier.
I mean for me to get a labworking and say GNS3 or EVE-NG.
I'd never been able to do thatin five minutes or so.

(54:11):
There was a lot of wranglingwith this and doing that and the
other thing and setting thislike and I love those tools, but
just lab as code.
And I guess I'll finish withthis my buddy, chris Margett,
that I worked with at Juniper.
He built this Terraformprovider.
I didn't know what Terraformwas and he was all in
infrastructure as code and I'mlike, all right, dude, like
you're just a nerdy developer, Ican't talk, like what are we
talking about?
But he, he spent an hourwalking me through it and I

(54:33):
understood it and I'm like huh,so like I could just write a
text file right, like it'sexecutable documentation yeah,
yeah, and it's kind of intent inthere, right, like tell it what
you want, push a button.
Terraform what is it?
Terraform create I forget theverbs, but like terraform apply,
right, it was amazing watchinghim do it and I told him and I
was on it, it was straight fromthe heart.

(54:54):
I'm like dude, I think I coulddo this and this looks
accessible to me and so like atool like Terraform, just as an
example, or like Labus Code orSR Linux or others.
So you know, I guess, if wewant to start closing it up, I
mean where I always tell peopleto start with Ansible because I
think it's the easiest thing todo.
You don't have to know code.

(55:18):
The syntax and the playbooksare pretty easy.
The config files, some IPaddresses I think it's been a
while since I've done it.
I mean, what would you tell the60 to 70% of network dinosaurs
who are still doing the IPhelper and maintenance windows
for $600,000 at a clip, like mybuddy that works in the public
sector?
Where do people start?
I mean, what do we say?
Start with something small,right, like start with something
that you can make your lifebetter with.

Speaker 3 (55:37):
I like the show commands or something that has a
small blast radius.
I mean, I imagine most peoplethat would tune into something
like this are going to have somehome networking switches.
Start by figuring out whatdifferent tooling those switches
can interact with.
Are you going to be usingOpenConfig or GNMI?
Are you going to be using heck?
You could use SNMP, whatever.

(55:59):
I mean, the most scripting I'veever done was Slacks and it was
painful and it was Juniper only.
I used some PyEasy, you know.
So there's libraries and stuffthat are focused on certain
vendors, but figure out what thevendors support and then cheat
like hell.
Somebody's already done whatyou want to do.
Don't think you have to cut itfrom whole cloth.
Go figure out what somebodyelse did, do it and then work

(56:20):
backwards through the automationwe say that where do you find
that?

Speaker 1 (56:24):
where's that place called?
There's no place you can getcode.
Well, a lot, of, a lot of.

Speaker 3 (56:27):
There was another one like a lot of companies will
also run their own repos orthey'll have their own forums or
presence where you can interactwith the community and get
access to tooling that'sspecific to their switches.
So I've got juniper hardwarehere, uh, at my house and some
hp and dell stuff as well.
But you know, ubiquity ispretty common in homes, uh, you

(56:52):
know that kind of stuff.
It that just figure out whatyou can do at home, uh, or?

Speaker 1 (56:58):
stack overflow.
That's what I was thinking, isthat?
Where people go and ask aquestion and then they'll give
you code like right, I mean,there's multiple places, I guess
you're gonna start, you'regonna google it, you're gonna
find it, but go like, go search.

Speaker 3 (57:07):
It's like, how do I automate the show command and
then use a postman right, whichis just I think Google, isn't
that a Google tool or something,I don't know, it's just, it's a
way.
It's the fastest way you'regoing to be able to just send a
command like a call, and it's a.
Basically there's two modelshere, and the one that you're
going to want to start with isjust I'm going to send a query
and it's going to send back aresponse.

(57:29):
Doing is you're creating asurrogate for a command that you
would type in a CLI and onceyou've got that done, you can
apply it and point it at as manydevices as you want.
But start small.
It'll start to feel neat andhopefully that'll be enough so
that maybe you spend a littlebit more time on it.
Also, it's like going to thegym or anything else that you
want to form a habit from,create some accountability
that's external to yourself.

(57:50):
Andy and I have had someconversations about how we can
do that with each other and finda community of people, whether
it's local or a lot of peoplehave, or cities have network
user groups from NUA and lookaround.
When I was trying to figure outresources to publicly speak and

(58:11):
get on stages and organize mythoughts, I started looking for
Toastmasters, chapters right,these things are out there, they
exist.
And the more you can build acommunity around you while you
do this, one thing that you'lllearn when you go to AutoCon,
andy, and you will, is thateverybody is super nice and
helpful and if you don't know adamn thing about automation,

(58:34):
everybody's going to want totalk to you because they're so
excited that you're there andyou're interested, and they want
to help and they want to followup and they want to exchange
information and they want toinvite you into Slack channels.
And they understand that onceyou get that ember going, you
have to kind of blow on it andgive it some more fuel.
And then, once you get it goingand I'm only now realizing that

(58:55):
with what's going on in LosAngeles, this is a terrible
terrible analogy to use rightnow.

Speaker 1 (59:07):
I think you get the point.
I'll feel like the hot girl atthe party at all.
Con.
I haven't felt like the hotgirl at the party in a long time
guys.

Speaker 2 (59:14):
I'm all in.
Jeff, what do you think, man?
Your closing thoughts, yeah, so, in terms of you asked the
question, where do you getstarted?
And I'm going to sound like I'mbeating the AI drum, but I'm
telling you the stuff that I can.
You know, I popped in thequestion to chat to you.
Give me 10 ideas for networkautomation.
One of them is automateconfiguration backups.
Well, that's a great one towrite.
Create your own IPAM, so IPaddress management on that.
Create a device configurationauditing so actually that's

(59:35):
something I do regularly is,instead of actually pushing the
script to the device, I'll haveit create my change plan for me,
so it tells me what I'm goingto put in there.
Like, if I'm writing a script,I'll have it write the change
plan, then it's copy and pasteand I don't have to hit commit
on that until I'm confident inwhat it's put in there, but
start with it.
Until I'm confident in whatit's put in there, but start
with it.
Find a project, I mean, and Isay the AI stuff, because AI can

(59:57):
give you 100 bad ideas in asecond and out of those 100 bad
ideas, you can usually come upwith a good one, and I think
that's what's really great.
Is it going to take over all ofour jobs?
Sure, probably someday, but notin the immediate future.
And I think right now, going inthere and just getting it,
having it spit out a bunch ofideas of what you could work on

(01:00:18):
and then use it as a teacher, Iliterally learned Ansible
yesterday completely fromChatGPT.
I didn't go to the internet foranything, I just went to ChatGPT
.
I spent an hour writingsomething that, in the end, is a
completely stupid playbook,right, I mean, it doesn't save
me a ton of time, but I spent anhour and I learned something

(01:00:40):
different and I had the time.
I had the time to do it.
So, yes, I realize that's aluxury that not everybody has,
but it was fun, right, I mean,it was a fun, interactive thing
and I wasn't working onproduction gear, so I wasn't
worried I was going to breaksomething, and the only person
in charge of change managementhere at the house is my wife and
I didn't even have to consulther with this.
We're good.
So, yeah, I mean, just find aproject, go do something, get

(01:01:02):
your hands dirty.

Speaker 3 (01:01:03):
Don't break the toaster.

Speaker 2 (01:01:04):
Don't break the toaster, I had a boss that told
me something that was the bestadvice I ever got from a manager
and it made me feel the mostcomfortable in my job and I
think I said it last time I wason.
Which was he told me?
He said go break things, don'tbe afraid to break things right.
Go, go break something.
Make sure it's not productionright.
You don't want to have togenerate your resume or your
resume anytime soon, but gobreak stuff in your own lab,

(01:01:29):
because you'll learn so muchmore by putting it together.
And the same thing is true ofautomation, the same thing is
true of scripting.
Go mess it up a couple of timesand figure it out.

Speaker 1 (01:01:38):
Thanks so much, guys.
It's been an incredibleconversation for me.
For all things Art of NetworkEngineering, we have a link tree
.
It's linktreecom forward slashArt of NetEng.
I always try to remind folksthat we have a great Discord
channel and they're called.
It's all about the journey.
There are thousands of peopleand they're studying all kinds
of things, helping each otherout.
Somebody just said they wanteda home lab, somebody else just

(01:01:59):
gave it to them.
So if you don't have acommunity around you, I highly
suggest it.
I've been in tech with thecommunity and without, and life
is much better with one.
So link tree forward slash artof net edge.
You can find all kinds of coolstuff in there, including our
Discord server.
Thanks so much everybody forjoining Guys.
Thanks, great seeing you againand we'll see you next time on

(01:02:21):
the Art of Network Engineeringpodcast.
Hey folks, if you like what youheard today, please subscribe
to our podcast and your favoritepodcatcher.
You can find us on socials atArt of NetEng and you can visit
Linkt socials at Art of NetEngand you can visit linktreecom
forward slash Art of NetEng forlinks to all of our content,
including the A1 merch store andour virtual community on
Discord called it's All Aboutthe Journey.

(01:02:42):
You can see our pretty faces onour YouTube channel named the
Art of Network Engineering.
That's youtubecom forward slashArt of NetEng.
Thanks for listening.