What does it mean to be a network engineer in 2023—with Brian Davenport

Phil: Quick history lesson. The carburetor was first invented almost 200 years ago in 1826. And that was the main technology used in cars all the way until the late 1980s, or early 1990s or so. So not that long ago. That means mechanics, car mechanics had to know how to install carburetors, fix them, tweak them, really just understand how they work and interact with the rest of the engine. It was an extremely important skill for any decent mechanic. Now, carburetors were great at the time. They met a need in automotive technology. That was how air and fuel was mixed together and then delivered into the car cylinders. So your car wasn't going anywhere without a properly functioning carburetor. But in the late 1950s or so, electronic fuel injection was developed and it solved a specific problem for the automotive industry. Basically, how can we get more power and better fuel efficiency from an engine without making the engine bigger, and bigger and bigger? You see a carburetor mixes air and fuel and then delivers it to the car cylinders mechanically, that's the key there. You could tweak it a little bit, but because it's mechanical it's imprecise. So it struggles with things like changing air temperatures, subtle differences in fuel quality, and it really limits how much output and efficiency that you can get from your car that has a limited space for an actual engine. Now, fuel injection uses an electronically controlled system to really fine tune that air to fuel mixture and then delivers it much, much more precisely into the car's cylinders. And then that, in turn, dramatically improves performance and fuel economy. So what you get is with the same size engine, you get a better performing car that uses less fuel. So here's my question for you, those mechanics that knew carburetors inside and out, they were subject matter experts. Was it unfair or maybe part of just the automotive hype of the time that they needed to update their skills to work on fuel injected cars? No, of course not. They still needed that foundational knowledge of how cars work, but new and better technology came out. And mechanics needed to learn it. That meant needing to learn how fuel injection works as a system, but also how to use the tools to diagnose and fix those systems. In the same way, the network industry has seen these sort of bursts of change every so often when a new technology comes out that solves a real problem. And then, it starts to get adopted everywhere. And, in the same way, engineers need to learn that new technology but also learn how to use those tools that you use to work with it. So where are we today in terms of skills, foundational knowledge and the tools someone uses? What does it mean to be a network engineer in 2023? So in this multi- part series, I'll be talking to experienced veteran network engineers about what they think it means to be a network engineer in 2023. You're listening to Telemetry Now. Let's get started. All right, so with me today is Brian Davenport, who's a solutions engineer for Kentik. Is it sales or solutions engineer?

Brian Davenport: Depends on the day of the week, I guess. But yeah, either/ or.

Phil: Either/ or. I always like saying solutions engineer'cause I didn't want to associate myself with the sales team.

Brian Davenport: Yeah, there's that.

Phil: Okay so, Brian is a solutions engineer. Brian, we've both been engineers in one way, shape or form for a very long time. And we've both been into the weeds of networking in general, I guess you could say. And I think we both have enough actual time of years experience under our belts to be able to see that things are changing for network engineers out there in the field turning wrenches. So, first of all, do you agree with that or no? And like my math teacher in seventh grade said, explain your answer.

Brian Davenport: Yeah, no speaking of math teachers, classically trained, I'm actually a high school history teacher. That's what I graduated college with.

Phil: Really?

Brian Davenport: Yeah. And then, I kind of transitioned into technology, but I know you've been a sales engineer as well and it is, to me, very similar to teaching in a sense of, if you're high school and you're specializing in history, I'm enterprise and specializing in network. But you're still teaching something to an audience for sure.

Phil: Yeah. So did you spend time in the classroom?

Brian Davenport: I did, yeah. So, I was 18 and you got to figure out what you want to do with your entire life. You're 18 now, what do you want to do? And so I was like, " Oh, I guess I want to be a teacher, I'll try that." So I went to college and I've always liked that aspect of working with people and helping them learn stuff. So, I thought it was going to be a good career choice. It wasn't exactly what I wanted to do. And then, luckily I kind of found, for me, a very fulfilling career and keeping some of the teaching aspects that I studied in school. But working with technology, which I've always been kind of a computer nerd at heart. That's kind of how I got to where I am.

Phil: Yeah, very interesting. I didn't know that about you. I was actually a high school English teacher for five years in private school. Yeah, prior to getting into tech. And my reasons for getting into tech were very practical'cause I loved teaching and I still do. And I agree with you. I was a solutions architect, that's what we called it, for a few years for a very large var. And I still got to be a nerd. I had to be an engineer through and through. I was on the command line, I was working with customers on the command line, and doing designs. And as a requirement of my job, had to have a deep understanding of the latest technology of how things integrated together, what problems we really did solve, how to add a lot of margin to projects, there's that. But also, to have the soft skills to be able to deliver compelling presentations to interact with customers over. I loved it, that was my favorite job. I love what I do now, don't get me wrong, but I really liked being a sales engineer and solutions architect very much.

Brian Davenport: Going back to your original question though...

Phil: I was about to say are you stalling is my question. But what do you think, do you agree with this idea that engineering, network engineers, the nature of being a network engineer is changing?

Brian Davenport: I feel like it's changed a ton. If you go back to when I first started, the cloud wasn't really a thing. I mean it was there but it wasn't what it is today. And it was a lot of on- prem networking. So much Cisco, I just remember nine years ago it was all about Cisco command line, being a CISSP, or... I can't remember the acronyms now, CIE, or whatever, or Cisco architect. And then, it's a lot of understanding routing, and switching, and spanning tree, and all this kind of stuff. And then, slowly you moved into what I kind of saw was a huge explosion in SD-WAN. So all the engineers were kind of learning SD-WAN and kind of how all that stuff worked. And then, over the last two years I think it's changed a bunch. It's a ton of cloud. And most engineers I'm working with now are writing Python code to do a lot of automation. You're not really banging away on the command line like you used to be. So I think it's changed tremendously.

Phil: All right so then let me ask you this... I do want to ask you about degrees and certifications and all of that, but you already touched on new skills that engineers pretty much need these days. What would you say are the latest skills that engineers need to acquire if they are brand new to the industry, or maybe veterans of the industry but need to adapt to how things are changing?

Brian Davenport: I think the understanding how packets move on a wire is kind of becoming a dying art in a sense. And I think that when you're troubleshooting things, being able to understand those concepts of if this needs to get to this, what is it going to do, how's it going to do that? I think those core concepts are still important. And I think that having that skillset is great. But with a lot of that being abstracted away through overlay networking and cloud networking, the skills that I see a lot of the sharper engineers I'm working with is really what I was so glad somebody encouraged me to do. One of my mentors six years ago, she was like, " If you're gonna be in this field, you have to know how to program. You just gotta know how to do it. Just pick up a programming language and learn it if you want to be a great engineer." So I'm not a C programmer, or anything, but I can write some Python and understand it. And aside from being able to code, I think what learning some programming will teach you is where traditional network engineering, you understand how the packets move on the wire. Nowadays, we have a lot of application performance issues, or latency issues. Learning to program teaches you how an application works, so you can kind of get that other layer of thinking about something even if you're not actually writing code all day. It gives you another layer of understanding. So, for me, I think most engineers I'm working with are picking up programming skills for sure. I always am doing API work now, and people are writing code and we're working together on it. Nothing crazy at all. And then, the other thing is the cloud is... I was just at AWS Reinvent and a lot of people that I talked to weren't called network engineers anymore, although after talking with them for five or six minutes, they were network engineers three years ago, but now they're cloud architect, or cloud network engineer, or something like that. And they're kind of transitioning into these hybrid roles of understanding the cloud. So, I think most engineers are probably getting pushed towards learning that. But if you're interested in the networking, your traditional networking field, I'd definitely focus on understanding at least how AWS, Azure and Google work'cause those seem to be the big players to have an understanding and there's a lot to it.

Phil: Yeah so for new skills, learn a programming language. And you mentioned Python. And learn how public cloud works.

Brian Davenport: Yeah ...

Phil: The two main fillers there.

Brian Davenport: Yeah, those are the two bullet takeaways. And then, don't lose the passion for understanding how TCP/ IP works, and how BGP works and how routing protocols work. Because when something really breaks, I feel like the networking team is always the one that gets called in. They're the only ones that get blamed. But I think part of that is because they want to pull those guys into the problem because they actually understand how the data moves and they always have that guy that just knows where to look and how to fix something, for sure,'cause you have a broad skillset.

Phil: Well I mean that's something that we deal with at work and in the industry as a whole right now is that not all, but most of the applications that we consume personal and for work are delivered over the internet and the local network that you happen to be on that day whether you own it or not. And so, to me, it's just logical that there's a tremendous amount of application performance information embedded in the network. So a network engineer who understands network visibility, network devices, how information works over a network, and isn't necessarily as interested in application code reviews and server logs they have a unique perspective, a network centric perspective into application performance that is absolutely required today. It's not a cool thing where, " We got this idea, let's build a platform around it and try to sell it." No, this is how we consume applications today. So I feel like it's the illogical extension, or another aspect of APM that we really need to pay attention to and unique for network engineers in particular.

Brian Davenport: Yeah. And one thing I kind of didn't say, it's the whole COVID shift too I think was a big transition for network engineers where I worked for a different company in FinTech prior to COVID. And I worked in networking and it was a lot of how do these remote offices connect together, and site to site connections, and people are coming back to the data center, and connecting to an application. And now, I see a lot of people are all spread out through the world and it's kind of either from the cloud in, or from the data center in, or what we're doing with synthetics of just what's the internet weather? Is this even my problem? If it's a network problem, is it my network has been a big transition.

Phil: The internet weather, I've never heard that term. I really like it a lot. That's really cool. So you got a new network engineer, or maybe somebody who's changing careers, or whatever, somebody's getting into the field and they want to become a great network engineer, but today. You mentioned that they need to have a basic understanding of the fundamentals of networking, how packets move over a wire. You mentioned that they should probably learn how to program in a modern, relevant language like Python, they should learn public cloud. What do you think about the whole degree versus certification thing? That was a debate that went on... Well no, it was on and off for like 10 years of my career where people were like anti degree, pro certification, pro degree anti- cert... In fact, there was a whole segment of network engineers that were against certifications altogether. Where do you think that is today?

Brian Davenport: So I have probably bias because I don't have any certifications. So all certifications are a waste of time, why would you want them?

Phil: There you go. Brian, I want your gut, real honest answer.

Brian Davenport: So here's my thing with that. And I hate to fence it on anything, but I really do think there's a couple things I want to dial into on that topic. And one of the key things I think you said, but I'll get back to it. So if it helps you to learn a technology and you're interested in it, I always found that studying for something and kind of really pushing to understand it does help you do that. It helps me anyway. So I do think there is value in that. The problem that I always find with some certs is it feels marketing exercisy to me sometimes. I do have a couple certifications that I've gotten, and a lot of the ones I've gotten are vendor specific where it's like you're kind of getting molded into this architecture. I feel personally my gut is they were really important a while ago, and they're not as important now. But I don't know that to be true. That's just my gut feeling. I do want to ask you though, you kind of said something that struck a chord with me, which is say you're changing careers, or you want to move to be a network engineer within an organization, or maybe you want to be a security engineer, or something like that, that feels hard. It feels like a hard process. And I'm curious why you think... I have some thoughts on why that is, but why do you think that is, or do you think it is to move to a completely different new role within an organization? And if yes, why? And if no, why?

Phil: So is it difficult? I mean it depends on the role, it depends on how adjacent that new role, that new niche of networking or technology is to what you're currently doing. So, for me, going from traditional network engineering to network visibility, and now network observability in a technical marketing role, not very hard because I'm using... Well, I'm discussing the same technologies I've always been using. So not too difficult. But to go to something a little bit more different, divergent like network security, yeah I got to learn both the jargon, the mindset and that takes time. So it took me probably two years to almost maybe three years of working in purely network visibility and observability to be at the point where I now can literally just for an hour go through an entire conversation deeply about the mechanics of network observability, the problem, solution and all that stuff. It took a few years. I have to imagine that it would take a similar amount of time getting into network security. However, adding on all the stuff that I don't know. So there's that. I don't know, maybe that's not a good example'cause-

Brian Davenport: I think it is.

Phil: Network security's built on networking, so there's that.

Brian Davenport: I think too and kind of convey one thing is that certifications and education is definitely important. But I think for me personally in my career, the most important is having a good mentor of finding-

Phil: Oh yeah.

Brian Davenport: Somebody within the organization that's been there before. You just learn so much more from that. And if you're at a company and you're interested in moving positions, or something like that, finding some kind of relationship with somebody that can help you learn the ropes a little bit. And mentorship in technology, I think in probably any field, super important. But it's another thing I would throw out.

Phil: Yeah, I'm sure. But going back to this original question of what does networking, or network engineering look like now in 2023, and what does it mean to be a network engineer? In my introduction I talked about the car mechanics of years ago that were subject matter experts on carburetors. And they were experts on it because that was the technology at the time. And then, in the late 1950s electronic fuel injection was invented. And then, by the'80s or'90s most cars were fuel injection. And I made the comment in the introduction, was it unfair to those mechanics that they had to learn a new skill? Was it just automotive industry hype and that they were bowing down to and they needed to be stalwarts of traditional automotive mechanics? Well no, that's kind of a ridiculous thing to think. The technology changed and so be the nature of being a mechanic change. And that that's really how I look at networking right now. I mean the technology changes as a result of the needs of the industry, or the needs of people that are consuming the services we provide and therefore, engineers change along with it. I mean that's just the nature of anything. It's kind of weird when I hear a disdain for folks that are network engineers but really trying to learn the latest technology, or network automation. And they'll use not necessarily derogatory, it's kind of funny. But they'll say like, " Oh you're just a hipster network engineer," but you can sense a little bit of bitterness in there. And it's like, " Well hold on a second, this is what we're doing now." Would you say that to a mechanic in 1968 who has a fuel injector car in his shop and you say, " Oh I'm not gonna work on that. I refuse. That's beneath me." That's ridiculous. So I really look at it the same way that the industry is changing, for whatever reasons and in whatever ways, and engineers have to adapt as a result. That's just what it is.

Brian Davenport: So when I was learning to code, I think this will be parallel to that. So I learned Python, and then I had a friend who was a developer. And I was like, " What's the new languages?" And he was kind of like newer age and he was like, " Oh you have to learn React. It's this front end web framework that's super popular for building single page applications and you gotta learn this." So I bought some Udemy courses and was learning React. And then, one of the developers at the company I worked for, he was our web developer and I was like, " Hey, I'm learning React, curious to what you think about it." And he was like, "Well, do you know how JavaScript works?" And I was like, " No." And I think we kind of even said this at the beginning of understanding how packets move on the wire and some of the perils you can fall into when learning new technologies is once he kind of said that to me then I was like, " No." And then, I went and learned JavaScript first and then transitioned into trying to figure out how React worked. It just made it so much easier because you knew this is lik React is a framework built on JavaScript, much some network automation thing if you're really, really good at it, but you don't understand underlying networking concepts, I think you can get into trouble there, especially when things break. But there is definitely a resistance to change. And I think the people who are web developers probably have that there's a new web framework every three weeks to choose from. And in our space there's some new technology movement that's always happening. So if you're going to commit time to it, and learn it, and then it goes away and you know wasted all this time, I can see having that frustration of being like can't we just go back to the old days of...? I get it. But moral of the story I think is foundational knowledge is super important. And the guy who learned to build a car, and was a car mechanic, and then didn't resist new technologies and learned them as they came is probably a really, really good mechanic compared to somebody who resisted the change.

Phil: Yeah, absolutely. And I use that example of being a car mechanic and you can continue with it and the advent of various type of computer technology in cars beyond just electronic fuel ignition, rather injection. And how today, my mechanic right down the road, he uses an entire suite of computer diagnostic devices to figure out what's wrong with the car and often to even fix the car. So when you say requiring those foundational skills, or that foundational knowledge of networking is still important, what specifically are you talking about? You talked about how a packet works on a wire. That's fine, I understand what you mean by that. Can you expand on that a little bit?

Brian Davenport: Yeah, so I think the best way to think about this exercise is I think I call it a packet walk. It might be called a packet walk, I'm not sure. But if you just are sitting at your computer, and you pull up a website google. com and you press Enter on your browser, can you think about every single thing that happens between the time you hit Enter and the time the page renders? What is that? What's actually happening from A to B? And so, doing ARP, or doing the TCP connection, or doing the DNS resolution, or doing the get request, or how that packet is switching across different routers and leaving your PC's NIC. And if you can understand that concept, I think that's what I mean by understanding the core fundamentals of how data moves. And once you start learning those concepts, if you're new to networking and interested in it, that's when you'll just know that we live in the matrix. Because when you are then in California at a trade show talking to your wife on FaceTime who is in Maine, and there's no wires, and it's all in real time and you can see each other, you'll realize that none of it's possible, and we live in a simulation and it just doesn't make sense. So understanding those core concepts and building on them will really start to blow your mind when you understand how everything's connected. That's what I like about tech is, we mentioned, it's constantly shifting, but I always like where the more you learn, the less you understand. It's really weird profession that way where the more layers you learn, the less you're like, " How does this even work," which is pretty cool.

Phil: Yeah, in fact, in that packet walk that you just mentioned, you can dig into one of those components and really go deep. You talked about ARP, you talked about DNS resolution, we can spend the next month talking about just DNS and how that works, how it's used for load balancing, how it's used just obviously for name resolution, its basic function, things like that. So there is a lot there. And I think that that's where we are as network engineers today, 2023, is that we are required to have a broader understanding of not just how a packet goes from router A to router B and how a BGP adjacency is formed. It's still important but because of the nature of how applications are consumed, we really need to understand that broader spectrum of what's going on with application delivery. It's just part and parcel because it is over a network now we have no choice.

Brian Davenport: Yeah, for sure. The nice thing with this computer age is, going back to the education thing, nowadays you really have everything there. It's almost too much information sometimes. But resources I really like... This podcast is not sponsored by Udemy, but Udemy I've found is a tremendous resource because those are courses that are typically created by people that are doing the job. And you can find some good creators in there to learn the skillsets that they find important. And I've learned a lot from Udemy specifically. I think Coursera is another one. But other than that, just being able to Google well is a skill in and of itself, I really do think-

Phil: Being able to Google well, find the information.

Brian Davenport: I think that is. More know what question to ask is a better way to say that.

Phil: Yeah, and that's where I was about to go with it. 'Cause you do need some element of foundational knowledge to know what questions to ask in the first place. If you're a blank slate, you don't even know where to start. So you do need that foundational knowledge. And then, you can build upon that. So then tell me what you think are the less technical skills that somebody going into networking really needs to think about acquiring today? I don't want to say soft skills because those are... But more non- technical.

Brian Davenport: What I kind of want to say is you have all these products, or solutions likely that your company owns. And I think that a lot of times I find people might spend time with 10% of the product, or 10% of this thing that they have. And I think, I don't know if it's a soft skill per se, but just having the wherewithal, or the passion or whatever it is to really be an expert in the field that you're in, be passionate about it. It's hard, tech burnout is definitely a thing, but I think the people that excel in it are super interested in learning more and being passionate about the tech they're in. Kind of not the exact answer I wanted to give, but I hope the concept of I think a soft skill to succeed here is having an actual interest in the technology and being passionate about learning more about it and sharing ideas. I always find those are the best engineers to work with are people that are super excited about what they're doing.

Phil: And that's why I asked it that way. I didn't want you to say, " Oh you need people skills." The typical soft skills. I was looking for. What do you think it takes beyond just knowing how to configure a thing, or what TCP flag is? What TCP flag? What do you think it takes, non- technical, to be a good engineer? And, again, without getting into the typical trope of people skills and empathy and stuff, which I say trope negatively. You do need those things. But I think it is more than that. And now as far as passion though, I was never really passionate about networking until I started getting eyeball deep into it. Does that make sense?

Brian Davenport: I mean at the end of the day, a job's a job. But I think the passion of... So what I was going to say is I think a better answer to your question of soft skills may be to understand a problem before building a solution. That is a soft skill that it took me a while to develop where you'd have something you're trying to solve, or maybe a customer asks for something, or your boss asks for something and you think you understand it. And you build this entire solution. And then, you go back and then you get the, " Yeah, this is kind of cool, but that's not really what we're trying to do." And you kind of go through these processes of wasting time. And the other thing is ego loss I think is big. There's a lot of ego sometimes in tech of being right, or wanting to be right.

Phil: Oh yeah, for sure.

Brian Davenport: And I think that being okay with being wrong and being okay with embracing new ideas, and understanding why somebody is proposing a different technology, or whatever are some soft skills that are key there. Passion, I think is for any job you're doing for longevity, you got to have some interest in it if you can. I say in tech, I think it's important.

Phil: Yeah, that makes sense.

Brian Davenport: At the end of the day.

Phil: For me, the passion wasn't necessarily for networking itself as a field, but for figuring stuff out and fixing it. That I really enjoyed. Now, it happened to be networking, so of course I developed a great, great interest in networking and that's fine, they were in parallel, no problem. But I got to say, sometimes I'm in my basement and I'm figuring out why there's a plumbing problem. And I figure out some kind of weird solution. And I watch some YouTube videos and what plumbers do. And then, I fix it and then that's my Saturday. And man, when I'm done I'm like, " Well that was really fun. That was cool." I hated it at the same time because I had a problem with my plumbing, but it was really interesting. Or when my riding mower didn't work properly last summer and I spent half a day trying to fix it and I figured it out, I figured it out. I watched some YouTube videos and figured it out. So I get a similar fulfillment from networking again because you've developed that skill and so you're in there trying to figure out a problem for a customer, or design a solution and then you make it work, and it's very fulfilling. So I think that's where I would agree with you as far as the passion side is doing something meaningful, doing something productive. And it does happen to be networking, which works great. I love it. So they go hand in hand for me.

Brian Davenport: Yeah, totally. And I think it's the next time that lawnmower breaks, or next time there's a network problem, or next time there's a thing and you've gone through this process of solving it, and then you can do it quicker the next time, and quicker the next time you start to master it, I think there's fulfillment in that as well. The more times you solve the puzzle it becomes easier.

Phil: Oh yeah.

Brian Davenport: And there's always new puzzles to solve.

Phil: And you watch one 20 minute video and you're a subject matter expert, that was most of my career. I got a customer meeting coming up, quick 20 minute video on YouTube.

Brian Davenport: Me too.

Phil: Walk in, I'm like SME of the year. So it's pretty...

Brian Davenport: That's the humbling thing too is, like you said, when you think you understand DNS, then you talk to somebody who understands DNS. Or you think you understand TCP/ IP and you put it on your resume and then you have some guy that's like, " Oh you understand TCP/ IP? Okay, let's go." So kind of got to be careful with what you think. But understanding, I think, having that humbling of knowing you don't know everything is critical.

Phil: Yeah. And probably more critical now than ever. I mean 2023 and beyond with the overlays with networks that we don't own like public cloud, containerized architectures with the diversity of technology that is involved with delivering an application to somebody sitting on their phone, or at their computer. And you're right in the middle of it as a network engineer. It's just too much to understand all of it at once and it requires some level of humility for sure. And I never really bought into this idea of meantime to innocence. I don't care for that term, I don't really use it.'Cause back when I was a field engineer, we didn't use Zoom, we were using WebEx. We would get on the call to fix some problem, there would be a server administrator, maybe the application person, a security person, network person, whatever. And we were all working together to figure out what was going on. It wasn't that, " Oh look at that clue, it's not the network." And then, I dropped from the call. That never happened. Granted I did want to find the solution and if it wasn't the network, maybe I kind of faded into the background of the call. But we were all working as a team to figure out why this application wasn't working right, how we got the security breach, whatever it was. So I don't care for the meantime to innocence idea, that philosophy. And I think it's even less so today because you can't know everything at a subject matter expert level in the entire workflow of delivering an application. And so, you have to rely on others in order to be part of that team, in order to make sure that end user's experience using your application is really good and figure out why there's a security breach, why the application is slow, or whatever it is. And I think that's now more than ever. Again, it's a human thing. It's not necessarily a network engineer skill. Just having humility is probably important in any field if you think about it.

Brian Davenport: Yeah. It's a whole nother podcast to talk about silos, and why silos exist, and that kind of thing within organizations maybe for another time. But I do agree teamwork makes the dream work.

Phil: Brian, it's been a great conversation. I really appreciate you coming on. I'd love to have another talk with you coming up this spring, whenever you have some availability. We touched on so many topics today that I think we could grab one of those threads and really, really run with it.

Brian Davenport: Yeah, no, this was great. I've enjoyed listening and if any of you guys are first time listeners, I'll probably post this on LinkedIn, so you found it this way, definitely go back and listen to the rest of what Phil's done. I love the short form of this podcast. And it's been a bunch of really interesting conversations with our founder, and some machine learning stuff. So I encourage you guys to listen to them all. You can consume them quickly.

Phil: Cool, thanks. So if anybody wants to reach out, Brian, how can they do that online?

Brian Davenport: Yeah, please if you are listening to this, connect with me on LinkedIn. So just Brian Davenport on LinkedIn, you'll see a picture of me. That's, typically, the best way to get ahold of me. And I love to see who the people are that I'm working with and what you've done. So find me on LinkedIn.

Phil: Awesome, thank you. And you can find me on Twitter at network_phil. You can also search me on LinkedIn. Just search my name, Phillip Gervasi, Phillip with two Ls. My blog is networkphil. com. Not super active there, but you can find some contact information. Now, if you're interested in being a guest on Telemetry Now, or if you have an idea for a topic, please reach out. telemetrynow @ kentik. com. We'd love to hear from you. Until next time, thanks and bye- bye.