00:00
This is the art of network engineering.  Where technology meets the human side of IT.  Whether you're scaling networks, solving problems or shaping your career, you've got the insights, stories and tips to keep you ahead in the ever evolving world of networking. Welcome to the Art of Network Engineering podcast. My name is Andy Laptef and in this episode, I am joined by my  brother from another mother, my very good friend, my I wish we lived closer so we could hang out. William Collins. How you doing, William? Never better. Life is good.

00:29
The house is quiet. I'm home alone  getting into trouble with my uh adjacent podcast friend.  Yes. Let's do it. So  in this episode, you, you  know, when, by the time this gets  published, the recent ginormous AWS outage will be, you know, a distant memory, but there's a theme, right? There's a pattern. So I thought a great place to start for us would be, I don't want to call it a myth, but

00:54
You know, um I'm an old school on-prem data center guy, network engineer person.  And  I remember when we went to cloud, I think the big driver was time to market. We could spin things up fast and that was good because you would wait six weeks to get a new VLAN on-prem. So like I get it, the speed thing.  I'm also under the impression that, you know, you're getting more reliability, more resiliency, more uptime. And this was like, so  I pulled a Routers, Reuters, I don't know how you say that. It was the largest internet disruption like this year.

01:21
since like the big crowd strike thing. And again, this isn't like, I'm not punching down, right? Public Cloud's amazing. I don't know how they do it. It's magical. It's super awesome for everybody. But when US East one melts down what seems to be like once a year,  and when it takes down  like the entire internet, I'm left thinking as a person who's built a career in designing, building and maintaining systems that stay up, right?

01:45
How can a hyper, how can the biggest hyperscaler on the planet not have been able to design  a system that's more resilient? This  took down, I think banks, airports, hospitals.  It's the third time in five years that their Northern Virginia cluster known as USC Swan contributed to a major internet meltdown. Like this has happened three times in five years where they melt the entire internet. Like BGP was designed so that the internet can route around failures and yet.

02:13
AWS has figured out a way to melt the internet.  And dependent on VGP's awesomeness. you're my cloud guru expert guy. Can we just dig in a little bit to like... Calm down. What's going on? Yeah. And I mean, probably... mean, LinkedIn probably had to add additional capacity to make up for all the messages they were getting talking about the outage too. Like, boy, like logging into LinkedIn, was like  every message. Like I could scroll for a day and it's like...

02:39
Oh, another USC swan meme. And I'll be  honest with you.  Well, I didn't do that. Like everybody gets on and like, haha, right. And it becomes this, which is what I mean by punch down. Like, listen, I have worked enough very big, stressful, awful outages. My network engineer heart goes out to all the people who had to work this outage. I'm sure it was awful. Outages are always terrible. And I'm not trying to like, oh, the cloud isn't great. And I'm old man yelling at cloud. But I'm trying to understand from someone like you who's way more cloud native,  how can

03:09
One region in AWS melt the internet three times in five years. Like what's going on? Yeah, it's a good question and i'm gonna try to i'm gonna try to put on is uh i'm gonna pull a scott roban here and put a hat on i'm gonna  i'm gonna put my pragmatic hat on today  um So you're that whole myth of what what did you say cloud cloud equals resiliency? Nobody has a bigger budget than hyperscale. Right? You would think

03:36
Like we all have constraints financially that we can't build the resiliency we want. I would think AWS can build all the resiliency they need, right? I would say cloud equals resiliency by default  even is indeed a myth. Cause  I think it's important to almost add as a default. And you're absolutely right. So like ever since I first started working in clouds, like a long time ago, like this view  has been perpetuated so much since the early days. It was part of the sales tactics and the sales process.

04:06
And, you know, organizations, they begin these  gigantic migrations to AWS or other clouds and they're,  they do it as if they've bought some or they've signed some insurance policy thingy against downtime, you know, but what they're actually buying  is the potential for resiliency. So at the end of the day with most things in cloud, and I'm going to get to the trade-offs here in the nuances, but you get that resilient resiliency if you architect it correctly.

04:36
So the cloud providers give you the tools, but you have to use them properly. And one trend that I saw even with some of the companies I worked for, which I thought it's kind of interesting. First of all, going single region and sometimes even single availability zone in the early days, some companies thought, like an availability zone, it's a data center. So if I just have two of those, I'm good, even if they're in the same region. And that's a big...

05:04
is, you know, lot of companies have probably found out over the past five years with US East one, you need DR capabilities for your crown jewel applications. You want to be DR ready. That means multiple regions. So I think honestly, the real question here is why is it always US East one that causes the fuss? I mean, that's the, least the first thing I would question. And I think there's, I don't know if it was in, you put together a few notes for this or maybe I was reading somewhere, but it's like,  um,

05:34
the argument of it's too big to be reliable kind of thing. Cause I've actually heard that quite a bit and that argument has some merit at the end of the day. Um, but I think the root of the actual problem is a little more nuanced. So AWS is a, is a cloud provider. They started in USC swan. It's like the default region for so many like, uh, SDK thingies, like pipeline template, like services and third party stuff. So

06:01
When you say the default region, so for a customer that creates an account and spins up services, those services will just default to a physical geography called US one. If you create like an AWS, yeah. So say that you're part of a  really well put together team and you're trying to be very careful about selecting the right region to like land things in. Like you're like, okay, I'm avoiding USC.

06:24
And this is where the nuance comes in. okay, we're avoiding USC Swan. We've seen it on the news, but we have maybe one or two things there or something. Like we have that something in that region, but most of our stuff is somewhere else.  Um, this is where it gets tricky because you will often  have some sort of hidden dependency kind of lurking in US. So it's kind of like discovering is a, is an architect that you're supposedly like multi-region and DR capable of flash the application.

06:54
It's kind of like phoning home in Virginia for that, like some critical mysterious API call, you know, right before tucking it in for a nice nap and kapoof. So major problem. And I think in a second, I'll go into maybe some service examples, but uh another thing too. like, if you look at the RCA for this one, I think they label it as like a health or a

07:18
The network health monitor thing. is the biggest irony. It seems complex to me. I've never built services in the cloud, so I could be talking out of my, my Wahoo, but like, are there,  are there best practices to follow when building?  so like back to, it was ultimately a DNS, DynamoDB, you know, shenanigans, but yeah, it was like network, network health monitor, something root cause analysis, yada, yada, yada. That's to me, that's kind of telling in that when you have

07:47
that much interconnected infrastructure, like all in one place, kind of back to the whole too much, too big. um First of all, like the monitoring and orchestration systems themselves become essentially single points of failure in a sense, because it's kind of like the digital equivalent of who watches the watchman sort of thing. So the very system is meant to ensure some measure of reliability become the problem.  the kind of like where this goes to

08:16
Like I hear what you're saying, but like I want to fight you on every point.  If you have like a network management control platform, right? Like if you buy into like an automation thing, one of the value props is, listen, if this control point fails, your network will still operate. You just can't make changes.  The system that monitors health, if it fails, should just allow the system to continue to operate normally, but you can't make changes. Or maybe you don't get millisecond updates on the health, not melt the entire planet. You know what I mean? Like expand design.

08:45
Technically it was DNS was the actual  root cause, but ah so where you're going with this and like where I agree with you. So at the end of the day, forget AWS for a second and let's talk about the customer. If I'm a customer that's impacted, like what is the real world impact and what frustrates me about this is someone who like say that I had something built in US East one.  And this is where it gets tricky, but really I guess just frustrates me about these types of outages.

09:15
First of all is we've sort of established as a blast radius. So whenever, whenever us East one has issues, so any other AWS region can kind of fail and everything just kind of goes on as normal, like, okay, you had an outage, but if you were multi-region, you're okay. And that, you know, maybe it like highlights gaps in your architecture, blah, blah, blah, blah, blah. But when us East one has issues, certain things happen that don't make any sense.

09:43
Take Route 53. So Route 53 is their DNS service, right? So Route 53 is a service that is global in scope. As in, when you go in and you start configuring stuff, you're not saying, I want it to be in US East 1, or I want it to be in like US West or something. It is a global resource. So it isn't scoped at the regional level, meaning that if US East 1 goes down, Route 53 should maintain functionality the whole way through, right?

10:11
And I want to preface that by saying, mean, you can create regional DNS entries, obviously, but  the service itself is global. What that means is if US East one settles in for a nice siesta and decides to, you know, take a crap and die like this  other week,  um, it can potentially cause impact to a global service that serves all regions potentially. And we've seen this in the past, like services and other regions.

10:40
can actually fail if they depend  on control plane operations that are routed through US East one. Those services. seems like the design, right? The core services all seem to live in US East one. It's like the root of AWS's existence there. And there's just a lot of, I call it  the legacy technical debt. Yeah. You know, they're running into things that enterprises have been dealing with for a long time, but

11:07
I think one of the things here that you have to keep in mind, and I'm not defending AWS here, but at the end of the day, centralization can create systemic risk to some degree, no matter how good you put together the system, because these distributed systems are so complicated. Yeah, say what you're gonna say and then I'll continue ranting. No, I'm with you 100%. And we do have other topics for the listeners. I realized in the intro, I didn't say we have two other cool things you're gonna talk about. So I totally blew the intro, but let's pivot to...

11:36
Let's say we were  on the team that  wanted to try to avoid this happening in the future. Like we're engineers. Things happen. The growth was crazy. The design is what it is.  We were in this situation. I mean, this, I think these lessons can be applied to other contexts. So you and I are running AWS, US East one, everything lives there. It's not a great design. How can we fix this? Like, can they build a US East two?

12:04
and split services across like a, I'm thinking about building data centers, right? Usually build them at least in pairs, if not three, and then, you know, the DCI is between them so that if services go down and while they're like, you should be able to route around failure and you shouldn't have a global blast radius.  And I wonder, and I'm not a design guru, but I'm guessing. Yeah. And most of the time that's the way it works.  So like usually either it's kind of like network engineering one-on-one, you're either going to have an active standby design or DR, which is much

12:33
much, much cheaper or else you're going to have like a Netflix model where they're active, active all over the entire planet. So if you have it, mean, that would be the best case scenario if you had true. And if you go and you look up, there's a lot of, I don't know if they call them validated designs and the, and the AWS documentation and even in like some third party stuff, like vendors, they validated designs, right? Like if you're going to build a clove fabric, do this and right. Yeah. So that, I mean, the best way to get around this and have the highest level of resiliency is active, active across.

13:02
multiple regions getting to that, but that's extremely expensive. that is as a customer, that's a customer choice, right? Running active active. Yes. So here's here  and we're gonna we're gonna pivot soon to the next awesome topic. But I guess the problem I have with all of that  is we're still talking about the customer making decisions  like so yes, your  proposal of paying more for active active in two different regions would be a great solution. If it weren't for the fact

13:31
that when us East one goes down, the entire internet melts. So it doesn't matter if you have quadruple active across four zones all over the world. I mean, your servers should be, your services should be isolated though, depending on the design and everything. Like if you were deployed out West as well, then technically your service, I mean, there are, there's been cases where back to like what I was saying, I mean, I think maybe the route 53 was a bad example, but there's other

13:58
There's stuff you can search online where that's happened, where there's been some thing that a lot of things depended on and you have global services outages, but those aren't as common to be fair. em And I think the lesson here, and it's kind of funny because like thinking back to my- Teach us something. Is it our fault as the customer because we're not designing our systems properly or is it a shared  model between us maybe trying to save money, putting everything in one region like US East one, and then also maybe

14:28
AWS  looking a little deeper and harder at a little more, you know, resiliency or  I would think they would want to do something like this isn't a great track, right? See, the problem is they have such a captive market. You can't just leave, right? Like if you, if all your stuff's built there,  you can't just leave. they're, once you have the globe in your hands, I don't know if they're like,  Oh, we've had a redesign all this. So like, you know what? Three and five years, whatever. Everybody's fine. It's

14:54
Call us a deal of business, right? I don't know how they, I don't know what their culture is there. be flooded with memories here. So like back when I was actually building this on the customer side, like a lot of this stuff, this was a while back when I was on the customer side. at that time, I mean, AWS knows all this. There's the kicker. They've been trying to get people to diversify and get out of US East one for years back when I was on the customer side. Okay. And I mean,

15:20
Cause I mean, honestly, customers, know how it is working on the customer side, depending on the vertical or the industry and  just. how about AWS? That's the default zone somewhere else for people who don't know any better. Right. Like could that help steer people away from  East one? I don't know. Yeah. But mean, even if you take and you don't use the default stuff.

15:39
and you actually know what you're doing, you can still have problems when USC swan goes down. That's kind of the thing that you're just much lessened if you design because you failure is always going to happen no matter what they do or what the customers do. At some point, something's going to fail. I think the lesson isn't to avoid AWS or to completely avoid USC swan. It's that you've got to build resiliency and it's got to be a continuous engineering investment, not a procurement decision. So you don't buy resiliency, right?

16:09
We can agree on that. You build it  and after you build it, you maintain it. So at the end of the day, AWS has a system and design practices that honestly, a lot of enterprises are not staffed with the right talent or the right dollars to actually build this big active, active thing. But they also face a problem where they're not staffed they don't have the budget to build and manage their own data centers. So where does that leave the customer? They have to do the best.

16:38
with the dollars that they have at the end of the day. Because again, if you have something running in one region and you're doing it active-active, depending on the,  depending on quite a few things, I mean, you can just double your cloud bill. And if, you want to go three regions active-active, you're going to triple your cloud bill. And cloud bill is already expensive when it was just one region. So how do you do that? I don't have a good answer for that, to be honest. No,  I don't think we're going to, I don't think we're going to get an answer. just...

17:06
I thought it'd an interesting conversation to have as someone who isn't cloud native, knows all the things and I've been responsible for very large production networks  and melting those was bad enough.  And I'm just amazed.  I  think I've put people and now companies on pedestals in my career. And I figure that if you have all the market share in your, you know, vertical in your area  and all the resources and all the customers,  I assume.

17:35
infallibility. I just looked it up. I think in general, they don't post how many nines they provide, but it's about four nines across the board, which is about 53 minutes of downtime a year. Like, I don't know if that's true or not. But  I'm guessing let  let's end on this note.  customers need to know the limitations of the public cloud and the designs and try to design around it. I mean, I think it's a shared fate model. I'm not pointing at them  at the company saying, Oh, I don't have workloads there. So I actually don't care.  I don't have a personal interest in it. But

18:05
As a network engineer who could be impacted by this stuff, we had public cloud when I was managing production. So  more education is good. No, the limitations. have one last thing that's a mind vendor. So with all these resources, all the different things you can build in cloud have different SLA. So like I can't, I probably wasn't the first one to come up with this, but we had a, when I was building a lot of this stuff out in a multi-region capacity, we built this compound compound SLA calculator, because if you think about it,

18:35
Direct Connect has an SLA, this service has an SLA, that service has an SLA, and they're all different  a lot of times. So you don't have just, okay, I have one SLA for all of cloud. You don't have that.  When you're building a distributed application and you have different types of resources and services that you're using and they all have different SLAs, how do you really calculate the true SLA? That is easier said than done. I will just leave that where it's at.  I remembered my...

19:04
I remember my question is cloud uptime better than on-prem uptime just in general terms because if it is, hey, listen, I apologize to the good folks at AWS. You're doing better than we can on-prem and it is what it is. I'd say if you surveyed fortune 500, if you looked at the things that they have exclusively in cloud versus the things that they have either exclusively on-prem or with dependencies on-prem, I would say that the cloud is probably more,  um, has higher uptime because

19:34
Let's face it. mean, I can going back to my data center days. I don't even want to tell some of the stories like, time, limited resources, people leaving for other work, you having like, you know, 70 hour, 80 hour work weeks, sleeping in data centers. Yeah. Those are the people that you. Yeah. It's tough. right. So, um, I think we beat that up to death and, and, I hope that that was fun. Well,

20:00
It's not how I really wanted it to go.  I feel like I got a little too, uh you know, confrontational with the good folks over there. just, in trying to understand it and  pointing fingers, kind of, as we move along, I'm thinking of all the mistakes I made and all the things. And  really it's like a cognitive bias. Like they can do no wrong because they have so much market share and they are so big. But man,  size brings with it complexity. I'm just thinking of my own, you know, environments that I've managed and...

20:30
I can't imagine the scale and the complexity that they're dealing with. um I assume that they have it all worked out, but like simple is hard, just across the board on anything, right? Simple is hard  and  it's probably not simple  managing their systems  because of the sheer scale. Like, I don't think anything can get that big. Think of a startup, you've worked at startups, there's 15 obvious and how quick you can move and how great everything is.  And then you go to a  place with 40,000 employees and you're like,

21:00
It takes six months to do what? You know what mean? Like, the size  creates complexity. so, okay, uh we're going to move on to the next topic. So public speaking  as a way to elevate your career, right? um William has been all over the world in his private jet, speaking to all the minions and people about the things. I mean, I've been, I follow your stuff and I see what you're doing. I've seen your Autocon talks and I...

21:29
I love all the stuff you do. I, I happen to have a couple things coming up personally, and I know that you're a Mr. Public Speaker. So I thought it might be a quick fun discussion of if you're technical, if you're in engineering adjacent areas, and you have opportunities to, we've been telling people forever, like, create content, communicate, show your soft skills. It's, it's, it's an easy thing. It's low hanging fruit, right? If you can communicate and you're technical. Oh my god, that's amazing. So

21:59
uh Speaking, guess at conferences or places  seems to be a great way to do that. We got NFD coming up in Autocon and I'm speaking at both and I'm super pumped.  I'm also  like, oh my God, what have I done? This is  like a lot of planning and like, I'm confident that it's going to go great, but I'm in the weeds of doing the things and like, you know, forming narratives and creating decks. It's just there's a lot of like, oh my God.

22:27
And there's never enough time, right? So I guess what I wanted to ask you is like some of your experiences speaking at events,  know, wins, flops,  lessons, like this isn't about me, but I think in you sharing with me some best practices of presenting at these things, you know, the rest of the audience can maybe learn it as well. Yeah. I mean, especially if you're coming from an engineering background.  so, let me, let me just move back a little bit because this almost gets a little philosophical, even though you kind of don't.

22:57
usually want to take it there, but I've I love philosophical. I a I had a grandpa. Yeah. Yeah, it was my grandpa. So he used to tell me like all the time. And this kind of with me. Young, impressionable kid out there, you know, playing with sticks. He would always say this even long before I could understand any of it. But it's like, know, you can either move forward or you can sit dormant and pretty much, you know, stationary and be a loser.

23:24
or you can move backwards and be kind of like an ultra loser. And you want to win, He had this, he'd say like different variations of this. And it always stuck with me because I think we do get in a, hey, we're network engineers, we do our network engineering thing. And we hit a uh of a blocker with growth. Well, yeah, you got to learn how to talk to the business. You have to learn how to do a few more things. And  it's hard.

23:52
But let me, let me ask you something just yes or no, Andy, do you like winning? Do you like winning? I love winning. There you go. So are, are Superbowl and Stanley Cup contenders like known for sitting stationary or moving backwards with their progress? Nah. So public speaking is just one area where, you know, just like the Stanley Cup or

24:17
Super Bowl contenders are known for working hard. They're grinding, they're learning, they're improving and uh mastering the art of the hustle. think those are kind of a combination of things. And for me over the years, what it's been  is doing things that I was kind of uncomfortable with, but I saw value in. And that's really hard to get going at first, but

24:42
thing is once you get going, it's kind of like going to the gym. Like you go and then you're so sore for a day. Like you do legs for the first time in 10 years and you just, you know, you can't get up off the toilet. It's awful. And this is why I love you, William. Like we, we share a brain. It's so  surreal to me. I have, I have a blog that I drafted that I haven't published yet because I just passed 500 miles running this year.

25:08
And the whole thing is do hard things and everything you're talking about, right? And the more,  I'll, let's get back to you in a second, but I had a mentor earlier in my life, similar to your grandpa. The way he framed it to me was, Andy, do all the things you don't want to do and your life will get better. And it was such simple advice,  but that was 19 years ago, Bob Grow.  And I have been doing all the things I don't want to do, not every day, but most days. This morning,

25:37
I didn't sleep enough. was tired. I was sore.  My alarm went off at 6 a.m. I didn't want to go run. I did what I didn't want to do and I had a much better day as a result. And what I find, and then we'll get back to speaking, but what I find is the more you do the things you don't want to do or do hard things, if I can run 500 miles this year and I haven't run, you know, in a decade, well then if something at work comes up that's difficult.

26:04
Well, I do hard things. It's what I do. It's like this isn't as hard as that, right? So then you build an inertia confidence, which is hard to fake. so I love your framing that speaking is another hard thing to do. And it's scary. Like I like attention. I like a microphone, but I'm going to be  intimidated. I think looking at six to 800 people at Autocon for, you know, speaking to them next month, that's kind of intense. Yeah, I actually had, so I had a secret web before I went on this whole speaking.

26:34
And by the way, that's an awesome story. love the waking up and running because physically doing things that are uncomfortable. Like we sit way too much.  I'll just throw that out there. If you want to be completely honest with you way too much, I only do it. I started doing it for my mental health when I was out of work  and I continue to do it for my cognitive function. Like my brain, I'm much more sharp when I exercise in the morning. So this isn't like, you know,

27:01
It's hard to say like,  ran and I do hard things and not sound like, all right, Tony Robbins, I take it easy. Like, but it's, it's not, it's not because I am so like whatever. It's just that my brain works better. My mood is better. My cognition is I'm sharper. I'm more productive. So I'm just trying, like you said, I want to get better. I want to win. And I win on the day. I win more on the days that I have physical activity early on. So it's not a virtue is what I'm trying to say. It's just, I'm going to do something hard.

27:29
And the people that do hard things, win, William, right? Like it's a thing. Yeah. And I'm not saying you have to do these things. I'm just saying what has worked for me. Full stop. So everybody has maybe different recipes of success. No, I'm saying you have to do it. I'm going on record.  Cut the whining and nobody cares how you feel. Go do it.  So back to speaking. When I go to like these events over the years, like I don't talk at these events because I'm like the world's leading expert at a thing. I'm kind of speaking because I've

27:58
consistently want to show up, know, share what I've learned and build. I think the really important thing is like building relationships through all the previous talks that I've given. The speaking that I've done  created this expertise loop, not the other way around. So like I've built a network of people and I love the ones that are in person too. I love doing it in person. em But one thing I wanted to say is I kind of

28:28
Before I moved to the vendor side, I worked for a series of pretty big companies and I happened to just be  a

28:39
Not,  I don't know how to say this. I'm not trying to sound arrogant or anything, but I don't really get nervous with things as much  with people. Anyway, I'm pretty comfortable talking to people. And I had a series of roles where I had bosses that were like directors or VPs and they were like so nervous to go in and talk to the CIO or CTO about a thing. And I remember one time at a company where I was in there and my boss, like he just

29:09
Couldn't get the words out of his mouth. The CIO was  livid based on something that had happened. He was just. Grill. I'm like, Hey, I was like, this is what the problem is. And I just totally broke it down in like a few sentences. And I was like, this is it. And you know, he went on the, the CIO went on this rant about how we should be able to predict and we should never have an outage or something. And I'm like, well, Hey, can you predict the weather? I hear out, let me hear that, you know, this is, these are the facts and this is technology. So was kind of one of those things.

29:38
My boss's face like turned red and you know, it was one of those, but I mean, that's just kind of the way, Hey, it needs to be said, just say it. You know, if you're going to fire me, then fine, I'll go find another job, but I'm here to do my best to build technology and give you the things you need to hear, not the things you want to hear. I was kind of conditioned. you remember your first speaking engagement? Like why, why did you start? So I, maybe not why, but like, what was your first opportunity? So I spoke at a.

30:06
a AnsibleFests when I was on the enterprise side and then a few smaller like local events. And I never even did those because I wanted to. I got asked to. That was my next question. Yeah, okay. And then I found that I really liked it. It was kind of fun. And that's when I started. I mean, I've submitted a few call for papers like to Autocon. Like I've submitted papers and a few other events. Like I've done a lot of AWS events, summits and stuff.

30:35
And there's, okay, so the things, the takeaways that I would say first of all, to stay away from.  And this is one time where I was very nervous. As I was at an AWS summit, the crowd was huge, like a lot of people.  And I was doing live coding and live infrastructure deployment from my laptop.  And the two hours leading up to when I was set to go up, the internet was just like tanked.

31:05
tried my phone hotspot, tried my buddy's phone hotspot, like on a different provider, I couldn't do what I had built. It was,  and I started getting very, that was like the first time I've ever been nervous before, like a talk and thank goodness, cause I didn't have anything else. And that was the reason is like, I didn't really have anything else to talk about. It was live. had a few, like, this is what we're building. And I was going to go through and build it, screen share. And luckily for me that time, for some reason,

31:36
Internet started working flawlessly, like right before I had to go up. So I dodged, I dodged like utter humiliation there, but that told me that, hey, these events are so big. Everybody's on the internet. There's so many people there. Like, that's just a risk I don't want to take again. If it's a smaller, like low key thing, then maybe for the big things, sheesh, like avoid that, you know, like the plague and

32:06
The lessons that I've learned that have really served me well that I take with me to everything I do  is your audience doesn't need to know and understand everything you know and understand on a topic. Like your goal should be getting them to leave with like one or two clear takeaways. Like I've worked with product teams, Andy, uh before that seemed to want to present like the whole lexicon of their product, the origins, the future.

32:36
on and on and on and on. And every time this happens, an angel loses its wings. And everyone in the audience is thinking about dinner, even though they just had lunch. It's just I've I've been a good NFTs and I've been a bad NFTs and the bad NFTs are what you've just described. They give you the whole story. They're going to get through every deck and they think that I want to hear about every customer that they had in the beginning when they're four years in and doing like really cool stuff like it's it's.

33:04
For me to get people to care and this is what I wanted to ask you. Do you lean on? I mean a more on story than on technical prowess because I think that's how you get people hooked emotionally. You get them engaged mentally and they'll walk away to your point. They'll walk away with maybe one or two takeaways that they'll have there. This guy Matthew Dix a book I've been studying about storytelling for a couple years. He says no one has ever left.

33:34
a conference  and,  you know, talked about the PowerPoint, you know, the deck that they that they listened to for 45 minutes. Right. And he tells all these stories about him and his wife would leave, you know, conferences they were very interested in on the way home. Like, so what do you think? And what are you? You know, the only things they remembered were the people that use stories because people that went up and spouted facts or stories like, you know, the history of the company that nobody but them cares about. You know, 45 minutes later, you don't even know what they said.

34:02
So do you use story to kind of connect with your audience? I do. So you frame that so well. And I'll say that storytelling  is going to resonate much more than technical bullet points because the human brain is wired for narrative, not data dumps.  Like you said, stories create emotional connections, and emotional connections create new memories.  storytelling is huge.  So my last AutoCon...

34:30
I think it was AutoCon one or two, I can't remember, but  it was about the business. And I had this story that I'd given like ages ago. It actually got buy-in for like a multimillion dollar project using like variations of this story. But I was basically comparing like a startup to an enterprise, you know, and how startups are like riding a bike and enterprises are like driving a train.

34:52
Well, how long and how many people and how much process does it take to stop a train and get it turned around versus riding a bike in your neighborhood and just turning around. And that really is like the inertia factor there. stories in people, like after, after that conference, I had like, I don't want to make the number two, but I had at least 10 people maybe reach out to me on like LinkedIn saying that that story like resonated with them so much. And I was like, okay, that's, that's a good story. And that's another thing, the Q and a session.

35:22
The Q &A at the end of your talks, if you have time to take Q &A, that is so valuable because it really tells you what the audience in real time took from what you presented, like where their head space is and why they're asking certain questions. I love Q &A. And a lot of times, some of the questions aren't going to be maybe things you can answer. They might be deeper em or...

35:47
something, but I mean, most of the time, like all the questions that I've gotten at these types of events have been very good questions. And I've taken that as feedback as to how to do future stuff. Oh, and one more thing, truly understand what you're presenting. Not like in a deep, like, okay, I'm going down to the binary maybe on some things, but understand, like make sure you understand what it is that you're talking about. Don't memorize everything. That'll get you in a lot of trouble memorizing the whole kit and caboodle, you know?

36:17
Because you're going to get lost at some point. If you get nervous a little bit by nature and you're just memorizing stuff, you're going to be in trouble. Take time to understand the content. you have any speaking engagements coming up that we should be excited about and looking for? So I have two that are maybe,  one of them  is  depending on if I have to travel at the time or not. So, um, I can't say what that is yet because it's not publicly announced yet, but yeah.

36:44
The other one is like a public workshop type thing that I think is going to be pretty cool that I'm going to be leading on  actually MCP and AI. So hopefully that one happens. Nice segue.  You're doing my job for me. So right before we get into MCP, which is our last topic, um as you were speaking earlier, I just, so I kind of realized my arc of

37:10
So how do you start right? You already talked about the value of it and do hard things and it'll make you,  you know, better and elevate your career. I'm, I'm, I'm looking at, so speaking in NFD and Autocon will be the biggest audiences I've ever spoken in front of. Autocon is huge. It's, it's gigantic and everybody's like right there and you're on a platform and they're all staring up at you. I'm going to be out there wearing a shirt with your face on it and I'm going to be like making funny faces. So don't laugh. God, that's amazing.

37:38
I'm gonna wear a shirt with your face on it. Well, dude, that would be amazing if we walked around on a car with a shirt with each other's face on it, dude. All right, it just had if it happens that the idea started here. But what I wrote down here was, I started a blog forever ago when I was studying networking for the first time, you know, back in the day, and then out of the blog came a YouTube channel and like, you know what, let me try to do some stuff. And then from the YouTube channel, the podcast happened. And then

38:07
uh... you and i were at uh... not a p a not i think it was last year year-and-a-half ago whatever was but that was the first i guess room uh... that i was speaking to like that  uh... that story so your point people came up to me afterward and hit me up after the thing telling them that what i said resonated with them because i've been very vulnerable and open about my experience in my career some choices i made and how the you know probably with the smartest decision so you know don't do what i did learn from my mistakes but

38:36
The PA Nug one, you know, the next thing that happens like NFD, I got invited to NFD and I covered a couple of them. Well, the second NFD I went to created an opportunity to where I'm at now, working in Nokia. And now at, you know, my employer, I'm now representing them at, you know, NFD and Autocon. So  for someone listening that's, you know, like new, like how do you start? It's always the same advice we've always had, like start creating content, start communicating, but...

39:06
from a blog 15, 16 years ago, now I'm speaking in front of these  very large audiences. And I'm thrilled and I'm honored and I'm really excited to  deliver what I wanna deliver. And I can't, if you would have told me 20 years ago, sitting in my cable guy truck, that I'd be speaking to a gigantic room talking about oh my story or  some cool stuff we're releasing at work.

39:29
Thank you. Dude, you're crazy. Like, what are you talking about? You know, I'm a cable guy. Stop. Don't be afraid to reach out and talk to people either. So I'm going to tell a quick story. So I mean, this just goes to show you. every once in while, kind of have like a mentor or I'm a mentor to someone. I try to take it. I have like limited time these days, but I used to have like two people at a time. Maybe I'd mentor, but I was trying to help someone get a job in tech recently. That was a younger person. I'm going to leave it at that. And this kid's brilliant.

39:59
Like he, he's brilliant. He's versatile. Like he's just really smart. I'd say he almost has like a borderline photographic memory. He just remembers everything. And when I say to reach out to people for help, just listen to this story and imagine how crazy it is and just think that I will talk to anybody. But our biggest hurdle, and I almost said, Hey, we've got to cut ties  is he's going into these interviews and

40:30
Finally, he's like telling me that they just didn't like the way I looked and blah, blah, blah, blah, blah. And I'm like, well, was your hair on fire? Like what's going on? And he's like, uh, like what are you wearing? And he's like, Oh, I had a t-shirt on and I had just some, you know, Crocs in my, my sweatpants. I'm like, Whoa, this is a corporate company. Like in the fortune 200 buddy, like you've got to like wear khakis in a button up or something. Like you can't roll up in like board shorts and a tank top.

40:57
You know, this is your interview. That's your first impression. And he's like talking to me and he's like, we're  in 2025, bro.  And what? I know what year it is, bro. Like,  do you want to know why you're not getting these jobs or not?  You know, so we had this kind of like back and forth and I was giving him some hard knock advice. Well, we had a pause and last week was the first time I talked to him in a few months. And he's like, I guess the first job that he went into and interviewed.

41:27
with a suit that he got it like a, can't remember, it didn't fit right or whatever, but he didn't care. But he got the suit on, he got the job. The first interview he went on.  It doesn't mean you gotta wear a suit forever, but these are things that, I always overdress for every interview. I've had interviewers like kind of nudge, make fun of me, like rib me like, dude, you're in a suit. Like I was in a suit interviewing at like Fiserv, which was a very like.

41:54
They were very chill people. It very blue collar. They were all friends for like 20 years. And I come walking in in a suit, you're like, yo, dude, like, take it easy, bro. You know, like, I think my boss was in shorts and like same thing. Like they were in Crocs and board shorts. But I'm, I show up like ready for, you know, I'm going to make an impression. They hired me. I don't think it's because of the suit, but it sure as hell doesn't hurt. Right? All right. Last topic, dude. MCP. There you go. What is MCP? I see. So AI is everywhere.

42:24
I love it, I use it every day. We're doing AI stuff at work, it's great. Like I'm in, I'm not whining and yelling about AI like I was about automation. I see the value, it's awesome. I don't understand. So MCP came on my radar recently. You corrected me earlier, I even got the acronym wrong. It's model context protocol, I guess. So I'm gonna shut up and hand this over to you so you can kind of teach me slash us what the hell MCP is, but.

42:50
I don't understand why we need it because you and I were talking before the recording and when I learn about MCP, it seems like a protocol that lets  AI  or LLM systems talk to each other. And I understand that to be API calls, which we already have. So  what is MCP  and why do we need it if all it is is glorified API calls between AI systems?

43:20
Let me start from  the top. So that good question. I actually, when I was first getting into like, think like last December or January, when I was trying to figure it out a little bit, that was one of the things that I was thinking of is like, isn't this just API shenanigans? But we also have to do this in like 15 minutes.  Yeah, so I can go quick. I we could spend an hour, but  you don't have to teach us, teach us  just to let you off the hook.

43:47
So it's all it is like if you go to like their website, it'll say that this is a standardized communication protocol. So like if you go to the right. Yeah. But if you go to their GitHub, like first of all, I think this is important because um you'll find that it's open source. You know, I believe it uses the famously permissive yada yada yada open MIT license, which is very good.  Now, what is the goal of MCP? Why don't we start there? So the outcome and the goal that you want is to provide

44:16
a standards-based way to integrate your LLM applications and external data sources and tools. So not like Claude talking to Chad GPT, but if you think about the breadth of what an LLM can do and you think about the problem of like maybe a large enterprise that has  data in certain places and different things, well, how do you safely

44:45
connect these things. So let me talk in backwards riddles and analogies for a second. So  at the end of the day, it isn't too far removed from what BGP does. BGP running on a router, except we aren't routing packets at this point, we're running context. Because LLMs need context to make good, accurate decisions, to get more towards like deterministic outcomes.  So MCP is BGP-ish.

45:14
but instead of sharing prefixes,  we're sharing context. I think that's what you said, right? I wanna, so. Exactly. What does that mean? Like to me, context means  a series of questions or prompts  that you don't have to go back and repeat yourself because the context is retained of the conversation. Is that what you mean? Is context in this  regard a...

45:40
series of prompts that you've given that build some type of logic? Like what is context, model context protocol? What do you mean? It's context that you don't have to provide.  So say that I build an MCP server and in that MCP server, the Python code, like if I'm building it in like fast MCP, it might not look, it might not look too far different than  what an, you know, code for an API might look like at the end of the day. m But

46:10
In that code, like the way that the code is documented, like if you look at the doc strings, the descriptions, how the calls are supposed to work, all these things that are predicated on that endpoint, you all the things you can do against that endpoint, it automatically brings in a lot of that context by default. So it knows like, Hey, I know how to work with a net box, but I also know how to work with an potential. And I also know how to work with an info, you know, whoever has an MCP server. So I have all this data.

46:40
that I don't have to provide and think of my thing, my context to provide. They automatically can fit better together. But that's just part of it. So. Can I ask one more question? Yeah, fire away. So I  went to model context protocol.io  and you know, what can it enable agents can access things. And so is this  is MCP  part of the agentic AI boom or, you know, thing that like  it's,

47:10
Does agentic AI exist because of MCP or are they just kind of like both doing the same? Like it didn't create agentic AI is what I'm getting at or did it? Cause it sounds like it's just a protocol that allows these systems to talk to each other, which isn't really sending agents out to do work, right? Or is it? This paves the way for easier agentic AI, but like as an architecture to kind of go back, just so you kind of know the components of how this is sort of working. So with

47:39
the whole MCP thing em is a protocol. It is client server. So it's a client server architecture that's built a top like JSON, JSON RPC 2.0, which is just another way to say that this JSON RPC serves as the communications layer for like all the fancy interactions it does. em So as an architecture, has three  main sort of instruments that work in concert.

48:07
one with another. So you have like hosts. Sorry, I'm getting my acronyms and stuff mish-mashed in my head. So you have hosts, which might be comparable to like a network management workstation. And then you have client, which are kind of like  your routing protocol daemon. And then you have the MCP servers, which could be compared very loosely to like a route reflector that might

48:36
be exposing specific network segments. So like in the context of  moving from network comparison to AI, the host would be your  user facing applications  like VS Code or maybe Cloud Desktop. And  on these hosts,  the MCP clients manage the actual protocol communication with the external systems.

49:04
And then the MCP servers act as the, or what did I say? Route reflector-ish type thing that exposes the capabilities from like database stuff to APIs to other things. And so you mentioned APIs and you're, you're, you were spot on with why that's confusing. So, and this is another reason that makes MCP a little bit different. It actually inverts kind of the traditional client server relationships. So most APIs out there are going to be.

49:35
um request response. But  MCP adds a second channel. So servers can request AI capabilities while clients maintain the control. So this is kind of where like going into the agentic AI world, this kind of lends itself to like multi-step reasoning type workflows.  Like the AI making a decision to say, eh

50:03
I need more data or this or that or something else like mid analysis or mid workflow. And moreover, so instead of your, your clients, like back to the API thing, always having to initiate requests, like MCP servers can request AI model completions while clients can like maintain this control stuff um over the model selection and like privacy things. And did you ask or did somebody else ask this today? What is the difference between

50:31
MCP and API Gateway. Is that you? I would like to say it's me because it sounds smart, but I don't know what API Gateway is. So I'm gonna, I'm not gonna take credit for that one. Although I wish, I wish I had. So I'm already lost and it's not your fault. But this is the same. So this feels very familiar to me in the sense that when someone starts talking about coding,  I,  and you know, whatever that.

50:57
thing that happens to me is, which is why I'm fighting it and forcing myself to learn Python. Because if you were to sit here and talk Python to me, I would also have this like, he said, he said seven words that I don't understand the meaning of. And now he just said three more, I don't want to stop them.  And it's no fault of your own. Like it was a very good analogy, but  I don't  let me ask you a question. So when I'm working with chat GPT, I'm just going to use my context, like my experience,  I asked it some questions.

51:26
I upload some data and it uses that data and then whatever the hell magic it does to like do the thing. um Does MCP allow, like so instead of me having to keep giving it information, it seems to me like MCP can go to like databases and places and like get info without me having to like continually upload as we go. does it give it access to systems  and sources of information that it doesn't have access to?

51:55
Maybe I should have said, when we said the 15 minutes, I was jamming a bunch of stuff in there way too could be a total episode. No, you're absolutely right though. So think of it this way. So a better way to look at this would be to examine what this AI LLM world looked like before MCP. So basically what you had was like... do we need it, Exactly. So basically what you had is like vendors...

52:22
Um, or anybody like making tools would basically have to make their own proprietary integration to say that this AI tool could talk to some data or to some other things. And it was all proprietary. would almost be like pre-MCP world. It would be like every router manufacturer making their own routing protocol. So like the heck with BGP.

52:48
We have this one and that one and that one. And then you have like 20 or 30 routing protocols and everybody's crying. Well, that's kind of what MCP does one way. So it makes the integration layer much easier. Like it's the same streamlined integration layer across  all the LLM providers and it's received mass adoption. So open AI is on board.  Um, you know, Google Geminis on like everybody's sort of standardized around this as a protocol because it needed to happen.

53:17
Well, that's why we're talking about it. It's the thing. But no matter how much time I spend with it, I can't seem to understand it.  And it's coming. So part of what I've been trying to do on the show is like, listen, there's this stuff happening, and it's coming. It's here, like you need to learn this. And but then I try to look at MCP and I'm like, what the hell? Like, what is this doing? So what what couldn't chat GPT do before MCP? Like, I'm still trying to connect the dots. Like, what couldn't it do that it can now do?

53:46
Without getting to imagine a world where you're sitting in an enterprise and you have your chat GPT window open and you're just pasting big dumps of data in there from your private environment, your enterprise environment. So your crown jewels, your private data, your secrets, all of those things that you want to be private, that you want to be separate from the actual LLM. want to maintain control over all the important things.

54:15
This couldn't happen very easily without custom, very, very custom integrations prior to MCP. I didn't think you keep the stuff separate or private that you upload, which is why companies have these policies around like don't use or don't put anything internal. Like I thought once you uploaded it,  it's in the model. you saying MCP gets us around that? But it's, yeah, it's just.

54:39
And this is where like we would have to have like, think it would be a good idea to actually have a  full episode on this. So  basically, I mean, the thing to think about is prior to MCP, everything was a very custom ad hoc. There was no standardization for integration, not just with the, know, plugging in the LLMs, but cross tool functionality. now like even me at my desk here, like if I think of like process automation,

55:06
Like Zapier has an MCP server. So all the things that Zapier has access to, I can pull in and use in a larger workflow with like an MCP server from  Netbox or an MCP server from, you know, whatever other vendors that have one. And then the LLM is working for me across all these things in a secure way. But I can do that without any custom, like customizations on my end.

55:33
Netbox or an MCP server from, you know, whatever other vendors that have one. And then the LLM is working for me across all these things in a secure way. But I can do that without any custom, like customizations on my end. Can I get the same work done without an MCP? You could, but it would be a lot of custom, kind of like, so if you think about, think about this whenever back in the day when  network vendors, like you wanted a

56:03
some integration with this big box vendor and then this other platform. So you'd have to go on their feature roadmap. You'd have to go through this really long process, probably over a year, even if they got it done, just to make two, API endpoints on the backend, talk to each other. It was completely out of your control. You're  just relying on them and it took forever. So with MCP, as long as they have MCP as an interaction surface, you could do that.

56:35
in an hour, maybe less.  It's much easier. I mean, the potential is there to do it. I'm not saying that we're there yet because we're still early days, but there is that potential.  So this is this is for comedy sake, right? Because I'm going to I'm going to read the definition off their site. And when we're done reading this two sentences,  I'm going to tell you, I still don't understand.

57:00
Using MCP, AI applications like Cloud or ChatGPT can connect to data sources, for example, local files, databases, tools like search engines, calculators, and workflows like specialized prompts, enabling them to access key information and perform tasks. Now, I know what the words mean,  and  I could read that again, but this is the problem with some of this stuff for me. And maybe I'm not that smart, but I read it.

57:29
and I listen to you and at the end of it I'm like, I don't know why. Like does everybody else understand this but me or is this kind of weird and complex? Like do you have to be super coder smart guy like you and John Capo to like get this? Like is this intuitive? And I'm just not connecting the dots yet. Cause you're also a coder, right? Like I'm- Yeah, not as much anymore as I'd want to, but I think- Do you think the average trad net ops, if I can quote Mr. Robot again.

57:58
The trad net ops person who's still copying and pasting from an op-ed plus plus and 70 maintenance windows a week. Like, do you think MCP makes sense to them? Is this intuitive? Is this like, oh, wow, this is amazing. We should all do this because I liked your analogy of like, I mean, it will eventually. I liked your analogy about the routing protocol. Like that kind of landed with me. You wouldn't want to create new routing protocols over and over. Like, so we have routing protocols that are standard so that different vendor boxes can talk to each other.

58:27
I think where you're going with that is with MCP different what? LLMs can talk to each other or LLMs can talk to other resources that they formerly couldn't. The way that you expose tools and connect LLMs to the, yeah. Exposed tools. Can you give me an example of a tool? Like what are you talking about? So a tool would be like, so like say that, you know, I work for a potential, we have

58:51
You know, back to you, you know, trying to I knew you were going to go to your employer. I was going to say, can you tell me a tool that isn't at your employer? But here we are. So  it's just an easy one. So say we have a tool that like does or an API endpoint that launches a workflow. So like you go into our platform and you click a button that says, hey, go. And when you click go step, a step, B and step C happen inside the UI, because that's what we do. We do automation, right? Yeah. So that's in the UI. Well, behind every

59:20
modern day platform behind the UI and all the fancy stuff, you have backend services and you have APIs. And really what's happening is this front end is triggering something on backend and some maybe endpoint is getting triggered to do this or that. So you have all these things happening on the backend. So when I, when I reference tools, what that means is like say that we had a MCP server and as part of that MCP server, we had the ability to launch that workflow. Right.

59:50
What launched it before the MCP server? Well, it does. mean, you could launch it in many ways. could do the UI then the launches, right? Yeah. So why do I need an MCP server to launch it? Because you want to have this nice world where you can say, I want to use itential with this other vendor and with this other vendor. And I want to actually have an LLM at my disposal to be intelligent enough to do things. And I have to bring in the right context.

01:00:18
To do things. Are we talking about autonomous  actions, autonomous things? Like when you say to do things  without me having to... Go back to the network. Let's go back to network ops. So say that instead of going into, like say you're trying to triage a problem, and this is hypothetical, but say you're trying to triage a problem and you have to log into like five routers and look at a set of things. Or say you just want to log into 15 or 20 routers, get a set of things, format it in a report, send it in an email.

01:00:48
with like your brand guidelines so it looks right for like a VP or a director. And you have all these different tools you need to touch. need to say service now too. Say you need to update a ticket.  Well with MCP, I can just type in a prompt and say, hey, log into this list of routers and this report that I launched the last few times, take that report template and then send it to my boss.  I don't like the JSON file or whatever. No, it would just be uh like the template format of the email or something.

01:01:17
that you have saved. It's like your preference. But it would log, know, it could have the ability to be multi-vendor, multi-domain, like log into the stuff that you need, grab the stuff you need, populate a beautiful template, update us, you know, maybe a ServiceNow ticket and send it to your boss all from a little chat window. And so, yes, I think it might have just clicked. Don't say more words because you'll confuse me. So, so MCP has it as a UI, I guess it has some kind of interface.

01:01:46
and I can tell it to do things.  And then because it's a standardized protocol, it then has what it needs  to go take actions that I tell it to take or to connect to all the systems it needs to in a standardized way and get work done.  Did I get close? Yeah, exactly. And I think honestly, MCP, you're probably going to see less things in user interfaces in the future and more with like a specialized chat interface. Like user interfaces are probably going to get less cluttered.

01:02:14
in favor of using this sort of chat interface to get what you need. And then once you put guardrails around it and  you're, you're, in a good place. thank you for struggling through this with me. I I've seen a lot of your public content you've been doing around MCP stuff that you're working on and it's, it's compelling and it's starting to come up on my radar. And so I'm this again, this Chad net up sky, trying to learn Python. And now I'm trying to figure out, you know, MCP and how to, so.

01:02:42
I love this part about tech that there's always new stuff to learn. um And I have smart friends like you who can help me kind of start to, you know, I think you, what do they say? Like you eat the elephant one bite at a time. So this is my first conversation with someone. Do hard things. Like you said earlier, here we go. Here's our sweet rap. Like to me, this is hard.  And  the more I apply  effort to this and do hard things,  I will eventually get it.

01:03:10
And then what happens, William, when we do hard things? What's the three-letter word that happens?  Win.  We win!  William, it's always great to see you, man. And homage to Scott Robon, know, take off your Python hat and put on your  hard things MCP hat, Andy. You know, I'm really fortunate, man.  have, to your point, I mean, it wasn't from public speaking, but maybe it was if you consider podcasting public speaking. Like, I have met  so many awesome, not only smart people,

01:03:40
but wonderful communicators, good people, people who reach out to me as friends, you yourself included, Scott. I feel so, I'm so grateful for the people I've met doing this show. The access to the people that I have today is a direct result of participating in doing the show. just, it astounds me. I can reach out to you, Scott.

01:04:04
John Kappa. mean, any of like I look at all the guests we've had and the people that know me and like, can just reach out to any of these people because 15 years ago, I had somebody telling me to join Twitter so I could talk to people in the industry. And now they know me, they come up to me, we have pictures, they ping me, I ping them like, this is incredible, dude, right? Like this isn't. It's crazy. Grow your network. to so many smart people. Yeah. eh William, it pays dividends.

01:04:31
Thank you so much for coming on. Thank you for suffering through my whining about cloud not being perfect  and  I the public speaking stuff is awesome. Do it if you're not doing it.  Communicate. Learn the business. You said that earlier. Learn how the business communicates. Start to communicate with them. Get you're gonna you're gonna. What happened to me maybe too is like you're gonna get to a point in your technical career of almost like  a ceiling of sorts right and.

01:05:01
You can go super crazy minutiae and  learn all the things.  That's definitely a path. But if you can also sprinkle in some communication skills and learn the business and learn how people talk about problems and it's, I think the communication skills have just gotten me so far. Like I would love to be a triple CCIE by now, but I think I've gotten further with communication.

01:05:25
than I would have with, cause my wife would have left me and my kids wouldn't live with me if I tried to go for CCIEs cause I know what it takes and there's no way they're putting up with that crap.  Yeah. I CCIEs,  they don't communicate why the rest of us are carping all those DMs, right?  I'm totally kidding. IEs just need, those IEs need some MCP and.  No. Wait, you down with MCP? You down with MCP?

01:05:51
Yeah, you know me. Come on, Yeah, I wish I had my CCIE. I failed. So I didn't get there. Yeah, I had a family at the time. Like, actually, I had a family right before I was going to take the lab part. had my first kid and it nerfed everything. Like I was I had the money set aside and everything and I was getting ready to take it. I don't know if I would have passed it the first time because  I went I went, dude, I went in a box for like eight months. had the way I the way I interpreted, I had a family.

01:06:20
was  it's not your current family.  had a family and  I tried to go for the IE and now I have a new family. I don't think that's what you were saying, but that's how I interpret it. had a family when I tried to it. it uh became. Cause  that, is, mean,  I, know like a lot of folks out there much smarter than me when it comes to like all the, it's a lot of work that test requires like a good year of diehard dedication. You got to put in the time.

01:06:48
It's  a tough one. about putting things on pedestals and people, I have an enormous amount of respect for anyone who gets expert level certifications by any vendor because  it's no joke. So thank you super  duper  nerdy smart people. I'm just going to continue communicating and telling some stories and lean into my strengths.  The gold jacket packet plumbers of the world. love it. And serious inspiration. Like if you've worked with like a real good CCIE, like you know what I mean, like they're doing.

01:07:16
You want to have them around sometimes. They're great. William, thanks so much for coming on. For all things Art of NetEngine, can go to our link tree, linktree.org slash Art of NetEngine. Guess what? We have new merch for the first time in years.  I'm not going to bore you with what it is, but there's a pint glass, and there's  some cool water bottles, there's  some polos. So  apologies to, I've had people come in to me saying, when are we going to have this? And when are we going to have that?

01:07:44
It's just time, right, William?  So I finally, I stayed up late one night,  created a bunch of stuff. So if you're looking for any Art of Net Eng, if you're watching on YouTube, I got our t-shirt up here, yay. uh Check it out. More importantly, if you don't have a community, you should get a community. If you haven't learned anything in this episode, it's the people that you surround yourself with make a bigger impact than anything else you do in your career.  We have a community called It's All About the Journey. It's a Discord server, it's free. There's...

01:08:12
I don't know, but I think we're like 3500 at the moment. And it's just people in there trying to do the thing experts, we have triple CC is we have people that are trying to pivot out of their careers. We have people that are like, I heard about networking, I heard the show, somebody told me to come here and we're all hanging out, we have happy hours or study groups. So if you don't have a community, get a community. But thank you so much for listening. And we'll catch you next time on the Art of Network Engineering podcast. Hey, folks.

01:08:41
If you like what you heard today, please subscribe to our podcast and your favorite podcatcher. You can find us on socials at Art of NetEng, and you can visit linktree.com slash art of net eng for links to all of our content, including the A1 merch store and our virtual community on Discord called It's All About the Journey. You can see our pretty faces on our YouTube channel named the Art of Network Engineering. That's youtube.com forward slash art of net eng. Thanks for listening.