Speaker 1: 0:00

I really don't like the term source of truth. It's just so confusing. Common language, I think, is important, especially in an organization as you're building your automation capability. The concept behind source of truth, intended state database versus current state database those things are definitely important. How else do you audit your configurations? How do you audit your environment if you don't know what's intended to be there versus what is actually there? And then how do you aggregate all the data that's needed? I've worked with too many teams that have gotten hung up on the data piece. You can sit and spin cycles for a very long time trying to clean up your data or get your data to a very good state. You can get stuck in analysis paralysis for a very long time. Do I have the right management IP addresses in place? Do I know what my validated software is supposed to be? Do I know what my hardware models are? Draw a line in the sand, pick a starting point and figure out what data you need, just to get started.

Speaker 2: 1:08

And someone else's data center far, far away. I'm your host, william. Today, as always, I'm joined by Yvonne Sharp, and while I'm still trying to ascertain if public cloud is more Death Star or Millennium Falcon, yvonne has already mastered the ways of the Force and is completing change orders with her mind without even using generative AI. How does it feel to be a Jedi today, yvonne?

Speaker 3: 1:37

Shockingly, the same as every other day. It's good to be considered a Jedi, but man, after a week of travel, I am ready for the weekend.

Speaker 2: 1:49

That might be what a Jedi would actually say. So you're great.

Speaker 3: 1:54

We could go all Lord of the Rings and say you know, a wizard is never late, he appears exactly. You know he arrives precisely when he intends to. But then we'll make you a metaphor.

Speaker 2: 2:05

So with us today is someone I've had the distinct pleasure to spend some time with and get to know over the last four years, I guess Someone who is well-versed technically and strategically and is just all around a good person. That is Dan Cruz. Welcome to the show.

Speaker 1: 2:23

Hey, thanks, William.

Speaker 2: 2:25

Thanks for having me here today, and how are things going for you?

Speaker 1: 2:28

Oh, it's been a busy week, same with Yvonne. I've been traveling this week and just been busy working and trying to enjoy life with the family, so yeah, that's about it.

Speaker 2: 2:42

Yeah, I've been traveling a lot too, but just for kids stuff. Lately it's been pretty exhausting, a lot of weekend travel. So it's nice. It's kind of like vacation coming back home on Monday, which is kind of weird to think about.

Speaker 3: 2:56

Sleep for losers and non-parents.

Speaker 2: 3:00

Exactly, hey, and the more you go without sleep, the more sharper you get. It seems like it's almost muscle memory or something. I was reading something one time, actually, that they did a study this is over in Europe and they would basically wake you up in the middle of the night and ask you to do like four or five mildly complex tasks. Mildly complex tasks, just pure, you know, from from dead sleep. And the mothers, like the I think it was like five to six month your mothers with five to six month, uh, infants, you perform the best out of the bunch, even like on top of, like ceos and such. I thought, wow, that's really interesting.

Speaker 1: 3:44

I'd say sleep's a crutch, William. Good resources don't need it and bad resources don't deserve it.

Speaker 2: 3:52

I feel like someone that had a background in the arms of something like that.

Speaker 3: 3:56

Yeah, so you know I'll be a contrarian on that topic. Sleep is my favorite thing, and when I'm traveling I actually am able to go to bed earlier than I do at home, and I take advantage of that.

Speaker 2: 4:09

So anyway, yeah, Anyway, yeah. So I just got to get this out off my chest. I mean, I just have to be honest. I mean I'm glad you're not a Chiefs fan, dan, but I'm just not excited about the Super Bowl. I just have to say it publicly this is Groundhog Day, but for football I wake up in February and it's the same thing. Mahomes plays the hero. You have Travis Kelsey, taylor Swift getting more screen time than the touchdowns. Eagles fans are screaming it, innocent bystanders punching inanimate objects, refs making calls that divide the country. It's like the Fast and Furious franchise of Super Bowls. It just won't stop. And either way, in either of those cities, someone's car is going to get flipped. But I digress Anyhow.

Speaker 2: 5:01

So today's topic Dan and I had a really good conversation about network automation. I guess it's been about. It's been a few months ago, but that's going to be. The topic of this conversation is network automation and you know I want to get into talking about you know, a lot of times there's like a lot of hype, there's a lot of buzz, there's a lot of buy this, buy that.

Speaker 2: 5:24

Lot of times there's like a lot of hype, there's a lot of buzz, there's a lot of buy this, buy that, um and and many times network automation, I think to the public is not framed correctly, even like the value proposition sometimes isn't framed correctly and it's definitely been perceived in the past is not a must-have. But but that is changing here. In the recent past it's becoming a must-have and it's becoming business imperative, along with some of the other top-end things, especially if you have any sort of on-premises data center presence or your own tech stack that you manage. But yeah, that's the top of the conversation and I guess, before we get into that, do you want to give a brief background just of your um, your experience, your background? Dan, I don't know how far back you want to go for sure.

Speaker 1: 6:15

Uh, we'll go. We'll go back to I don't know 2005. Uh, I was in the military for a period of time. That's where I got most of my IT training, been deployed overseas, came back, went through a Cisco boot camp and got my first CCNA certification. That was like around 2007. And did network engineering for a while in the military and then finally got out, spent some time working at a startup company and then moved to my most recent employer and been there for a period of time. I did automation in kind of all of those areas, primarily in the infrastructure space, primarily with networking. I am trained in, or was trained in, a lot of different IT systems through the military I mean we used everything, and with large enterprise I mean we used everything, and with large enterprise, so working at Koch Industries, where I'm currently at as an enterprise architect.

Speaker 2: 7:39

you know all kinds of technology, all the tools, awesome.

Speaker 1: 7:45

Yeah, I know you're spread out between like you have quite a bit of not just network engineering experience at this point, but cloud as well. Yeah, cloud space cybersecurity, space network server infrastructure, backup recovery. I primarily work with the infrastructure teams, but at times work with the application teams, and when I say infrastructure, I include cloud. Yeah so kind of got my fingers in all the things Awesome.

Speaker 2: 8:10

And I know that my experience with network automation is very few. Network engineers in the earlier days really banged the gong and tried to bring attention to network automation. Usually you had a few that were like writing a lot of like. For me in my time it was pearl bash, scripting expect. And one of the things that you realize pretty quickly is that, okay, when I leave this company like this is dying, I didn't make an enterprise wide transformation and at the end of the day, what value was through there other than making my life easier, making me go faster and allowing me to do more work in? What really becomes important is bringing attention and making an enterprise wide transformation. But can you kind of talk to that a little bit? Like, when did you realize, like in your journey, that, okay, this like, how do we make this a strategy and a culture change rather than just scripting?

Speaker 1: 9:12

Yeah, I mean to your point right. There's always that one guy or a handful of people that are super passionate about automation and they're out there writing scripts, but it's just never sustainable. Once they leave, the automation starts to fall apart. Nobody knows how it was built, no one knows how it was coded, all of those things. So I realized it when I stayed in the same organization but transitioned roles and started working on other things and I saw the automation that I built fall apart and I had to get pulled back in um to fix it. Um, that that's how I realized very quickly that like, hey, I'm trying to do this other job, I'm trying to create this value over here. I can't keep getting pulled in, uh, to work on this old automation that I built a while back.

Speaker 2: 10:06

So how did you bring attention to that to the right people? Because, of course, you can use open source and just write raw general purpose code to do all the things, but usually there has to be some strategy wrapped around it. A lot of times, maybe you need a steroid injection from the outside, like some sort of agency or some help to come in and do discovery and, um, help you with things Like. There's just a combination of things and all that requires money you got to have. You have money to spend. So how do you get the folks with the deep pocket books to shed light on this?

Speaker 1: 10:47

Really good question. For me, it's very important to have senior leadership or executive buy-in to do some of these things, and they often don't see it or understand the value of it, Because really we're talking about creating operational efficiencies efficiencies for the teams themselves and when you have people that are coding or scripting and automating things in the background without a strategic plan, it's kind of like skunk works right, Like nobody knows what's going on, right. You're solving problems that nobody knows about. So you really have to expose those gaps. You really have to get senior leadership to identify and see the value that can be created by having a more strategic plan and approach.

Speaker 3: 11:48

Well, and one of the things that I've noticed too is a lot of times like automation projects. They start very grassroots and they start on the side. They don't get integrated and codified into the systems of the organization right, so you still are approving everything with manual change requests. There's always like the organization right, so you still are approving everything with manual change requests. There's always like the automated way to do it and then the hands-on way to do it, and until you get all those processes codified into the official working systems, it can very easily be left aside or left behind when you have a turnover and headcount, because it's all very, very tribal, and especially in large enterprise organizations. Those big enterprise systems have a gravity to them that just pulls everything that direction them.

Speaker 1: 12:48

That just pulls everything that direction. I would agree with that right. So when you talk about like end-to-end process automation, right, or event-driven type automation like those require that you integrate with the systems, that those are triggered independently through the workflow, that sort of stuff and that's, we don't really see that in the in the very early stages of the journey, right, it's always some highly technical resources like oh, I know how to fix that and they go and run their python script in the background somewhere, right, but they're manually kicking off that python script. It's not an orchestrated uh, orchestrated event that occurs.

Speaker 2: 13:25

Yeah, that's a good point Orchestration versus automation. So, like automation, you have these different pockets like Python scripts that are run, maybe ad hoc, from a server, or like even a cron, like I used to do this thing where I would always run certain things from cron jobs on servers and then take the data and then do something with it and if it broke, only me and one other person knew how to get it going again. And when you think about that, like leaders more often than not these days are looking down and they don't care that you were smart enough to write some python scripts and run them from a server or a jump host in a data center. When they they look down, they're thinking of services. They're thinking of, hey, we have this intake process, like new product coming into fruition. What are all the steps that have to happen? Like we want this whole thing automated from beginning to end, from the beginning the discovery, the paperwork, the changes, like the chat offs, all the different things, all the way to the point to where this stuff gets configured.

Speaker 1: 14:29

And that's a much harder problem to solve when you bring in the business processes yeah, I was gonna say you know, leaders are are more interested in the business outcome. What's the business outcome that I'm driving towards? Right, Um, and when you're like oh well, automation can make us more efficient. Well, not when it's not end to end process automation, when it's still like I have to call someone to go kick off a script manual manually. Yeah, you probably saved me five minutes. Uh, with automated script that you're running, but the? How does that fit into your work process and how is it making your work process more efficient? That's where the real value gains are at.

Speaker 3: 15:13

Well, and I think you know it's a sad reality and it sounds harsh to say it, but nobody really cares if the IT practitioners are saving time or not. I mean, unless you can convert that into a real dollar value, that applies to the business. That's when it matters. But I mean, basically most IT headcount in most organizations is it's planned for, it's in a bucket, like they already know, like it's just not calculated in a way that it's meaningful to the business and it and it sounds harsh, especially if you're that person and you're like wait, you're saying my time doesn't matter. Well, not exactly it does. Like it matters that you get more done in a day. But if you're making a business argument like saving the IT guy, time is not enough of an argument to push through a system-wide change. And that is an important distinction to understand when you're trying to go and make an argument for automated systems, because if your only answer is it saves this team of five folks a day a month, or two days a month, nobody's going to care. I'm sorry.

Speaker 1: 16:28

Especially when you like I've had this happen too many times right, like the technical resources are like oh, this is like, we need to automate, we need to do all these things. Okay, let's frame this up, let's take a look at what it will take to do this. Okay, let's frame this up, let's take a look at what it will take to do this. And they always come back with the like we need DNA center or we need glue networks or we need whatever you name, whatever automation platform, right. And it's like okay, you go to market and you look at those off the shelf solutions and the cost associated at scale no, the cost associated at scale. No. Like getting business buy-in for something like that when you have no record, no history of performance, uh, in the automation space is super difficult to get alignment and approval for yeah, one good point there too.

Speaker 2: 17:20

It's like that age-old decision making at least as long as I've been working in this space is build versus buy. And more often than not, even when it's time to buy a tool or buy a platform, like, okay, we need to go buy something. More often than not you're going to have to go and try to do the DIY approach first and figure out how painful it is and sort of do a calculation, a risk calculation, just all sorts of calculations to decipher. Ok, do we have the engineering talent to do this? Do we are going to, you know, do we have all the things that are required to meet this outcome? Maybe we do 15 of it, but this other platform does the rest.

Speaker 2: 18:10

Or you've got to figure out like, where in the abstraction pyramid that you want to place yourself, like, where, like when do you buy? But at times you just usually have to go through the pain first and prove out with data and other things that, yeah, this is why we need to buy something, because we can't accomplish this based on whether it's the system we work in, the engineering talent or the headcount that we're allowed to have. Or maybe we can or can't bring in a partner. So how do you look at that? Is that kind of how you view it? Build versus buy decision making like how does that ring through your head?

Speaker 1: 18:50

the way that that I I've thought about it over the years. I mean so I've never seen a tool fix a problem. What what I've seen is good people and processes adopting a tool in the right way that then fixes the problem. So my approach I tend to focus on the people and process side of it first, so you get the right skill set in, you get the right mental models, you get people working and developing their processes in the right way with any tool, and I would say this is applicable outside of IT.

Speaker 1: 19:26

My wife and I have this conversation when we go to Home Depot. I see some cool power tool on the wall and I'm like, hey, I want that. And she's like when was the last time you built something that required that type of tool? Right, you don't need. You don't need a power drill if you don't even know how to use a screwdriver, right, Right. So focus on the people and process side of it and then use the tools that are available to you and then at some point it probably makes sense to come back and reevaluate Do you have the right tools?

Speaker 3: 20:00

Yeah, well, that's such an important point because I have seen, you know I've worked in all different kinds of organizations, like organizations that are large and, you know, have large budgets for spending on every new tool in the toolbox, and then very small organizations where you have to be scrappy because you can't buy the newest tools, to be scrappy because you can't buy the neatest tools, and I think what folks that haven't been in this kind of environment it's hard to believe honestly is that sometimes throwing money at a problem makes it worse.

Speaker 3: 20:37

Right, like I've seen organizations end up with tool bloat because they think, well, if we just go spend a truckload of money, it will make this problem go away, and what they end up with is tool sprawl without the people, processes to implement it, and they end up with a patchwork of stuff that was never meant to work together or that was wasn't implemented in a way that it's going to work together, and then like, and then you end up with, like procurement people that are hired to manage all the things that you bought that you're not getting value from, and it's, it's, it's this, I don't know it's, it's.

Speaker 3: 21:17

It's a growing problem, that of inefficiency and misuse, and and so I think, like the starting. What problem are we trying to solve? What's our business problem? Who are the people and processes we need, and then what tools we need. I think that's very simple, but but the right framework, and it's easy sometimes for organizations that are kind of flush to skip the people process part and and it's it's the people process part and and it's, it's it can end up even toxic.

Speaker 1: 21:51

um, yeah, I 100 agree with you. I mean, like, if you just look at the simple economics behind there, right, like, depending on the size of the organization, right, you're probably going to pay a million dollars for a good tool off the shelf, right, and then you need at least one resource to run that tool, right, so you're looking at 1.1, 1.2 million, depending on how much you pay your resources and where your resources are out of. How many resources could I get if I didn't purchase the tool and used open source and focused on people in process and really looked at solving problems? Because in the former model, right, where you have one resource with one tool, guess what? You didn't solve your problem, because you still have processes that are dependent on one person.

Speaker 2: 22:40

Yeah, and throwing. I mean those are all good, amazing points. No-transcript, we did a thing. But you're absolutely right about the cost calculations that you have to make, because the price of the tooling and how do you even justify that cost? If you have a network that's ran okay for for the most part and it's never been such a big problem that it's gotten a, you know, attention of leadership, how do you justify the cost?

Speaker 2: 23:32

And I think that the way that I tried to do that in the past was actually, what am I? What am I helping? And it's a lot of times I was able to get this over the board with okay, we're not going faster, but since every outage that we have for this length of time costs the company this amount of money and it is resulting from human hands and misconfiguration, and these different things expand and make our reliability better for the networks that power our whole infrastructure. That is where the value comes in. So it's almost like I mean, maybe this isn't a thing for everybody, but for me I saw a lot of success with showing that, okay, if we make very consistent changes, very small changes more frequently that are more controlled and they're automated, no human hands, we are actually increasing our reliability because we're making consistency. Consistency equals, reliability equals kind of value, I guess.

Speaker 3: 24:33

And you have to tie that back to the cost of the outage. Right for the business, right? That's the secret sauce there. Go ahead, dan.

Speaker 1: 24:40

I was going to say it's hard, it's hard to do for technical resources and even for IT leaders, right, because the pain that you feel, the pain that your team feels, is the pain that you're focused on. Right, and you really have to look at it from a different lens, through a different perspective of how am I servicing the business? What outcomes am I driving towards? I servicing the business, what outcomes am I driving towards? What's the opportunity cost for the business when they're waiting on my team to do something enable them? So that's, you really have to look at it through a different lens. And it's hard to do when, when the pain you're feeling is is so right in front of you and evident.

Speaker 2: 25:18

Okay, so I'll tee this up by one of the things. It was when I first started trying, you know, we talked about like the scripting and just hey, I'm worried about numero no. I want to make my life easier. I'm going to knock some changes out to to bigger, bigger picture stuff. One thing this was a long time ago and I know this space is actually. This space really hasn't morphed that much. Actually, this space is actually the space really hasn't morphed that much. Actually, this stuff really hasn't changed that much in the past 10 years. To be honest, I don't think about it um, uh, now that I think about it.

Speaker 2: 25:50

But the thing about, okay, we have what is our operational state. This is brownfield and brownfield's crazy. Everybody knows that brownfield. You have different pockets of brownfield everywhere and you have to.

Speaker 2: 26:04

When you do any sort of good automation, there's a problem that you have to solve. That's a very hard problem actually, and that is deciphering between your desired state, what you want the network to be, and what is in operations today. The rabbit hole that that takes you down is bringing in some sort of database or source of truth or an aggregation of sources of truth. And when I started doing this, you basically had one solution and it was pretty new at the time. It was Netbox and all open source.

Speaker 2: 26:41

I remember the first time I hosted NetBox in production, you didn't have companies that offered support really on this. We had it running on a VM originally and then we transitioned to containers like Docker, swarm and we were running it on Swarm. But now there's a lot of paid solutions you can. You know it's been sassified a little bit. You know it's kind of become its own little you know sort of market in a sense. So you have Netbox, notobot, from Network to Code. You have a new platform, inf platform, um, infra hub from ops mill. So do you have any thoughts or opinions on whether this is a necessary thing or and is this something that you need to have teed up before you start doing any automation? How do you think about it, dan? How do you?

Speaker 1: 27:32

think about it, Dan. So I really don't like the term source of truth. It's just so confusing. So common language, I think, is important, especially in an organization as you're building your automation capability. I do agree, though, like the concept behind source of truth is important, right. So, like intended state database versus current state database, like those things are definitely important, Like how else do you audit your configurations? How do you audit your environment if you don't know what's intended to be there versus what is actually there? And then how do you aggregate all the data that's needed to create a configuration or a change that's required in the environment? Those are all definitely important things that need to be there. Whether or not you call it a source of truth, this is up to you.

Speaker 1: 28:29

Me personally, I don't like that term. But, getting started, I would say yes, certain components of that are required, and I've worked with too many teams that have gotten hung up on the data piece for too long. You can sit and spend cycles for a very long time trying to clean up your data or get your data to a very good state. I am trying to clean up your data or get your data to a very good state, Right. Most teams struggle I won't say all, but most teams struggle with like just inventory what are all my assets and where do they exist? You can you can get stuck in analysis paralysis for a very long time. Do I have the right management IP addresses in place? Do I know what my validated software is supposed to be? Do I know what my hardware models are? Just draw a line in the sand, pick a starting point and figure out what data you need. Just to get started is what I would say. Otherwise you'll get stuck in analysis paralysis started is what I would say.

Speaker 2: 29:38

Otherwise, you'll get stuck in analysis paralysis. I love that. I know we I think we talked about this, which is why like, that's kind of how I feel about it, because I know that there's some folks reach out sometimes and you know, just having some of these conversations, you see companies a lot of times they want to actually account for everything and get that source of truth piece perfectly planned out and all the data just perfectly sanitized across all their multi-vendor, multi-cloud, multi-everything network and if you do that, that's like a 10-year process. It's just never going to be done.

Speaker 2: 30:17

Organizations are too complicated these days, enterprises are way too complicated and a lot of these things, some of the things you only have limited control over. You don't have the same control that you have on your routers and your switches, but you still require some of this other data, so you can't actually even ensure the integrity of it. You can read it in and you can use some of it, but you don't control it wholesale. You, you aggregate it to some degree. So if you're, you're absolutely right, the analysis paralysis thing is huge. You got to get started. You know that it that doesn't mean that you don't need us. You know some sort of. You've got to have some method or mechanism to differentiate between that desired outcome and your operational network and be able to validate continuously as you go along yeah, I.

Speaker 1: 31:04

I would say like, if you look at any switch environment right, just the switching environment how many different switch models are you going to end up with? Like out of a thousand devices, you're probably going to have 20 different models. That would not surprise me at all're probably going to have 20 different models. That would not surprise me at all, right. And then of those 20 different models, how many different OS versions are you running? Because if you're not running any automation, chances are most of that stuff's not standardized and so, like when I've gotten started with teams in the past looking at automation, it's hey, pick the switches that are common that you can run common commands on, group those together and start with those. Don't try and do your switches, your routers, your load balancers all like your cloud stuff. Like pick one environment and get started.

Speaker 2: 31:54

It's great advice, I love it and that is, I'm guessing, that that approach has served you well in the real world.

Speaker 1: 32:03

Making progress, absolutely right. Like, and it's incremental. I don't know how much we've talked about I know well, we've talked a little bit about Agile in the past, but that's the other thing. Right Is shifting your teams to an Ag agile model and focusing on MVP to make progress. Right, like if we're doing you know those waterfall projects and we're trying to get everything perfect, like it's so difficult to make progress because this is such a big problem. You really have to take this huge problem that you have with automation automation break it down into little incremental steps that you can make progress on yeah, and by mvp for those that don't know that term.

Speaker 2: 32:44

We're not talking about the super bowl, most valuable player, a minimal, viable product. Essentially to say, hey, we, we need a starting point, we have to deliver some value. But, hey, the sooner we get something out that door, the sooner we can get feedback on a smaller component of it, which makes it easier to reiterate and continue developing more value, instead of saying, hey, we're going to get all the things done at once and then ask for feedback and then have some elongated feedback loop. We're getting it out the door quicker, showing value quicker and getting feedback quicker and making it better quicker.

Speaker 2: 33:22

It's a big deal, and that's having an agile mindset, an agile team structure, bringing in some of the DevOps, which is a culture, not a position, is really important.

Speaker 3: 33:37

It's a philosophy.

Speaker 2: 33:39

It is Yvonne, is the philosopher, the resident philosopher ranter. It's all about the DevOps.

Speaker 3: 33:45

It's how we think about how we work. Right, it's more of an approach to working than it is like I do. Devops, Okay yeah.

Speaker 2: 33:56

One thing I want to. So one thing about you, Dan, is you've never been shy of throwing out good. I mean, usually your opinions are grounded and pretty, you know data and experiences like good stuff and they're usually pretty spot on. But I just want to get your take on the, the platforms and tooling surrounding network automation specifically like is it really matured? Has it gotten better? And then, differentiating between you mentioned dnac earlier, which before that it was prime, and I've gotten stuck in the muck and mire there in the past. But like the vendor produced boxes that you can install versus the other tools and platforms that are more maybe bleeding edge. But do you have any thoughts there on the maturity? Like, is it maturing or like would you like to see new things? Like, where is this thing going?

Speaker 1: 34:56

maturing or like would you like to see new things? Like where is this thing going? So, yeah, a couple of thoughts there. So I think I think maturity in the past has been limited based on the way that you can connect to network infrastructure right, like in the past with network infrastructure you were limited to SSH, telnet, snmp as mechanisms to interact with a network device for configuration and troubleshooting. So I think that does limit your tooling capability and the maturity as such. Now, over the last decade, yeah, things have been changing. We have more cloud-based systems today, more software-defined systems today in the infrastructure space than we ever have in the past, and I think that has opened up the door for maturity within tool sets. However, I think that's where some of these industry tool sets are lagging behind and not keeping up with the changes that have occurred in infrastructure. When you look at observability, otel, those type of things, like some of the traditional network tooling, doesn't account for that stuff. It's still using SNMP as a way of monitoring appliances. Why aren't we moving forward in those spaces?

Speaker 2: 36:10

That is such a good point. Right there they opened telemetry piece. I love that. We can discuss that, maybe also later. But yeah, go ahead.

Speaker 1: 36:19

I do think that we will see some advances here soon. We're starting to see it already with things like agentic AI, generative AI starting to be built into the tool sets, and I think that will help drive things forward, make things easier, but at the end of the day right, that's what these tool sets do is they just make it easier for development to occur? I think of it as like no code, low code opportunities right, that's what those tool sets, those power tools are doing. Dna Center the way that I see teams interacting with that is around kind of no-code, low-code mental models. They're not putting in the time and effort to upskill and develop those pro-code skills to interact through API and things like that with the tool sets and create orchestrated workflows and integrations.

Speaker 3: 37:20

Well, so I guess I just like, I just feel like the conversation still like how much have we moved forward? Right? I feel like these, you know we're still talking about SNMP. I mean it's been 20 years and well, for me, like it's not been 20 years for SNMP, it's been 20 years for me and yeah, the stuff going on with open telemetry is super exciting. But I do sit here and wonder like, yeah, gosh, why has it been so slow, just so slow? Because I mean I feel like everybody knows that we need to do it differently and yet here we are I?

Speaker 1: 38:00

I honestly I think some of it is us, some of it is our network resource, like networking and applications were so far apart for such a long time, right like, and now, when we look at automation, like you're really starting to step into development and coding and uh, automation platform looks more like an a full-blown application than it does infrastructure, and I think we have some some old mental models within our network teams. It's us that are holding ourselves back. We complain and moan about the problems that we have, but we're not. How often do you see a network guy going out and learning how to code and how to be a developer?

Speaker 2: 38:50

Yeah, this is so true Like I can't count the conversations I've had over the past two years with leading edge tech professionals that are in the network space that they don't understand when I say something like hey, enterprises are actually locking down their AWS console. They don't want people logging into the console and making changes that way anymore because of the risk of all this configuration drift. They want this stuff codified. They want of all this configuration drift. They want this stuff codified. They want to produce an artifact because they want to be able to roll things back.

Speaker 2: 39:21

You know, they want this modern approach to managing network infrastructure and it's it's like well, why it's really hard for network engineers, I think, a lot of times to see that value and to see why enterprises would want to do that in the first place. And and that's something I mean what do you think about that? Because that's something I see at a lot of places right now where the UI is being used purely read only and, if it's not, at a given company, they're trying to shift that way. They want to really have control over all those changes because in order to basically supplant ITIL-based change management, you have to have a reliable and a thorough understanding about breaking those changes into smaller pieces and only making them, you know, completing them through approved pipelines, or you know something, workflows or something similar.

Speaker 1: 40:12

Yeah, I see the same thing happening, william, like in the cloud space, application space, definitely walking down the ui, um and uh, following better change control practices, um. But I want to go back for just a minute because I feel like we've been pretty hard on network engineers, network resources, to be fair, right. To be fair to guys like the knowledge required to troubleshoot in the network space, right, all the things you have to know about BGP, ospf, eigrp, like all the routing protocols, layer two, wireless, like there's so much in the network space, can we really be like?

Speaker 3: 40:51

oh, now you have to go learn to be a developer like oh, now you have to go learn to be a developer. Well, and still, the industry, like their startups, they're trying, but our big vendors, they're doing some things, but but it's still not as baked in to the work as it is in other industries, like in in cloud. It's baked in, you know, like the ability to automate, the ability to deploy via code. It is 100% baked into the platform that those capabilities are there. And two, we're dealing with infrastructures that may be deployed for a decade, and so the newer capabilities, they just don't exist or weren't designed in from the beginning.

Speaker 3: 41:47

And I think the the best thing we can do is have a good idea of what our, what we want the desired end state to be, the capabilities that we want at the end of the day, and and yes, it is, you know, infrastructure as code, automated deployment, some sort of state discovery, all of those capabilities, and then every decision that we make incrementally needs to be in that direction, and I think that that that is the piece that often gets missing.

Speaker 3: 42:17

Is this overall, like vision, or and and and I feel like vision is too lofty of a word, but this really clear objective that we want to achieve. And then the will, the organizational will over a long period of time to get there. Because what happens is you might have a great dynamic leader who wants to get everybody there, and then they get scooped up by a bigger fish and then they go, they move on, and then all of those initiatives get replaced by a new person who has new, you know, a new ax to grind and like. To me that's a big part of the problem, it's not. It's not just like the practitioners, it's the system as a whole. Um, that those realities play out and and you just can't get traction when you come in and you clear the slate every two years.

Speaker 1: 43:10

I think those are some really good points and, like you, triggered some thoughts in my head. Um, something that I wanted to mention is that like, uh, you don't have to be a network resource to develop network automation. Network resources understand the network and how to troubleshoot and the network and the processes associated. Right, so, as as leaders are thinking about their strategies and approach, um, think about, hey, can I hire a developer to come in versus a network and just partner them with a network resource, like I've done that in the past where brought in developers, partnered them with network resources and they were able to learn from each other and the network resource was able to upskill and eventually become a developer on their own, a developer on their own. I've had server resources that guys that worked on server infrastructure knew nothing about networks when they wanted to step into automation space, partnered them with the network automation team. Guess what they were building network automation as being server infrastructure guys.

Speaker 2: 44:26

That's awesome. Hey, you got to make the best. You know the great, the greatest teams out there. It's like team when the U? S team beat Russia in the Olympics. You know they didn't have the best, every player wasn't the best player in the world, but they had the right team. They were good at different things. You got to have the right team If you want to be successful.

Speaker 3: 44:45

Come on out the hockey analogies again.

Speaker 1: 44:47

Oh, it's a good. It's a good point, though, william. Right like understanding which resources are advantaged to do what. Right like if you're. If you're building an automation platform in the cloud, guess what?

Speaker 2: 45:01

your network resources probably aren't the right team to run that platform, yeah, but you can get them with the network resources to understand the processes that need to be automated and if you're hiring let's say you have five headcount, five, nice number and you hire five experts that are just, uh, you know, 100 foot deep with bgp but they they're not versed in other areas is that the right team? Probably not. Um, you want varying levels of skill set on your team, like maybe, like you were saying, maybe you have a developer, maybe you have someone that is good with process automation or devops and things, and maybe you have two or three that are you know, route switch, rock stars and what you said earlier was so funny because network engineers do get a bad rap a lot of times and a story popped in my head. So I worked somewhere and just so the audience knows like how wild this can get sometimes.

Speaker 2: 46:00

I started working in a network where there's a routing protocol called EIGRP and it works well for most networks by taking a balance of bandwidth and delay and it has very default. They're called K values, which made understanding like how paths were being selected, like nothing was documented and I've never seen anybody do this. I've never seen anybody mess with K values in EIGRP. It's like there was suboptimal path all the time.

Speaker 2: 46:40

That is a bad idea. Go to ISIS or OSPF if you want to get custom with metrics and such. But yeah, that's like a thing. That was like such a huge time sink. And when you're trying to like sort all this out and okay, if you have one router that's configured one way and others that are configured other ways, you have like loops and convergence issues and interoperability stuff, Like yeah, that's welcome to being a network engineer for for five minutes wow, that's to be honest.

Speaker 1: 47:12

I think that's because we all think of what we do as art, right, like we try and customize it, making our own thing. It's so beautiful, like, like when the network is humming, it's a beautiful thing. Right, it's an art to get your network humming Stop trying to make it Because I can do this.

Speaker 2: 47:30

Does it mean should I do this Absolutely? It means I should do this. I'm going to do it. I'm studying for the CCIE, of course.

Speaker 1: 47:36

Stop making it an art, standardize it.

Speaker 3: 47:40

And here's the thing you know that there's this whole field called architecture, and I'm talking about physical architecture here in buildings. That is, this combination of art and science, and there's always going to be a bit of that, right? I mean, it can be beautiful, but it doesn't need to be like hyper modern art. Do you know what I'm saying? Like, it needs to have some symmetry to it and it needs to, you know, make sense when you look at it. It's not. You shouldn't sit there and go, hmm, how do I feel about this network? No, you just look at it and be like, oh, this makes sense, yeah.

Speaker 1: 48:17

I 100% agree with you. I love that.

Speaker 2: 48:21

I think we've reached the top of the hour, yvonne, is it? Yes, is it in time?

Speaker 3: 48:25

It is.

Speaker 2: 48:27

I feel like we didn't get to everything that I wanted to discuss, but we should have a follow-up episode, because I have a whole list of other things. 100% Always happy to come back. William, awesome, where can people find you? Are you on TikTok making dance videos, or where do people find you?

Speaker 1: 48:44

Not yet. I am thinking about starting something soon. In the meantime, you can find me on LinkedIn. Feel free to hit me up.