Bill Marantz of Linode on automation, mentorship, and problem solving

Hi, and welcome to network a f. This week, I'm talking to Bill Marantz at Lenode. We're talking about how he got into technology. We're talking about open source netbox systems of truth and record and how that ties to, automation.

We're also talking about mentorship recruiting people when we're growing very fast and and and trying to grow the grow the pool. And also about problem solving and how important that is and how it can be really helpful to bring to networking if you're interested even without some of the deep networking technical details background. So thanks. Please join us.

Hi, and welcome to network a f. This week, I'm with my friend Bill Marantz at, Lenode, We'll be talking about networking, open source software, decision making, community, and let's get to it. Bill, could you give us a quick introduction?

Yes. I'm Bill Marantz. I'm the director of a network strategy and interconnection at Lenode. That's quite an interesting, full of a title, but I I wear a great many hats doing, you know, network engineering architecture down to, you know, DWDM and and cable plans and then also a lot on the sourcing and strategy and negotiation side working with data center providers, different colos, working on, ordering cross connects, turning up peering transit in in other capacity. And, you know, I'm also our our peering coordinator.

Got it.

And, thank you. I have been a Lenode customer for quite some time. I enjoy using it. And, it's also cool as, as, to talk with other folks that are doing networking in Philadelphia as as this is my background.

So And and so how did you get into, tech? How did you get into computers? And and how did you find networking? Well, I guess when I started it, which that's what we call it.

We call it computers. Hey, and that's like I always knew when I grew up, I wanted to be in computers. Mhmm. From I got my first computer in fourth probably fourth grade.

Mhmm. And then by the time I got to to high school, they started actually having you know, BBSs and and dial up in some tiny lands. And I said, well, this is this is really cool, I guess, in in freshman year of high school. And then I went to actually a specialized, technology school at the time, a magnet school starting from my my sophomore year called high technology high school.

So I said, alright. I really wanted to go into this area.

And when I started to learn programming, I was like, you know, this is cool, but it's not something that I could do every day.

And I said, I and I don't wanna be a, you know, an IT generalist either. And then as I started learning more about networking, I said, this is cool. And the internet was really starting to explode at that time, and Yes. You had AOL CDs, and you've got mail and everything, but it was also you started to see commercial, you know, ISPss. When I went off the college, we really had networks in the dorms.

And I said, okay. This is this is cool. This is what I wanna do. Work on the, you know, the fundamental infrastructure that gets users to whatever applications are are out there.

And at that time, it was, you know, mostly email and some basic business websites. And then it quickly developed, and then walls in college, you know, peer to peer file sharing really started mostly for, you know, bootleg uses, but, At that time, it it exploded when I was done with college. I said, I pay him. I wanna go work for an ISP.

I had work for AT and T, actually. Oh, wow. Yeah. My my high school had a really cool mentorship program.

It's in it was it was science and engineering and technology, but it was really more math, physics, chemistry, electrical engineering. And then we're we're really sure what what to do with me. And they said, oh, know, we have someone at AT and T and so, okay. I'll I'll go look at telecom.

That sounds really cool. They kind of, you know, put me in a basement with a box and and gave me, Jezwick and Bobvin's book on Fireles. And so why don't you figure out, you know, internet firewalls, which was, you know, early. In its very infancy those days and said, here's some books.

Understand TCP IP understand, you know, routing and give a presentation at the end of it. I said, okay?

You know, this is this is really awesome. And, you know, I figured it out and and got it working. I said, well, why? This is definitely, you know, what I wanna do for for my career. And then every kind of summer and winter during college, it went back to AT and T Bell Labs and, you know, help them out and get a lot of general IT support and some Windows server support, but there were also a lot of you know, Cisco routers and and other stuff, and they just started playing with it and said, alright. This is, you know, so what I what I wanna do.

Cool. Yeah. It's, great that you had that opportunity. When I showed up at college, I was interested in distributed processing and I mean, obviously, it's related. You can't really distribute anything if you don't have things connecting, but I fell into the networking side of it, and, got into optimizing multi user dungeon games. So, you know, learned UNIX IPC, but also, I mean, we we did on VMS a little but not my my not to my taste, but also, you know, then sockets and decentralizing and streams, and we even did some OSI stuff, which I think we only now have an Isis in the, you know, I think that's that's the only remnants of it that are that are, you know, sort of in networking.

And, you know, that was back in the days that that was back in the days where a lot of stuff was open source but that didn't mean you could get it to compile between, you know, Egypt Erex, AT and T, PSD, Oteryx, STI, HP UX, you know, whatever. So the libraries with this, the so But, you know, you mentioned open source is something that you use and, you know, is a passion.

Curious, you know, what your you know, nowadays what your interaction, with the open sources, personally in in the job, you know, in networking.

Makes mostly around, you know, Python scripts that can do networking things. You manipulate IP addresses and and and the like, or, you know, render giving some set of data and a templating ring language render that you know, template or or gift that template and say, okay. What what what changes occurred?

Here, most recently, I I've been using Netbox a lot.

And I and I I find, like, as as someone's building out and scaling these awesome cloud networks globally, there's a lot of often a lack of appreciation that there's still something physical there. And and that box is great for, okay, I wanna trace the cable from point a to to point z. And and I have a DWDM network, and I have a cross connect in a carrier hotel that's bringing back n by ten gig or n by hundred gig circuits And the knock needs to be able to to troubleshoot that. And how how does that all all connect?

And how does it multiplex up in okay. I need to swap out an optic. I need to change the cable. Where where do I even will and and Netbox was was great for that.

And then once I have all that information in there, they have a, you know, an API. So I can then query that API and and use their functions and automatically, you know, generate network interface so they can say, okay. This is this is point a. This is point z.

This is the carrier at point a, and this is the dark fiber that it rides to our carrier hotel. So someone can jump on the router and say, oh, okay. What what's going on here? And now okay.

Everything looks good logically. Where where is the physical tie in? And how does it tie in? And just immediately, look that up in in Netbox and using I I I don't program our our alerting systems, but we do use a lot of great, you know, open source prometheus and and other things, and they support labels, and you can put that label and it imports it from the interface description directly into that system.

And then when it fires an alert and says, okay. This is that utilization or it's, you know, hit a certain threshold of errors might level what what have you. And then there it says, here's your net box link. You look on that.

You click a little button and it's gonna show you the the path for made a to z potentially across dozens of data centers in in dark fiber and and cross connects and patch panels so you can really, you know, start troubleshooting.

Yeah. It's it's interesting because when we started Kintech, we built in the ability to be very flexible with that kinda tagging, as you mentioned, you know, some of the time series and other open source systems have as well. But one of our challenges has been getting, you know, people sort of giggle hysterically or sigh or cry or fall under the table when we say, where's your source of truth that we can pull from, you know, rack locations or what an application is to IP address mappings or you know, whether it's CMDB, iPad, you know, stuff like that. And it's been great to see the growth of, of Netbox and NS One on the DNS side has really, I think taken on the project and and invested heavily and is, you know, is focused on that.

So, you know, it's great to see. It's it's really hard to automate when you don't know what the parts of the plane are. Or in the Kintek sense when you have no dashboard.

It's really hard to, you know, make a flight plan and and and make things go.

Is, is, you know, Python and network libraries templating, is that something used across the group you know, inside the Linux? Yes. It it's it's very widely used. And I mean, everyone kind of we don't necessarily contribute as a network came to open source, but we're using it. Everybody writes changes for templates and where the underlying data. But, I mean, it really starts with that that single source of truth and the data model, and then you feed that into the templates, and then you get, you know, the simplest thing even though it's very complicated, is is interface descriptions, and then that can feed all of your monitoring and alerting, as you said, just tie right into to ten to can take and classify your interfaces as pairing transit backbone, customer, data center interconnects, or whatever else you have to to then, you know, capacity manager, cost manager, send up alerts to the right people.

Yeah. We we definitely see that, the older the network is a vintage wise, the more likely there is to be at least some part which has you know, is the dungeon of if there is an interface description, it's wrong, and most usually there isn't.

But, less in web companies and more in, you know, companies that evolved or got or evolved since Synchronet was a thing.

You know, where you're just starting to connect stuff together.

But that is really what we see as the basic level of Like, if you're if you're just doing that life cycle, keeping things clean, starting what you're describing with Python, that's really ninety something percentile actually for companies. There's all this vendor juju about, oh, well, everything is automated and everyone's behind it is you know, talking to their computers and, you know, like, like, like Scotty in in in the Star Trek, whatever movie that was. But, you know, that's that's the struggle that everyone has right now, I think. So.

Well, this, you know, if they want some fear of missing out, then they wanna sell their software, and sometimes your software implies that, you know, a design that may not solve your your problems.

Again, that's another topic for maybe a panel on automation, but I was surprised how much you actually have to know how the router thinks about itself in the CLI to use some APIs. So it's not like you wave your magic wand and say, you know, I just want to do this to that.

And, you know, you have a policy affected.

And then, you know, a lot of the most advanced intent stuff is for very I'll just say constrained solutions and topologies, not for, you know, sort of internet facing the stuff that we that we actually face. And we get asked to solve that all the time. Like, that is a hard problem. That's I mean, a lot of those tools are I I I don't wanna discount them because a lot of them are are great, but they're really for data center causes, and and and and fabrics.

We have a very fixed topology when when I mean, my room of background is backbone engineering, and no tube headers, fortunately, are alike. So it's more instead of saying, okay, this is what a router looks like. It's like, no. These are all the different components that could be.

There's peering, there's transit, there's backbone links. There's x routing policies, and then you combine them to make a router. And so strictly defining a router, you define all the components that go into that that device. Yeah.

Yeah. I think we'll see a lot of progress on that, and I think we'll see even just, you know, we've had rancid forever, to do config monitoring, but sort of the re the inverse that make it so command, the NCCM that we're config in changing config management, you know, doing that at scale, that's still something that's, that's evolving, which, again, we get asked to solve. But as we sort of view that as as outside the purview, you know, for our focus right now of observability. So, yeah.

But but one one thing I'd like is, you know, you do the network configuration you do the templates. You have the template at interface descriptions. You have what you think the topology is. I've always wanted to write something.

I've never had the time. To reverse engineer that with LLDP and say, well, this is what I describe, and I think exist actually it exists because LLDTP is really good at telling you what's actually there.

Let's talk offline about that. We actually have a script that we've done.

In fact, I didn't tell you about that commercially, but you know, it's like when you have, as you said, Python APIs, sometimes you can put stuff together. And so when we see people asking for features that aren't exactly there, but, you know, you can use this platform. You can use Netbox to grab some of that.

In fact, on some devices, you know, even if you don't have a CLI scraping mechanism, you you see LDB in the Mib or in streaming telemetry, you know, so then you can combine these different things to put it together. Doesn't always have to be the most elegant thing. In fact, I call it exigent engineering Everyone else calls it Avi Pro code, but, you know, it's like let's just demonstrate let's build a running specification. This could be done. And then have the smart people that actually write software, you know, professionally look at how to do that, you know, better. So, we can talk about that use case. Cool.

So I I am jealous.

I had a wizard who had a lot of Bell Labs experience who got me into UNX when I was, in my teens, but I did not get to work at the the at the, mecca, bell labs.

My uncle shut me off from the arpanet after about thirty minutes of me poking around, actually pre units even, you know, like, PDP days. So that was a mentorship program that you were on, you know, as part of the high school. Was it Yeah. It was a senior senior mentorship program, and then I kind of extended it more because I was I was so, you know, I was so into it and You you couldn't go to a community college.

You know, they didn't have Cisco academies or or any of that at the time. There there were few vendors. What vendors you know, existed. Didn't have formal training when I was looking for, you know, to go on to the university for a for a four year degree.

It was you know, IT or information systems. It was not there was no network engineering that wasn't that wasn't the field. So kinda had a you know, find my own way there, and I definitely learned a lot more in during my summers and winters at AT and T than I did in any of the you know, course work. I mean, obviously, I've learned more in the course work, but not necessarily about networking.

And then mean, I guess it was my senior year. I did end up taking a graduate level class. Mhmm. In specifically computer networking, it was taught by was an adjunct professor, but he was the chief network architect for for the city of Pittsburgh.

You know, hi. This is which is really cool. But at at that point, it was, you know, it was an it was a night class. It was mostly for people getting a, you know, an advanced or or a second degree.

And it was, unfortunately, it was very good class. It just wasn't I had already achieved most of those skills by that point. So I was like, oh, it wasn't learning all that that much. But it was it was good to validate what I had kind of learned in different pieces on my own from somebody who had had really been doing this for for years, they say, oh, okay. Uh-huh.

Well, there's the formal. Here's how it works in distance vector and, you know, that Then there's the just because you can do x doesn't mean you should. Right? I mean, just because you can just keep your doubts doesn't mean that you should go to that as your first thing to do.

And, you know, you know, how we learn these things. Yeah. That today would be I think it would be a very different course at a grad school today, because the stuff that was taught then, you know, most people that have come up through IT will have already know. And that would have been a lot more useful.

It's like, okay. The books and the diagrams and a lot of the sample labs, what would no one would do that in the real world. So here's the problem, and these are possible ways to solve it, which is really, you know, the best way. And the best way is not always the same for every company, and they may have different technical parameters.

They have made different business parameters. They have made different, totally different cost structures and and financing structures or you know, a much more established company versus, okay, I need to get this up fast and quick and just do a proof of concept and say, hey, we can Hey, we can do this, improve it to someone that didn't invest in this startup so we can really scale it and, you know, And it's it's really amazing even the nontechnical side. For me, I remember emailing the May East mailing list? Like, how does this a BGP thing work?

Do I just show up and get peering? And and, I got a email from Bob Gibson who ran case, and was like, call me. And he was like, well, this is a grand secret. You can't tell people, but, like, I'm like, what's an MRI?

And what's this? And how does pairing work? And what's what's end you know, it it was, like, I was lucky, you know, I had a mentor. I had, Dan Ellis, Alec Peterson, you know, had different people that helped teach me these things because at the again, in the nineties, the the the information to lay it out there for people that weren't already deep into networking.

I'll save I I call it for, you know, curious assistance, which is where I was coming from at the time.

You know, was not so great. So, you know, sounds like that was a great experience at AT and T. How do you think about how do you think about mentorship today?

You know, as as you're, you know, running things leading, building teams.

I mean, I'd say in the early part of my career, I was so busy. I didn't have extra extra cycles.

And then when I was at Salesforce, I said, okay. To move up in the organization, you need to become a mentor and start you know, creating future leaders. I said, okay. Great.

If you're giving me the time to do it, I I would love to do it. So Being in the engineering organization was a more, you know, operations focused organization. And sometimes, you know, watch those tickets or be on the email thread. I just kind of like, interject myself and say, hey, maybe we could do it this way.

And then some people were very open to it, and some people were we're not. And the people that opened to it, then came you know, started asking you more questions. Okay. Well, why did you do it that way?

What are what are the other options? You know, thank you for that. I I really like that. That's awesome.

I wanna learn more or people near me.

I've wrote a lot of documentation at Salesforce, and people are just kind of find that documentation. Say, I this was this was interesting.

You know, I I'd like to learn more. Alright. If you're working in a project Bill, can can I be an understudy, or could you, you know, go about part of that responsibility? And I was just, you know, happy to do it. And it was it was fulfilling. I I don't know. I think it really grew both both sides, you know.

And you you learn a lot more and you can really have a crisper delivery of things if you have to teach it to somebody else.

Well, people ask. Teaching is harder than doing. I was like, are you doing? Do it all the time you you forget.

But now how am I gonna ex how am I gonna explain all those steps and why I do that? And how do I make that simple to to someone else who may not have the the years of experience as a technical background or even know some of the underlying technologies How can you really simplify that and and draw diagrams or simple words and and get people moving? And and if I find most people, you know, appreciate that and and want to to learn. And, you know, I've developed some really great long term, you know, friendships with with my mentees, and I, you know, still keep in touch with, and they occasionally ask me technical questions.

I mean, we mostly talk about personal stuff now, but, you know, technical question comes up here and there, and You know, I I get my input and say, hey, I looked at it this way. I said, I didn't. That's great.

I like different viewpoints, and there's there's so many different ways to to solve problems in in working, and the right solution for company a could be very different from the right solution for company b, or they could be the same just not necessarily at the same time due to organizational maturity or skill, you know, skill levels. It's just definitely been Okay. I didn't do this because we didn't have the monitoring or or automation to to build that kind of network at the time, or we didn't have the skill set to to support it. But that doesn't mean that's not aspirational.

It's like, okay. We we're gonna get there. We're just not we're not there yet and just break up that project into the the smaller chunks and assign owners and say, okay. We're we're not there where the vendors could not be there.

I mean, sometimes our needs are ahead of ahead of the technology. I mean, I know that some of your other podcasters were talking about sonic. Pack it over Sonic. It's like, oh, man.

At ATM, I was like, man, this is something that's simple. And then, you know, then carrier Ethernet became popular in Ethernet, you know, we've just like boom. An MPLS, you know, dealt with bugs while they were getting it. There's always, you know, there's always trade offs.

You know, and I can say that with the hindsight of decades, I don't feel that old, but, when you teach people things and are helping people, you know, many of those people will go on to I don't wanna use a loaded word, but surpass. At any given time, there may be something that you need to learn or an introduction that you need or, you know, something they come around, you know, in business. So, there's, you know, pauses to it also.

I guess the the trick and and something I could do better too is, like, how do we show people that it's encouraged? You know, I think maybe sometimes we expect people to model behavior, or I expect people to see that when people engage and ask questions and have the bright shiny eyes that that good things happen, But, you know, maybe there's people from different backgrounds who, or who are Shire, who don't, you know, look for non structured, you know, interactions. So sounds like Salesforce had a good structure for that and it's something we think about.

And, you know, other companies think about this. How do you how do you encourage that, you know, that, that mentorship and and connecting people. So And and and some people are assertive. And and as is it, and and some people are are not, but doesn't mean, okay, I've seen this person do this good work, and they haven't reached out and asked for more.

But I I say, Well, I have a project and they've done something similar or showed an aptitude, at least give them a chance and say, Hey, would you like to work on this with me. Mhmm. And, yep, of course, they could say is is no, and and the same in the other direction. I mean, somebody could always come out and say, hey, ability of the time or, you know, Do you wanna work with me?

The worst I could say is no. Usually, I'm gonna say yes. I can't say yes to to everybody at at once. Right?

Yeah. No. That makes sense. And we we definitely think the same way.

At the same time as we're growing, try to we're we're trying to think a lot about that right now. How do we formalize that? You know?

And so, you know, that's something, we're spending time on. I've I've seen other companies of similar size, you know, a few hundred people, where you're not quite at the size where you have process and and everything formalized, but, we wanna take the best of what's going on and and and try to scale it. So Yeah. I I don't know if the actual process being formalized is super helpful, but I think the the baby step of at least providing the matching is, like, ninety percent of the solution. It's just, you know, finding people that are willing to teach and people that want to learn and and mixing, putting them together, and maybe their styles don't work, and maybe they need to move on to a different pairing, but Well, as you mentioned at Salesforce, also having the time to do it. Right? The the acknowledgement that it does take time.

But then, you know, good things happen at the end, or maybe people decide that isn't for them, and they find another path. So At what time in in in in patients because there's always the the the quick way is to to give somebody the answer, but they're not gonna learn all that much. It's like, okay. Well, how would you do this?

Okay. This is wrong. Can you think about why it's wrong? Or have you thought about what would happen if this happened?

And I was like, oh my. This is not, you know, a redundant design or well, I didn't didn't anticipate that, or I'm draining a router, and I'm I'm doing all the the right things. I'm doing them in the wrong order. And okay.

Well, well, BGP's up. I've turned down Isis and now uh-oh, what happened?

Sometimes you have people that are like, no. You're wrong.

I will show you. And what's fun is, usually eighty percent of the time, you know, they'll like, oh, okay. You're right. Twenty percent of the time, you might be wrong in your assumption or there might be a different approach, and then that's also Either way is, you know, a good outcome.

But, you're right. You have to I recall one, a very long discussion about that.

In one scenario, and they're just like, no, you're wrong. I said, let me diagram out exactly our topology and and and and why I'm right. And Oh, no. It's always gonna pick a consistent belt. I'm like, nope.

Well, people think that BGP does a lot of things that it doesn't doesn't do. And, you know, including really the deeper down you squint at, best path selection, know, people think networks are much more deterministic than they are and also underestimate bugs, which is a whole other topic of how much you have to do planning. People like, well, you can't consider vendor bugs in your in your disaster scenario. This is like, oh, oh, yes, you can. You should.

You know, because they occur in certain ways. In the nineties, it was like, put the fitting card in and sparks shoot out the hissing port, but Today, it's more consistent kinds of things that are just what you shouldn't do. Or it's like, yeah. I know it says you can have that many next tops, but Not really.

Not really. They don't really mean it. They, you know, it meant that their automated test didn't break, but that's probably not a good idea. Again, it's it can be hard, in the non network world too, you know, or the network world where we talked about open source.

Some of the line is blurring between you know, what's a what's a service mesh and a network mesh and all that.

Use a new tool, you know, If you don't know how it fails and you're not actively developing it, that's a dangerous position, to be in because software you know, is not perfect and fills all around. You know, we're lucky, that we have Linux underneath and and that has run, you know, pretty well, and has gotten very stable, but, you know, definitely things to look at. Speaking of that. Or have a controller that sits in your network that's then part of the path that you may break.

And now the controller can't talk to. Oh, so many multi levels. And now your network won't work. So speaking of that, You know, you mentioned this before problem solving, right, which is, always reminded me of my physics teachers who are, like, starting from the basic laws of physics, drive this and this and this.

It's, like, because, networking is complex, or or lots of simple things that that that work together complex in, especially internet connected real world applications, you know, how do you think about problem solving, selecting hiring, training, you know, mentoring around problem solving and networking?

I guess from from my perspective, it's it's really crisply defining the problem in in the user space and understanding someone's gonna use that application or that part of the infrastructure, or how many things are layered on top of that infrastructure, So then what features you need to deliver? And do you need one infrastructure? Do you need multiple infrastructures?

Do you, you know, cater to the least common denominator there, or or or how do you, you know, how do you really approach that? And then just looking at a bunch of diverse backgrounds and say, well, how did you solve that problem? Or how would you solve that problem if you never solved it? And just coming at it, like, Okay. I've never solved this problem. I don't necessarily even understand how the underlying protocols work. But if I was gonna solve that problem or if it was greenfield, like, what what things are when I consider?

And I I just find that's that's very helpful that there's somebody who's always solved the problem.

And always solve the problem one way. Could be a lot less useful than someone who solved the problem five times in five different ways, or someone who's never even solved the problem.

But just is curious and wants to really ask and understand and say, okay. If this broke or okay. Well, now we're not using this device in a car. We're using this device underground. Right?

How how does that change the the problem space? It's interesting. I mean, I know that's an extreme example, but Yeah. A lot of companies at at Kentic, we don't do the, you know, the crazy, you know, the crazy, either stand up at a whiteboard and reverse a binary tree or or the how many light bulbs are there in the United States, but I think it's definitely true that, even if you don't get to the right answer, understanding how people can break something down and and attack it whether it's learning or whether it's problem solving is helpful.

It's another thing that, there's a lot of wisdom about that people might have, might not have. And so we also think about how do we set expectations about, say, an interview. What what are the conversations that we're gonna have? What are you gonna do? Don't worry. If you don't know the exact answer, we're trying to get at this.

Again, as we scale, we we think a lot about that. So But I hear you talking about sort of you can have all the network experience in the world, or maybe all the network experience in a manufacturing plant in the world and be the best at that. But if you don't think generally enough about problem solving and and how that applies to Maybe not even the technical, maybe even the business and and and Yeah. I mean, I yeah.

I've had interviews where they Only, like, the questions they asked, it's, like, so specific to their environment, and I did not work in that kind of environment. I hadn't really thought about that kind of environment. So I I can give them a rough guess, but it would take me a lot more time than that interview to think them in detail and say, okay. These are all the inputs.

These are all the variables. These are all the permutations, these are all the things that can go wrong. You always need to be thanked. To be a good engineer, you need to think about all the things that could go wrong, and almost in in that way be a business person and prioritize them in likely with probability, right, you know, risk management.

Okay. Is this likely? Is this not, you know, is this like or not? Is this a corner case or is this going to happen?

All the time. But when when I'm interviewing someone, I I really wanna see their thought process, see how they would troubleshoot things. And and I I try to ask more open ended short questions and just let them go. One of the things I really ask about is, okay, packet comes in one port on a layer two device. Other layer two device.

What must happen? What could happen?

What happens? Right? But, you know, what what happens? In a layer two scenario, and then doing a layer three scenario.

Okay? I'm gonna go in one port out towards another router. What what are just to show It's crazy. I'm a little bit fuzzy about They're thinking about TTLs.

They're thinking about buffering. They're thinking, okay, this could be multicast. It could be GRE encapsulated. It could be VVX LAN encapsulated.

It could go into an IP sec. VPN, it could be added. Those are, you know, all potential things that could could happen on a layer three device. Right?

What what you're looking for is relative to their background and claimed expertise and experience.

Right. You know, you can always give hints, but you know, it's not gonna occur to a developer who hasn't looked at it that, you know, switches do Mac learning and, you know, versus they might have seen ARP you know, from layer three. But if someone's saying they've been running larger data centers, then they should know that or or draw the internet. Which, again, for let's say someone's appearing coordinator, but not, you know, a hands on, you know, into, you know, this still should have some idea at some level. And also gives you a good idea about the people come at it from the application side, the infrastructure side, you know, etcetera.

You know, you you talked about diversity, of background, and people that have pure networking experience are very could be very senior with very specific network experience versus people that, you know, can bring an approach to it.

You know, the the the broader, the set of people and backgrounds, the better questions you ask, the better answers you get, you know, how do you think about, getting a diverse set of people, in, in a networking organization.

You know, recruiting them, pulling them from other parts of the company or, you know, from from the world, where there's, you know, especially at the senior level, there's there's, you know, we're disadvantaged in some ways, just due to history and and and approachability.

Yeah. I I guess, a part of, but I I wear somebody hat, so I do interface with a lot of different parts of the company. So I do wanna, you know, gauge interest and say, hey, would you like to have a session? Do you wanna wear an Do you wanna learn more about that?

Mhmm. Because there's there's definitely more diversity when you you look across certain organization, like, we know that there's there's a lot of support people. There's a lot of developers. There's, you know, finance people.

There's folks in those different roles that tend to be more diverse than just network engineers. Right?

And and I really think getting very young is very important. And this is something I've re and and it's it's been a challenge for me, and I've reached out and And I just moved and now COVID's winding down. So I I plan to reach out again is go into high school and elementary school career days, and and everyone's just so tied into their devices today, but they it's almost neglected. It's like, this magic just happens.

I'm like, no. There's a lot of thought. There's a lot of engineering. There's a lot of resiliency.

There's a lot of this to like, this the scale to make watching whatever video you're watching or whatever social media site you happen to be hitting at that time work at that scale is is just mind blowing. And I think young young folks would be really fascinated by that. So so so get them, you know, young. And I think a lot of people really wanna be and it is set problem.

What happened to me is, like, I knew I wanted to be in technology I knew I wanted to be in computers, but I didn't necessarily wanna program. I didn't wanna necessarily design computer chips or to signals and systems that, like, detailed electrical engineering or or optical engineering, and and maybe, you know, I don't think a lot of people know that is an option. And they ask, like, what I do? I say, okay.

I build the Internet infrastructure. What does that mean? And when you talk to people and say, okay. You're you're sending data.

Are you making a phone call from Europe to the United States? Can you talk about subsea landing stations and indeed, WDM systems, and and other things, and and and cable ships and cable repairs, and people are fascinated Well, how is it powered and you talk about that? It's like, you know, people are Okay. Everyday people get pretty pretty interested.

That's if we start, you know, It says people, you know, they've never been really successful in three years. Internet infrastructure is in the news today. Right? It's been in the news.

It keeps being in the news. I mean, it's it's relevant to us and and and how we work, you know, I mean, that's a great idea, Aaron Kagawa, who works for Kentech talks about tech, not even specifically networking, in Hawaii. It goes to different islands and talks to schools. I know Anna Clayborn was talking about when Pack and Fabric was talking about getting math folks, which also, you know, is is well, earlier in career is generally more diverse, also in even in computer science, but that a math folks who study distributed who think about parallel processing and algorithms and distributed systems or, to, you know, in control systems, and to get them interested, you know, and the internet from that perspective.

I used to go to Temple University when I was still in Philly, although to your point, I went to talk to seniors, which was much less useful than talking to. Freshman would have been.

You know, about we found some interesting, folks that were interested, but, you know, they sort of are sort of already showed interest. What kind of messaging did those students run into early in their life that they thought maybe that wasn't a bio viable career path for them. But if we we talk to them to young, and technologies in just like every aspect of people's lives. And I talk to child a, and their thing is sports.

And child b, they they wanna watch videos. And as there is, you know, voice voice recording in in music, the technology is in there, and you can you can apply that and say, okay. Well, I wanna do video encoding at in in streaming locally or globally at at scale, and and I wanna produce this, and I want I wanna, you know, do a video or inter interactive Or or how it's metaverse. Right.

What have you? Right? Yeah. Perhaps now it's metaverse. Right?

With, Facebook and their direction, everyone the kids are not aware of the edge computing hype, but know, if you really wanna have ready player one, there's a lot of interesting network and and software systems that have to be designed you know, to really make that happen. So, So the other side is just like really investing in in our schools and the technology they have, there's a lot of awesome awesome teachers that meet maybe, you know, with a specialized in networking or an art or something else and and use this technology and distance learning now that Zoom is so popular. But it was or or or other, you know, streaming technologies after after COVID, but it still seems like the trac classroom is traditional that all the kids are still in the same town tied to a teacher in that same town or if you're really lucky, it's done in on a county basis.

Well, if you find fifty kids across the nation that are really interested in this specific area of of technology or or culture or arts and find an expert teacher and spread that person across all those kids using, you know, these awesome technologies that we now have to really help those kids So, you know, focus on something that they're they're passionate about and not get, you know, lost in the system and not, you know, get through high school and say, I, you know, I don't have an option. I don't have a choice. I it's either gonna go to college or I'm gonna go you know, work in retail. It's

almost like trades are are forgotten. And and, you know, we talk about mentorship, and you've mentioned this before. It really It's really like a modern day apprenticeship. Mhmm.

Right? Right. Yeah. I mean, what's the VOTek, for, for this kind of thing. I think that, you know, Nanogg is trying to, trying an approach towards this, I think.

You're describing, I could see working. Maybe if there was a core curriculum and a bunch of people that were interested in in in helping, and and maybe it wouldn't be the density in every class or in every grade or in every district, but finding people that were, interested in effectively a more interactive Con Academy approach, maybe targeted high school versus college level, could be a good way of of helping people get more educated. And, of course, people wanna know about cloud, and they wanna know about architecture, and, you know, also, but, you know, to have to be able to do that on networking would probably be helpful.

And we have, you know, some of that for people that we wanna train up at Kintech and at Akamai, I think the second week, I did a class on BGP, and we had half the company squeezing in the room to try to understand. They'd already achieved massive success, but, actually, peering and how negotiating and policies and all that, you know, sort of vague, because it came from computer science and a practical background, not, you know, from a networking side. So Yep. I've seen links really step into that space too.

And I'll tell I'll have to take a look at that. Talk about oh, okay. How do we How do we grow IXs? Well, people need to know what they exist.

They need to understand BGP. They they they need to understand that there's it used to be a very cost savings, and and it still is, but there's just a lot more parts of of diversity and capacity and and being able to handle handle burst. And, you know, traffic is is all over the place with with geopolitical events and, you know, now so much of sporting events and other things are just live in in real time and This network goes from zero to nine hundred in in seconds, and then back down again. Hearing always had elements of cost performance, control, and diversity.

Right? Having diverse paths gives you control. Mhmm. And definitely in the nineties, it was more about cost.

At, you know, two thousand dollars a megabit. And now transit can can be cheaper. In fact, for many of our customers, transit is cheaper, but the reason they don't do it is because then, you know, they're dependent. Now there's trade offs.

If you announce your paths to you know, three hundred networks. There's three hundred people that could do something bad with your routes, but, you know, especially for content heavy folks, having more paths means you actually have tools to fix things. So for content, you can't move to a CDN or multiple CDNs, you know, for the most part, not everywhere, but, you know, outside of South Africa and and and, you know, other places, it's the cost is not, you know, the primary factor there now. And and I said, path diversity is a major driver.

There's showing no downside to path diversity today. And routers can hold the paths. I mean, there used to be a downside. Right?

But Right. We're we're not the routers are not blowing up on on where I am these days. Yeah. No.

It's it's it's working, overall pretty well. So, I mean, that it works. And that, you know, we just talk about getting into the parent community and mail this and just like, oh, well, I just sent an email to someone in a ten ten minutes or ten days later, they responded. We just set up a PGP session, and now, you know, we're exchanging more traffic over that link on a shared eye accident, backbones, you know, exchanged in the late nineties.

Right? Right. No. I know it's pretty crazy. I remember, a gentleman came up to me at a Nenog in eighty sorry.

Ninety nine, I guess, when I was at AboveNET. And he was like, you don't know me, but, I'm Eron Quek, and I'm behind you know, I'm, your big probably your biggest source behind it. Forget you gonna have. And I was, like, oh, yes.

I think it was five sixty eight, whatever Bell Canada, Palnixia. And he was he was like, yes. How'd you know? I was like, well, I watched this stuff too.

Although it was much harder to figure that out back then before know, when Netflow was barely at all much less being able to take the data and use it.

And, you know, it's it's sort of fun.

But again, separate topic, just the the the philosophies of peering.

And, you know, again, the background, a lot of it is about economic of politics and not just the technology. So it's it is a beautiful thing when you can find people that are compatible and all of a sudden, the customers get happier. That's ultimately the best outcome.

And and and you you'll meet some people and they're like, oh, man, this company is so rough. And then you actually they're not gonna peer in. You meet the person, and it's not necessarily them. It is the business decision.

They could be the most the nicest, most helpful person, and it will introduce you to other peers, and and and help you out. They may not be able to help you out And they move. For pairing with, you know, big eyeball network a, but that doesn't mean they're not gonna help you out and and be valuable or or learn something from each other. I mean?

Yeah.

Yeah. And and and it's also an it is a direction I encourage people to go if they're not interested in as much in the technology side. And in some sense, it can be more welcoming because it is a much more diverse community because people come from even more different backgrounds, than the, you know, let's face it in in networking.

You can have very spirited debates about architecture and what's best here and what's best there. And, now we have the same fit debates and interconnection.

But there are more likely to be people that may have a similar background to you or look like you or, you know, in those environments, especially when you go international.

And so I think they've done a even better job of keeping that up. And and getting people from a from a business side, from a technology side, you know, from, sometimes a marketing side And then sometimes even getting into the switch hats and get into the more of the technology.

Although that rarely comes into backbone and cloud networking. Usually, it stays on the Internet interconnection side.

So I mean, but as an industry, we just have so many job openings. We need to we need to diversify. We need to focus on outreach. We need to get the to people early.

And, you know, maybe get some of those electrical engineers or programmers before they they go down that path and say, wow, networking's, you know, really cool. Or other people say, you know, they wanna be a business hybrid you know, I think can go into can go into peering. Right? It's not just college.

It's not just high school. It's not just, you know, internal transfers.

I think we need a a next, diverse approach to it, and, we'll, give it some further thought.

As, you know, like, Cloudflare's done a great job with their learning center. We're trying to do something similar.

You know, a lot of other companies are also, but how do we how do we curate and help people, do that for, and not just networking, but infrastructure in general observability, system design, you know, all these things are related and the lines are blurring over time, and, you know, but it's it can be hard to get into if you're, you know, starting with an iPhone.

Yeah. You know, and and I understand everything underneath That's a pretty big gap. It's a bigger gap than, you know, coming from an eight bit computer and trying to serial connect it than understanding networking. So Yeah.

I mean, I I I appreciate the outreach, you know, you're doing. And a lot of people are starting to add those sections on their their websites, whether it's white papers or architectural diagram. They're just general learning resources, and that's awesome. Unfortunately, a lot of them still are behind not necessarily paywalls, but Yeah.

Oh, well, you have to give me information so I can mark it to you. And and that's gonna, you know, turn off students and and as a marketing person, they're now gonna be chasing ten college students, and they're not gonna be buying anything. They just they just wanna learn. Yeah. Yeah. No. Definitely something to think about.

Well, thank you for the time, and, for sharing. Definitely, seeing a lot of the pattern of folks using Netbox and trying to wrangle things together and and understand how to do automation and hiring as you said, you know, is a challenge for for everyone.

And, need definitely some creative ways of thinking about it. If, people wanna find you, Bill, how can they reach out to you?

Best to just find me as a Bill Marantz on LinkedIn.

Okay. This is the best way to contact me. Cool. And I'm, Avi Friedman on LinkedIn, Twitter, avi at kintech dot com.

And, if you, like, this kind of format, feel free to find, like, subscribe to network af. If you have ideas for, other interesting, topics, areas of discussion, please ping me as well. Thanks again, thanks again, Bill. Alright. Thank you, Abby.