September 24, 2025 • 50 mins
The gap between cloud-native and traditional networking has never been more evident. As organizations struggle with hybrid environments, finding a unified management strategy feels like searching for the mythical "one ring to rule them all."
In this thought-provoking episode, we welcome Eric Chou, author, instructor, and podcast host with over a decade of experience at AWS and Azure. Eric brings a rare insider perspective on how hyperscalers approach networking fundamentally differently than traditional vendors.
We explore why cloud providers built their infrastructure API-first from day one, while traditional networking vendors had to retrofit APIs onto existing hardware. This architectural distinction creates significant challenges when trying to manage both environments cohesively. Eric explains why cloud tools excel at declarative configurations while traditional networking tools often take a more procedural approach, and when each might be appropriate for your organization.
The conversation takes a fascinating turn when we discuss how AI is reshaping network engineering. Are we headed toward a dangerous knowledge gap as junior engineers rely on AI without developing foundational skills? Eric advocates for an "enhance, not replace" philosophy that values human expertise while leveraging AI as a productivity multiplier. We debate whether simulation can ever truly replace the hard-earned lessons of 3 AM network outages.
Whether you're managing a hybrid network environment or wondering how to prepare for an AI-driven future, this episode offers practical insights and a surprisingly optimistic outlook on the future of networking. Listen now to understand how bridging the gap between cloud and on-premises networking might be less about finding a universal tool and more about developing the right mindset and approach.
Connect with Eric:
Network Automation Nerds Podcast: https://packetpushers.net/podcast/network-automation-nerds/
Amazon Author Page: https://www.amazon.com/author/ericchou
LinkedIn: https://www.linkedin.com/in/choueric/
Network Automation Nerds Website: https://networkautomationnerds.com/
Purchase Chris and Tim's new book on AWS Cloud Networking: https://www.amazon.com/Certified-Advanced-Networking-Certification-certification/dp/1835080839/
Check out the Monthly Cloud Networking News
https://docs.google.com/document/d/1fkBWCGwXDUX9OfZ9_MvSVup8tJJzJeqrauaE6VPT2b0/
Visit our website and subscribe: https://www.cables2clouds.com/
Follow us on BlueSky: https://bsky.app/profile/cables2clouds.com
Follow us on YouTube: https://www.youtube.com/@cables2clouds/
Follow us on TikTok: https://www.tiktok.com/@cables2clouds
Merch Store: https://store.cables2clouds.com/
Join the Discord Study group: https://artofneteng.com/iaatj
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Tim (00:13):
Hey and welcome back to another episode of the Cables to
Clouds podcast.
I'm Tim McConaughey.
I am here at the Cables toClouds podcast.
I am here at the Cables toClouds podcast and with me, as
always, is my co-host, I guessChris Miles Just your buddy man,
just your buddy yeah that'sright.
Head of Real Life, mate,whatever we're going with this
(00:35):
week.
And we have a guest with us thisweek, which you probably
noticed if you're watching theYouTube Eric Cho, which is a
good friend of ours and of thepodcast.
We have not had a chance tohave him on yet, but we've been
trying for a good long time.
For those that don't alreadyknow you, Eric, you want to give
a really quick intro ofyourself.
Eric (00:55):
Yeah, sure, hey, it's good to be here.
Thanks for having me.
I don't think you guys triedvery hard, because I'm not very
hard to find.
I think it's just that you tryto keep the guest quality up
right, so you don't want to dragon that average, so I get it,
no worries.
I'm here, so now I'm happy.
Yeah, eric Cho.
And if you listen to NetworkAnimation Nerds podcast, I'm
(01:17):
there right by your earbuds.
Maybe every other week,hopefully.
If not, maybe you know me fromvarious books.
I've written six of them andthe book's been translated into
five different languages.
So if you're joining from Korea, thank you.
I doubt it, but because both ofthe readers in Korea are in the
time zone difference.
(01:39):
But yeah joking aside, right?
So I teach online courses atLinkedIn Learning, at Network
Expert, at Pluralsight and atvarious locations, so I'm not
very hard to find.
Hopefully we're connected onLinkedIn somehow.
If not, then please welcome tosend me an invite.
I'm happy to be engaged invarious conversations and not
just network engineering.
Tim (02:00):
That's great.
That's a good intro.
Eric is extremely prolific injust about all the content
creation stuff.
He's 10 times as good at thisas I am.
So it's usually like, hey, I'vetried that and that didn't work
so you don't have to right.
Eric (02:27):
So that's always been.
My mindset is just this um, youknow, learn, do and then teach,
and then just rinse and repeat,and I apply that to probably
almost everything in my life.
So you know, technology or newconcepts, books, um, yeah, all
all kinds of stuff, and we couldget into that later, but I
don't want to interrupt yourflow.
Tim (02:49):
All good man, that's a good point, all right.
So we brought Eric here becausewe really wanted to talk about
something that we've talked alittle bit about on the podcast
just ancillary for a long timeactually which is the automation
aspect, the infrastructure ascode aspect, of both cloud
networking and traditionalon-prem networking.
(03:12):
I don't know hardware networkingI'm not sure what you what is
the other word that we use fortalking about more like
traditional hardware networkingor at least traditional vendors.
You have the cloud nativethat's built with IAC in mind,
right, based on the cloudproviders, exposing APIs and
using IAC type methodology.
(03:33):
But then you have liketraditional network automation,
which you know, for those in thenetwork engineering space has
been growing for just a longtime, right, has been growing
for just a long time right Likeusing things like Ansible,
python and PyATS and all theframeworks that have been built
around network automation on thetraditional side.
So what we're really interestedin talking about with Eric is
(03:58):
kind of, first of all, like kindof getting a little in the
weeds on both of those, but alsoreally like what does an
organization do in a hybridworld where you really need like
a framework that kind ofencompasses both or all, or what
is the strategy thatorganizations should be looking
at to manage both of theseenvironments together?
Eric (04:18):
Yeah, I think that's a very valid question and, tim, to
your point.
I think we should probably justfirst define what we're talking
about, right?
So, begin with, just put intodifferent buckets.
So the first bucket would becloud native and, uh, so we're
talking about maybe aws, googlecloud and azure, and then we
have the on-prem right, likethat's back when you refer to as
(04:39):
just being physical networking.
We're actually going to thecisco, the junipers and we we
could get all the way down intothe back lanes where there's a
chassis base, where there's apizza box and so on and so forth
.
And the automation strategy,like you said before.
I might even add that we'vebeen trying for a long time and
unsuccessfully trying toautomate it.
Tim (05:01):
I know how to say it.
Eric (05:02):
Success rate.
It's always on the spectrum.
So you know some organizationsare more successful than others,
but I don't think we couldclaim 100% success rate at any
of the organizations, even foryou know the hyperscalers, you
know so, as you know, I'veworked for AWS for about five
years.
I worked for Azure for aboutfive years so that's 10 years
(05:23):
from an insider's perspectiveand for about five years I
worked for Azure for about fiveyears, so that's 10 years from
an insider's perspective andthen I was a vendor for you know
the hyperscalers and, being inSeattle, you know I've always
had visibility to AliCloud, toOracle Cloud and all these other
locations that may not be thetop three but definitely still
up there and playing and tryingto get engaged into the game.
So I would say, you know, say Idon't think there's any
(05:48):
strategy, that there's no onering that rules them all.
Just get that out of the way.
So I think, even tooling-wise,there are softwares that are out
of cloud, native, and they'rebetter at cloud.
If you think about Terraforms,if you think about all these
other very natively driven andthey started from the cloud,
(06:09):
going into on-prem and everybodytrying to get into each other's
territory, and then you havesay ansible.
That started maybe for theon-prem, maybe for even systems,
and then go into networking andthen they expand you to the
cloud where you run yourplaybook and they could actually
, you know, uh, touch terraformor go into the cloud apis
(06:29):
directly, but, um, but I don'tthink either one of them could
claim complete dominance on eachother.
So so I think it's really on thespectrum and a percentage game.
So if your organization is morecloud, then you probably want
to have your bias toward thesecloud native tools, and if your
(06:52):
organization is more on-prem,then you probably want to take a
look at these tools that arekind of favoring on-prem devices
, favoring on-prem devices.
So I don't know if that makessense, because I've lived in
both worlds, and I would saymost of the time, just because
I'm old, I don't have a beard,but I have been doing this for a
(07:16):
couple of bubbles now.
So, yeah, so in my previousexperience I've always dealt
with on-prem a little bit moreand therefore I have more
knowledge on, like the ensemblesof the world, if you will write
python scripts, nor near namiko, that sort of stuff, and, uh,
less on the terraform side don'tworry, eric, we'll get you a
beard.
Chris (07:34):
We'll put it on a beard.
It's gotta be a fake one, myagent does not allow, uh, any
kind of beard.
It's like if I grow for twoweeks.
Eric (07:43):
My wife would just be like , hey, is this something dirt
like a little?
Tim (07:46):
bit.
You have a little somethinglike yeah you gotta wipe that
off right but um yeah
Eric (07:53):
I, I came to peace with it .
Chris (07:54):
Yeah, that's I mean to your point.
You know the, the cloud, uh,we've talked about this on the
show plenty of times, but it'slike everything is api first.
Right, that's kind ofeverything that has an api, just
like out of the box.
It's not even going to go tomarket unless it has a front end
API that you can interact with,right, um, whereas I feel like
in the traditional on-prem worldthat was always a struggle, at
(08:17):
least just like having APIsupport from any of the major
vendors across the board or evenjust getting kind of like
structured data from a lot ofnetwork appliances across the
board right.
That was a lot of screenscraping, a lot of cli commands
and things like that yeah, whatdo you feel like obviously
ansible's kind of come into playand then they can, you know
they help with that a little bit, and ordinary and things like
(08:37):
that.
What do you feel, jesus?
Eric (08:40):
sorry, the plane just went over so.
No problem, that's exactly howI feel.
The plane just running over.
Chris (08:50):
What do you feel is the state of that today?
Where have we made it to andhow are people interacting with
both?
Eric (08:56):
Yeah, and I think I want to get back to your point about
API driven to begin with, right?
So I think that's veryimportant and kind of set the
stage for the mindset following,because when I was working for
Amazon, it was 2006.
We had S3 bucket and we didn'thave EC3, we didn't have VPC.
We didn't have any of that.
(09:16):
And if you roll back into acouple of years ago, when Warner
Vogel, the CTO for Amazon, whenhe joined, he had in mind, even
before the cloud, what we knowas the CTO for Amazon when he
joined, he had in mind, evenbefore the cloud, what we know
as the AWS in the cloud, even inthe retail world.
He had that vision of you know,there's no like, we want to
commercialize, we want to sellthis to external customer.
So internally there was amandate to have everything and
(09:39):
he wrote about it in his blog,right, this is no secret that
everything needs to have an api.
Nobody has backdoor.
And back then, if you remember,you know databases always
drives a lot of the operations,uh, loads, as far as you know.
Uh, just the overhead, right,like you're trying to index
stuff, you try to dump data andtry to get data out and
everything's data driven.
(10:00):
So even the database part, likethey don't have a backdoor,
they don't have a direct, youknow, command line going to go
into the database in the backend, so every single service has
to be terminated internally, weuse api to talk to each of the
services.
So so then, that makes itreally easy to commercialize it
later on and be api on par withthe features on the feature set.
(10:23):
And obviously, after that,azure was the second one.
They saw how it was.
And now, if you remember, therewas a time when Azure had I
think they still do have thisfeature comparison between Azure
and AWS and be like hey, theycall it VPC, we call it VNet,
they call it Transit Gateway, wecall it something else, they
(10:43):
call it Direct Connect, theycall it Transit Gateway, we call
it something else, they call itDirect Connect.
So there are feature parity andobviously they have to have API
as well.
And so what I want to drive tois that this mindset of API
first and abstraction.
So I think the biggestdifference between cloud and the
(11:03):
on-prem is that there's adifferent abstraction layer
that's come from the cloudprovider, whereas on-prem you're
dealing directly with thedevices and you're at the mercy
of the equipment vendors thatgive you these abstraction or
not.
And therefore, I think you knowit's almost like starting from
(11:24):
the root, because we're we don'thave this abstraction layer, we
don't have this, um, you know,like a different middle
middleman that allows us to, uh,you know, abstract some of the
hardware, like the messy details.
So therefore, we have to dealwith the messy detail, with the
on-prem, and therefore,therefore, the tools, the
drivers and the software SDKswill have to live in that world.
(11:48):
And even when we're trying tohave this, even when we're
trying to get consensus, thatwould never happen, right?
Like you know, part of thereason why Ansible was so
successful was because theyprovide a common framework, but
at the same time, they alsoallow different vendors to shine
.
Whereas, you know, puppets andChefs of the World, they not
(12:11):
only have agents, they also tryto normalize everything and
they're trying to live off onthe common set of commands.
And so the vendors do not wantto support Puppet, they don't
want to support Chef because itabstracts their secret sauce,
right?
So, whereas Ansible, they say,okay, you're normalized on the
(12:32):
playbook, but we also allow youto create your own custom
modules.
So, arista, you have these setof secret sauces.
You could do Cisco, you couldhave these, and then they sort
of converge in that front.
So I think the biggestdifference is we don't have this
abstraction layer for theon-prem devices and therefore we
have to deal with these youknow different vendors and makes
(12:52):
it really difficult tonormalize on the set of
standards, whereas it'sdifficult technology wise and
it's difficult politically, oryou know business drives.
So therefore it's kind of justthe reality when we deal with
the on-prem I don't know if thatmakes sense or if that's uh
jiving what you guys have heard.
I mean, obviously you guys havedealt with a lot more than more
(13:13):
than me, so I'd love to hear youknow what you guys just thought
on that as well, that's I thinkthat's pretty good.
Tim (13:18):
I mean, um, yeah, I definitely agree with that.
I I hadn't thought about whatyou're saying about the you know
, puppet and Chef versus Ansiblein terms of implementation, but
I think that tracks Also.
What I find is that the way andyou kind of touched on it when
you said like we had kind ofbecause it's real hardware you
know we have to deal with themessiness of it being real
(13:38):
hardware but also is just withthe real hardware.
We're coming at it from aretrofit perspective.
We're building the solution tomeet the hardware, whereas from
the cloud, native side, theyoriginally built the solution
with that you know that IAC orAPI rather in mind.
So it's like you know there'sthat too right.
(14:01):
Like Ansible or Nornir, forexample, all the frameworks for
managing or automating networkdevices were built long after
the network device existed,right.
So it's all coming at it fromthe retrofit perspective of we
have, here's what exists.
(14:22):
Now we have to build aframework to manage that thing,
given the restraints that arealready in place for that thing
that we have to manage, versus,like you said, with Amazon, like
they built it right up frontnot just Amazon, but you know
what I mean Like the CSPs builtit.
The solutions that they builtwere API first.
So we're going to build asolution and we're going to make
sure it has an API out the gate.
(14:43):
So definitely a big differencein the requirements for both
frameworks, I think.
Eric (14:50):
Yeah, and I also want to add that each of the cloud
providers, I mean they servetheir own purpose, right, like
they're trying to drive it cloudadaptation, whereas in the
network vendors they're tryingto sell more devices, so they're
trying to differentiatethemselves.
But Amazon, you know, trying todifferentiate themselves on the
kind of services that theyprovide, which is another layer
(15:12):
above networking.
They're happy to just have likea bunch of bridging interfaces.
Tim (15:16):
They don't care about the network, I don't think
performance is that big of anissue.
Eric (15:20):
But whereas in the physical networking you know the
speed and feeds are, definitelyexponentially increasing.
We're talking about backplanes.
If you talk about micro buffersor micro bursts, how much
buffer do you have in that NIC?
Or if you're doing the 40 gigand the 25 gig and the 100 gig,
(15:41):
and how do you do the splitcable and how do you transfer
that into a non-blockingbackplane?
So I think all of these arejust different requirements and,
um, you know, from a customer'sperspective, obviously you're
not, you don't have to beconcerned with it.
But even when we're buildingdata centers for amazon and
azure I do like it's a car foreverybody.
Yeah, it's a car for everybodyelse, for us, us it's racks and
(16:05):
cooling, and how much bandwidthand oversubscription, right.
So those are the kind ofchallenges that somebody has to
deal with it.
So whether it's the cloudprovider, whether it's you, the
network engineer, whether it'sJoe Schmock over at Data Center,
it doesn't really matter,somebody has to deal with it.
(16:25):
It's just that, as a customer,you know, do you, do we make you
deal with it or not?
And so those are the twodifferent crowds that that I
think we're facing with.
Chris (16:34):
So you know obviously you've you've also been at
network to code for for a whileas well.
I'm curious, like in your inyour time that you've spent
there.
We talk a lot on the show aboutthe hybrid network being in
cloud and on-prem as well.
What do you see as the mainstruggle or combative piece for
(16:59):
people trying to manage theircloud networks and their on-prem
networks?
Because, like you said, there'sa lot of different tooling and
in some cases it's much easierto just use, like Terraform for
cloud, whereas you know there'sTerraform providers written for
every major networking vendor aswell, but I don't know how well
that actually works inoperation.
What do you see in the realworld as far as how people are
(17:21):
doing that today?
Eric (17:22):
Yeah, I think that's kind of interesting to me and
obviously we're not going totalk any particular customer,
we're going to talk inaggregated and generalized form.
So I think the difference ishow the enterprise, each company
, is approaching this cloudthing.
So I think there are companieswho are just moving on-prem to
(17:43):
the cloud versus cloud nativeright.
So I mean you know, just becauseyou're using AWS doesn't mean
you are using the cloud services.
You're just, you know, moving,you're spinning up a bunch of
VMs as opposed to using, youknow, vmware on-prem, and then
you move those services overversus.
Maybe you're using DynamoDBover versus.
(18:08):
Uh, maybe you're using dynamodb, maybe you're using, uh, you
know, the vnets to and having,like, transit gateways and not
gateways and all of these otherstuff, right?
So they're different approaches, whereas they start from the
top.
And, uh, what, what kind ofapproach are we taking to the
cloud?
So, so, for the ones that arejust taking moving workloads
into the cloud as opposed tocloud native, they kind of use
(18:29):
the same tool, right, like,whatever works on the on-prem,
they can have to work it in thecloud as well.
Just because they're dealingwith a local API versus Amazon's
API doesn't really matter.
So so I think that the toolsare kind of transparent, but
that means all the headaches aretransparent as well, and I'm
not just saying it, for you know, network to code customers,
right.
It's just that my generalobservation from talking to my
(18:58):
guests on the podcast, fromtalking to other people during
conferences and so on.
And then there are others whoare truly taking advantage of
the cloud.
The cloud, for example, they'reusing Lambda functions, they
use storages and they use IAMfor authentication, as opposed
to just having a I don't knowTACX server per se in the cloud.
So I think for those approachesthen it's a lot easier and
(19:19):
they're less patient, if youwill.
They're less patient, if youwill, and they're trying to use
those.
So once they get used to thoseabstractions and use elastic
services no pun intended thenthey try to use that, they're
trying to transfer that into theon-prem and therefore you see
them bleed back into.
They're more receptive toDocker, they're more receptive
(19:40):
to Kubernetes and therefore theyuse these, maybe Terraform a
little bit more, and then theyuse you know, majority of the
workload is in the cloud andusing Terraforms and then they
try to use the same tool tomanage the on-prem.
So I think it really starts withthe strategy on the enterprise,
(20:01):
on how they're migrating to thecloud and how they're using the
cloud, and then go from there.
And I would say most of thetime, at least from my
observation, is the prior camp.
It's like when they talk aboutwhen there was like a frenzy
about moving workloads into thecloud.
They simply spun out VMs andthen they just moved the
(20:21):
workloads over.
So it's like, yeah, it's greatthat we can spin up a VM as
opposed to provision a localdevice, but at the same time
it's the same, it's kind of thesame thing.
And then they gradually workedover.
You know, oh, there's this, youknow, lambda function, that's
great, and there's this APIgateway, that's great.
So I see kind of thistransitioning, but it really
(20:42):
starts from how you're treatingyour workload and then that kind
of triggered down intonetworking, because you know,
nobody cares about networking aslong as your packet goes from
point A to point B, that's sotrue.
Yeah, then we're good, right.
So yeah, for all, we care.
Like I said, we could have abunch of bridge interfaces, just
like what Docker uses natively,right?
Tim (21:01):
Yeah, that's a really good point.
Yeah, so the more we talk aboutthe tooling, so the more we
talk about the tooling, the moreI keep thinking about, like we
have all these tools formanaging and some of them are
strong at managing, say, realhardware, and some of them are
stronger at managing, you know,cloud native or API driven stuff
.
And then that's without gettinginto things like traditional
(21:23):
vendors that have API GUIs tomanage their network stuff, like
you know, for example.
Eric (21:27):
You know it's like all over the thing that have API
GUIs to manage their networkstuff.
Oh yeah, those are horrible.
It's like a whole other thing.
Don't get me started onmenu-driven, right?
You got to press 1, and thenyou press 1, and then they go oh
press, what kind do you want?
I was like oh my God, it's justlike no right.
Tim (21:44):
GUI-driven workflows tend to suck right If you have the
ability to do it with an API,and that's, you know, hit and
miss depending on who createdthe API for the GUI driven.
That's like a whole other thingright there.
But the tooling wise, what Ifind interesting is like so,
like, take like just Terraformas an example.
Right, like Cisco, juniper,like Arista, they've all got
(22:06):
Terraform modules for theirhardware, right, so that you can
handle it, manage the gear orwhatever, and it's supposed to
be declarative and all of that.
But do you find, with somethinglike Terraform, where it's all
like, hey, the state shouldalways be in this state, versus
something like Ansel, whereyou're playing a playbook, where
(22:27):
it's idempotent but it's alittle different the way it
handles the life cycling of theplaybook is totally different.
Do you find that?
That what's the word I'mlooking for, like that kind of
management strategy to be betterfor one over the other.
Eric (22:43):
Yeah, I don't know.
I think they're different.
I don't know if one is betterthan the other.
Certainly I think theidempotency is a little bit
easier to do it on the API frontrather than doing natively, and
it's great that Ansible, forexample, is getting more
declarative.
But there's still a lot ofprocedures that is kind of
procedural, where you just kindof do step by step and you've
(23:07):
got to handle that out of bandyourself.
You're collecting, uh,collecting facts, for example,
right, and then you know, basedon the collecting fact that you
do it and if, if the moduleyou're using is nice, then they
do it for you.
Uh, if not, then you kind ofhandle that yourself.
Your your, you know collections, or you know your vendor choice
, so then we're getting intokind of the weeds on.
Or you know your vendor ofchoice, so then we're getting
(23:28):
into kind of the weeds on.
You know what does ID ponzimean, right, and what does
declarative mean, and so I thinkyou know it's just like these
concepts are kind of foreign.
For you know traditionalnetwork engineers, like you know
what do you mean.
Like I always want to do config, t, interface, and then you
know, change my description,whether then you know phase, and
(23:49):
then you know, change mydescription, whether then you
know and it takes a while tochange that mindset into
thinking, okay, I just want tosay this is my description.
And then I want to say, true,right, then, I don't care how
you do it, I just want it to betrue and I want this is my
description, as long as it hasit, I don't care how you put it
there, and that's thetransparent into like say, uh,
so if those two other lines,then then it's okay with the
(24:09):
underlying is Cisco, with Arista, juniper and so on and so forth
.
So I think that's also a kindof a hurdle is the skill gap,
this mindset gap that people are, you know, learning, or they
brought up in a certain way.
So I would say it's different.
I don't know if it's better ornot, because the challenges are
different.
What I would say is I think thenewer engineers, the engineers
(24:32):
who were born after maybe 2000sand now they're just getting
into the main state of the teams, that they are more receptive
and they're more, I guess,gravitate toward these APIs and
gravitate toward declarative,whereas if you talk to somebody
(24:54):
who's been doing this for a longtime, that you know they're
pretty much said in their ownways.
So I would call them as beingdifferent and kind of tailored
toward the environment thatyou're in.
But I would say I don't know ifit's a generational difference,
but I do think that the new waysare kind of getting into it.
So people are kind ofscratching their head.
(25:15):
It's like what do you mean?
The traditional iOS doesn'thave APIs, right, and what do
you mean?
That it's a simple HTTP serverthat doesn't have encryption, or
like password-basedauthentication versus key based.
So I think I think all of theseare just gradually take place
and we do need a lot more, um, Iwould say, like the younger
(25:36):
engineers, the new blocks, tocome in and kind of give us new
perspective and um, you know andI don't know if you want to
touch into ai, but maybe youknow, like people are talking
about ai native engineers, right, and and I kind of just thought
, what are you talking about?
Ai has only been around forthree years, so are you going to
hire babies?
(25:57):
They're certainly AI native.
Tim (26:00):
Yeah, well, that gets into the whole.
What does an AI native engineereven mean?
Does that mean you code all dayby time?
Are you vibe coding?
Is that what that means whenwe're talking about AI native
engineer even mean?
Does that mean you code all dayby time?
Are you vibe coding?
Is that what that means whenwe're talking about AI native?
We've talked a few times about,many times about the whole idea
of the gap that's going to existbetween you've got your senior
engineers now who learned theway they learned and they know
(26:24):
what they know and whatnot.
And then, for better or forworse, it seems like businesses
want to replace you knowexpertise essentially with AI to
some degree.
Right, even if you have aperson in the seat, they want
that person to be leveraging alarge amount of AI to, in theory
, make them better or faster.
It's really the same networkautomation argument we've been
(26:48):
having for the last what almost10 years now at this point about
how network automation is goingto A take everybody's jobs or B
make everybody faster, or bothright.
But you know, I wonder wherethe gap will be when you've got
these juniors that only know howto use AI, that don't you know,
have to learn and go throughthe experience and get
experience.
They just rely on that, don'tyou know?
Have to learn and go throughthe experience of, and get
(27:09):
experience?
They just rely on AI foreverything you know.
All that training data istrained on people that have done
this stuff over time.
So what happens when the cliffis hit and the people are gone
that that knew how to do thestuff and the training data with
it?
Snake eat its own tail or likewhat.
What happens there?
Eric (27:27):
Yeah, I think I think you know interesting, you brought
that up.
I mean.
So there's only so much data,existing data, that you're able
to leverage and you knowexisting knowledge.
Right, it took us, you know,probably the beginning of 2000
to build all the way up untilnow to have this data.
And in the last AI extent for Ithink it was Sequoia Capital, I
(27:47):
mean, they actually, you know,deliberately come out and say
you know, we're running out ofdata.
So what they're trying to do isthey're trying to simulate more
data and especially run outdata for physical AI.
So you know writing code, yeah,sure, everybody could just
scrape GitHub and you get abunch of like code examples and
you have a bias toward opensource, but that's another story
(28:09):
.
But what they're running out ofdata is physical data, right,
like think about how many imagesdo you have, chefs, like
cooking, and so you could trainthe robot to do that.
So there's not a lot oftraining that you could do
because they don't have data.
So they're trying to simulateor, you know, put in another way
, if they're trying to, you know, you, how many of these actual
(28:29):
driving data do you have?
Right, how many Teslas outthere?
That's aggregating the databack.
So they have these trainingdata?
They don't.
So what they're trying to do istrying to simulate data and so
on.
So that's like one thing thatthey brought up and that's
absolutely true.
But back to your original pointabout hiring engineers whether
they're junior, whether they'resenior, whether they've been
(28:51):
doing this for a while, I thinkthe difference is that they're
transitioning from thinkingabout human to thinking about a
group of tasks, right?
So it's just okay, I have thesebundle of tasks, if you say one
to a hundred, these tasks,bundle of tasks.
You know, if you say one to ahundred, like these tasks and
(29:12):
previously I know that myselection is limited I need to
hire a senior engineer with xamount of salary, with amount of
benefits, in order to handlethese tasks.
So my pool is very small.
But now that you know, when Ilook at it, I said I could hire
one senior engineer and use hisAI army, these AI agents, that's
able to accomplish these 100tasks in the same amount of time
or less, right?
(29:33):
So I think that thetransitioning is more around the
mindset of from humans andtaking the human constraints
with them into just thinkingabout it as a group of tasks.
So back to what you were talkingabout is does it really matter
whether it as a group of tasks?
So back to what you weretalking about is does it really
matter whether it's a juniorperson that's using these tools,
that's being productive andable to accomplish tasks, or
(29:56):
whether it's, you know, still asenior person but he's using
these AIs, agents and helpers todo these tasks right?
So I think it is shifting themindset away from human because
that's no longer a constraintinto tasks.
And then how productive can yoube?
So that begs the question youknow what tools can make you
(30:17):
productive and to me that's very, very different between each
person.
You know I might like Cursor,you might like Cloud and Chris
might like your ChatGPT, and youknow 5, six, seven, eight,
whatever they're coming out now,right, so Sam Altman, huge Sam
Altman fan.
Oh my God, I don't know man, Ihave a few books to uh.
Uh, I think it's a.
(30:38):
It's called AI empire by uh.
Tim (30:40):
Empire of AI.
Right, yeah, you recommendedthat one to me.
Yeah, you recommend that to me.
Eric (30:50):
Anyways, yeah, so, um.
So to me, anyways, yeah, so, um.
So I think I think it's justthese um, these mindset shifts
on, you know, grouping um,because the the constraints no
longer on the human andtherefore we're changing our
shifting our mindsets to justgroup a task.
And how can you be moreproductive?
So that's up to each one of usto think about what works best,
right?
So, and then I think that'skind of individual,
individualistic, like tim.
You know, before we hit therecord button, you said you use
(31:11):
Windows and Windows make yousuper productive.
And for me, you know, I've beenusing Mac about 25 years, so I
had no other shortcuts.
You know, I know the Vim editorand I have all these backend,
you know, shortcuts that I use.
So whatever makes youproductive to each of their own
and I think that translates verywell into ai is just that I
don't care if you just have twoyears of experience, I don't
(31:33):
care if you have 20 years ofexperience is how can you
accomplish these tasks with highquality shorter amount of time?
Chris (31:39):
yeah, I think it's.
I think I think that is a goodpoint.
Like, obviously you know,expanding your productivity and
kind of efficiency as anengineer is is is obviously a
great opportunity with ai and alot of tooling that's you know
out or coming out today.
But, like the, the thing islike you have to have the
(31:59):
awareness of how to use thetools and I think that's what
I'm worried about because, like,even like me, I think of an
example like I don't like evenme.
I someone I've been innetworking probably like for 15
years now and to this date Istill have never actually
physically implemented dot 1xever in my life.
Eric (32:17):
So like I just go on chat, gpt or lucky you yeah, no,
spanning tree, you don't have totrace back to your rubric.
Oh my god, you know drperlman's gonna be anyways.
Yeah, yeah, but no, like I goand I'm like just tell me about
dot 1x, like I just traced backto your rubric.
Chris (32:28):
Oh my God, you know Dr Perlman is going to be yeah,
yeah, but no, like I go and I'mlike, just tell me about that
one X Like.
But like I noticed, like I, Iknow I have a certain level of
knowledge about what I don'tknow, right, right, like, which
is, which is a very much biggerbox than what I do actually know
.
So I know, whenever I'minteracting with these tools, I
want to provide so much context,like be very, very specific
(32:51):
about what this environment isthat I'm interacting with and
how I should get arecommendation or get kind of a
lead on something, whereas thejunior guy isn't going to know
junior guy or gal isn't going toknow to provide that level of
context.
They're not going to say likeoh, they're going to say like oh
isn't going to know to providethat level of context.
They're not going to say likeoh, they're going to say like oh
(33:11):
, how do I just add a VLAN tothis switch or something like
that.
Tim (33:14):
But there's so much like in , there's so much context to it.
Chris (33:16):
Absolutely destroy it Right.
So I feel like it's or it'sdangerous territory in some
scenarios not in all scenarios,but in some of them.
I think that's what worries me.
Eric (33:25):
Yeah, absolutely.
I think on the same line ofthoughts, chris.
I think you know so for me, youknow I understand Django a
little bit better.
It's what I use for webframework.
So when I fire up my cursor andI want to, you know, do a few
front pages and all of that, Iwould say, hey, use Django, Use
UV as your package management,and this is how I want to
(33:50):
organize my views, my back-enddatabase, and then they just go
and do it.
What used to take me maybe acouple of days, they could do in
a couple hours, and that makesme more productive.
And where they run into issuesI could troubleshoot, I could
say, hey, why are you puttingthis way?
Why are you doing that?
So to your point is that youneed to provide context and it's
to speed up, as opposed to youknow your vibe coding and just
give me a web page and itbecomes a security vulnerability
(34:12):
.
It becomes, you know, a um, aspaghetti code, for nobody else
can understand but ai themselves, right?
So I think that begs thequestion.
So how do you get a juniorengineer really, really fast up
to speed on to a senior level sothey could redirect all the
other agents to be able to beproductive like you and I right
(34:32):
so I think yeah.
so I think my answer to that isit's very difficult, but one way
to get started was to pick aitools that are more transparent
than others.
So there are tools that whenyou ask a, a, uh, an ai agent
and say, oh, not a agent, maybethey'll prompt right.
So when you ask something,they'll give you the answer back
.
And when you need to go askagain to say why are you saying
(34:53):
that, does this change when Iprovide more context, more
examples and 5,000 other thingsthat I want you to know?
And then it does change.
However, there are other toolswhere you give it a question and
then they'll say, oh, let methink about it.
Right, let me think about it.
And then here's what I takeinto consideration, here's what
I'm trying.
Oh, that didn't work and let mego try something else.
(35:15):
It's all in the background, andthen that's a transparency.
You will hide it at the end andgive you an answer, because
nobody wants to read all of thatjust to get the answer.
But you have the choice ofgoing back and say I want to see
your step one, two, three andfour.
So, as a junior engineer or assomebody who you know for me,
you know I understand Django alittle bit better, but I don't
(35:37):
know JavaScript.
So whenever I have a JavaScriptquestion, I always try to tell
it to slow down, give me moresteps, and then I'll always go
back to those prompt until Ifeel comfortable with whatever
java javascript framework I'musing.
So I think that's very true and,um, and if you're, if you're
concerned about the gap, I thinkeverybody is right, like
everybody wants five years ofexperience, but nobody wants to
(36:00):
train somebody for five years.
So so those are, how do weshortcut it?
And to me, I think that ups,that's uh, it's up to us, like
the senior engineer, to demandthat kind of transparency
through the tools that we use.
So, pick a tool that isresponsible, that's ethical and
then takes care of AI safety,and then give you that trust,
(36:22):
give you that transparency tobuild trust for us, as well as
to bring up the other peoplethat are, you know, just
graduated out of school and thenthey need that busy work in
order to build out theirknowledge base quickly.
Tim (36:35):
I think that's pretty good.
I still do have some smallconcern that, because I mean,
how does someone become senior?
Ultimately they have to beexperienced and they have to
understand that there's thingsyou cannot learn out of a book
or by AI telling you about it.
Right, there's anybody who'sever and this is one thing I've
never actually done, but likeanybody who's ever done the
(36:58):
switch port trunk ad, you know,or VLAN, whatever.
Eric (37:02):
Without ad.
Tim (37:03):
yeah, and erased all the VLANs.
Eric (37:05):
Right and erased all the VLANs.
Tim (37:06):
There's lessons to be learned throughout the
experience of being an engineeror whatever.
That simply cannot be filled inby whatever reason AI or other
book learning or videos orwhatever you have.
So I'm still, but I do agreethat actually what you described
(37:26):
was perfect, right, like yousaid, use Django, use this
database, like you know what youwant.
You just don't want to type forgood reason.
You don't want to sit there andtype it all out and do the work
.
That's the kind of work I thinkis perfectly right to hand over
to an AI agent to do, becauseyou already know what you want,
(37:48):
what the end product should beand all of it.
Right.
But you yourself know thatbecause of your years of
experience.
Like Chris said, if a vibecoder comes in and says, hey, I
need a website and a database,like you pointed out, they're
going to.
You know.
God only knows what you'regoing to end up with, and the
person who wrote that prompt hasno idea what they're looking at
or whether it's right wrong.
Eric (38:11):
Yeah, I think you're absolutely right, tim, but
that's a challenge of ourgeneration and that is a
challenge of, I think, to alarger degree, how the society
will be able to cope with AI andimprove upon it.
So, no doubt, right, no doubt,when you get something burned,
when you're at 3 am in themorning that you're typing in
that command that you described,and then you wipe out all the
(38:33):
trunking ports, right, yournative Vlan is now whatever, and
then you lock yourself out andthen you have to drive to the
car.
So those kind of lessons thatburn into your brain, right,
like, you're just, you just kindof your eyes bleed, and then
you remember it.
Of course, you know absolutely,however, you know we, it's just
reality.
There's no way that we could,we could do, right Like, the
(38:54):
speed of change, the wide scopeof technology.
They're just not going tohappen.
And so how do we learn how tolearn Then?
That's the challenge of ourgeneration is how do we learn
how to learn and how do we bringpeople up to speed on such a
broad scope of knowledge quicklywithout having to actually
(39:15):
spending the time to learn thatand um, and that's why I'm
pretty optimistic on thelearning aspect of it, right,
like I think you know, um, ifyou think back on, uh, you know
just how do you learn the ethics?
How do you learn that?
Um, so that you don't have togo repeat everything you don't
learn as well.
But you know no-transcriptconfetti, the VLAN trunk, right?
(40:05):
So yeah, simulate that,simulate some sort of VR program
where it's so real that you getthat bleeding of eyes.
You get that.
You know, 3 am in the morning,kind of nervous shot.
And maybe even simulate drivingto the hub sites.
Right, but you know thedifference is, instead of
physically driving to the hubsite, you actually say, ok,
you're there on the hub site,right?
(40:26):
So so, yeah, so I think I thinkI echo what you're saying and
but I also challenge a littlebit on.
You know, I think that's thechallenge.
That is how, how we're going tomove forward as a society is
how can we bring everybodyupwards at the same time?
So, um, so we talked about, youknow, kind of uh, kind of my
(40:47):
vision, right, my North star onsome of these other stuff.
So so the first one, that'seven before trust, is, uh,
enhance, not replace.
So there are tools out there ortheir ai startups that promises
to reimagine, whatever, xyz,and then you don't need these
anymore.
But for me, you know, I, I wantto bring everybody forward,
right like that's my passion.
(41:08):
Yeah, so I think you know thatenhanced, not replaced, and that
kind of drives a lot of the um,a lot of subsequent projects or
or something like that.
Right, like I don't want togive up on people.
Tim (41:18):
No, actually, yeah, I love it, go ahead.
Chris (41:21):
I was going to say, yeah, that's like I totally agree
with you in that, in that, likewhere on where we need to get to
the pro, the thing that Istruggle with is like, as
someone that is, you know,considered a senior in this you
know kind of field, like I, likepeople that are getting into it
, it's hard for me to givedirections Right, cause it's
like, you know, if we think backabout to like back when we were
(41:41):
learning, you know, like CCNAor something like that, I
remember when I was taking myCCNA, I remember I was like
learning about frame relay andI'm like why the hell am I
learning about this?
I've never touched frame relay,frame relay in my life, like
that was something thateventually fell off the back of
the truck because more stuff gotadded to the front of the truck
, right, yeah, but now I'mwondering if so much has been
added to the front and like Idon't know what's fallen off,
(42:03):
right, and to tell people whatnot to waste their time on,
because I like I don't know weprobably overthink this stuff.
But I can think of like so manyscenarios like well, you might
need to know about this, you,you, you know, you need to know
about VLANs and things like that.
You know, even if you're doinga lot of cloud stuff, you know
like if if you, if you're anetwork engineer that just got
into cloud, you would probablynever touch a cloud.
(42:25):
Like if you were just doingpurely cloud, you never touch a
VLAN in your life.
But VLAN is like such a coreconcept that is like required
everywhere else.
It's just like is like requiredeverywhere else.
It's just like.
That's, yeah, it's the gap thatI don't know how to fill right
On, how to tell people to getinto this stuff.
I guess and I'm worried aboutthe bottom rungs of the ladder,
kind of you know becoming veryshaky very soon.
Eric (42:47):
Yeah.
So I think, going back to yourpoint, Chris, that VLAN is
fundamental.
So if we're going back to saymaybe the VLAN, this VLAN is
fundamental, so if we're goingback to say maybe the VLAN, this
VLAN thing, or it might changeto VNets or something else, or
we'll just have enough VNets outthere, Nobody needs VLAN
anymore or something like that,but the concept of broadcast
(43:07):
domain, collision domain, thesebasics do not change right.
So maybe what we need to do isto teach the fundamentals.
We teach them about IPaddresses.
Tim (43:17):
Subnetting and stuff.
Yeah.
Eric (43:18):
Subnetting whatever it is that we consider as basic and
that's fundamental.
That's the building block.
So we give them enough big youknow Lego pieces and whatever
smaller pieces on top of that.
Then those are transparent andwe make it clear that previously
you know this dude, when he was, you know implementing switches
, like we have to know VLANs.
(43:38):
But hey, dude, like you're thenew generation and you may not
need to know that because you'recloud native, however, you know
your collision domain and itdepends on really how deep the
cloud provider provides right.
So I think it's getting theclarification on.
You know what are thefundamental building blocks,
tgl's fundamental buildingblocks, and then you know you
(43:59):
build on top of it and becausewe're getting much more
specialized, so all of us are ina way, one way or another,
generalists.
And you know I think you haveWill last on and he clearly
defined himself as a generalistright and I would agree to that
last time, that he clearlydefined himself as a generalist
right.
So, and I would agree to that,but I think, as we move forward,
(44:22):
there just might be just cloudnetwork engineers or there might
just be, you know, hyperscaler,you know network engineers
within data centers, you knowdoing top of rack switches,
whatever right.
So I think, you know, with eachof those roles as being
specialized, the building blocksthat we teach might be a little
bit different, and I'moptimistic, but I do think the
(44:44):
skill gap and the fact thatnobody again back to what you
were saying, tim, that everybodywants three years of experience
but nobody wants to give thatthree-year experience to the new
grads, that's a problem.
So how do we solve that?
That's a challenge of ourgeneration, I feel.
Tim (44:55):
Yeah, we're up against time , but I'd love to know you know
what's your using AI or notusing AI, like I don't want to
just leave it here.
Eric (45:04):
Oh, I'm using AI every day .
No, no, I mean no, no, sorry.
Tim (45:08):
Yeah, I mean, we all are in some, in some capacity.
I think we all are at thispoint.
I use no checks too.
I don't feel bad about that.
Yeah, exactly.
Um.
So what?
Moving forward, like what iswhat do you think is the very
shortly period of time?
What do you think is the?
The right answer is it, is itget a junior teach the
(45:28):
fundamentals and then we givethem, I guess, just ai tooling
and say, like you know, here areyour tasks, uh, use your ai
tools, or what is that?
It or what's the?
How do we solve this problem?
Moving forward, do you think?
Eric (45:41):
I think, going back to my newer start, right.
So, like other people mighthave a different answer, but my
newer start is enhance, notreplace.
So that is my answer.
That's what the answer I wantedto be, and I'm trying to be the
change that I want I want tosee.
So I want to bring a juniorengineer in, or somebody who's
you know in college right now,and in fact, I'm talking to my
(46:02):
friend and say, uh, I don't knowif you guys saw, I clear a
bunch of uh, networking gears inmy garage and I'm donating them
to the local college and I'mtalking to them on, you know,
how do we bridge this gap?
Right?
So I think I'm putting my moneywhere my mouth is and that's
the answer I want.
I don't know if that's theanswer will be or if that's the
(46:23):
answer that's everybody's.
All I can say is that's theanswer I want to see, and I'm
taking actions to accomplishthat goal is yes, I want to
bring somebody and, as a fatherof two teenagers, I want them to
have somebody else when they'reworking in whatever field that
they want, that somebody wouldtell them yes, come on, right,
(46:44):
like, I will teach you whateverit is that you need to learn.
But here's the group of work,here's the body of work you have
to put up with, and then youcould get to the other side.
So, yeah, so that's my answer.
You know, I'm optimistic, Iwant to give efforts to that
movement and, uh, yes, you know,just, I want to enhance, I want
(47:05):
to enhance people so that theycould be, um, you know, capable
of thriving in this economy inthe next 20, 30 years right.
Tim (47:13):
Yeah, I like the enhance not replace as well.
But the only thing that worriesme and we're going to close out
here but what worries me about?
Enhance, not replace, or notthe opposite what worries me
about?
Not enhance, not replace, notenhance, which seems to be the
way a lot of corporations aregoing these days to pay for the
AI that they're building is justthat right.
(47:35):
They seem to be on the replace,not enhance.
But I agree with you when I useAI, it's about enhancing my
workflow, not replacing myworkflow.
I don't hand the keys over.
I use it to do stuff I alreadyknow how to do.
Eric (47:48):
What I think is happening is the pendulum always swings
over the one way or direction ornot.
So now, as you know, we have abunch of layoffs in the industry
and some people joke aboutthey're being replaced by GPUs
right, so they're spendingbillions of dollars on GPUs, but
they're cutting thousands ofdollars, hundreds of thousands
of dollars in salaries.
(48:09):
So I think that pendulum is kindof swinging both ways and what
I see happening is theyoverhired and over putting a lot
of bets into human resourcesand capitals during the COVID
years, and now they have thisdrunken effect, the day-next-day
hangover effect.
So the pendulum is swinging thisway and hopefully I think
(48:30):
that's going to swing back whenwe're a little deeper into the
hype cycle and then we find thebalance and so on.
So I do think that if we'rejust looking at all the bubbles
and all the histories and youand I, tim and Chris, probably
that we live through the dot-combubble, we live through the
(48:50):
financial crisis, we livethrough for me at least, you
know, like the Asian, you knoweconomic crisis, the Korean
market crash and so on, so forth.
So so I think you know, Ialways see these pendulums
swinging, so hopefully we'regoing to have reached a more
equilibrium in a short while.
And if you know because beingin Seattle and I know a lot of
(49:11):
layoffs has been happening justthroughout the years and don't
lose hope.
I think you know the the if youjust look at the history, just
go get through this dark periodand then you know we might have
something that, uh, that worksout at the end.
Chris (49:24):
Thanks, we will.
We will survive this one.
Whatever happens, we willsurvive we always do right.
Eric (49:29):
I mean, I'm optimistic, so I hope so.
Uh.
If not, then uh, then thatsucks yeah, I like that.
Tim (49:36):
All right, everybody, we'll go ahead and uh and then wrap
it there.
Uh, thanks for joining us.
Uh, eric, eric, where can be?
Uh?
Where can people find you?
Eric (49:43):
yeah, so you know, connect with me on linkedin.
I'm not very hard to find.
So, uh, eric chou, if you wantto take a look at some of my
books, you can find outeverywhere you get your books
amazon, uh, apes books orwhatever that you get your books
from.
No more physical bookstore,unfortunately, and last but not
least, if you want to check outmy podcast, network Animation
Nerds, I weekly, biweekly,release and hope to just engage
(50:09):
with you one way or another andcollaborate and let's make this
world a better place.
Thanks for having me, it's beena pleasure.
Tim (50:14):
All right, great.
Any closing thoughts?
Chris, are you ready?
Chris (50:17):
to roll.
No, all good man, it's beengreat.
We'll definitely have to haveEric back and oh, for sure.
Yeah, make sure you check outNetwork Automation Nerds.
It's a great podcast.
We'll put the notes in there orput the link in the show notes.
Tim (50:29):
All right, everybody.
Well, this is Tim and we'll seeyou next time.
Hey and welcome back to another episode of the Cables to
Clouds podcast.
I'm Tim McConaughey.
I am here at the Cables toClouds podcast.
I am here at the Cables toClouds podcast and with me, as
always, is my co-host, I guessChris Miles Just your buddy man,
just your buddy yeah that'sright.
Head of Real Life, mate,whatever we're going with this
(00:35):
week.
And we have a guest with us thisweek, which you probably
noticed if you're watching theYouTube Eric Cho, which is a
good friend of ours and of thepodcast.
We have not had a chance tohave him on yet, but we've been
trying for a good long time.
For those that don't alreadyknow you, Eric, you want to give
a really quick intro ofyourself.
Eric (00:55):
Yeah, sure, hey, it's good to be here.
Thanks for having me.
I don't think you guys triedvery hard, because I'm not very
hard to find.
I think it's just that you tryto keep the guest quality up
right, so you don't want to dragon that average, so I get it,
no worries.
I'm here, so now I'm happy.
Yeah, eric Cho.
And if you listen to NetworkAnimation Nerds podcast, I'm
(01:17):
there right by your earbuds.
Maybe every other week,hopefully.
If not, maybe you know me fromvarious books.
I've written six of them andthe book's been translated into
five different languages.
So if you're joining from Korea, thank you.
I doubt it, but because both ofthe readers in Korea are in the
time zone difference.
(01:39):
But yeah joking aside, right?
So I teach online courses atLinkedIn Learning, at Network
Expert, at Pluralsight and atvarious locations, so I'm not
very hard to find.
Hopefully we're connected onLinkedIn somehow.
If not, then please welcome tosend me an invite.
I'm happy to be engaged invarious conversations and not
just network engineering.
Tim (02:00):
That's great.
That's a good intro.
Eric is extremely prolific injust about all the content
creation stuff.
He's 10 times as good at thisas I am.
So it's usually like, hey, I'vetried that and that didn't work
so you don't have to right.
Eric (02:27):
So that's always been.
My mindset is just this um, youknow, learn, do and then teach,
and then just rinse and repeat,and I apply that to probably
almost everything in my life.
So you know, technology or newconcepts, books, um, yeah, all
all kinds of stuff, and we couldget into that later, but I
don't want to interrupt yourflow.
Tim (02:49):
All good man, that's a good point, all right.
So we brought Eric here becausewe really wanted to talk about
something that we've talked alittle bit about on the podcast
just ancillary for a long timeactually which is the automation
aspect, the infrastructure ascode aspect, of both cloud
networking and traditionalon-prem networking.
(03:12):
I don't know hardware networkingI'm not sure what you what is
the other word that we use fortalking about more like
traditional hardware networkingor at least traditional vendors.
You have the cloud nativethat's built with IAC in mind,
right, based on the cloudproviders, exposing APIs and
using IAC type methodology.
(03:33):
But then you have liketraditional network automation,
which you know, for those in thenetwork engineering space has
been growing for just a longtime, right, has been growing
for just a long time right Likeusing things like Ansible,
python and PyATS and all theframeworks that have been built
around network automation on thetraditional side.
So what we're really interestedin talking about with Eric is
(03:58):
kind of, first of all, like kindof getting a little in the
weeds on both of those, but alsoreally like what does an
organization do in a hybridworld where you really need like
a framework that kind ofencompasses both or all, or what
is the strategy thatorganizations should be looking
at to manage both of theseenvironments together?
Eric (04:18):
Yeah, I think that's a very valid question and, tim, to
your point.
I think we should probably justfirst define what we're talking
about, right?
So, begin with, just put intodifferent buckets.
So the first bucket would becloud native and, uh, so we're
talking about maybe aws, googlecloud and azure, and then we
have the on-prem right, likethat's back when you refer to as
(04:39):
just being physical networking.
We're actually going to thecisco, the junipers and we we
could get all the way down intothe back lanes where there's a
chassis base, where there's apizza box and so on and so forth
.
And the automation strategy,like you said before.
I might even add that we'vebeen trying for a long time and
unsuccessfully trying toautomate it.
Tim (05:01):
I know how to say it.
Eric (05:02):
Success rate.
It's always on the spectrum.
So you know some organizationsare more successful than others,
but I don't think we couldclaim 100% success rate at any
of the organizations, even foryou know the hyperscalers, you
know so, as you know, I'veworked for AWS for about five
years.
I worked for Azure for aboutfive years so that's 10 years
(05:23):
from an insider's perspectiveand for about five years I
worked for Azure for about fiveyears, so that's 10 years from
an insider's perspective andthen I was a vendor for you know
the hyperscalers and, being inSeattle, you know I've always
had visibility to AliCloud, toOracle Cloud and all these other
locations that may not be thetop three but definitely still
up there and playing and tryingto get engaged into the game.
So I would say, you know, say Idon't think there's any
(05:48):
strategy, that there's no onering that rules them all.
Just get that out of the way.
So I think, even tooling-wise,there are softwares that are out
of cloud, native, and they'rebetter at cloud.
If you think about Terraforms,if you think about all these
other very natively driven andthey started from the cloud,
(06:09):
going into on-prem and everybodytrying to get into each other's
territory, and then you havesay ansible.
That started maybe for theon-prem, maybe for even systems,
and then go into networking andthen they expand you to the
cloud where you run yourplaybook and they could actually
, you know, uh, touch terraformor go into the cloud apis
(06:29):
directly, but, um, but I don'tthink either one of them could
claim complete dominance on eachother.
So so I think it's really on thespectrum and a percentage game.
So if your organization is morecloud, then you probably want
to have your bias toward thesecloud native tools, and if your
(06:52):
organization is more on-prem,then you probably want to take a
look at these tools that arekind of favoring on-prem devices
, favoring on-prem devices.
So I don't know if that makessense, because I've lived in
both worlds, and I would saymost of the time, just because
I'm old, I don't have a beard,but I have been doing this for a
(07:16):
couple of bubbles now.
So, yeah, so in my previousexperience I've always dealt
with on-prem a little bit moreand therefore I have more
knowledge on, like the ensemblesof the world, if you will write
python scripts, nor near namiko, that sort of stuff, and, uh,
less on the terraform side don'tworry, eric, we'll get you a
beard.
Chris (07:34):
We'll put it on a beard.
It's gotta be a fake one, myagent does not allow, uh, any
kind of beard.
It's like if I grow for twoweeks.
Eric (07:43):
My wife would just be like , hey, is this something dirt
like a little?
Tim (07:46):
bit.
You have a little somethinglike yeah you gotta wipe that
off right but um yeah
Eric (07:53):
I, I came to peace with it .
Chris (07:54):
Yeah, that's I mean to your point.
You know the, the cloud, uh,we've talked about this on the
show plenty of times, but it'slike everything is api first.
Right, that's kind ofeverything that has an api, just
like out of the box.
It's not even going to go tomarket unless it has a front end
API that you can interact with,right, um, whereas I feel like
in the traditional on-prem worldthat was always a struggle, at
(08:17):
least just like having APIsupport from any of the major
vendors across the board or evenjust getting kind of like
structured data from a lot ofnetwork appliances across the
board right.
That was a lot of screenscraping, a lot of cli commands
and things like that yeah, whatdo you feel like obviously
ansible's kind of come into playand then they can, you know
they help with that a little bit, and ordinary and things like
(08:37):
that.
What do you feel, jesus?
Eric (08:40):
sorry, the plane just went over so.
No problem, that's exactly howI feel.
The plane just running over.
Chris (08:50):
What do you feel is the state of that today?
Where have we made it to andhow are people interacting with
both?
Eric (08:56):
Yeah, and I think I want to get back to your point about
API driven to begin with, right?
So I think that's veryimportant and kind of set the
stage for the mindset following,because when I was working for
Amazon, it was 2006.
We had S3 bucket and we didn'thave EC3, we didn't have VPC.
We didn't have any of that.
(09:16):
And if you roll back into acouple of years ago, when Warner
Vogel, the CTO for Amazon, whenhe joined, he had in mind, even
before the cloud, what we knowas the CTO for Amazon when he
joined, he had in mind, evenbefore the cloud, what we know
as the AWS in the cloud, even inthe retail world.
He had that vision of you know,there's no like, we want to
commercialize, we want to sellthis to external customer.
So internally there was amandate to have everything and
(09:39):
he wrote about it in his blog,right, this is no secret that
everything needs to have an api.
Nobody has backdoor.
And back then, if you remember,you know databases always
drives a lot of the operations,uh, loads, as far as you know.
Uh, just the overhead, right,like you're trying to index
stuff, you try to dump data andtry to get data out and
everything's data driven.
(10:00):
So even the database part, likethey don't have a backdoor,
they don't have a direct, youknow, command line going to go
into the database in the backend, so every single service has
to be terminated internally, weuse api to talk to each of the
services.
So so then, that makes itreally easy to commercialize it
later on and be api on par withthe features on the feature set.
(10:23):
And obviously, after that,azure was the second one.
They saw how it was.
And now, if you remember, therewas a time when Azure had I
think they still do have thisfeature comparison between Azure
and AWS and be like hey, theycall it VPC, we call it VNet,
they call it Transit Gateway, wecall it something else, they
(10:43):
call it Direct Connect, theycall it Transit Gateway, we call
it something else, they call itDirect Connect.
So there are feature parity andobviously they have to have API
as well.
And so what I want to drive tois that this mindset of API
first and abstraction.
So I think the biggestdifference between cloud and the
(11:03):
on-prem is that there's adifferent abstraction layer
that's come from the cloudprovider, whereas on-prem you're
dealing directly with thedevices and you're at the mercy
of the equipment vendors thatgive you these abstraction or
not.
And therefore, I think you knowit's almost like starting from
(11:24):
the root, because we're we don'thave this abstraction layer, we
don't have this, um, you know,like a different middle
middleman that allows us to, uh,you know, abstract some of the
hardware, like the messy details.
So therefore, we have to dealwith the messy detail, with the
on-prem, and therefore,therefore, the tools, the
drivers and the software SDKswill have to live in that world.
(11:48):
And even when we're trying tohave this, even when we're
trying to get consensus, thatwould never happen, right?
Like you know, part of thereason why Ansible was so
successful was because theyprovide a common framework, but
at the same time, they alsoallow different vendors to shine
.
Whereas, you know, puppets andChefs of the World, they not
(12:11):
only have agents, they also tryto normalize everything and
they're trying to live off onthe common set of commands.
And so the vendors do not wantto support Puppet, they don't
want to support Chef because itabstracts their secret sauce,
right?
So, whereas Ansible, they say,okay, you're normalized on the
(12:32):
playbook, but we also allow youto create your own custom
modules.
So, arista, you have these setof secret sauces.
You could do Cisco, you couldhave these, and then they sort
of converge in that front.
So I think the biggestdifference is we don't have this
abstraction layer for theon-prem devices and therefore we
have to deal with these youknow different vendors and makes
(12:52):
it really difficult tonormalize on the set of
standards, whereas it'sdifficult technology wise and
it's difficult politically, oryou know business drives.
So therefore it's kind of justthe reality when we deal with
the on-prem I don't know if thatmakes sense or if that's uh
jiving what you guys have heard.
I mean, obviously you guys havedealt with a lot more than more
(13:13):
than me, so I'd love to hear youknow what you guys just thought
on that as well, that's I thinkthat's pretty good.
Tim (13:18):
I mean, um, yeah, I definitely agree with that.
I I hadn't thought about whatyou're saying about the you know
, puppet and Chef versus Ansiblein terms of implementation, but
I think that tracks Also.
What I find is that the way andyou kind of touched on it when
you said like we had kind ofbecause it's real hardware you
know we have to deal with themessiness of it being real
(13:38):
hardware but also is just withthe real hardware.
We're coming at it from aretrofit perspective.
We're building the solution tomeet the hardware, whereas from
the cloud, native side, theyoriginally built the solution
with that you know that IAC orAPI rather in mind.
So it's like you know there'sthat too right.
(14:01):
Like Ansible or Nornir, forexample, all the frameworks for
managing or automating networkdevices were built long after
the network device existed,right.
So it's all coming at it fromthe retrofit perspective of we
have, here's what exists.
(14:22):
Now we have to build aframework to manage that thing,
given the restraints that arealready in place for that thing
that we have to manage, versus,like you said, with Amazon, like
they built it right up frontnot just Amazon, but you know
what I mean Like the CSPs builtit.
The solutions that they builtwere API first.
So we're going to build asolution and we're going to make
sure it has an API out the gate.
(14:43):
So definitely a big differencein the requirements for both
frameworks, I think.
Eric (14:50):
Yeah, and I also want to add that each of the cloud
providers, I mean they servetheir own purpose, right, like
they're trying to drive it cloudadaptation, whereas in the
network vendors they're tryingto sell more devices, so they're
trying to differentiatethemselves.
But Amazon, you know, trying todifferentiate themselves on the
kind of services that theyprovide, which is another layer
(15:12):
above networking.
They're happy to just have likea bunch of bridging interfaces.
Tim (15:16):
They don't care about the network, I don't think
performance is that big of anissue.
Eric (15:20):
But whereas in the physical networking you know the
speed and feeds are, definitelyexponentially increasing.
We're talking about backplanes.
If you talk about micro buffersor micro bursts, how much
buffer do you have in that NIC?
Or if you're doing the 40 gigand the 25 gig and the 100 gig,
(15:41):
and how do you do the splitcable and how do you transfer
that into a non-blockingbackplane?
So I think all of these arejust different requirements and,
um, you know, from a customer'sperspective, obviously you're
not, you don't have to beconcerned with it.
But even when we're buildingdata centers for amazon and
azure I do like it's a car foreverybody.
Yeah, it's a car for everybodyelse, for us, us it's racks and
(16:05):
cooling, and how much bandwidthand oversubscription, right.
So those are the kind ofchallenges that somebody has to
deal with it.
So whether it's the cloudprovider, whether it's you, the
network engineer, whether it'sJoe Schmock over at Data Center,
it doesn't really matter,somebody has to deal with it.
(16:25):
It's just that, as a customer,you know, do you, do we make you
deal with it or not?
And so those are the twodifferent crowds that that I
think we're facing with.
Chris (16:34):
So you know obviously you've you've also been at
network to code for for a whileas well.
I'm curious, like in your inyour time that you've spent
there.
We talk a lot on the show aboutthe hybrid network being in
cloud and on-prem as well.
What do you see as the mainstruggle or combative piece for
(16:59):
people trying to manage theircloud networks and their on-prem
networks?
Because, like you said, there'sa lot of different tooling and
in some cases it's much easierto just use, like Terraform for
cloud, whereas you know there'sTerraform providers written for
every major networking vendor aswell, but I don't know how well
that actually works inoperation.
What do you see in the realworld as far as how people are
(17:21):
doing that today?
Eric (17:22):
Yeah, I think that's kind of interesting to me and
obviously we're not going totalk any particular customer,
we're going to talk inaggregated and generalized form.
So I think the difference ishow the enterprise, each company
, is approaching this cloudthing.
So I think there are companieswho are just moving on-prem to
(17:43):
the cloud versus cloud nativeright.
So I mean you know, just becauseyou're using AWS doesn't mean
you are using the cloud services.
You're just, you know, moving,you're spinning up a bunch of
VMs as opposed to using, youknow, vmware on-prem, and then
you move those services overversus.
Maybe you're using DynamoDBover versus.
(18:08):
Uh, maybe you're using dynamodb, maybe you're using, uh, you
know, the vnets to and having,like, transit gateways and not
gateways and all of these otherstuff, right?
So they're different approaches, whereas they start from the
top.
And, uh, what, what kind ofapproach are we taking to the
cloud?
So, so, for the ones that arejust taking moving workloads
into the cloud as opposed tocloud native, they kind of use
(18:29):
the same tool, right, like,whatever works on the on-prem,
they can have to work it in thecloud as well.
Just because they're dealingwith a local API versus Amazon's
API doesn't really matter.
So so I think that the toolsare kind of transparent, but
that means all the headaches aretransparent as well, and I'm
not just saying it, for you know, network to code customers,
right.
It's just that my generalobservation from talking to my
(18:58):
guests on the podcast, fromtalking to other people during
conferences and so on.
And then there are others whoare truly taking advantage of
the cloud.
The cloud, for example, they'reusing Lambda functions, they
use storages and they use IAMfor authentication, as opposed
to just having a I don't knowTACX server per se in the cloud.
So I think for those approachesthen it's a lot easier and
(19:19):
they're less patient, if youwill.
They're less patient, if youwill, and they're trying to use
those.
So once they get used to thoseabstractions and use elastic
services no pun intended thenthey try to use that, they're
trying to transfer that into theon-prem and therefore you see
them bleed back into.
They're more receptive toDocker, they're more receptive
(19:40):
to Kubernetes and therefore theyuse these, maybe Terraform a
little bit more, and then theyuse you know, majority of the
workload is in the cloud andusing Terraforms and then they
try to use the same tool tomanage the on-prem.
So I think it really starts withthe strategy on the enterprise,
(20:01):
on how they're migrating to thecloud and how they're using the
cloud, and then go from there.
And I would say most of thetime, at least from my
observation, is the prior camp.
It's like when they talk aboutwhen there was like a frenzy
about moving workloads into thecloud.
They simply spun out VMs andthen they just moved the
(20:21):
workloads over.
So it's like, yeah, it's greatthat we can spin up a VM as
opposed to provision a localdevice, but at the same time
it's the same, it's kind of thesame thing.
And then they gradually workedover.
You know, oh, there's this, youknow, lambda function, that's
great, and there's this APIgateway, that's great.
So I see kind of thistransitioning, but it really
(20:42):
starts from how you're treatingyour workload and then that kind
of triggered down intonetworking, because you know,
nobody cares about networking aslong as your packet goes from
point A to point B, that's sotrue.
Yeah, then we're good, right.
So yeah, for all, we care.
Like I said, we could have abunch of bridge interfaces, just
like what Docker uses natively,right?
Tim (21:01):
Yeah, that's a really good point.
Yeah, so the more we talk aboutthe tooling, so the more we
talk about the tooling, the moreI keep thinking about, like we
have all these tools formanaging and some of them are
strong at managing, say, realhardware, and some of them are
stronger at managing, you know,cloud native or API driven stuff
.
And then that's without gettinginto things like traditional
(21:23):
vendors that have API GUIs tomanage their network stuff, like
you know, for example.
Eric (21:27):
You know it's like all over the thing that have API
GUIs to manage their networkstuff.
Oh yeah, those are horrible.
It's like a whole other thing.
Don't get me started onmenu-driven, right?
You got to press 1, and thenyou press 1, and then they go oh
press, what kind do you want?
I was like oh my God, it's justlike no right.
Tim (21:44):
GUI-driven workflows tend to suck right If you have the
ability to do it with an API,and that's, you know, hit and
miss depending on who createdthe API for the GUI driven.
That's like a whole other thingright there.
But the tooling wise, what Ifind interesting is like so,
like, take like just Terraformas an example.
Right, like Cisco, juniper,like Arista, they've all got
(22:06):
Terraform modules for theirhardware, right, so that you can
handle it, manage the gear orwhatever, and it's supposed to
be declarative and all of that.
But do you find, with somethinglike Terraform, where it's all
like, hey, the state shouldalways be in this state, versus
something like Ansel, whereyou're playing a playbook, where
(22:27):
it's idempotent but it's alittle different the way it
handles the life cycling of theplaybook is totally different.
Do you find that?
That what's the word I'mlooking for, like that kind of
management strategy to be betterfor one over the other.
Eric (22:43):
Yeah, I don't know.
I think they're different.
I don't know if one is betterthan the other.
Certainly I think theidempotency is a little bit
easier to do it on the API frontrather than doing natively, and
it's great that Ansible, forexample, is getting more
declarative.
But there's still a lot ofprocedures that is kind of
procedural, where you just kindof do step by step and you've
(23:07):
got to handle that out of bandyourself.
You're collecting, uh,collecting facts, for example,
right, and then you know, basedon the collecting fact that you
do it and if, if the moduleyou're using is nice, then they
do it for you.
Uh, if not, then you kind ofhandle that yourself.
Your your, you know collections, or you know your vendor choice
, so then we're getting intokind of the weeds on.
Or you know your vendor ofchoice, so then we're getting
(23:28):
into kind of the weeds on.
You know what does ID ponzimean, right, and what does
declarative mean, and so I thinkyou know it's just like these
concepts are kind of foreign.
For you know traditionalnetwork engineers, like you know
what do you mean.
Like I always want to do config, t, interface, and then you
know, change my description,whether then you know phase, and
(23:49):
then you know, change mydescription, whether then you
know and it takes a while tochange that mindset into
thinking, okay, I just want tosay this is my description.
And then I want to say, true,right, then, I don't care how
you do it, I just want it to betrue and I want this is my
description, as long as it hasit, I don't care how you put it
there, and that's thetransparent into like say, uh,
so if those two other lines,then then it's okay with the
(24:09):
underlying is Cisco, with Arista, juniper and so on and so forth
.
So I think that's also a kindof a hurdle is the skill gap,
this mindset gap that people are, you know, learning, or they
brought up in a certain way.
So I would say it's different.
I don't know if it's better ornot, because the challenges are
different.
What I would say is I think thenewer engineers, the engineers
(24:32):
who were born after maybe 2000sand now they're just getting
into the main state of the teams, that they are more receptive
and they're more, I guess,gravitate toward these APIs and
gravitate toward declarative,whereas if you talk to somebody
(24:54):
who's been doing this for a longtime, that you know they're
pretty much said in their ownways.
So I would call them as beingdifferent and kind of tailored
toward the environment thatyou're in.
But I would say I don't know ifit's a generational difference,
but I do think that the new waysare kind of getting into it.
So people are kind ofscratching their head.
(25:15):
It's like what do you mean?
The traditional iOS doesn'thave APIs, right, and what do
you mean?
That it's a simple HTTP serverthat doesn't have encryption, or
like password-basedauthentication versus key based.
So I think I think all of theseare just gradually take place
and we do need a lot more, um, Iwould say, like the younger
(25:36):
engineers, the new blocks, tocome in and kind of give us new
perspective and um, you know andI don't know if you want to
touch into ai, but maybe youknow, like people are talking
about ai native engineers, right, and and I kind of just thought
, what are you talking about?
Ai has only been around forthree years, so are you going to
hire babies?
(25:57):
They're certainly AI native.
Tim (26:00):
Yeah, well, that gets into the whole.
What does an AI native engineereven mean?
Does that mean you code all dayby time?
Are you vibe coding?
Is that what that means whenwe're talking about AI native
engineer even mean?
Does that mean you code all dayby time?
Are you vibe coding?
Is that what that means whenwe're talking about AI native?
We've talked a few times about,many times about the whole idea
of the gap that's going to existbetween you've got your senior
engineers now who learned theway they learned and they know
(26:24):
what they know and whatnot.
And then, for better or forworse, it seems like businesses
want to replace you knowexpertise essentially with AI to
some degree.
Right, even if you have aperson in the seat, they want
that person to be leveraging alarge amount of AI to, in theory
, make them better or faster.
It's really the same networkautomation argument we've been
(26:48):
having for the last what almost10 years now at this point about
how network automation is goingto A take everybody's jobs or B
make everybody faster, or bothright.
But you know, I wonder wherethe gap will be when you've got
these juniors that only know howto use AI, that don't you know,
have to learn and go throughthe experience and get
experience.
They just rely on that, don'tyou know?
Have to learn and go throughthe experience of, and get
(27:09):
experience?
They just rely on AI foreverything you know.
All that training data istrained on people that have done
this stuff over time.
So what happens when the cliffis hit and the people are gone
that that knew how to do thestuff and the training data with
it?
Snake eat its own tail or likewhat.
What happens there?
Eric (27:27):
Yeah, I think I think you know interesting, you brought
that up.
I mean.
So there's only so much data,existing data, that you're able
to leverage and you knowexisting knowledge.
Right, it took us, you know,probably the beginning of 2000
to build all the way up untilnow to have this data.
And in the last AI extent for Ithink it was Sequoia Capital, I
(27:47):
mean, they actually, you know,deliberately come out and say
you know, we're running out ofdata.
So what they're trying to do isthey're trying to simulate more
data and especially run outdata for physical AI.
So you know writing code, yeah,sure, everybody could just
scrape GitHub and you get abunch of like code examples and
you have a bias toward opensource, but that's another story
(28:09):
.
But what they're running out ofdata is physical data, right,
like think about how many imagesdo you have, chefs, like
cooking, and so you could trainthe robot to do that.
So there's not a lot oftraining that you could do
because they don't have data.
So they're trying to simulateor, you know, put in another way
, if they're trying to, you know, you, how many of these actual
(28:29):
driving data do you have?
Right, how many Teslas outthere?
That's aggregating the databack.
So they have these trainingdata?
They don't.
So what they're trying to do istrying to simulate data and so
on.
So that's like one thing thatthey brought up and that's
absolutely true.
But back to your original pointabout hiring engineers whether
they're junior, whether they'resenior, whether they've been
(28:51):
doing this for a while, I thinkthe difference is that they're
transitioning from thinkingabout human to thinking about a
group of tasks, right?
So it's just okay, I have thesebundle of tasks, if you say one
to a hundred, these tasks,bundle of tasks.
You know, if you say one to ahundred, like these tasks and
(29:12):
previously I know that myselection is limited I need to
hire a senior engineer with xamount of salary, with amount of
benefits, in order to handlethese tasks.
So my pool is very small.
But now that you know, when Ilook at it, I said I could hire
one senior engineer and use hisAI army, these AI agents, that's
able to accomplish these 100tasks in the same amount of time
or less, right?
(29:33):
So I think that thetransitioning is more around the
mindset of from humans andtaking the human constraints
with them into just thinkingabout it as a group of tasks.
So back to what you were talkingabout is does it really matter
whether it as a group of tasks?
So back to what you weretalking about is does it really
matter whether it's a juniorperson that's using these tools,
that's being productive andable to accomplish tasks, or
(29:56):
whether it's, you know, still asenior person but he's using
these AIs, agents and helpers todo these tasks right?
So I think it is shifting themindset away from human because
that's no longer a constraintinto tasks.
And then how productive can yoube?
So that begs the question youknow what tools can make you
(30:17):
productive and to me that's very, very different between each
person.
You know I might like Cursor,you might like Cloud and Chris
might like your ChatGPT, and youknow 5, six, seven, eight,
whatever they're coming out now,right, so Sam Altman, huge Sam
Altman fan.
Oh my God, I don't know man, Ihave a few books to uh.
Uh, I think it's a.
(30:38):
It's called AI empire by uh.
Tim (30:40):
Empire of AI.
Right, yeah, you recommendedthat one to me.
Yeah, you recommend that to me.
Eric (30:50):
Anyways, yeah, so, um.
So to me, anyways, yeah, so, um.
So I think I think it's justthese um, these mindset shifts
on, you know, grouping um,because the the constraints no
longer on the human andtherefore we're changing our
shifting our mindsets to justgroup a task.
And how can you be moreproductive?
So that's up to each one of usto think about what works best,
right?
So, and then I think that'skind of individual,
individualistic, like tim.
You know, before we hit therecord button, you said you use
(31:11):
Windows and Windows make yousuper productive.
And for me, you know, I've beenusing Mac about 25 years, so I
had no other shortcuts.
You know, I know the Vim editorand I have all these backend,
you know, shortcuts that I use.
So whatever makes youproductive to each of their own
and I think that translates verywell into ai is just that I
don't care if you just have twoyears of experience, I don't
(31:33):
care if you have 20 years ofexperience is how can you
accomplish these tasks with highquality shorter amount of time?
Chris (31:39):
yeah, I think it's.
I think I think that is a goodpoint.
Like, obviously you know,expanding your productivity and
kind of efficiency as anengineer is is is obviously a
great opportunity with ai and alot of tooling that's you know
out or coming out today.
But, like the, the thing islike you have to have the
(31:59):
awareness of how to use thetools and I think that's what
I'm worried about because, like,even like me, I think of an
example like I don't like evenme.
I someone I've been innetworking probably like for 15
years now and to this date Istill have never actually
physically implemented dot 1xever in my life.
Eric (32:17):
So like I just go on chat, gpt or lucky you yeah, no,
spanning tree, you don't have totrace back to your rubric.
Oh my god, you know drperlman's gonna be anyways.
Yeah, yeah, but no, like I goand I'm like just tell me about
dot 1x, like I just traced backto your rubric.
Chris (32:28):
Oh my God, you know Dr Perlman is going to be yeah,
yeah, but no, like I go and I'mlike, just tell me about that
one X Like.
But like I noticed, like I, Iknow I have a certain level of
knowledge about what I don'tknow, right, right, like, which
is, which is a very much biggerbox than what I do actually know
.
So I know, whenever I'minteracting with these tools, I
want to provide so much context,like be very, very specific
(32:51):
about what this environment isthat I'm interacting with and
how I should get arecommendation or get kind of a
lead on something, whereas thejunior guy isn't going to know
junior guy or gal isn't going toknow to provide that level of
context.
They're not going to say likeoh, they're going to say like oh
isn't going to know to providethat level of context.
They're not going to say likeoh, they're going to say like oh
(33:11):
, how do I just add a VLAN tothis switch or something like
that.
Tim (33:14):
But there's so much like in , there's so much context to it.
Chris (33:16):
Absolutely destroy it Right.
So I feel like it's or it'sdangerous territory in some
scenarios not in all scenarios,but in some of them.
I think that's what worries me.
Eric (33:25):
Yeah, absolutely.
I think on the same line ofthoughts, chris.
I think you know so for me, youknow I understand Django a
little bit better.
It's what I use for webframework.
So when I fire up my cursor andI want to, you know, do a few
front pages and all of that, Iwould say, hey, use Django, Use
UV as your package management,and this is how I want to
(33:50):
organize my views, my back-enddatabase, and then they just go
and do it.
What used to take me maybe acouple of days, they could do in
a couple hours, and that makesme more productive.
And where they run into issuesI could troubleshoot, I could
say, hey, why are you puttingthis way?
Why are you doing that?
So to your point is that youneed to provide context and it's
to speed up, as opposed to youknow your vibe coding and just
give me a web page and itbecomes a security vulnerability
(34:12):
.
It becomes, you know, a um, aspaghetti code, for nobody else
can understand but ai themselves, right?
So I think that begs thequestion.
So how do you get a juniorengineer really, really fast up
to speed on to a senior level sothey could redirect all the
other agents to be able to beproductive like you and I right
(34:32):
so I think yeah.
so I think my answer to that isit's very difficult, but one way
to get started was to pick aitools that are more transparent
than others.
So there are tools that whenyou ask a, a, uh, an ai agent
and say, oh, not a agent, maybethey'll prompt right.
So when you ask something,they'll give you the answer back
.
And when you need to go askagain to say why are you saying
(34:53):
that, does this change when Iprovide more context, more
examples and 5,000 other thingsthat I want you to know?
And then it does change.
However, there are other toolswhere you give it a question and
then they'll say, oh, let methink about it.
Right, let me think about it.
And then here's what I takeinto consideration, here's what
I'm trying.
Oh, that didn't work and let mego try something else.
(35:15):
It's all in the background, andthen that's a transparency.
You will hide it at the end andgive you an answer, because
nobody wants to read all of thatjust to get the answer.
But you have the choice ofgoing back and say I want to see
your step one, two, three andfour.
So, as a junior engineer or assomebody who you know for me,
you know I understand Django alittle bit better, but I don't
(35:37):
know JavaScript.
So whenever I have a JavaScriptquestion, I always try to tell
it to slow down, give me moresteps, and then I'll always go
back to those prompt until Ifeel comfortable with whatever
java javascript framework I'musing.
So I think that's very true and,um, and if you're, if you're
concerned about the gap, I thinkeverybody is right, like
everybody wants five years ofexperience, but nobody wants to
(36:00):
train somebody for five years.
So so those are, how do weshortcut it?
And to me, I think that ups,that's uh, it's up to us, like
the senior engineer, to demandthat kind of transparency
through the tools that we use.
So, pick a tool that isresponsible, that's ethical and
then takes care of AI safety,and then give you that trust,
(36:22):
give you that transparency tobuild trust for us, as well as
to bring up the other peoplethat are, you know, just
graduated out of school and thenthey need that busy work in
order to build out theirknowledge base quickly.
Tim (36:35):
I think that's pretty good.
I still do have some smallconcern that, because I mean,
how does someone become senior?
Ultimately they have to beexperienced and they have to
understand that there's thingsyou cannot learn out of a book
or by AI telling you about it.
Right, there's anybody who'sever and this is one thing I've
never actually done, but likeanybody who's ever done the
(36:58):
switch port trunk ad, you know,or VLAN, whatever.
Eric (37:02):
Without ad.
Tim (37:03):
yeah, and erased all the VLANs.
Eric (37:05):
Right and erased all the VLANs.
Tim (37:06):
There's lessons to be learned throughout the
experience of being an engineeror whatever.
That simply cannot be filled inby whatever reason AI or other
book learning or videos orwhatever you have.
So I'm still, but I do agreethat actually what you described
(37:26):
was perfect, right, like yousaid, use Django, use this
database, like you know what youwant.
You just don't want to type forgood reason.
You don't want to sit there andtype it all out and do the work
.
That's the kind of work I thinkis perfectly right to hand over
to an AI agent to do, becauseyou already know what you want,
(37:48):
what the end product should beand all of it.
Right.
But you yourself know thatbecause of your years of
experience.
Like Chris said, if a vibecoder comes in and says, hey, I
need a website and a database,like you pointed out, they're
going to.
You know.
God only knows what you'regoing to end up with, and the
person who wrote that prompt hasno idea what they're looking at
or whether it's right wrong.
Eric (38:11):
Yeah, I think you're absolutely right, tim, but
that's a challenge of ourgeneration and that is a
challenge of, I think, to alarger degree, how the society
will be able to cope with AI andimprove upon it.
So, no doubt, right, no doubt,when you get something burned,
when you're at 3 am in themorning that you're typing in
that command that you described,and then you wipe out all the
(38:33):
trunking ports, right, yournative Vlan is now whatever, and
then you lock yourself out andthen you have to drive to the
car.
So those kind of lessons thatburn into your brain, right,
like, you're just, you just kindof your eyes bleed, and then
you remember it.
Of course, you know absolutely,however, you know we, it's just
reality.
There's no way that we could,we could do, right Like, the
(38:54):
speed of change, the wide scopeof technology.
They're just not going tohappen.
And so how do we learn how tolearn Then?
That's the challenge of ourgeneration is how do we learn
how to learn and how do we bringpeople up to speed on such a
broad scope of knowledge quicklywithout having to actually
(39:15):
spending the time to learn thatand um, and that's why I'm
pretty optimistic on thelearning aspect of it, right,
like I think you know, um, ifyou think back on, uh, you know
just how do you learn the ethics?
How do you learn that?
Um, so that you don't have togo repeat everything you don't
learn as well.
But you know no-transcriptconfetti, the VLAN trunk, right?
(40:05):
So yeah, simulate that,simulate some sort of VR program
where it's so real that you getthat bleeding of eyes.
You get that.
You know, 3 am in the morning,kind of nervous shot.
And maybe even simulate drivingto the hub sites.
Right, but you know thedifference is, instead of
physically driving to the hubsite, you actually say, ok,
you're there on the hub site,right?
(40:26):
So so, yeah, so I think I thinkI echo what you're saying and
but I also challenge a littlebit on.
You know, I think that's thechallenge.
That is how, how we're going tomove forward as a society is
how can we bring everybodyupwards at the same time?
So, um, so we talked about, youknow, kind of uh, kind of my
(40:47):
vision, right, my North star onsome of these other stuff.
So so the first one, that'seven before trust, is, uh,
enhance, not replace.
So there are tools out there ortheir ai startups that promises
to reimagine, whatever, xyz,and then you don't need these
anymore.
But for me, you know, I, I wantto bring everybody forward,
right like that's my passion.
(41:08):
Yeah, so I think you know thatenhanced, not replaced, and that
kind of drives a lot of the um,a lot of subsequent projects or
or something like that.
Right, like I don't want togive up on people.
Tim (41:18):
No, actually, yeah, I love it, go ahead.
Chris (41:21):
I was going to say, yeah, that's like I totally agree
with you in that, in that, likewhere on where we need to get to
the pro, the thing that Istruggle with is like, as
someone that is, you know,considered a senior in this you
know kind of field, like I, likepeople that are getting into it
, it's hard for me to givedirections Right, cause it's
like, you know, if we think backabout to like back when we were
(41:41):
learning, you know, like CCNAor something like that, I
remember when I was taking myCCNA, I remember I was like
learning about frame relay andI'm like why the hell am I
learning about this?
I've never touched frame relay,frame relay in my life, like
that was something thateventually fell off the back of
the truck because more stuff gotadded to the front of the truck
, right, yeah, but now I'mwondering if so much has been
added to the front and like Idon't know what's fallen off,
(42:03):
right, and to tell people whatnot to waste their time on,
because I like I don't know weprobably overthink this stuff.
But I can think of like so manyscenarios like well, you might
need to know about this, you,you, you know, you need to know
about VLANs and things like that.
You know, even if you're doinga lot of cloud stuff, you know
like if if you, if you're anetwork engineer that just got
into cloud, you would probablynever touch a cloud.
(42:25):
Like if you were just doingpurely cloud, you never touch a
VLAN in your life.
But VLAN is like such a coreconcept that is like required
everywhere else.
It's just like is like requiredeverywhere else.
It's just like.
That's, yeah, it's the gap thatI don't know how to fill right
On, how to tell people to getinto this stuff.
I guess and I'm worried aboutthe bottom rungs of the ladder,
kind of you know becoming veryshaky very soon.
Eric (42:47):
Yeah.
So I think, going back to yourpoint, Chris, that VLAN is
fundamental.
So if we're going back to saymaybe the VLAN, this VLAN is
fundamental, so if we're goingback to say maybe the VLAN, this
VLAN thing, or it might changeto VNets or something else, or
we'll just have enough VNets outthere, Nobody needs VLAN
anymore or something like that,but the concept of broadcast
(43:07):
domain, collision domain, thesebasics do not change right.
So maybe what we need to do isto teach the fundamentals.
We teach them about IPaddresses.
Tim (43:17):
Subnetting and stuff.
Yeah.
Eric (43:18):
Subnetting whatever it is that we consider as basic and
that's fundamental.
That's the building block.
So we give them enough big youknow Lego pieces and whatever
smaller pieces on top of that.
Then those are transparent andwe make it clear that previously
you know this dude, when he was, you know implementing switches
, like we have to know VLANs.
(43:38):
But hey, dude, like you're thenew generation and you may not
need to know that because you'recloud native, however, you know
your collision domain and itdepends on really how deep the
cloud provider provides right.
So I think it's getting theclarification on.
You know what are thefundamental building blocks,
tgl's fundamental buildingblocks, and then you know you
(43:59):
build on top of it and becausewe're getting much more
specialized, so all of us are ina way, one way or another,
generalists.
And you know I think you haveWill last on and he clearly
defined himself as a generalistright and I would agree to that
last time, that he clearlydefined himself as a generalist
right.
So, and I would agree to that,but I think, as we move forward,
(44:22):
there just might be just cloudnetwork engineers or there might
just be, you know, hyperscaler,you know network engineers
within data centers, you knowdoing top of rack switches,
whatever right.
So I think, you know, with eachof those roles as being
specialized, the building blocksthat we teach might be a little
bit different, and I'moptimistic, but I do think the
(44:44):
skill gap and the fact thatnobody again back to what you
were saying, tim, that everybodywants three years of experience
but nobody wants to give thatthree-year experience to the new
grads, that's a problem.
So how do we solve that?
That's a challenge of ourgeneration, I feel.
Tim (44:55):
Yeah, we're up against time , but I'd love to know you know
what's your using AI or notusing AI, like I don't want to
just leave it here.
Eric (45:04):
Oh, I'm using AI every day .
No, no, I mean no, no, sorry.
Tim (45:08):
Yeah, I mean, we all are in some, in some capacity.
I think we all are at thispoint.
I use no checks too.
I don't feel bad about that.
Yeah, exactly.
Um.
So what?
Moving forward, like what iswhat do you think is the very
shortly period of time?
What do you think is the?
The right answer is it, is itget a junior teach the
(45:28):
fundamentals and then we givethem, I guess, just ai tooling
and say, like you know, here areyour tasks, uh, use your ai
tools, or what is that?
It or what's the?
How do we solve this problem?
Moving forward, do you think?
Eric (45:41):
I think, going back to my newer start, right.
So, like other people mighthave a different answer, but my
newer start is enhance, notreplace.
So that is my answer.
That's what the answer I wantedto be, and I'm trying to be the
change that I want I want tosee.
So I want to bring a juniorengineer in, or somebody who's
you know in college right now,and in fact, I'm talking to my
(46:02):
friend and say, uh, I don't knowif you guys saw, I clear a
bunch of uh, networking gears inmy garage and I'm donating them
to the local college and I'mtalking to them on, you know,
how do we bridge this gap?
Right?
So I think I'm putting my moneywhere my mouth is and that's
the answer I want.
I don't know if that's theanswer will be or if that's the
(46:23):
answer that's everybody's.
All I can say is that's theanswer I want to see, and I'm
taking actions to accomplishthat goal is yes, I want to
bring somebody and, as a fatherof two teenagers, I want them to
have somebody else when they'reworking in whatever field that
they want, that somebody wouldtell them yes, come on, right,
(46:44):
like, I will teach you whateverit is that you need to learn.
But here's the group of work,here's the body of work you have
to put up with, and then youcould get to the other side.
So, yeah, so that's my answer.
You know, I'm optimistic, Iwant to give efforts to that
movement and, uh, yes, you know,just, I want to enhance, I want
(47:05):
to enhance people so that theycould be, um, you know, capable
of thriving in this economy inthe next 20, 30 years right.
Tim (47:13):
Yeah, I like the enhance not replace as well.
But the only thing that worriesme and we're going to close out
here but what worries me about?
Enhance, not replace, or notthe opposite what worries me
about?
Not enhance, not replace, notenhance, which seems to be the
way a lot of corporations aregoing these days to pay for the
AI that they're building is justthat right.
(47:35):
They seem to be on the replace,not enhance.
But I agree with you when I useAI, it's about enhancing my
workflow, not replacing myworkflow.
I don't hand the keys over.
I use it to do stuff I alreadyknow how to do.
Eric (47:48):
What I think is happening is the pendulum always swings
over the one way or direction ornot.
So now, as you know, we have abunch of layoffs in the industry
and some people joke aboutthey're being replaced by GPUs
right, so they're spendingbillions of dollars on GPUs, but
they're cutting thousands ofdollars, hundreds of thousands
of dollars in salaries.
(48:09):
So I think that pendulum is kindof swinging both ways and what
I see happening is theyoverhired and over putting a lot
of bets into human resourcesand capitals during the COVID
years, and now they have thisdrunken effect, the day-next-day
hangover effect.
So the pendulum is swinging thisway and hopefully I think
(48:30):
that's going to swing back whenwe're a little deeper into the
hype cycle and then we find thebalance and so on.
So I do think that if we'rejust looking at all the bubbles
and all the histories and youand I, tim and Chris, probably
that we live through the dot-combubble, we live through the
(48:50):
financial crisis, we livethrough for me at least, you
know, like the Asian, you knoweconomic crisis, the Korean
market crash and so on, so forth.
So so I think you know, Ialways see these pendulums
swinging, so hopefully we'regoing to have reached a more
equilibrium in a short while.
And if you know because beingin Seattle and I know a lot of
(49:11):
layoffs has been happening justthroughout the years and don't
lose hope.
I think you know the the if youjust look at the history, just
go get through this dark periodand then you know we might have
something that, uh, that worksout at the end.
Chris (49:24):
Thanks, we will.
We will survive this one.
Whatever happens, we willsurvive we always do right.
Eric (49:29):
I mean, I'm optimistic, so I hope so.
Uh.
If not, then uh, then thatsucks yeah, I like that.
Tim (49:36):
All right, everybody, we'll go ahead and uh and then wrap
it there.
Uh, thanks for joining us.
Uh, eric, eric, where can be?
Uh?
Where can people find you?
Eric (49:43):
yeah, so you know, connect with me on linkedin.
I'm not very hard to find.
So, uh, eric chou, if you wantto take a look at some of my
books, you can find outeverywhere you get your books
amazon, uh, apes books orwhatever that you get your books
from.
No more physical bookstore,unfortunately, and last but not
least, if you want to check outmy podcast, network Animation
Nerds, I weekly, biweekly,release and hope to just engage
(50:09):
with you one way or another andcollaborate and let's make this
world a better place.
Thanks for having me, it's beena pleasure.
Tim (50:14):
All right, great.
Any closing thoughts?
Chris, are you ready?
Chris (50:17):
to roll.
No, all good man, it's beengreat.
We'll definitely have to haveEric back and oh, for sure.
Yeah, make sure you check outNetwork Automation Nerds.
It's a great podcast.
We'll put the notes in there orput the link in the show notes.
Tim (50:29):
All right, everybody.
Well, this is Tim and we'll seeyou next time.
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.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.