Tim: 0:13

Hey and welcome back to another episode of the Cables to Clouds podcast. I'm Tim McConaughey. I am here at the Cables to Clouds podcast. I am here at the Cables to Clouds podcast and with me, as always, is my co-host, I guess Chris Miles Just your buddy man, just your buddy yeah that's right. Head of Real Life, mate, whatever we're going with this week.

Tim: 0:41

And we have a guest with us this week, which you probably noticed if you're watching the YouTube Eric Cho, which is a good friend of ours and of the podcast. We have not had a chance to have him on yet, but we've been trying for a good long time. For those that don't already know you, Eric, you want to give a really quick intro of yourself.

Eric: 0:55

Yeah, sure, hey, it's good to be here. Thanks for having me. I don't think you guys tried very hard, because I'm not very hard to find. I think it's just that you try to keep the guest quality up right, so you don't want to drag on that average, so I get it, no worries.

Eric: 1:10

I'm here, so now I'm happy. Yeah, eric Cho. And if you listen to Network Animation Nerds podcast, I'm there right by your earbuds. Maybe every other week, hopefully. If not, maybe you know me from various books. I've written six of them and the book's been translated into five different languages. So if you're joining from Korea, thank you. I doubt it, but because both of the readers in Korea are in the time zone difference.

Eric: 1:39

But yeah joking aside, right? So I teach online courses at LinkedIn Learning, at Network Expert, at Pluralsight and at various locations, so I'm not very hard to find. Hopefully we're connected on LinkedIn somehow. If not, then please welcome to send me an invite. I'm happy to be engaged in various conversations and not just network engineering.

Tim: 2:00

That's great. That's a good intro. Eric is extremely prolific in just about all the content creation stuff. He's 10 times as good at this as I am. So it's usually like, hey, I've tried that and that didn't work so you don't have to right.

Eric: 2:27

So that's always been. My mindset is just this um, you know, 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 new concepts, books, um, yeah, all all kinds of stuff, and we could get into that later, but I don't want to interrupt your flow.

Tim: 2:49

All good man, that's a good point, all right.

Tim: 2:53

So we brought Eric here because we really wanted to talk about something that we've talked a little bit about on the podcast just ancillary for a long time actually which is the automation aspect, the infrastructure as code aspect, of both cloud networking and traditional on-prem networking.

Tim: 3:12

I don't know hardware networking I'm not sure what you what is the other word that we use for talking about more like traditional hardware networking or at least traditional vendors. You have the cloud native that's built with IAC in mind, right, based on the cloud providers, exposing APIs and using IAC type methodology. But then you have like traditional network automation, which you know, for those in the network engineering space has been growing for just a long time, right, has been growing for just a long time right Like using things like Ansible, python and PyATS and all the frameworks that have been built around network automation on the traditional side. So what we're really interested in talking about with Eric is kind of, first of all, like kind of getting a little in the weeds on both of those, but also really like what does an organization do in a hybrid world where you really need like a framework that kind of encompasses both or all, or what is the strategy that organizations should be looking at to manage both of these environments together?

Eric: 4:18

Yeah, I think that's a very valid question and, tim, to your point. I think we should probably just first define what we're talking about, right? So, begin with, just put into different buckets. So the first bucket would be cloud native and, uh, so we're talking about maybe aws, google cloud and azure, and then we have the on-prem right, like that's back when you refer to as just being physical networking. We're actually going to the cisco, the junipers and we we could get all the way down into the back lanes where there's a chassis base, where there's a pizza box and so on and so forth. And the automation strategy, like you said before. I might even add that we've been trying for a long time and unsuccessfully trying to automate it.

Tim: 5:01

I know how to say it.

Eric: 5:02

Success rate. It's always on the spectrum. So you know some organizations are more successful than others, but I don't think we could claim 100% success rate at any of the organizations, even for you know the hyperscalers, you know so, as you know, I've worked for AWS for about five years. I worked for Azure for about five years so that's 10 years from an insider's perspective and for about five years I worked for Azure for about five years, so that's 10 years from an insider's perspective and then I was a vendor for you know the hyperscalers and, being in Seattle, you know I've always had visibility to AliCloud, to Oracle Cloud and all these other locations that may not be the top three but definitely still up there and playing and trying to get engaged into the game. So I would say, you know, say I don't think there's any strategy, that there's no one ring 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're better at cloud.

Eric: 6:01

If you think about Terraforms, if you think about all these other very natively driven and they started from the cloud, going into on-prem and everybody trying to get into each other's territory, and then you have say ansible.

Eric: 6:15

That started maybe for the on-prem, maybe for even systems, and then go into networking and then they expand you to the cloud where you run your playbook and they could actually, you know, uh, touch terraform or go into the cloud apis directly, but, um, but I don't think either one of them could claim complete dominance on each other.

Eric: 6:36

So so I think it's really on the spectrum and a percentage game. So if your organization is more cloud, then you probably want to have your bias toward these cloud native tools, and if your organization is more on-prem, then you probably want to take a look at these tools that are kind of favoring on-prem devices, favoring on-prem devices. So I don't know if that makes sense, because I've lived in both worlds, and I would say most of the time, just because I'm old, I don't have a beard, but I have been doing this for a couple of bubbles now. So, yeah, so in my previous experience I've always dealt with on-prem a little bit more and therefore I have more knowledge on, like the ensembles of the world, if you will write python scripts, nor near namiko, that sort of stuff, and, uh, less on the terraform side don't worry, eric, we'll get you a beard.

Chris: 7:34

We'll put it on a beard. It's gotta be a fake one, my agent does not allow, uh, any kind of beard. It's like if I grow for two weeks.

Eric: 7:43

My wife would just be like, hey, is this something dirt like a little?

Tim: 7:46

bit. You have a little something like yeah you gotta wipe that off right but um yeah

Eric: 7:53

I, I came to peace with it.

Chris: 7: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's like everything is api first. Right, that's kind of everything that has an api, just like out of the box. It's not even going to go to market unless it has a front end API that you can interact with, right, um, whereas I feel like in the traditional on-prem world that was always a struggle, at least just like having API support from any of the major vendors across the board or even just getting kind of like structured data from a lot of network appliances across the board right.

Chris: 8:26

That was a lot of screen scraping, a lot of cli commands and things like that yeah, what do you feel like obviously ansible's kind of come into play and then they can, you know they help with that a little bit, and ordinary and things like that. What do you feel, jesus?

Eric: 8:40

sorry, the plane just went over so. No problem, that's exactly how I feel. The plane just running over.

Chris: 8:50

What do you feel is the state of that today? Where have we made it to and how are people interacting with both?

Eric: 8: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 very important 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't have EC3, we didn't have VPC. We didn't have any of that. And if you roll back into a couple of years ago, when Warner Vogel, the CTO for Amazon, when he joined, he had in mind, even before the cloud, what we know as the CTO for Amazon when he joined, he had in mind, even before the cloud, what we know as the AWS in the cloud, even in the retail world. He had that vision of you know, there's no like, we want to commercialize, we want to sell this to external customer. So internally there was a mandate to have everything and 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 and try to get data out and everything's data driven. So even the database part, like they don't have a backdoor, they don't have a direct, you know, command line going to go into the database in the back end, so every single service has to be terminated internally, we use api to talk to each of the services. So so then, that makes it really easy to commercialize it later on and be api on par with the features on the feature set. And obviously, after that, azure was the second one. They saw how it was. And now, if you remember, there was a time when Azure had I think they still do have this feature comparison between Azure and AWS and be like hey, they call it VPC, we call it VNet, they call it Transit Gateway, we call it something else, they call it Direct Connect, they call it Transit Gateway, we call it something else, they call it Direct Connect. So there are feature parity and obviously they have to have API as well. And so what I want to drive to is that this mindset of API first and abstraction. So I think the biggest difference between cloud and the on-prem is that there's a different abstraction layer that's come from the cloud provider, whereas on-prem you're dealing directly with the devices and you're at the mercy of the equipment vendors that give you these abstraction or not. And therefore, I think you know it's almost like starting from the root, because we're we don't have 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 deal with the messy detail, with the on-prem, and therefore, therefore, the tools, the drivers and the software SDKs will have to live in that world. And even when we're trying to have this, even when we're trying to get consensus, that would never happen, right?

Eric: 11:56

Like you know, part of the reason why Ansible was so successful was because they provide a common framework, but at the same time, they also allow different vendors to shine.

Eric: 12:08

Whereas, you know, puppets and Chefs of the World, they not only have agents, they also try to normalize everything and they're trying to live off on the common set of commands. And so the vendors do not want to support Puppet, they don't want to support Chef because it abstracts their secret sauce, right? So, whereas Ansible, they say, okay, you're normalized on the playbook, but we also allow you to create your own custom modules. So, arista, you have these set of secret sauces. You could do Cisco, you could have these, and then they sort of converge in that front. So I think the biggest difference is we don't have this abstraction layer for the on-prem devices and therefore we have to deal with these you know different vendors and makes it really difficult to normalize on the set of standards, whereas it's difficult technology wise and it's difficult politically, or you know business drives. So therefore it's kind of just the reality when we deal with the on-prem I don't know if that makes sense or if that's uh jiving what you guys have heard.

Eric: 13:10

I mean, obviously you guys have dealt with a lot more than more than me, so I'd love to hear you know what you guys just thought on that as well, that's I think that's pretty good.

Tim: 13:18

I mean, um, yeah, I definitely agree with that. I I hadn't thought about what you're saying about the you know, puppet and Chef versus Ansible in terms of implementation, but I think that tracks Also. What I find is that the way and you kind of touched on it when you said like we had kind of because it's real hardware you know we have to deal with the messiness of it being real hardware but also is just with the real hardware. We're coming at it from a retrofit perspective. We're building the solution to meet the hardware, whereas from the cloud, native side, they originally built the solution with that you know that IAC or API rather in mind. So it's like you know there's that too right.

Tim: 14:01

Like Ansible or Nornir, for example, all the frameworks for managing or automating network devices were built long after the network device existed, right. So it's all coming at it from the retrofit perspective of we have, here's what exists. Now we have to build a framework to manage that thing, given the restraints that are already in place for that thing that we have to manage, versus, like you said, with Amazon, like they built it right up front not just Amazon, but you know what I mean Like the CSPs built it. The solutions that they built were API first. So we're going to build a solution and we're going to make sure it has an API out the gate. So definitely a big difference in 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 serve their own purpose, right, like they're trying to drive it cloud adaptation, whereas in the network vendors they're trying to sell more devices, so they're trying to differentiate themselves. But Amazon, you know, trying to differentiate themselves on the kind of services that they provide, which is another layer above networking. They're happy to just have like a bunch of bridging interfaces.

Tim: 15:16

They don't care about the network, I don't think performance is that big of an issue.

Eric: 15:20

But whereas in the physical networking you know the speed and feeds are, definitely exponentially increasing.

Eric: 15:28

We're talking about backplanes. If you talk about micro buffers or micro bursts, how much buffer do you have in that NIC? Or if you're doing the 40 gig and the 25 gig and the 100 gig, and how do you do the split cable and how do you transfer that into a non-blocking backplane? So I think all of these are just different requirements and, um, you know, from a customer's perspective, obviously you're not, you don't have to be concerned with it. But even when we're building data centers for amazon and azure I do like it's a car for everybody.

Eric: 16:01

Yeah, it's a car for everybody else, for us, us it's racks and cooling, and how much bandwidth and oversubscription, right. So those are the kind of challenges that somebody has to deal with it. So whether it's the cloud provider, whether it's you, the network engineer, whether it's Joe Schmock over at Data Center, it doesn't really matter, somebody has to deal with it. 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 two different 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 while as well. I'm curious, like in your in your time that you've spent there. We talk a lot on the show about the hybrid network being in cloud and on-prem as well. What do you see as the main struggle or combative piece for people trying to manage their cloud networks and their on-prem networks? Because, like you said, there's a lot of different tooling and in some cases it's much easier to just use, like Terraform for cloud, whereas you know there's Terraform providers written for every major networking vendor as well, but I don't know how well that actually works in operation. What do you see in the real world as far as how people are doing that today?

Eric: 17:22

Yeah, I think that's kind of interesting to me and obviously we're not going to talk any particular customer, we're going to talk in aggregated and generalized form. So I think the difference is how the enterprise, each company, is approaching this cloud thing. So I think there are companies who are just moving on-prem to the cloud versus cloud native right.

Eric: 17:46

So I mean you know, just because you'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, you know, vmware on-prem, and then you move those services over versus. Maybe you're using DynamoDB over versus. Uh, maybe you're using dynamo db, maybe you're using, uh, you know, the vnets to and having, like, transit gateways and not gateways and all of these other stuff, right? So they're different approaches, whereas they start from the top. And, uh, what, what kind of approach are we taking to the cloud? So, so, for the ones that are just taking moving workloads into the cloud as opposed to cloud native, they kind of use the same tool, right, like, whatever works on the on-prem, they can have to work it in the cloud as well. Just because they're dealing with a local API versus Amazon's API doesn't really matter. So so I think that the tools are kind of transparent, but that means all the headaches are transparent as well, and I'm not just saying it, for you know, network to code customers, right. It's just that my general observation from talking to my guests on the podcast, from talking to other people during conferences and so on. And then there are others who are truly taking advantage of the cloud. The cloud, for example, they're using Lambda functions, they use storages and they use IAM for authentication, as opposed to just having a I don't know TACX server per se in the cloud. So I think for those approaches then it's a lot easier and they're less patient, if you will. They're less patient, if you will, and they're trying to use those. So once they get used to those abstractions and use elastic services no pun intended then they try to use that, they're trying to transfer that into the on-prem and therefore you see them bleed back into. They're more receptive to Docker, they're more receptive to Kubernetes and therefore they use these, maybe Terraform a little bit more, and then they use you know, majority of the workload is in the cloud and using Terraforms and then they try to use the same tool to manage the on-prem.

Eric: 19:56

So I think it really starts with the strategy on the enterprise, on how they're migrating to the cloud and how they're using the cloud, and then go from there. And I would say most of the time, at least from my observation, is the prior camp. It's like when they talk about when there was like a frenzy about moving workloads into the cloud. They simply spun out VMs and then they just moved the workloads over. So it's like, yeah, it's great that we can spin up a VM as opposed to provision a local device, but at the same time it's the same, it's kind of the same thing. And then they gradually worked over. You know, oh, there's this, you know, lambda function, that's great, and there's this API gateway, that's great. So I see kind of this transitioning, but it really starts from how you're treating your workload and then that kind of triggered down into networking, because you know, nobody cares about networking as long as your packet goes from point A to point B, that's so true.

Eric: 20:52

Yeah, then we're good, right. So yeah, for all, we care. Like I said, we could have a bunch 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 about the tooling, so the more we talk about the tooling, the more I keep thinking about, like we have all these tools for managing and some of them are strong at managing, say, real hardware, and some of them are stronger at managing, you know, cloud native or API driven stuff. And then that's without getting into things like traditional vendors that have API GUIs to manage 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 network stuff. Oh yeah, those are horrible. It's like a whole other thing. Don't get me started on menu-driven, right? You got to press 1, and then you press 1, and then they go oh press, what kind do you want? I was like oh my God, it's just like 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 created the API for the GUI driven. That's like a whole other thing right there. But the tooling wise, what I find interesting is like so, like, take like just Terraform as an example. Right, like Cisco, juniper, like Arista, they've all got Terraform modules for their hardware, right, so that you can handle it, manage the gear or whatever, and it's supposed to be declarative and all of that. But do you find, with something like Terraform, where it's all like, hey, the state should always be in this state, versus something like Ansel, where you're playing a playbook, where it's idempotent but it's a little different the way it handles the life cycling of the playbook is totally different. Do you find that? That what's the word I'm looking for, like that kind of management strategy to be better for one over the other.

Eric: 22:43

Yeah, I don't know.

Eric: 22:45

I think they're different. I don't know if one is better than the other. Certainly I think the idempotency is a little bit easier to do it on the API front rather than doing natively, and it's great that Ansible, for example, is getting more declarative. But there's still a lot of procedures that is kind of procedural, where you just kind of do step by step and you've got to handle that out of band yourself. You're collecting, uh, collecting facts, for example, right, and then you know, based on the collecting fact that you do it and if, if the module you're using is nice, then they do it for you. Uh, if not, then you kind of handle that yourself. Your your, you know collections, or you know your vendor choice, so then we're getting into kind of the weeds on. Or you know your vendor of choice, so then we're getting into kind of the weeds on. You know what does ID ponzi mean, right, and what does declarative mean, and so I think you know it's just like these concepts are kind of foreign. For you know traditional network 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 then you know, change my description, whether then you know and it takes a while to change that mindset into thinking, okay, I just want to say 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 be true and I want this is my description, as long as it has it, I don't care how you put it there, and that's the transparent into like say, uh, so if those two other lines, then then it's okay with the underlying is Cisco, with Arista, juniper and so on and so forth. So I think that's also a kind of 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 or not, because the challenges are different. What I would say is I think the newer engineers, the engineers who were born after maybe 2000s and 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 who's been doing this for a long time, that you know they're pretty much said in their own ways. So I would call them as being different and kind of tailored toward the environment that you're in.

Eric: 25:05

But I would say I don't know if it's a generational difference, but I do think that the new ways are kind of getting into it. So people are kind of scratching their head. It's like what do you mean? The traditional iOS doesn't have APIs, right, and what do you mean? That it's a simple HTTP server that doesn't have encryption, or like password-based authentication versus key based. So I think I think all of these are just gradually take place and we do need a lot more, um, I would say, like the younger engineers, the new blocks, to come in and kind of give us new perspective and um, you know and I don't know if you want to touch into ai, but maybe you know, 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 for three years, so are you going to hire babies? They're certainly AI native.

Tim: 26:00

Yeah, well, that gets into the whole. What does an AI native engineer even mean? Does that mean you code all day by time? Are you vibe coding? Is that what that means when we're talking about AI native engineer even mean? Does that mean you code all day by time? Are you vibe coding? Is that what that means when we're talking about AI native?

Tim: 26:13

We've talked a few times about, many times about the whole idea of the gap that's going to exist between you've got your senior engineers now who learned the way they learned and they know what they know and whatnot.

Tim: 26:25

And then, for better or for worse, it seems like businesses want to replace you know expertise essentially with AI to some degree. Right, even if you have a person in the seat, they want that person to be leveraging a large amount of AI to, in theory, make them better or faster. It's really the same network automation argument we've been having for the last what almost 10 years now at this point about how network automation is going to A take everybody's jobs or B make everybody faster, or both right. But you know, I wonder where the gap will be when you've got these juniors that only know how to use AI, that don't you know, have to learn and go through the experience and get experience. They just rely on that, don't you know? Have to learn and go through the experience of, and get experience? They just rely on AI for everything you know. All that training data is trained on people that have done this stuff over time.

Tim: 27:17

So what happens when the cliff is hit and the people are gone that that knew how to do the stuff and the training data with it? Snake eat its own tail or like what. 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 know existing knowledge. Right, it took us, you know, probably the beginning of 2000 to build all the way up until now to have this data. And in the last AI extent for I think it was Sequoia Capital, I mean, they actually, you know, deliberately come out and say you know, we're running out of data. So what they're trying to do is they're trying to simulate more data and especially run out data for physical AI. So you know writing code, yeah, sure, everybody could just scrape GitHub and you get a bunch of like code examples and you have a bias toward open source, but that's another story. But what they're running out of data is physical data, right, like think about how many images do you have, chefs, like cooking, and so you could train the robot to do that. So there's not a lot of training that you could do because they don't have data. So they're trying to simulate or, you know, put in another way, if they're trying to, you know, you, how many of these actual driving data do you have? Right, how many Teslas out there? That's aggregating the data back. So they have these training data? They don't. So what they're trying to do is trying to simulate data and so on. So that's like one thing that they brought up and that's absolutely true.

Eric: 28:44

But back to your original point about hiring engineers whether they're junior, whether they're senior, whether they've been doing this for a while, I think the difference is that they're transitioning from thinking about human to thinking about a group of tasks, right? So it's just okay, I have these bundle of tasks, if you say one to a hundred, these tasks, bundle of tasks. You know, if you say one to a hundred, like these tasks and previously I know that my selection is limited I need to hire a senior engineer with x amount of salary, with amount of benefits, in order to handle these tasks. So my pool is very small. But now that you know, when I look at it, I said I could hire one senior engineer and use his AI army, these AI agents, that's able to accomplish these 100 tasks in the same amount of time or less, right? So I think that the transitioning is more around the mindset of from humans and taking the human constraints with them into just thinking about it as a group of tasks.

Eric: 29:45

So back to what you were talking about is does it really matter whether it as a group of tasks? So back to what you were talking about is does it really matter whether it's a junior person that's using these tools, that's being productive and able to accomplish tasks, or whether it's, you know, still a senior person but he's using these AIs, agents and helpers to do these tasks right? So I think it is shifting the mindset away from human because that's no longer a constraint into tasks. And then how productive can you be? So that begs the question you know what tools can make you 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 you know 5, six, seven, eight, whatever they're coming out now, right, so Sam Altman, huge Sam Altman fan.

Eric: 30:33

Oh my God, I don't know man, I have a few books to uh. Uh, I think it's a. It's called AI empire by uh.

Tim: 30:40

Empire of AI. Right, yeah, you recommended that 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 just these um, these mindset shifts on, you know, grouping um, because the the constraints no longer on the human and therefore we're changing our shifting our mindsets to just group a task. And how can you be more productive? So that's up to each one of us to think about what works best, right? So, and then I think that's kind of individual, individualistic, like tim. You know, before we hit the record button, you said you use Windows and Windows make you super productive. And for me, you know, I've been using Mac about 25 years, so I had no other shortcuts. You know, I know the Vim editor and I have all these backend, you know, shortcuts that I use. So whatever makes you productive to each of their own and I think that translates very well into ai is just that I don't care if you just have two years of experience, I don't care if you have 20 years of experience is how can you accomplish these tasks with high quality shorter amount of time?

Chris: 31:39

yeah, I think it's. I think I think that is a good point. Like, obviously you know, expanding your productivity and kind of efficiency as an engineer is is is obviously a great opportunity with ai and a lot of tooling that's you know out or coming out today. But, like the, the thing is like you have to have the awareness of how to use the tools 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 even me. I someone I've been in networking probably like for 15 years now and to this date I still have never actually physically implemented dot 1x ever 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 to trace back to your rubric. Oh my god, you know dr perlman's gonna be anyways. Yeah, yeah, but no, like I go and I'm like just tell me about dot 1x, like I just traced back to 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'm like, just tell me about that one X Like. But like I noticed, like I, I know I have a certain level of knowledge about what I don't know, right, right, like, which is, which is a very much bigger box than what I do actually know. So I know, whenever I'm interacting with these tools, I want to provide so much context, like be very, very specific about what this environment is that I'm interacting with and how I should get a recommendation or get kind of a lead on something, whereas the junior guy isn't going to know junior guy or gal isn't going to know to provide that level of context. They're not going to say like oh, they're going to say like oh isn't going to know to provide that level of context. They're not going to say like oh, they're going to say like oh, how do I just add a VLAN to this 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's dangerous 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 of thoughts, chris. I think you know so for me, you know I understand Django a little bit better. It's what I use for web framework. So when I fire up my cursor and I want to, you know, do a few front pages and all of that, I would say, hey, use Django, Use UV as your package management, and this is how I want to organize my views, my back-end database, and then they just go and do it.

Eric: 33:52

What used to take me maybe a couple of days, they could do in a couple hours, and that makes me more productive. And where they run into issues I could troubleshoot, I could say, hey, why are you putting this way? Why are you doing that? So to your point is that you need to provide context and it's to speed up, as opposed to you know your vibe coding and just give me a web page and it becomes a security vulnerability. It becomes, you know, a um, a spaghetti code, for nobody else can understand but ai themselves, right? So I think that begs the question. So how do you get a junior engineer really, really fast up to speed on to a senior level so they could redirect all the other agents to be able to be productive like you and I right so I think yeah.

Eric: 34:33

so I think my answer to that is it's very difficult, but one way to get started was to pick ai tools that are more transparent than others. So there are tools that when you ask a, a, uh, an ai agent and say, oh, not a agent, maybe they'll prompt right. So when you ask something, they'll give you the answer back. And when you need to go ask again to say why are you saying that, does this change when I provide more context, more examples and 5,000 other things that I want you to know? And then it does change. However, there are other tools where you give it a question and then they'll say, oh, let me think about it. Right, let me think about it. And then here's what I take into consideration, here's what I'm trying. Oh, that didn't work and let me go try something else.

Eric: 35:15

It's all in the background, and then that's a transparency. You will hide it at the end and give you an answer, because nobody wants to read all of that just to get the answer. But you have the choice of going back and say I want to see your step one, two, three and four. So, as a junior engineer or as somebody who you know for me, you know I understand Django a little bit better, but I don't know JavaScript. So whenever I have a JavaScript question, I always try to tell it to slow down, give me more steps, and then I'll always go back to those prompt until I feel comfortable with whatever java javascript framework I'm using.

Eric: 35:49

So I think that's very true and, um, and if you're, if you're concerned about the gap, I think everybody is right, like everybody wants five years of experience, but nobody wants to train somebody for five years. So so those are, how do we shortcut it? And to me, I think that ups, that's uh, it's up to us, like the senior engineer, to demand that kind of transparency through the tools that we use. So, pick a tool that is responsible, that's ethical and then takes care of AI safety, and then give you that trust, give you that transparency to build trust for us, as well as to bring up the other people that are, you know, just graduated out of school and then they need that busy work in order to build out their knowledge base quickly.

Tim: 36:35

I think that's pretty good. I still do have some small concern that, because I mean, how does someone become senior? Ultimately they have to be experienced and they have to understand that there's things you cannot learn out of a book or by AI telling you about it. Right, there's anybody who's ever and this is one thing I've never actually done, but like anybody who's ever done the 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 engineer or whatever. That simply cannot be filled in by whatever reason AI or other book learning or videos or whatever you have. So I'm still, but I do agree that actually what you described was perfect, right, like you said, use Django, use this database, like you know what you want. You just don't want to type for good reason. You don't want to sit there and type it all out and do the work. That's the kind of work I think is perfectly right to hand over to an AI agent to do, because you already know what you want, what the end product should be and all of it. Right. But you yourself know that because of your years of experience. Like Chris said, if a vibe coder 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're going to end up with, and the person who wrote that prompt has no 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 our generation and that is a challenge of, I think, to a larger degree, how the society will be able to cope with AI and improve upon it. So, no doubt, right, no doubt, when you get something burned, when you're at 3 am in the morning that you're typing in that command that you described, and then you wipe out all the trunking ports, right, your native Vlan is now whatever, and then you lock yourself out and then you have to drive to the car. So those kind of lessons that burn into your brain, right, like, you're just, you just kind of 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 speed of change, the wide scope of technology. They're just not going to happen. And so how do we learn how to learn Then?

Eric: 39:03

That's the challenge of our generation is how do we learn how to learn and how do we bring people up to speed on such a broad scope of knowledge quickly without having to actually spending the time to learn that and um, and that's why I'm pretty optimistic on the learning aspect of it, right, like I think you know, um, if you 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 to go repeat everything you don't learn as well. But you know no-transcript confetti, the VLAN trunk, right? So yeah, simulate that, simulate some sort of VR program where it's so real that you get that bleeding of eyes. You get that. You know, 3 am in the morning, kind of nervous shot. And maybe even simulate driving to the hub sites.

Eric: 40:20

Right, but you know the difference is, instead of physically driving to the hub site, you actually say, ok, you're there on the hub site, right? So so, yeah, so I think I think I echo what you're saying and but I also challenge a little bit on. You know, I think that's the challenge. That is how, how we're going to move forward as a society is how can we bring everybody upwards at the same time? So, um, so we talked about, you know, kind of uh, kind of my vision, right, my North star on some of these other stuff. So so the first one, that's even before trust, is, uh, enhance, not replace. So there are tools out there or their ai startups that promises to reimagine, whatever, xyz, and then you don't need these anymore. But for me, you know, I, I want to bring everybody forward, right like that's my passion.

Eric: 41:08

Yeah, so I think you know that enhanced, 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 to give 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, like where on where we need to get to the pro, the thing that I struggle with is like, as someone that is, you know, considered a senior in this you know kind of field, like I, like people that are getting into it, it's hard for me to give directions Right, cause it's like, you know, if we think back about to like back when we were learning, you know, like CCNA or something like that, I remember when I was taking my CCNA, I remember I was like learning about frame relay and I'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 that eventually fell off the back of the truck because more stuff got added to the front of the truck, right, yeah, but now I'm wondering if so much has been added to the front and like I don't know what's fallen off, right, and to tell people what not to waste their time on, because I like I don't know we probably overthink this stuff. But I can think of like so many scenarios 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 doing a lot of cloud stuff, you know like if if you, if you're a network engineer that just got into cloud, you would probably never touch a cloud. Like if you were just doing purely cloud, you never touch a VLAN in your life.

Chris: 42:28

But VLAN is like such a core concept that is like required everywhere else. It's just like is like required everywhere else. It's just like. That's, yeah, it's the gap that I don't know how to fill right On, how to tell people to get into this stuff. I guess and I'm worried about the bottom rungs of the ladder, kind of you know becoming very shaky very soon.

Eric: 42:47

Yeah. So I think, going back to your point, Chris, that VLAN is fundamental. So if we're going back to say maybe the VLAN, this VLAN is fundamental, so if we're going back to say maybe the VLAN, this VLAN thing, or it might change to VNets or something else, or we'll just have enough VNets out there, Nobody needs VLAN anymore or something like that, but the concept of broadcast domain, collision domain, these basics do not change right. So maybe what we need to do is to teach the fundamentals. We teach them about IP addresses.

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 you know Lego pieces and whatever smaller pieces on top of that. Then those are transparent and we make it clear that previously you know this dude, when he was, you know implementing switches, like we have to know VLANs. But hey, dude, like you're the new generation and you may not need to know that because you're cloud native, however, you know your collision domain and it depends on really how deep the cloud provider provides right. So I think it's getting the clarification on.

Eric: 43:55

You know what are the fundamental building blocks, tgl's fundamental building blocks, and then you know you build on top of it and because we're getting much more specialized, so all of us are in a way, one way or another, generalists.

Eric: 44:08

And you know I think you have Will last on and he clearly defined himself as a generalist right and I would agree to that last time, that he clearly defined himself as a generalist right. So, and I would agree to that, but I think, as we move forward, there just might be just cloud network engineers or there might just be, you know, hyperscaler, you know network engineers within data centers, you know doing top of rack switches, whatever right. So I think, you know, with each of those roles as being specialized, the building blocks that we teach might be a little bit different, and I'm optimistic, but I do think the skill gap and the fact that nobody again back to what you were saying, tim, that everybody wants three years of experience but nobody wants to give that three-year experience to the new grads, that's a problem. So how do we solve that? That's a challenge of our generation, 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 not using 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 this point. I use no checks too. I don't feel bad about that. Yeah, exactly. Um. So what? Moving forward, like what is what do you think is the very shortly period of time? What do you think is the? The right answer is it, is it get a junior teach the fundamentals and then we give them, I guess, just ai tooling and say, like you know, here are your 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 might have a different answer, but my newer start is enhance, not replace. So that is my answer. That's what the answer I wanted to be, and I'm trying to be the change that I want I want to see. So I want to bring a junior engineer in, or somebody who's you know in college right now, and in fact, I'm talking to my friend and say, uh, I don't know if you guys saw, I clear a bunch of uh, networking gears in my garage and I'm donating them to the local college and I'm talking to them on, you know, how do we bridge this gap? Right? So I think I'm putting my money where my mouth is and that's the answer I want.

Eric: 46:21

I don't know if that's the answer will be or if that's the answer that's everybody's. All I can say is that's the answer I want to see, and I'm taking actions to accomplish that goal is yes, I want to bring somebody and, as a father of two teenagers, I want them to have somebody else when they're working in whatever field that they want, that somebody would tell them yes, come on, right, like, I will teach you whatever it 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 you could get to the other side. So, yeah, so that's my answer. You know, I'm optimistic, I want to give efforts to that movement and, uh, yes, you know, just, I want to enhance, I want to enhance people so that they could be, um, you know, capable of thriving in this economy in the next 20, 30 years right.

Tim: 47:13

Yeah, I like the enhance not replace as well. But the only thing that worries me and we're going to close out here but what worries me about? Enhance, not replace, or not the opposite what worries me about? Not enhance, not replace, not enhance, which seems to be the way a lot of corporations are going these days to pay for the AI that they're building is just that right. They seem to be on the replace, not enhance. But I agree with you when I use AI, it's about enhancing my workflow, not replacing my workflow. I don't hand the keys over. I use it to do stuff I already know how to do.

Eric: 47:48

What I think is happening is the pendulum always swings over the one way or direction or not.

Eric: 47:53

So now, as you know, we have a bunch of layoffs in the industry and some people joke about they're being replaced by GPUs right, so they're spending billions of dollars on GPUs, but they're cutting thousands of dollars, hundreds of thousands of dollars in salaries.

Eric: 48:09

So I think that pendulum is kind of swinging both ways and what I see happening is they overhired and over putting a lot of bets into human resources and capitals during the COVID years, and now they have this drunken effect, the day-next-day hangover effect.

Eric: 48:28

So the pendulum is swinging this way and hopefully I think that's going to swing back when we're a little deeper into the hype cycle and then we find the balance and so on. So I do think that if we're just looking at all the bubbles and all the histories and you and I, tim and Chris, probably that we live through the dot-com bubble, we live through the financial crisis, we live through for me at least, you know, like the Asian, you know economic crisis, the Korean market crash and so on, so forth. So so I think you know, I always see these pendulums swinging, so hopefully we're going to have reached a more equilibrium in a short while. And if you know because being in Seattle and I know a lot of layoffs has been happening just throughout the years and don't lose hope. I think you know the the if you just look at the history, just go get through this dark period and then you know we might have something that, uh, that works out at the end.

Chris: 49:24

Thanks, we will. We will survive this one. Whatever happens, we will survive we always do right.

Eric: 49:29

I mean, I'm optimistic, so I hope so. Uh. If not, then uh, then that sucks 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 want to take a look at some of my books, you can find out everywhere you get your books amazon, uh, apes books or whatever that you get your books from. No more physical bookstore, unfortunately, and last but not least, if you want to check out my podcast, network Animation Nerds, I weekly, biweekly, release and hope to just engage with you one way or another and collaborate and let's make this world a better place. Thanks for having me, it's been a 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 been great. We'll definitely have to have Eric back and oh, for sure. Yeah, make sure you check out Network Automation Nerds. It's a great podcast. We'll put the notes in there or put the link in the show notes.

Tim: 50:29

All right, everybody. Well, this is Tim and we'll see you next time.