March 18, 2025 • 49 mins
In this episode, we dive into the evolving world of network automation with Dan Cruz, Enterprise Architect at Koch Industries. Dan shares his journey from military IT training to enterprise architecture, offering valuable perspectives on transforming network automation from individual scripting to an enterprise-wide strategy. We explore the challenges of justifying automation investments to leadership, the importance of focusing on business outcomes rather than technical solutions, and the delicate balance between building in-house solutions versus purchasing off-the-shelf tools. Dan also provides practical advice on starting small with automation initiatives, avoiding analysis paralysis with data management, and creating cross-functional teams that combine network expertise with development skills to drive successful automation efforts.
Where to Find Dan Cruz
- LinkedIn: https://www.linkedin.com/in/daniel-cruz-a1427249/
- AWS re:Invent: https://www.youtube.com/watch?v=7rSuagETP4I
Show Links
- Koch Industries: https://www.kochindustries.com/
- Open Telemetry: https://opentelemetry.io/
- Netbox (Network Source of Truth): https://netbox.dev/
- InfraHub by OpsMill: https://www.opsmill.com/products/infrahub
- Network to Code (Nautobot): https://networktocode.com/nautobot/
Follow, Like, and Subscribe!
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
I really don't like the term source of truth.
It's just so confusing.
Common language, I think, isimportant, especially in an
organization as you're buildingyour automation capability.
The concept behind source oftruth, intended state database
versus current state databasethose things are definitely
important.
How else do you audit yourconfigurations?
How do you audit yourenvironment if you don't know
(00:21):
what's intended to be thereversus what is actually there?
And then how do you aggregateall the data that's needed?
I've worked with too many teamsthat have gotten hung up on the
data piece.
You can sit and spin cycles fora very long time trying to
clean up your data or get yourdata to a very good state.
You can get stuck in analysisparalysis for a very long time.
(00:42):
Do I have the right managementIP addresses in place?
Do I know what my validatedsoftware is supposed to be?
Do I know what my hardwaremodels are?
Draw a line in the sand, pick astarting point and figure out
what data you need, just to getstarted.
Speaker 2 (01:08):
And someone else's data center far, far away.
I'm your host, william.
Today, as always, I'm joined byYvonne Sharp, and while I'm
still trying to ascertain ifpublic cloud is more Death Star
or Millennium Falcon, yvonne hasalready mastered the ways of
the Force and is completingchange orders with her mind
(01:29):
without even using generative AI.
How does it feel to be a Jeditoday, yvonne?
Speaker 3 (01:37):
Shockingly, the same as every other day.
It's good to be considered aJedi, but man, after a week of
travel, I am ready for theweekend.
Speaker 2 (01:49):
That might be what a Jedi would actually say.
So you're great.
Speaker 3 (01:54):
We could go all Lord of the Rings and say you know, a
wizard is never late, heappears exactly.
You know he arrives preciselywhen he intends to.
But then we'll make you ametaphor.
Speaker 2 (02:05):
So with us today is someone I've had the distinct
pleasure to spend some time withand get to know over the last
four years, I guess Someone whois well-versed technically and
strategically and is just allaround a good person.
That is Dan Cruz.
Welcome to the show.
Speaker 1 (02:23):
Hey, thanks, William.
Speaker 2 (02:25):
Thanks for having me here today, and how are things
going for you?
Speaker 1 (02:28):
Oh, it's been a busy week, same with Yvonne.
I've been traveling this weekand just been busy working and
trying to enjoy life with thefamily, so yeah, that's about it
.
Speaker 2 (02:42):
Yeah, I've been traveling a lot too, but just
for kids stuff.
Lately it's been prettyexhausting, a lot of weekend
travel.
So it's nice.
It's kind of like vacationcoming back home on Monday,
which is kind of weird to thinkabout.
Speaker 3 (02:56):
Sleep for losers and non-parents.
Speaker 2 (03:00):
Exactly, hey, and the more you go without sleep, the
more sharper you get.
It seems like it's almostmuscle memory or something.
I was reading something onetime, actually, that they did a
study this is over in Europe andthey would basically wake you
up in the middle of the nightand ask you to do like four or
five mildly complex tasks.
(03:21):
Mildly complex tasks, just pure, you know, from from dead sleep
.
And the mothers, like the Ithink it was like five to six
month your mothers with five tosix month, uh, infants, you
perform the best out of thebunch, even like on top of, like
ceos and such.
I thought, wow, that's reallyinteresting.
Speaker 1 (03:44):
I'd say sleep's a crutch, William.
Good resources don't need itand bad resources don't deserve
it.
Speaker 2 (03:52):
I feel like someone that had a background in the
arms of something like that.
Speaker 3 (03:56):
Yeah, so you know I'll be a contrarian on that
topic.
Sleep is my favorite thing, andwhen I'm traveling I actually
am able to go to bed earlierthan I do at home, and I take
advantage of that.
Speaker 2 (04:09):
So anyway, yeah, Anyway, yeah.
So I just got to get this outoff my chest.
I mean, I just have to behonest.
I mean I'm glad you're not aChiefs fan, dan, but I'm just
not excited about the Super Bowl.
I just have to say it publiclythis is Groundhog Day, but for
football I wake up in Februaryand it's the same thing.
(04:30):
Mahomes plays the hero.
You have Travis Kelsey, taylorSwift getting more screen time
than the touchdowns.
Eagles fans are screaming it,innocent bystanders punching
inanimate objects, refs makingcalls that divide the country.
It's like the Fast and Furiousfranchise of Super Bowls.
It just won't stop.
(04:51):
And either way, in either ofthose cities, someone's car is
going to get flipped.
But I digress Anyhow.
So today's topic Dan and I had areally good conversation about
network automation.
I guess it's been about.
It's been a few months ago, butthat's going to be.
(05:13):
The topic of this conversationis network automation and you
know I want to get into talkingabout you know, a lot of times
there's like a lot of hype,there's a lot of buzz, there's a
lot of buy this, buy that.
Lot of times there's like a lotof hype, there's a lot of buzz,
there's a lot of buy this, buythat, um and and many times
network automation, I think tothe public is not framed
correctly, even like the valueproposition sometimes isn't
(05:35):
framed correctly and it'sdefinitely been perceived in the
past is not a must-have.
But but that is changing here.
In the recent past it'sbecoming a must-have and it's
becoming business imperative,along with some of the other
top-end things, especially ifyou have any sort of on-premises
(05:57):
data center presence or yourown tech stack that you manage.
But yeah, that's the top of theconversation and I guess,
before we get into that, do youwant to give a brief background
just of your um, your experience, your background?
Dan, I don't know how far backyou want to go for sure.
Speaker 1 (06:15):
Uh, we'll go.
We'll go back to I don't know2005.
Uh, I was in the military for aperiod of time.
That's where I got most of myIT training, been deployed
overseas, came back, wentthrough a Cisco boot camp and
(06:36):
got my first CCNA certification.
That was like around 2007.
And did network engineering fora while in the military and
then finally got out, spent sometime working at a startup
company and then moved to mymost recent employer and been
(07:03):
there for a period of time.
I did automation in kind of allof those areas, primarily in
the infrastructure space,primarily with networking.
I am trained in, or was trainedin, a lot of different IT
systems through the military Imean we used everything, and
with large enterprise I mean weused everything, and with large
(07:26):
enterprise, so working at KochIndustries, where I'm currently
at as an enterprise architect.
Speaker 2 (07:39):
you know all kinds of technology, all the tools,
awesome.
Speaker 1 (07:45):
Yeah, I know you're spread out between like you have
quite a bit of not just networkengineering experience at this
point, but cloud as well.
Yeah, cloud space cybersecurity, space network server
infrastructure, backup recovery.
I primarily work with theinfrastructure teams, but at
times work with the applicationteams, and when I say
infrastructure, I include cloud.
Yeah so kind of got my fingersin all the things Awesome.
Speaker 2 (08:10):
And I know that my experience with network
automation is very few.
Network engineers in theearlier days really banged the
gong and tried to bringattention to network automation.
Usually you had a few that werelike writing a lot of like.
For me in my time it was pearlbash, scripting expect.
(08:33):
And one of the things that yourealize pretty quickly is that,
okay, when I leave this companylike this is dying, I didn't
make an enterprise widetransformation and at the end of
the day, what value was throughthere other than making my life
easier, making me go faster andallowing me to do more work in?
What really becomes importantis bringing attention and making
(08:56):
an enterprise widetransformation.
But can you kind of talk tothat a little bit?
Like, when did you realize,like in your journey, that, okay
, this like, how do we make thisa strategy and a culture change
rather than just scripting?
Speaker 1 (09:12):
Yeah, I mean to your point right.
There's always that one guy ora handful of people that are
super passionate aboutautomation and they're out there
writing scripts, but it's justnever sustainable.
Once they leave, the automationstarts to fall apart.
Nobody knows how it was built,no one knows how it was coded,
(09:33):
all of those things.
So I realized it when I stayedin the same organization but
transitioned roles and startedworking on other things and I
saw the automation that I builtfall apart and I had to get
pulled back in um to fix it.
Um, that that's how I realizedvery quickly that like, hey, I'm
(09:54):
trying to do this other job,I'm trying to create this value
over here.
I can't keep getting pulled in,uh, to work on this old
automation that I built a whileback.
Speaker 2 (10:06):
So how did you bring attention to that to the right
people?
Because, of course, you can useopen source and just write raw
general purpose code to do allthe things, but usually there
has to be some strategy wrappedaround it.
A lot of times, maybe you needa steroid injection from the
(10:28):
outside, like some sort ofagency or some help to come in
and do discovery and, um, helpyou with things Like.
There's just a combination ofthings and all that requires
money you got to have.
You have money to spend.
So how do you get the folkswith the deep pocket books to
shed light on this?
Speaker 1 (10:47):
Really good question.
For me, it's very important tohave senior leadership or
executive buy-in to do some ofthese things, and they often
don't see it or understand thevalue of it, Because really
we're talking about creatingoperational efficiencies
efficiencies for the teamsthemselves and when you have
(11:12):
people that are coding orscripting and automating things
in the background without astrategic plan, it's kind of
like skunk works right, Likenobody knows what's going on,
right.
You're solving problems thatnobody knows about.
So you really have to exposethose gaps.
(11:32):
You really have to get seniorleadership to identify and see
the value that can be created byhaving a more strategic plan
and approach.
Speaker 3 (11:48):
Well, and one of the things that I've noticed too is
a lot of times like automationprojects.
They start very grassroots andthey start on the side.
They don't get integrated andcodified into the systems of the
organization right, so youstill are approving everything
with manual change requests.
There's always like theorganization right, so you still
are approving everything withmanual change requests.
There's always like theautomated way to do it and then
(12:10):
the hands-on way to do it, anduntil you get all those
processes codified into theofficial working systems, it can
very easily be left aside orleft behind when you have a
turnover and headcount, becauseit's all very, very tribal, and
(12:35):
especially in large enterpriseorganizations.
Those big enterprise systemshave a gravity to them that just
pulls everything that directionthem.
Speaker 1 (12:48):
That just pulls everything that direction.
I would agree with that right.
So when you talk about likeend-to-end process automation,
right, or event-driven typeautomation like those require
that you integrate with thesystems, that those are
triggered independently throughthe workflow, that sort of stuff
and that's, we don't really seethat in the in the very early
stages of the journey, right,it's always some highly
(13:09):
technical resources like oh, Iknow how to fix that and they go
and run their python script inthe background somewhere, right,
but they're manually kickingoff that python script.
It's not an orchestrated uh,orchestrated event that occurs.
Speaker 2 (13:25):
Yeah, that's a good point Orchestration versus
automation.
So, like automation, you havethese different pockets like
Python scripts that are run,maybe ad hoc, from a server, or
like even a cron, like I used todo this thing where I would
always run certain things fromcron jobs on servers and then
take the data and then dosomething with it and if it
(13:47):
broke, only me and one otherperson knew how to get it going
again.
And when you think about that,like leaders more often than not
these days are looking down andthey don't care that you were
smart enough to write somepython scripts and run them from
a server or a jump host in adata center.
When they they look down,they're thinking of services.
They're thinking of, hey, wehave this intake process, like
(14:11):
new product coming into fruition.
What are all the steps thathave to happen?
Like we want this whole thingautomated from beginning to end,
from the beginning thediscovery, the paperwork, the
changes, like the chat offs, allthe different things, all the
way to the point to where thisstuff gets configured.
Speaker 1 (14:29):
And that's a much harder problem to solve when you
bring in the business processesyeah, I was gonna say you know,
leaders are are more interestedin the business outcome.
What's the business outcomethat I'm driving towards?
Right, Um, and when you're likeoh well, automation can make us
more efficient.
Well, not when it's not end toend process automation, when
(14:52):
it's still like I have to callsomeone to go kick off a script
manual manually.
Yeah, you probably saved mefive minutes.
Uh, with automated script thatyou're running, but the?
How does that fit into yourwork process and how is it
making your work process moreefficient?
That's where the real valuegains are at.
Speaker 3 (15:13):
Well, and I think you know it's a sad reality and it
sounds harsh to say it, butnobody really cares if the IT
practitioners are saving time ornot.
I mean, unless you can convertthat into a real dollar value,
that applies to the business.
That's when it matters.
But I mean, basically most ITheadcount in most organizations
(15:36):
is it's planned for, it's in abucket, like they already know,
like it's just not calculated ina way that it's meaningful to
the business and it and itsounds harsh, especially if
you're that person and you'relike wait, you're saying my time
doesn't matter.
Well, not exactly it does.
(15:56):
Like it matters that you getmore done in a day.
But if you're making a businessargument like saving the IT guy
, time is not enough of anargument to push through a
system-wide change.
And that is an importantdistinction to understand when
you're trying to go and make anargument for automated systems,
(16:18):
because if your only answer isit saves this team of five folks
a day a month, or two days amonth, nobody's going to care.
I'm sorry.
Speaker 1 (16:28):
Especially when you like I've had this happen too
many times right, like thetechnical resources are like oh,
this is like, we need toautomate, we need to do all
these things.
Okay, let's frame this up,let's take a look at what it
will take to do this.
Okay, let's frame this up,let's take a look at what it
will take to do this.
And they always come back withthe like we need DNA center or
we need glue networks or we needwhatever you name, whatever
(16:52):
automation platform, right.
And it's like okay, you go tomarket and you look at those off
the shelf solutions and thecost associated at scale no, the
cost associated at scale.
No.
Like getting business buy-infor something like that when you
have no record, no history ofperformance, uh, in the
(17:13):
automation space is superdifficult to get alignment and
approval for yeah, one goodpoint there too.
Speaker 2 (17:20):
It's like that age-old decision making at least
as long as I've been working inthis space is build versus buy.
And more often than not, evenwhen it's time to buy a tool or
buy a platform, like, okay, weneed to go buy something.
More often than not you'regoing to have to go and try to
(17:43):
do the DIY approach first andfigure out how painful it is and
sort of do a calculation, arisk calculation, just all sorts
of calculations to decipher.
Ok, do we have the engineeringtalent to do this?
Do we are going to, you know,do we have all the things that
(18:04):
are required to meet thisoutcome?
Maybe we do 15 of it, but thisother platform does the rest.
Or you've got to figure out like, where in the abstraction
pyramid that you want to placeyourself, like, where, like when
do you buy?
But at times you just usuallyhave to go through the pain
first and prove out with dataand other things that, yeah,
(18:26):
this is why we need to buysomething, because we can't
accomplish this based on whetherit's the system we work in, the
engineering talent or theheadcount that we're allowed to
have.
Or maybe we can or can't bringin a partner.
So how do you look at that?
Is that kind of how you view it?
Build versus buy decisionmaking like how does that ring
(18:49):
through your head?
Speaker 1 (18:50):
the way that that I I've thought about it over the
years.
I mean so I've never seen atool fix a problem.
What what I've seen is goodpeople and processes adopting a
tool in the right way that thenfixes the problem.
So my approach I tend to focuson the people and process side
(19:12):
of it first, so you get theright skill set in, you get the
right mental models, you getpeople working and developing
their processes in the right waywith any tool, and I would say
this is applicable outside of IT.
My wife and I have thisconversation when we go to Home
Depot.
I see some cool power tool onthe wall and I'm like, hey, I
want that.
And she's like when was thelast time you built something
(19:35):
that required that type of tool?
Right, you don't need.
You don't need a power drill ifyou don't even know how to use
a screwdriver, right, Right.
So focus on the people andprocess side of it and then use
the tools that are available toyou and then at some point it
(19:55):
probably makes sense to comeback and reevaluate Do you have
the right tools?
Speaker 3 (20:00):
Yeah, well, that's such an important point because
I have seen, you know I'veworked in all different kinds of
organizations, likeorganizations that are large and
, you know, have large budgetsfor spending on every new tool
in the toolbox, and then verysmall organizations where you
have to be scrappy because youcan't buy the newest tools, to
(20:27):
be scrappy because you can't buythe neatest tools, and I think
what folks that haven't been inthis kind of environment it's
hard to believe honestly is thatsometimes throwing money at a
problem makes it worse.
Right, like I've seenorganizations end up with tool
bloat because they think, well,if we just go spend a truckload
of money, it will make thisproblem go away, and what they
(20:50):
end up with is tool sprawlwithout the people, processes to
implement it, and they end upwith a patchwork of stuff that
was never meant to work togetheror that was wasn't implemented
in a way that it's going to worktogether, and then like, and
then you end up with, likeprocurement people that are
hired to manage all the thingsthat you bought that you're not
(21:11):
getting value from, and it's,it's, it's this, I don't know
it's, it's.
It's a growing problem, that ofinefficiency and misuse, and and
so I think, like the starting.
What problem are we trying tosolve?
What's our business problem?
Who are the people andprocesses we need, and then what
tools we need.
I think that's very simple, butbut the right framework, and
(21:35):
it's easy sometimes fororganizations that are kind of
flush to skip the people processpart and and it's it's the
people process part and and it's, it's it can end up even toxic.
Speaker 1 (21:51):
um, yeah, I 100 agree with you.
I mean, like, if you just lookat the simple economics behind
there, right, like, depending onthe size of the organization,
right, you're probably going topay a million dollars for a good
tool off the shelf, right, andthen you need at least one
resource to run that tool, right, so you're looking at 1.1, 1.2
million, depending on how muchyou pay your resources and where
(22:11):
your resources are out of.
How many resources could I getif I didn't purchase the tool
and used open source and focusedon people in process and really
looked at solving problems?
Because in the former model,right, where you have one
resource with one tool, guesswhat?
You didn't solve your problem,because you still have processes
(22:34):
that are dependent on oneperson.
Speaker 2 (22:40):
Yeah, and throwing.
I mean those are all good,amazing points.
No-transcript, we did a thing.
(23:10):
But you're absolutely rightabout the cost calculations that
you have to make, because theprice of the tooling and how do
you even justify that cost?
If you have a network that'sran okay for for the most part
and it's never been such a bigproblem that it's gotten a, you
know, attention of leadership,how do you justify the cost?
(23:32):
And I think that the way that Itried to do that in the past was
actually, what am I?
What am I helping?
And it's a lot of times I wasable to get this over the board
with okay, we're not goingfaster, but since every outage
that we have for this length oftime costs the company this
amount of money and it isresulting from human hands and
(23:54):
misconfiguration, and thesedifferent things expand and make
our reliability better for thenetworks that power our whole
infrastructure.
That is where the value comesin.
So it's almost like I mean,maybe this isn't a thing for
everybody, but for me I saw alot of success with showing that
(24:15):
, okay, if we make veryconsistent changes, very small
changes more frequently that aremore controlled and they're
automated, no human hands, weare actually increasing our
reliability because we're makingconsistency.
Consistency equals, reliabilityequals kind of value, I guess.
Speaker 3 (24:33):
And you have to tie that back to the cost of the
outage.
Right for the business, right?
That's the secret sauce there.
Go ahead, dan.
Speaker 1 (24:40):
I was going to say it's hard, it's hard to do for
technical resources and even forIT leaders, right, because the
pain that you feel, the painthat your team feels, is the
pain that you're focused on.
Right, and you really have tolook at it from a different lens
, through a differentperspective of how am I
servicing the business?
What outcomes am I drivingtowards?
(25:01):
I servicing the business, whatoutcomes am I driving towards?
What's the opportunity cost forthe business when they're
waiting on my team to dosomething enable them?
So that's, you really have tolook at it through a different
lens.
And it's hard to do when, whenthe pain you're feeling is is so
right in front of you andevident.
Speaker 2 (25:18):
Okay, so I'll tee this up by one of the things.
It was when I first startedtrying, you know, we talked
about like the scripting andjust hey, I'm worried about
numero no.
I want to make my life easier.
I'm going to knock some changesout to to bigger, bigger
picture stuff.
One thing this was a long timeago and I know this space is
(25:40):
actually.
This space really hasn'tmorphed that much.
Actually, this space isactually the space really hasn't
morphed that much.
Actually, this stuff reallyhasn't changed that much in the
past 10 years.
To be honest, I don't thinkabout it um, uh, now that I
think about it.
But the thing about, okay, wehave what is our operational
state.
This is brownfield andbrownfield's crazy.
Everybody knows that brownfield.
You have different pockets ofbrownfield everywhere and you
(26:04):
have to.
When you do any sort of goodautomation, there's a problem
that you have to solve.
That's a very hard problemactually, and that is
deciphering between your desiredstate, what you want the
network to be, and what is inoperations today.
The rabbit hole that that takesyou down is bringing in some
(26:28):
sort of database or source oftruth or an aggregation of
sources of truth.
And when I started doing this,you basically had one solution
and it was pretty new at thetime.
It was Netbox and all opensource.
I remember the first time Ihosted NetBox in production, you
didn't have companies thatoffered support really on this.
We had it running on a VMoriginally and then we
(26:54):
transitioned to containers likeDocker, swarm and we were
running it on Swarm.
But now there's a lot of paidsolutions you can.
You know it's been sassified alittle bit.
You know it's kind of becomeits own little you know sort of
market in a sense.
So you have Netbox, notobot,from Network to Code.
You have a new platform, infplatform, um, infra hub from ops
(27:19):
mill.
So do you have any thoughts oropinions on whether this is a
necessary thing or and is thissomething that you need to have
teed up before you start doingany automation?
How do you think about it, dan?
How do you?
Speaker 1 (27:32):
think about it, Dan.
So I really don't like the termsource of truth.
It's just so confusing.
So common language, I think, isimportant, especially in an
organization as you're buildingyour automation capability.
I do agree, though, like theconcept behind source of truth
(27:55):
is important, right.
So, like intended statedatabase versus current state
database, like those things aredefinitely important, Like how
else do you audit yourconfigurations?
How do you audit yourenvironment if you don't know
what's intended to be thereversus what is actually there?
And then how do you aggregateall the data that's needed to
create a configuration or achange that's required in the
(28:18):
environment?
Those are all definitelyimportant things that need to be
there.
Whether or not you call it asource of truth, this is up to
you.
Me personally, I don't like thatterm.
But, getting started, I wouldsay yes, certain components of
(28:38):
that are required, and I'veworked with too many teams that
have gotten hung up on the datapiece for too long.
You can sit and spend cyclesfor a very long time trying to
clean up your data or get yourdata to a very good state.
I am trying to clean up yourdata or get your data to a very
good state, Right.
Most teams struggle I won't sayall, but most teams struggle
(29:00):
with like just inventory whatare all my assets and where do
they exist?
You can you can get stuck inanalysis paralysis for a very
long time.
Do I have the right managementIP addresses in place?
Do I know what my validatedsoftware is supposed to be?
(29:21):
Do I know what my hardwaremodels are?
Just draw a line in the sand,pick a starting point and figure
out what data you need.
Just to get started is what Iwould say.
Otherwise you'll get stuck inanalysis paralysis started is
what I would say.
Speaker 2 (29:38):
Otherwise, you'll get stuck in analysis paralysis.
I love that.
I know we I think we talkedabout this, which is why like,
that's kind of how I feel aboutit, because I know that there's
some folks reach out sometimesand you know, just having some
of these conversations, you seecompanies a lot of times they
want to actually account foreverything and get that source
of truth piece perfectly plannedout and all the data just
(30:01):
perfectly sanitized across alltheir multi-vendor, multi-cloud,
multi-everything network and ifyou do that, that's like a
10-year process.
It's just never going to bedone.
Organizations are toocomplicated these days,
enterprises are way toocomplicated and a lot of these
(30:21):
things, some of the things youonly have limited control over.
You don't have the same controlthat you have on your routers
and your switches, but you stillrequire some of this other data
, so you can't actually evenensure the integrity of it.
You can read it in and you canuse some of it, but you don't
control it wholesale.
You, you aggregate it to somedegree.
So if you're, you're absolutelyright, the analysis paralysis
(30:44):
thing is huge.
You got to get started.
You know that it that doesn'tmean that you don't need us.
You know some sort of.
You've got to have some methodor mechanism to differentiate
between that desired outcome andyour operational network and be
able to validate continuouslyas you go along yeah, I.
Speaker 1 (31:04):
I would say like, if you look at any switch
environment right, just theswitching environment how many
different switch models are yougoing to end up with?
Like out of a thousand devices,you're probably going to have
20 different models.
That would not surprise me atall're probably going to have 20
different models.
That would not surprise me atall, right.
And then of those 20 differentmodels, how many different OS
versions are you running?
Because if you're not runningany automation, chances are most
(31:33):
of that stuff's notstandardized and so, like when
I've gotten started with teamsin the past looking at
automation, it's hey, pick theswitches that are common that
you can run common commands on,group those together and start
with those.
Don't try and do your switches,your routers, your load
balancers all like your cloudstuff.
Like pick one environment andget started.
Speaker 2 (31:54):
It's great advice, I love it and that is, I'm
guessing, that that approach hasserved you well in the real
world.
Speaker 1 (32:03):
Making progress, absolutely right.
Like, and it's incremental.
I don't know how much we'vetalked about I know well, we've
talked a little bit about Agilein the past, but that's the
other thing.
Right Is shifting your teams toan Ag agile model and focusing
on MVP to make progress.
Right, like if we're doing youknow those waterfall projects
(32:26):
and we're trying to geteverything perfect, like it's so
difficult to make progressbecause this is such a big
problem.
You really have to take thishuge problem that you have with
automation automation break itdown into little incremental
steps that you can make progresson yeah, and by mvp for those
that don't know that term.
Speaker 2 (32:44):
We're not talking about the super bowl, most
valuable player, a minimal,viable product.
Essentially to say, hey, we, weneed a starting point, we have
to deliver some value.
But, hey, the sooner we getsomething out that door, the
sooner we can get feedback on asmaller component of it, which
makes it easier to reiterate andcontinue developing more value,
(33:08):
instead of saying, hey, we'regoing to get all the things done
at once and then ask forfeedback and then have some
elongated feedback loop.
We're getting it out the doorquicker, showing value quicker
and getting feedback quicker andmaking it better quicker.
It's a big deal, and that'shaving an agile mindset, an
agile team structure, bringingin some of the DevOps, which is
(33:31):
a culture, not a position, isreally important.
Speaker 3 (33:37):
It's a philosophy.
Speaker 2 (33:39):
It is Yvonne, is the philosopher, the resident
philosopher ranter.
It's all about the DevOps.
Speaker 3 (33:45):
It's how we think about how we work.
Right, it's more of an approachto working than it is like I do
.
Devops, Okay yeah.
Speaker 2 (33:56):
One thing I want to.
So one thing about you, Dan, isyou've never been shy of
throwing out good.
I mean, usually your opinionsare grounded and pretty, you
know data and experiences likegood stuff and they're usually
pretty spot on.
But I just want to get yourtake on the, the platforms and
(34:19):
tooling surrounding networkautomation specifically like is
it really matured?
Has it gotten better?
And then, differentiatingbetween you mentioned dnac
earlier, which before that itwas prime, and I've gotten stuck
in the muck and mire there inthe past.
But like the vendor producedboxes that you can install
(34:42):
versus the other tools andplatforms that are more maybe
bleeding edge.
But do you have any thoughtsthere on the maturity?
Like, is it maturing or likewould you like to see new things
?
Like, where is this thing going?
Speaker 1 (34:56):
maturing or like would you like to see new things
?
Like where is this thing going?
So, yeah, a couple of thoughtsthere.
So I think I think maturity inthe past has been limited based
on the way that you can connectto network infrastructure right,
like in the past with networkinfrastructure you were limited
to SSH, telnet, snmp asmechanisms to interact with a
network device for configurationand troubleshooting.
(35:19):
So I think that does limit yourtooling capability and the
maturity as such.
Now, over the last decade, yeah, things have been changing.
We have more cloud-basedsystems today, more
software-defined systems todayin the infrastructure space than
we ever have in the past, and Ithink that has opened up the
door for maturity within toolsets.
(35:41):
However, I think that's wheresome of these industry tool sets
are lagging behind and notkeeping up with the changes that
have occurred in infrastructure.
When you look at observability,otel, those type of things,
like some of the traditionalnetwork tooling, doesn't account
for that stuff.
It's still using SNMP as a wayof monitoring appliances.
(36:05):
Why aren't we moving forward inthose spaces?
Speaker 2 (36:10):
That is such a good point.
Right there they openedtelemetry piece.
I love that.
We can discuss that, maybe alsolater.
But yeah, go ahead.
Speaker 1 (36:19):
I do think that we will see some advances here soon
.
We're starting to see italready with things like agentic
AI, generative AI starting tobe built into the tool sets, and
I think that will help drivethings forward, make things
easier, but at the end of theday right, that's what these
(36:41):
tool sets do is they just makeit easier for development to
occur?
I think of it as like no code,low code opportunities right,
that's what those tool sets,those power tools are doing.
Dna Center the way that I seeteams interacting with that is
(37:05):
around kind of no-code, low-codemental models.
They're not putting in the timeand effort to upskill and
develop those pro-code skills tointeract through API and things
like that with the tool setsand create orchestrated
workflows and integrations.
Speaker 3 (37:20):
Well, so I guess I just like, I just feel like the
conversation still like how muchhave we moved forward?
Right?
I feel like these, you knowwe're still talking about SNMP.
I mean it's been 20 years andwell, for me, like it's not been
20 years for SNMP, it's been 20years for me and yeah, the
(37:42):
stuff going on with opentelemetry is super exciting.
But I do sit here and wonderlike, yeah, gosh, why has it
been so slow, just so slow?
Because I mean I feel likeeverybody knows that we need to
do it differently and yet herewe are I?
Speaker 1 (38:00):
I honestly I think some of it is us, some of it is
our network resource, likenetworking and applications were
so far apart for such a longtime, right like, and now, when
we look at automation, likeyou're really starting to step
into development and coding anduh, automation platform looks
(38:23):
more like an a full-blownapplication than it does
infrastructure, and I think wehave some some old mental models
within our network teams.
It's us that are holdingourselves back.
We complain and moan about theproblems that we have, but we're
not.
How often do you see a networkguy going out and learning how
(38:46):
to code and how to be adeveloper?
Speaker 2 (38:50):
Yeah, this is so true Like I can't count the
conversations I've had over thepast two years with leading edge
tech professionals that are inthe network space that they
don't understand when I saysomething like hey, enterprises
are actually locking down theirAWS console.
They don't want people logginginto the console and making
(39:11):
changes that way anymore becauseof the risk of all this
configuration drift.
They want this stuff codified.
They want of all thisconfiguration drift.
They want this stuff codified.
They want to produce anartifact because they want to be
able to roll things back.
You know, they want this modernapproach to managing network
infrastructure and it's it'slike well, why it's really hard
for network engineers, I think,a lot of times to see that value
(39:32):
and to see why enterpriseswould want to do that in the
first place.
And and that's something I meanwhat do you think about that?
Because that's something I seeat a lot of places right now
where the UI is being usedpurely read only and, if it's
not, at a given company, they'retrying to shift that way.
They want to really havecontrol over all those changes
because in order to basicallysupplant ITIL-based change
(39:56):
management, you have to have areliable and a thorough
understanding about breakingthose changes into smaller
pieces and only making them, youknow, completing them through
approved pipelines, or you knowsomething, workflows or
something similar.
Speaker 1 (40:12):
Yeah, I see the same thing happening, william, like
in the cloud space, applicationspace, definitely walking down
the ui, um and uh, followingbetter change control practices,
um.
But I want to go back for justa minute because I feel like
we've been pretty hard onnetwork engineers, network
resources, to be fair, right.
(40:33):
To be fair to guys like theknowledge required to
troubleshoot in the networkspace, right, all the things you
have to know about BGP, ospf,eigrp, like all the routing
protocols, layer two, wireless,like there's so much in the
network space, can we really belike?
Speaker 3 (40:51):
oh, now you have to go learn to be a developer like
oh, now you have to go learn tobe a developer.
Well, and still, the industry,like their startups, they're
trying, but our big vendors,they're doing some things, but
but it's still not as baked into the work as it is in other
(41:13):
industries, like in in cloud.
It's baked in, you know, likethe ability to automate, the
ability to deploy via code.
It is 100% baked into theplatform that those capabilities
are there.
And two, we're dealing withinfrastructures that may be
(41:35):
deployed for a decade, and sothe newer capabilities, they
just don't exist or weren'tdesigned in from the beginning.
And I think the the best thingwe can do is have a good idea of
what our, what we want thedesired end state to be, the
(41:55):
capabilities that we want at theend of the day, and and yes, it
is, you know, infrastructure ascode, automated deployment,
some sort of state discovery,all of those capabilities, and
then every decision that we makeincrementally needs to be in
that direction, and I think thatthat that is the piece that
(42:16):
often gets missing.
Is this overall, like vision, orand and and I feel like vision
is too lofty of a word, but thisreally clear objective that we
want to achieve.
And then the will, theorganizational will over a long
period of time to get there.
Because what happens is youmight have a great dynamic
(42:38):
leader who wants to geteverybody there, and then they
get scooped up by a bigger fishand then they go, they move on,
and then all of thoseinitiatives get replaced by a
new person who has new, you know, a new ax to grind and like.
To me that's a big part of theproblem, it's not.
It's not just like thepractitioners, it's the system
(42:59):
as a whole.
Um, that those realities playout and and you just can't get
traction when you come in andyou clear the slate every two
years.
Speaker 1 (43:10):
I think those are some really good points and,
like you, triggered somethoughts in my head.
Um, something that I wanted tomention is that like, uh, you
don't have to be a networkresource to develop network
automation.
Network resources understandthe network and how to
troubleshoot and the network andthe processes associated.
(43:32):
Right, so, as as leaders arethinking about their strategies
and approach, um, think about,hey, can I hire a developer to
come in versus a network andjust partner them with a network
resource, like I've done thatin the past where brought in
developers, partnered them withnetwork resources and they were
(43:54):
able to learn from each otherand the network resource was
able to upskill and eventuallybecome a developer on their own,
a developer on their own.
I've had server resources thatguys that worked on server
infrastructure knew nothingabout networks when they wanted
to step into automation space,partnered them with the network
(44:17):
automation team.
Guess what they were buildingnetwork automation as being
server infrastructure guys.
Speaker 2 (44:26):
That's awesome.
Hey, you got to make the best.
You know the great, thegreatest teams out there.
It's like team when the U?
S team beat Russia in theOlympics.
You know they didn't have thebest, every player wasn't the
best player in the world, butthey had the right team.
They were good at differentthings.
You got to have the right teamIf you want to be successful.
Speaker 3 (44:45):
Come on out the hockey analogies again.
Speaker 1 (44:47):
Oh, it's a good.
It's a good point, though,william.
Right like understanding whichresources are advantaged to do
what.
Right like if you're.
If you're building anautomation platform in the cloud
, guess what?
Speaker 2 (45:01):
your network resources probably aren't the
right team to run that platform,yeah, but you can get them with
the network resources tounderstand the processes that
need to be automated and ifyou're hiring let's say you have
five headcount, five, nicenumber and you hire five experts
(45:21):
that are just, uh, you know,100 foot deep with bgp but they
they're not versed in otherareas is that the right team?
Probably not.
Um, you want varying levels ofskill set on your team, like
maybe, like you were saying,maybe you have a developer,
maybe you have someone that isgood with process automation or
(45:41):
devops and things, and maybe youhave two or three that are you
know, route switch, rock starsand what you said earlier was so
funny because network engineersdo get a bad rap a lot of times
and a story popped in my head.
So I worked somewhere and justso the audience knows like how
wild this can get sometimes.
I started working in a networkwhere there's a routing protocol
(46:04):
called EIGRP and it works wellfor most networks by taking a
balance of bandwidth and delayand it has very default.
They're called K values, whichmade understanding like how
(46:27):
paths were being selected, likenothing was documented and I've
never seen anybody do this.
I've never seen anybody messwith K values in EIGRP.
It's like there was suboptimalpath all the time.
That is a bad idea.
Go to ISIS or OSPF if you wantto get custom with metrics and
(46:48):
such.
But yeah, that's like a thing.
That was like such a huge timesink.
And when you're trying to likesort all this out and okay, if
you have one router that'sconfigured one way and others
that are configured other ways,you have like loops and
convergence issues andinteroperability stuff, Like
yeah, that's welcome to being anetwork engineer for for five
(47:09):
minutes wow, that's to be honest.
Speaker 1 (47:12):
I think that's because we all think of what we
do as art, right, like we tryand customize it, making our own
thing.
It's so beautiful, like, likewhen the network is humming,
it's a beautiful thing.
Right, it's an art to get yournetwork humming Stop trying to
make it Because I can do this.
Speaker 2 (47:30):
Does it mean should I do this Absolutely?
It means I should do this.
I'm going to do it.
I'm studying for the CCIE, ofcourse.
Speaker 1 (47:36):
Stop making it an art , standardize it.
Speaker 3 (47:40):
And here's the thing you know that there's this whole
field called architecture, andI'm talking about physical
architecture here in buildings.
That is, this combination ofart and science, and there's
always going to be a bit of that, right?
I mean, it can be beautiful,but it doesn't need to be like
hyper modern art.
(48:01):
Do you know what I'm saying?
Like, it needs to have somesymmetry to it and it needs to,
you know, make sense when youlook at it.
It's not.
You shouldn't sit there and go,hmm, how do I feel about this
network?
No, you just look at it and belike, oh, this makes sense, yeah
.
Speaker 1 (48:17):
I 100% agree with you .
I love that.
Speaker 2 (48:21):
I think we've reached the top of the hour, yvonne, is
it?
Yes, is it in time?
Speaker 3 (48:25):
It is.
Speaker 2 (48:27):
I feel like we didn't get to everything that I wanted
to discuss, but we should havea follow-up episode, because I
have a whole list of otherthings.
100% Always happy to come back.
William, awesome, where canpeople find you?
Are you on TikTok making dancevideos, or where do people find
you?
Speaker 1 (48:44):
Not yet.
I am thinking about startingsomething soon.
In the meantime, you can findme on LinkedIn.
Feel free to hit me up.
I really don't like the term source of truth.
It's just so confusing.
Common language, I think, isimportant, especially in an
organization as you're buildingyour automation capability.
The concept behind source oftruth, intended state database
versus current state databasethose things are definitely
important.
How else do you audit yourconfigurations?
How do you audit yourenvironment if you don't know
(00:21):
what's intended to be thereversus what is actually there?
And then how do you aggregateall the data that's needed?
I've worked with too many teamsthat have gotten hung up on the
data piece.
You can sit and spin cycles fora very long time trying to
clean up your data or get yourdata to a very good state.
You can get stuck in analysisparalysis for a very long time.
(00:42):
Do I have the right managementIP addresses in place?
Do I know what my validatedsoftware is supposed to be?
Do I know what my hardwaremodels are?
Draw a line in the sand, pick astarting point and figure out
what data you need, just to getstarted.
Speaker 2 (01:08):
And someone else's data center far, far away.
I'm your host, william.
Today, as always, I'm joined byYvonne Sharp, and while I'm
still trying to ascertain ifpublic cloud is more Death Star
or Millennium Falcon, yvonne hasalready mastered the ways of
the Force and is completingchange orders with her mind
(01:29):
without even using generative AI.
How does it feel to be a Jeditoday, yvonne?
Speaker 3 (01:37):
Shockingly, the same as every other day.
It's good to be considered aJedi, but man, after a week of
travel, I am ready for theweekend.
Speaker 2 (01:49):
That might be what a Jedi would actually say.
So you're great.
Speaker 3 (01:54):
We could go all Lord of the Rings and say you know, a
wizard is never late, heappears exactly.
You know he arrives preciselywhen he intends to.
But then we'll make you ametaphor.
Speaker 2 (02:05):
So with us today is someone I've had the distinct
pleasure to spend some time withand get to know over the last
four years, I guess Someone whois well-versed technically and
strategically and is just allaround a good person.
That is Dan Cruz.
Welcome to the show.
Speaker 1 (02:23):
Hey, thanks, William.
Speaker 2 (02:25):
Thanks for having me here today, and how are things
going for you?
Speaker 1 (02:28):
Oh, it's been a busy week, same with Yvonne.
I've been traveling this weekand just been busy working and
trying to enjoy life with thefamily, so yeah, that's about it
.
Speaker 2 (02:42):
Yeah, I've been traveling a lot too, but just
for kids stuff.
Lately it's been prettyexhausting, a lot of weekend
travel.
So it's nice.
It's kind of like vacationcoming back home on Monday,
which is kind of weird to thinkabout.
Speaker 3 (02:56):
Sleep for losers and non-parents.
Speaker 2 (03:00):
Exactly, hey, and the more you go without sleep, the
more sharper you get.
It seems like it's almostmuscle memory or something.
I was reading something onetime, actually, that they did a
study this is over in Europe andthey would basically wake you
up in the middle of the nightand ask you to do like four or
five mildly complex tasks.
(03:21):
Mildly complex tasks, just pure, you know, from from dead sleep
.
And the mothers, like the Ithink it was like five to six
month your mothers with five tosix month, uh, infants, you
perform the best out of thebunch, even like on top of, like
ceos and such.
I thought, wow, that's reallyinteresting.
Speaker 1 (03:44):
I'd say sleep's a crutch, William.
Good resources don't need itand bad resources don't deserve
it.
Speaker 2 (03:52):
I feel like someone that had a background in the
arms of something like that.
Speaker 3 (03:56):
Yeah, so you know I'll be a contrarian on that
topic.
Sleep is my favorite thing, andwhen I'm traveling I actually
am able to go to bed earlierthan I do at home, and I take
advantage of that.
Speaker 2 (04:09):
So anyway, yeah, Anyway, yeah.
So I just got to get this outoff my chest.
I mean, I just have to behonest.
I mean I'm glad you're not aChiefs fan, dan, but I'm just
not excited about the Super Bowl.
I just have to say it publiclythis is Groundhog Day, but for
football I wake up in Februaryand it's the same thing.
(04:30):
Mahomes plays the hero.
You have Travis Kelsey, taylorSwift getting more screen time
than the touchdowns.
Eagles fans are screaming it,innocent bystanders punching
inanimate objects, refs makingcalls that divide the country.
It's like the Fast and Furiousfranchise of Super Bowls.
It just won't stop.
(04:51):
And either way, in either ofthose cities, someone's car is
going to get flipped.
But I digress Anyhow.
So today's topic Dan and I had areally good conversation about
network automation.
I guess it's been about.
It's been a few months ago, butthat's going to be.
(05:13):
The topic of this conversationis network automation and you
know I want to get into talkingabout you know, a lot of times
there's like a lot of hype,there's a lot of buzz, there's a
lot of buy this, buy that.
Lot of times there's like a lotof hype, there's a lot of buzz,
there's a lot of buy this, buythat, um and and many times
network automation, I think tothe public is not framed
correctly, even like the valueproposition sometimes isn't
(05:35):
framed correctly and it'sdefinitely been perceived in the
past is not a must-have.
But but that is changing here.
In the recent past it'sbecoming a must-have and it's
becoming business imperative,along with some of the other
top-end things, especially ifyou have any sort of on-premises
(05:57):
data center presence or yourown tech stack that you manage.
But yeah, that's the top of theconversation and I guess,
before we get into that, do youwant to give a brief background
just of your um, your experience, your background?
Dan, I don't know how far backyou want to go for sure.
Speaker 1 (06:15):
Uh, we'll go.
We'll go back to I don't know2005.
Uh, I was in the military for aperiod of time.
That's where I got most of myIT training, been deployed
overseas, came back, wentthrough a Cisco boot camp and
(06:36):
got my first CCNA certification.
That was like around 2007.
And did network engineering fora while in the military and
then finally got out, spent sometime working at a startup
company and then moved to mymost recent employer and been
(07:03):
there for a period of time.
I did automation in kind of allof those areas, primarily in
the infrastructure space,primarily with networking.
I am trained in, or was trainedin, a lot of different IT
systems through the military Imean we used everything, and
with large enterprise I mean weused everything, and with large
(07:26):
enterprise, so working at KochIndustries, where I'm currently
at as an enterprise architect.
Speaker 2 (07:39):
you know all kinds of technology, all the tools,
awesome.
Speaker 1 (07:45):
Yeah, I know you're spread out between like you have
quite a bit of not just networkengineering experience at this
point, but cloud as well.
Yeah, cloud space cybersecurity, space network server
infrastructure, backup recovery.
I primarily work with theinfrastructure teams, but at
times work with the applicationteams, and when I say
infrastructure, I include cloud.
Yeah so kind of got my fingersin all the things Awesome.
Speaker 2 (08:10):
And I know that my experience with network
automation is very few.
Network engineers in theearlier days really banged the
gong and tried to bringattention to network automation.
Usually you had a few that werelike writing a lot of like.
For me in my time it was pearlbash, scripting expect.
(08:33):
And one of the things that yourealize pretty quickly is that,
okay, when I leave this companylike this is dying, I didn't
make an enterprise widetransformation and at the end of
the day, what value was throughthere other than making my life
easier, making me go faster andallowing me to do more work in?
What really becomes importantis bringing attention and making
(08:56):
an enterprise widetransformation.
But can you kind of talk tothat a little bit?
Like, when did you realize,like in your journey, that, okay
, this like, how do we make thisa strategy and a culture change
rather than just scripting?
Speaker 1 (09:12):
Yeah, I mean to your point right.
There's always that one guy ora handful of people that are
super passionate aboutautomation and they're out there
writing scripts, but it's justnever sustainable.
Once they leave, the automationstarts to fall apart.
Nobody knows how it was built,no one knows how it was coded,
(09:33):
all of those things.
So I realized it when I stayedin the same organization but
transitioned roles and startedworking on other things and I
saw the automation that I builtfall apart and I had to get
pulled back in um to fix it.
Um, that that's how I realizedvery quickly that like, hey, I'm
(09:54):
trying to do this other job,I'm trying to create this value
over here.
I can't keep getting pulled in,uh, to work on this old
automation that I built a whileback.
Speaker 2 (10:06):
So how did you bring attention to that to the right
people?
Because, of course, you can useopen source and just write raw
general purpose code to do allthe things, but usually there
has to be some strategy wrappedaround it.
A lot of times, maybe you needa steroid injection from the
(10:28):
outside, like some sort ofagency or some help to come in
and do discovery and, um, helpyou with things Like.
There's just a combination ofthings and all that requires
money you got to have.
You have money to spend.
So how do you get the folkswith the deep pocket books to
shed light on this?
Speaker 1 (10:47):
Really good question.
For me, it's very important tohave senior leadership or
executive buy-in to do some ofthese things, and they often
don't see it or understand thevalue of it, Because really
we're talking about creatingoperational efficiencies
efficiencies for the teamsthemselves and when you have
(11:12):
people that are coding orscripting and automating things
in the background without astrategic plan, it's kind of
like skunk works right, Likenobody knows what's going on,
right.
You're solving problems thatnobody knows about.
So you really have to exposethose gaps.
(11:32):
You really have to get seniorleadership to identify and see
the value that can be created byhaving a more strategic plan
and approach.
Speaker 3 (11:48):
Well, and one of the things that I've noticed too is
a lot of times like automationprojects.
They start very grassroots andthey start on the side.
They don't get integrated andcodified into the systems of the
organization right, so youstill are approving everything
with manual change requests.
There's always like theorganization right, so you still
are approving everything withmanual change requests.
There's always like theautomated way to do it and then
(12:10):
the hands-on way to do it, anduntil you get all those
processes codified into theofficial working systems, it can
very easily be left aside orleft behind when you have a
turnover and headcount, becauseit's all very, very tribal, and
(12:35):
especially in large enterpriseorganizations.
Those big enterprise systemshave a gravity to them that just
pulls everything that directionthem.
Speaker 1 (12:48):
That just pulls everything that direction.
I would agree with that right.
So when you talk about likeend-to-end process automation,
right, or event-driven typeautomation like those require
that you integrate with thesystems, that those are
triggered independently throughthe workflow, that sort of stuff
and that's, we don't really seethat in the in the very early
stages of the journey, right,it's always some highly
(13:09):
technical resources like oh, Iknow how to fix that and they go
and run their python script inthe background somewhere, right,
but they're manually kickingoff that python script.
It's not an orchestrated uh,orchestrated event that occurs.
Speaker 2 (13:25):
Yeah, that's a good point Orchestration versus
automation.
So, like automation, you havethese different pockets like
Python scripts that are run,maybe ad hoc, from a server, or
like even a cron, like I used todo this thing where I would
always run certain things fromcron jobs on servers and then
take the data and then dosomething with it and if it
(13:47):
broke, only me and one otherperson knew how to get it going
again.
And when you think about that,like leaders more often than not
these days are looking down andthey don't care that you were
smart enough to write somepython scripts and run them from
a server or a jump host in adata center.
When they they look down,they're thinking of services.
They're thinking of, hey, wehave this intake process, like
(14:11):
new product coming into fruition.
What are all the steps thathave to happen?
Like we want this whole thingautomated from beginning to end,
from the beginning thediscovery, the paperwork, the
changes, like the chat offs, allthe different things, all the
way to the point to where thisstuff gets configured.
Speaker 1 (14:29):
And that's a much harder problem to solve when you
bring in the business processesyeah, I was gonna say you know,
leaders are are more interestedin the business outcome.
What's the business outcomethat I'm driving towards?
Right, Um, and when you're likeoh well, automation can make us
more efficient.
Well, not when it's not end toend process automation, when
(14:52):
it's still like I have to callsomeone to go kick off a script
manual manually.
Yeah, you probably saved mefive minutes.
Uh, with automated script thatyou're running, but the?
How does that fit into yourwork process and how is it
making your work process moreefficient?
That's where the real valuegains are at.
Speaker 3 (15:13):
Well, and I think you know it's a sad reality and it
sounds harsh to say it, butnobody really cares if the IT
practitioners are saving time ornot.
I mean, unless you can convertthat into a real dollar value,
that applies to the business.
That's when it matters.
But I mean, basically most ITheadcount in most organizations
(15:36):
is it's planned for, it's in abucket, like they already know,
like it's just not calculated ina way that it's meaningful to
the business and it and itsounds harsh, especially if
you're that person and you'relike wait, you're saying my time
doesn't matter.
Well, not exactly it does.
(15:56):
Like it matters that you getmore done in a day.
But if you're making a businessargument like saving the IT guy
, time is not enough of anargument to push through a
system-wide change.
And that is an importantdistinction to understand when
you're trying to go and make anargument for automated systems,
(16:18):
because if your only answer isit saves this team of five folks
a day a month, or two days amonth, nobody's going to care.
I'm sorry.
Speaker 1 (16:28):
Especially when you like I've had this happen too
many times right, like thetechnical resources are like oh,
this is like, we need toautomate, we need to do all
these things.
Okay, let's frame this up,let's take a look at what it
will take to do this.
Okay, let's frame this up,let's take a look at what it
will take to do this.
And they always come back withthe like we need DNA center or
we need glue networks or we needwhatever you name, whatever
(16:52):
automation platform, right.
And it's like okay, you go tomarket and you look at those off
the shelf solutions and thecost associated at scale no, the
cost associated at scale.
No.
Like getting business buy-infor something like that when you
have no record, no history ofperformance, uh, in the
(17:13):
automation space is superdifficult to get alignment and
approval for yeah, one goodpoint there too.
Speaker 2 (17:20):
It's like that age-old decision making at least
as long as I've been working inthis space is build versus buy.
And more often than not, evenwhen it's time to buy a tool or
buy a platform, like, okay, weneed to go buy something.
More often than not you'regoing to have to go and try to
(17:43):
do the DIY approach first andfigure out how painful it is and
sort of do a calculation, arisk calculation, just all sorts
of calculations to decipher.
Ok, do we have the engineeringtalent to do this?
Do we are going to, you know,do we have all the things that
(18:04):
are required to meet thisoutcome?
Maybe we do 15 of it, but thisother platform does the rest.
Or you've got to figure out like, where in the abstraction
pyramid that you want to placeyourself, like, where, like when
do you buy?
But at times you just usuallyhave to go through the pain
first and prove out with dataand other things that, yeah,
(18:26):
this is why we need to buysomething, because we can't
accomplish this based on whetherit's the system we work in, the
engineering talent or theheadcount that we're allowed to
have.
Or maybe we can or can't bringin a partner.
So how do you look at that?
Is that kind of how you view it?
Build versus buy decisionmaking like how does that ring
(18:49):
through your head?
Speaker 1 (18:50):
the way that that I I've thought about it over the
years.
I mean so I've never seen atool fix a problem.
What what I've seen is goodpeople and processes adopting a
tool in the right way that thenfixes the problem.
So my approach I tend to focuson the people and process side
(19:12):
of it first, so you get theright skill set in, you get the
right mental models, you getpeople working and developing
their processes in the right waywith any tool, and I would say
this is applicable outside of IT.
My wife and I have thisconversation when we go to Home
Depot.
I see some cool power tool onthe wall and I'm like, hey, I
want that.
And she's like when was thelast time you built something
(19:35):
that required that type of tool?
Right, you don't need.
You don't need a power drill ifyou don't even know how to use
a screwdriver, right, Right.
So focus on the people andprocess side of it and then use
the tools that are available toyou and then at some point it
(19:55):
probably makes sense to comeback and reevaluate Do you have
the right tools?
Speaker 3 (20:00):
Yeah, well, that's such an important point because
I have seen, you know I'veworked in all different kinds of
organizations, likeorganizations that are large and
, you know, have large budgetsfor spending on every new tool
in the toolbox, and then verysmall organizations where you
have to be scrappy because youcan't buy the newest tools, to
(20:27):
be scrappy because you can't buythe neatest tools, and I think
what folks that haven't been inthis kind of environment it's
hard to believe honestly is thatsometimes throwing money at a
problem makes it worse.
Right, like I've seenorganizations end up with tool
bloat because they think, well,if we just go spend a truckload
of money, it will make thisproblem go away, and what they
(20:50):
end up with is tool sprawlwithout the people, processes to
implement it, and they end upwith a patchwork of stuff that
was never meant to work togetheror that was wasn't implemented
in a way that it's going to worktogether, and then like, and
then you end up with, likeprocurement people that are
hired to manage all the thingsthat you bought that you're not
(21:11):
getting value from, and it's,it's, it's this, I don't know
it's, it's.
It's a growing problem, that ofinefficiency and misuse, and and
so I think, like the starting.
What problem are we trying tosolve?
What's our business problem?
Who are the people andprocesses we need, and then what
tools we need.
I think that's very simple, butbut the right framework, and
(21:35):
it's easy sometimes fororganizations that are kind of
flush to skip the people processpart and and it's it's the
people process part and and it's, it's it can end up even toxic.
Speaker 1 (21:51):
um, yeah, I 100 agree with you.
I mean, like, if you just lookat the simple economics behind
there, right, like, depending onthe size of the organization,
right, you're probably going topay a million dollars for a good
tool off the shelf, right, andthen you need at least one
resource to run that tool, right, so you're looking at 1.1, 1.2
million, depending on how muchyou pay your resources and where
(22:11):
your resources are out of.
How many resources could I getif I didn't purchase the tool
and used open source and focusedon people in process and really
looked at solving problems?
Because in the former model,right, where you have one
resource with one tool, guesswhat?
You didn't solve your problem,because you still have processes
(22:34):
that are dependent on oneperson.
Speaker 2 (22:40):
Yeah, and throwing.
I mean those are all good,amazing points.
No-transcript, we did a thing.
(23:10):
But you're absolutely rightabout the cost calculations that
you have to make, because theprice of the tooling and how do
you even justify that cost?
If you have a network that'sran okay for for the most part
and it's never been such a bigproblem that it's gotten a, you
know, attention of leadership,how do you justify the cost?
(23:32):
And I think that the way that Itried to do that in the past was
actually, what am I?
What am I helping?
And it's a lot of times I wasable to get this over the board
with okay, we're not goingfaster, but since every outage
that we have for this length oftime costs the company this
amount of money and it isresulting from human hands and
(23:54):
misconfiguration, and thesedifferent things expand and make
our reliability better for thenetworks that power our whole
infrastructure.
That is where the value comesin.
So it's almost like I mean,maybe this isn't a thing for
everybody, but for me I saw alot of success with showing that
(24:15):
, okay, if we make veryconsistent changes, very small
changes more frequently that aremore controlled and they're
automated, no human hands, weare actually increasing our
reliability because we're makingconsistency.
Consistency equals, reliabilityequals kind of value, I guess.
Speaker 3 (24:33):
And you have to tie that back to the cost of the
outage.
Right for the business, right?
That's the secret sauce there.
Go ahead, dan.
Speaker 1 (24:40):
I was going to say it's hard, it's hard to do for
technical resources and even forIT leaders, right, because the
pain that you feel, the painthat your team feels, is the
pain that you're focused on.
Right, and you really have tolook at it from a different lens
, through a differentperspective of how am I
servicing the business?
What outcomes am I drivingtowards?
(25:01):
I servicing the business, whatoutcomes am I driving towards?
What's the opportunity cost forthe business when they're
waiting on my team to dosomething enable them?
So that's, you really have tolook at it through a different
lens.
And it's hard to do when, whenthe pain you're feeling is is so
right in front of you andevident.
Speaker 2 (25:18):
Okay, so I'll tee this up by one of the things.
It was when I first startedtrying, you know, we talked
about like the scripting andjust hey, I'm worried about
numero no.
I want to make my life easier.
I'm going to knock some changesout to to bigger, bigger
picture stuff.
One thing this was a long timeago and I know this space is
(25:40):
actually.
This space really hasn'tmorphed that much.
Actually, this space isactually the space really hasn't
morphed that much.
Actually, this stuff reallyhasn't changed that much in the
past 10 years.
To be honest, I don't thinkabout it um, uh, now that I
think about it.
But the thing about, okay, wehave what is our operational
state.
This is brownfield andbrownfield's crazy.
Everybody knows that brownfield.
You have different pockets ofbrownfield everywhere and you
(26:04):
have to.
When you do any sort of goodautomation, there's a problem
that you have to solve.
That's a very hard problemactually, and that is
deciphering between your desiredstate, what you want the
network to be, and what is inoperations today.
The rabbit hole that that takesyou down is bringing in some
(26:28):
sort of database or source oftruth or an aggregation of
sources of truth.
And when I started doing this,you basically had one solution
and it was pretty new at thetime.
It was Netbox and all opensource.
I remember the first time Ihosted NetBox in production, you
didn't have companies thatoffered support really on this.
We had it running on a VMoriginally and then we
(26:54):
transitioned to containers likeDocker, swarm and we were
running it on Swarm.
But now there's a lot of paidsolutions you can.
You know it's been sassified alittle bit.
You know it's kind of becomeits own little you know sort of
market in a sense.
So you have Netbox, notobot,from Network to Code.
You have a new platform, infplatform, um, infra hub from ops
(27:19):
mill.
So do you have any thoughts oropinions on whether this is a
necessary thing or and is thissomething that you need to have
teed up before you start doingany automation?
How do you think about it, dan?
How do you?
Speaker 1 (27:32):
think about it, Dan.
So I really don't like the termsource of truth.
It's just so confusing.
So common language, I think, isimportant, especially in an
organization as you're buildingyour automation capability.
I do agree, though, like theconcept behind source of truth
(27:55):
is important, right.
So, like intended statedatabase versus current state
database, like those things aredefinitely important, Like how
else do you audit yourconfigurations?
How do you audit yourenvironment if you don't know
what's intended to be thereversus what is actually there?
And then how do you aggregateall the data that's needed to
create a configuration or achange that's required in the
(28:18):
environment?
Those are all definitelyimportant things that need to be
there.
Whether or not you call it asource of truth, this is up to
you.
Me personally, I don't like thatterm.
But, getting started, I wouldsay yes, certain components of
(28:38):
that are required, and I'veworked with too many teams that
have gotten hung up on the datapiece for too long.
You can sit and spend cyclesfor a very long time trying to
clean up your data or get yourdata to a very good state.
I am trying to clean up yourdata or get your data to a very
good state, Right.
Most teams struggle I won't sayall, but most teams struggle
(29:00):
with like just inventory whatare all my assets and where do
they exist?
You can you can get stuck inanalysis paralysis for a very
long time.
Do I have the right managementIP addresses in place?
Do I know what my validatedsoftware is supposed to be?
(29:21):
Do I know what my hardwaremodels are?
Just draw a line in the sand,pick a starting point and figure
out what data you need.
Just to get started is what Iwould say.
Otherwise you'll get stuck inanalysis paralysis started is
what I would say.
Speaker 2 (29:38):
Otherwise, you'll get stuck in analysis paralysis.
I love that.
I know we I think we talkedabout this, which is why like,
that's kind of how I feel aboutit, because I know that there's
some folks reach out sometimesand you know, just having some
of these conversations, you seecompanies a lot of times they
want to actually account foreverything and get that source
of truth piece perfectly plannedout and all the data just
(30:01):
perfectly sanitized across alltheir multi-vendor, multi-cloud,
multi-everything network and ifyou do that, that's like a
10-year process.
It's just never going to bedone.
Organizations are toocomplicated these days,
enterprises are way toocomplicated and a lot of these
(30:21):
things, some of the things youonly have limited control over.
You don't have the same controlthat you have on your routers
and your switches, but you stillrequire some of this other data
, so you can't actually evenensure the integrity of it.
You can read it in and you canuse some of it, but you don't
control it wholesale.
You, you aggregate it to somedegree.
So if you're, you're absolutelyright, the analysis paralysis
(30:44):
thing is huge.
You got to get started.
You know that it that doesn'tmean that you don't need us.
You know some sort of.
You've got to have some methodor mechanism to differentiate
between that desired outcome andyour operational network and be
able to validate continuouslyas you go along yeah, I.
Speaker 1 (31:04):
I would say like, if you look at any switch
environment right, just theswitching environment how many
different switch models are yougoing to end up with?
Like out of a thousand devices,you're probably going to have
20 different models.
That would not surprise me atall're probably going to have 20
different models.
That would not surprise me atall, right.
And then of those 20 differentmodels, how many different OS
versions are you running?
Because if you're not runningany automation, chances are most
(31:33):
of that stuff's notstandardized and so, like when
I've gotten started with teamsin the past looking at
automation, it's hey, pick theswitches that are common that
you can run common commands on,group those together and start
with those.
Don't try and do your switches,your routers, your load
balancers all like your cloudstuff.
Like pick one environment andget started.
Speaker 2 (31:54):
It's great advice, I love it and that is, I'm
guessing, that that approach hasserved you well in the real
world.
Speaker 1 (32:03):
Making progress, absolutely right.
Like, and it's incremental.
I don't know how much we'vetalked about I know well, we've
talked a little bit about Agilein the past, but that's the
other thing.
Right Is shifting your teams toan Ag agile model and focusing
on MVP to make progress.
Right, like if we're doing youknow those waterfall projects
(32:26):
and we're trying to geteverything perfect, like it's so
difficult to make progressbecause this is such a big
problem.
You really have to take thishuge problem that you have with
automation automation break itdown into little incremental
steps that you can make progresson yeah, and by mvp for those
that don't know that term.
Speaker 2 (32:44):
We're not talking about the super bowl, most
valuable player, a minimal,viable product.
Essentially to say, hey, we, weneed a starting point, we have
to deliver some value.
But, hey, the sooner we getsomething out that door, the
sooner we can get feedback on asmaller component of it, which
makes it easier to reiterate andcontinue developing more value,
(33:08):
instead of saying, hey, we'regoing to get all the things done
at once and then ask forfeedback and then have some
elongated feedback loop.
We're getting it out the doorquicker, showing value quicker
and getting feedback quicker andmaking it better quicker.
It's a big deal, and that'shaving an agile mindset, an
agile team structure, bringingin some of the DevOps, which is
(33:31):
a culture, not a position, isreally important.
Speaker 3 (33:37):
It's a philosophy.
Speaker 2 (33:39):
It is Yvonne, is the philosopher, the resident
philosopher ranter.
It's all about the DevOps.
Speaker 3 (33:45):
It's how we think about how we work.
Right, it's more of an approachto working than it is like I do
.
Devops, Okay yeah.
Speaker 2 (33:56):
One thing I want to.
So one thing about you, Dan, isyou've never been shy of
throwing out good.
I mean, usually your opinionsare grounded and pretty, you
know data and experiences likegood stuff and they're usually
pretty spot on.
But I just want to get yourtake on the, the platforms and
(34:19):
tooling surrounding networkautomation specifically like is
it really matured?
Has it gotten better?
And then, differentiatingbetween you mentioned dnac
earlier, which before that itwas prime, and I've gotten stuck
in the muck and mire there inthe past.
But like the vendor producedboxes that you can install
(34:42):
versus the other tools andplatforms that are more maybe
bleeding edge.
But do you have any thoughtsthere on the maturity?
Like, is it maturing or likewould you like to see new things
?
Like, where is this thing going?
Speaker 1 (34:56):
maturing or like would you like to see new things
?
Like where is this thing going?
So, yeah, a couple of thoughtsthere.
So I think I think maturity inthe past has been limited based
on the way that you can connectto network infrastructure right,
like in the past with networkinfrastructure you were limited
to SSH, telnet, snmp asmechanisms to interact with a
network device for configurationand troubleshooting.
(35:19):
So I think that does limit yourtooling capability and the
maturity as such.
Now, over the last decade, yeah, things have been changing.
We have more cloud-basedsystems today, more
software-defined systems todayin the infrastructure space than
we ever have in the past, and Ithink that has opened up the
door for maturity within toolsets.
(35:41):
However, I think that's wheresome of these industry tool sets
are lagging behind and notkeeping up with the changes that
have occurred in infrastructure.
When you look at observability,otel, those type of things,
like some of the traditionalnetwork tooling, doesn't account
for that stuff.
It's still using SNMP as a wayof monitoring appliances.
(36:05):
Why aren't we moving forward inthose spaces?
Speaker 2 (36:10):
That is such a good point.
Right there they openedtelemetry piece.
I love that.
We can discuss that, maybe alsolater.
But yeah, go ahead.
Speaker 1 (36:19):
I do think that we will see some advances here soon
.
We're starting to see italready with things like agentic
AI, generative AI starting tobe built into the tool sets, and
I think that will help drivethings forward, make things
easier, but at the end of theday right, that's what these
(36:41):
tool sets do is they just makeit easier for development to
occur?
I think of it as like no code,low code opportunities right,
that's what those tool sets,those power tools are doing.
Dna Center the way that I seeteams interacting with that is
(37:05):
around kind of no-code, low-codemental models.
They're not putting in the timeand effort to upskill and
develop those pro-code skills tointeract through API and things
like that with the tool setsand create orchestrated
workflows and integrations.
Speaker 3 (37:20):
Well, so I guess I just like, I just feel like the
conversation still like how muchhave we moved forward?
Right?
I feel like these, you knowwe're still talking about SNMP.
I mean it's been 20 years andwell, for me, like it's not been
20 years for SNMP, it's been 20years for me and yeah, the
(37:42):
stuff going on with opentelemetry is super exciting.
But I do sit here and wonderlike, yeah, gosh, why has it
been so slow, just so slow?
Because I mean I feel likeeverybody knows that we need to
do it differently and yet herewe are I?
Speaker 1 (38:00):
I honestly I think some of it is us, some of it is
our network resource, likenetworking and applications were
so far apart for such a longtime, right like, and now, when
we look at automation, likeyou're really starting to step
into development and coding anduh, automation platform looks
(38:23):
more like an a full-blownapplication than it does
infrastructure, and I think wehave some some old mental models
within our network teams.
It's us that are holdingourselves back.
We complain and moan about theproblems that we have, but we're
not.
How often do you see a networkguy going out and learning how
(38:46):
to code and how to be adeveloper?
Speaker 2 (38:50):
Yeah, this is so true Like I can't count the
conversations I've had over thepast two years with leading edge
tech professionals that are inthe network space that they
don't understand when I saysomething like hey, enterprises
are actually locking down theirAWS console.
They don't want people logginginto the console and making
(39:11):
changes that way anymore becauseof the risk of all this
configuration drift.
They want this stuff codified.
They want of all thisconfiguration drift.
They want this stuff codified.
They want to produce anartifact because they want to be
able to roll things back.
You know, they want this modernapproach to managing network
infrastructure and it's it'slike well, why it's really hard
for network engineers, I think,a lot of times to see that value
(39:32):
and to see why enterpriseswould want to do that in the
first place.
And and that's something I meanwhat do you think about that?
Because that's something I seeat a lot of places right now
where the UI is being usedpurely read only and, if it's
not, at a given company, they'retrying to shift that way.
They want to really havecontrol over all those changes
because in order to basicallysupplant ITIL-based change
(39:56):
management, you have to have areliable and a thorough
understanding about breakingthose changes into smaller
pieces and only making them, youknow, completing them through
approved pipelines, or you knowsomething, workflows or
something similar.
Speaker 1 (40:12):
Yeah, I see the same thing happening, william, like
in the cloud space, applicationspace, definitely walking down
the ui, um and uh, followingbetter change control practices,
um.
But I want to go back for justa minute because I feel like
we've been pretty hard onnetwork engineers, network
resources, to be fair, right.
(40:33):
To be fair to guys like theknowledge required to
troubleshoot in the networkspace, right, all the things you
have to know about BGP, ospf,eigrp, like all the routing
protocols, layer two, wireless,like there's so much in the
network space, can we really belike?
Speaker 3 (40:51):
oh, now you have to go learn to be a developer like
oh, now you have to go learn tobe a developer.
Well, and still, the industry,like their startups, they're
trying, but our big vendors,they're doing some things, but
but it's still not as baked into the work as it is in other
(41:13):
industries, like in in cloud.
It's baked in, you know, likethe ability to automate, the
ability to deploy via code.
It is 100% baked into theplatform that those capabilities
are there.
And two, we're dealing withinfrastructures that may be
(41:35):
deployed for a decade, and sothe newer capabilities, they
just don't exist or weren'tdesigned in from the beginning.
And I think the the best thingwe can do is have a good idea of
what our, what we want thedesired end state to be, the
(41:55):
capabilities that we want at theend of the day, and and yes, it
is, you know, infrastructure ascode, automated deployment,
some sort of state discovery,all of those capabilities, and
then every decision that we makeincrementally needs to be in
that direction, and I think thatthat that is the piece that
(42:16):
often gets missing.
Is this overall, like vision, orand and and I feel like vision
is too lofty of a word, but thisreally clear objective that we
want to achieve.
And then the will, theorganizational will over a long
period of time to get there.
Because what happens is youmight have a great dynamic
(42:38):
leader who wants to geteverybody there, and then they
get scooped up by a bigger fishand then they go, they move on,
and then all of thoseinitiatives get replaced by a
new person who has new, you know, a new ax to grind and like.
To me that's a big part of theproblem, it's not.
It's not just like thepractitioners, it's the system
(42:59):
as a whole.
Um, that those realities playout and and you just can't get
traction when you come in andyou clear the slate every two
years.
Speaker 1 (43:10):
I think those are some really good points and,
like you, triggered somethoughts in my head.
Um, something that I wanted tomention is that like, uh, you
don't have to be a networkresource to develop network
automation.
Network resources understandthe network and how to
troubleshoot and the network andthe processes associated.
(43:32):
Right, so, as as leaders arethinking about their strategies
and approach, um, think about,hey, can I hire a developer to
come in versus a network andjust partner them with a network
resource, like I've done thatin the past where brought in
developers, partnered them withnetwork resources and they were
(43:54):
able to learn from each otherand the network resource was
able to upskill and eventuallybecome a developer on their own,
a developer on their own.
I've had server resources thatguys that worked on server
infrastructure knew nothingabout networks when they wanted
to step into automation space,partnered them with the network
(44:17):
automation team.
Guess what they were buildingnetwork automation as being
server infrastructure guys.
Speaker 2 (44:26):
That's awesome.
Hey, you got to make the best.
You know the great, thegreatest teams out there.
It's like team when the U?
S team beat Russia in theOlympics.
You know they didn't have thebest, every player wasn't the
best player in the world, butthey had the right team.
They were good at differentthings.
You got to have the right teamIf you want to be successful.
Speaker 3 (44:45):
Come on out the hockey analogies again.
Speaker 1 (44:47):
Oh, it's a good.
It's a good point, though,william.
Right like understanding whichresources are advantaged to do
what.
Right like if you're.
If you're building anautomation platform in the cloud
, guess what?
Speaker 2 (45:01):
your network resources probably aren't the
right team to run that platform,yeah, but you can get them with
the network resources tounderstand the processes that
need to be automated and ifyou're hiring let's say you have
five headcount, five, nicenumber and you hire five experts
(45:21):
that are just, uh, you know,100 foot deep with bgp but they
they're not versed in otherareas is that the right team?
Probably not.
Um, you want varying levels ofskill set on your team, like
maybe, like you were saying,maybe you have a developer,
maybe you have someone that isgood with process automation or
(45:41):
devops and things, and maybe youhave two or three that are you
know, route switch, rock starsand what you said earlier was so
funny because network engineersdo get a bad rap a lot of times
and a story popped in my head.
So I worked somewhere and justso the audience knows like how
wild this can get sometimes.
I started working in a networkwhere there's a routing protocol
(46:04):
called EIGRP and it works wellfor most networks by taking a
balance of bandwidth and delayand it has very default.
They're called K values, whichmade understanding like how
(46:27):
paths were being selected, likenothing was documented and I've
never seen anybody do this.
I've never seen anybody messwith K values in EIGRP.
It's like there was suboptimalpath all the time.
That is a bad idea.
Go to ISIS or OSPF if you wantto get custom with metrics and
(46:48):
such.
But yeah, that's like a thing.
That was like such a huge timesink.
And when you're trying to likesort all this out and okay, if
you have one router that'sconfigured one way and others
that are configured other ways,you have like loops and
convergence issues andinteroperability stuff, Like
yeah, that's welcome to being anetwork engineer for for five
(47:09):
minutes wow, that's to be honest.
Speaker 1 (47:12):
I think that's because we all think of what we
do as art, right, like we tryand customize it, making our own
thing.
It's so beautiful, like, likewhen the network is humming,
it's a beautiful thing.
Right, it's an art to get yournetwork humming Stop trying to
make it Because I can do this.
Speaker 2 (47:30):
Does it mean should I do this Absolutely?
It means I should do this.
I'm going to do it.
I'm studying for the CCIE, ofcourse.
Speaker 1 (47:36):
Stop making it an art , standardize it.
Speaker 3 (47:40):
And here's the thing you know that there's this whole
field called architecture, andI'm talking about physical
architecture here in buildings.
That is, this combination ofart and science, and there's
always going to be a bit of that, right?
I mean, it can be beautiful,but it doesn't need to be like
hyper modern art.
(48:01):
Do you know what I'm saying?
Like, it needs to have somesymmetry to it and it needs to,
you know, make sense when youlook at it.
It's not.
You shouldn't sit there and go,hmm, how do I feel about this
network?
No, you just look at it and belike, oh, this makes sense, yeah
.
Speaker 1 (48:17):
I 100% agree with you .
I love that.
Speaker 2 (48:21):
I think we've reached the top of the hour, yvonne, is
it?
Yes, is it in time?
Speaker 3 (48:25):
It is.
Speaker 2 (48:27):
I feel like we didn't get to everything that I wanted
to discuss, but we should havea follow-up episode, because I
have a whole list of otherthings.
100% Always happy to come back.
William, awesome, where canpeople find you?
Are you on TikTok making dancevideos, or where do people find
you?
Speaker 1 (48:44):
Not yet.
I am thinking about startingsomething soon.
In the meantime, you can findme on LinkedIn.
Feel free to hit me up.
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com