00:00
Welcome to the Cables to Clouds podcast.

00:15
Cloud adoption is on the rise and many network infrastructure professionals are being asked to adopt a hybrid approach. As individuals who have already started this journey, we would like to empower those professionals with the tools and the knowledge to bridge the gap. Hello and welcome back to the Cables to Clouds podcast. My name is Alex Perkins and today I'm joined with my two amazing co-hosts, Chris Miles and Tim McConney. Tim, how are you doing today? Doing pretty good.

00:43
actually just to finish the work day. I'm sitting down doing a recording of the podcast, finishing up a bunch of extra stuff. So nothing crazy today, unfortunately. I'd love to tell you all about all the cool stuff I'm doing, but it's not that cool. That's not cool. Right? Come on. Oh, I'm sorry. You know what? I'm going to let you make something up, Chris. What do you got going on? Hey, I'm doing good. Yeah, nothing really. Well, I am going to play softball later.

01:14
man dream of thinking I could still play baseball. So yeah, I'm going to do that this weekend. Get the ice packs ready. Yeah, I know. But yeah, so how about you Alex, how you doing? Yeah, good. You know, finishing up all those fun maintenance as I've been doing. Friday night, Monday night, Tuesday night, Wednesday night. Today is the only break and then tomorrow we've got more. Every time we get on here, Alex is the only one.

01:40
doing any work. I feel really bad. I mean, that's what it seems like. You know what you do to day to day, Tim? I just sat around, I was drinking. Funny, yeah, I went to play baseball, you know. No big deal. Oh man. All right, well, yeah, let's jump in. You know, today is going to be sort of like a roundtable discussion into just some of our insights into how, you know, your mindset might shift.

02:10
as you transition from a traditional network engineer to a more cloud-centric networking role. So we're going to talk about what kind of things we brought with us, what kind of things we needed to learn or get up to speed with on the way, and things maybe we should have focused more on the start, at the start of our journeys. So kick it off with the first question. Tim, how did you have to shift your mindset from the on-prem networking to hybrid cloud networking?

02:37
That's a good question. So I mean, from a mindset shift perspective, it's such a funny question. How did your mindset shift, right? So I don't know. So let me think about that for a second. So when we talk about mindsets, yeah, maybe I should learn how to talk. When we talk about a mindset shift, I think we're talking about how did we have to just change how we're thinking about networking when we're moving from on-prem to the cloud. And for me,

03:05
I think the biggest mindset shift was just from going from the focus being more on the user and the single experience, either single app or single user experience. In the cloud, of course, you can have users with Azure Virtual Desktop or Amazon Workspaces or something like that, but even then, you're really taking care of apps. You're shifting away from people.

03:33
And you're working, I think you're really starting to work more holistically on the app side of the house in the cloud. I think that was a big mindset was to, you know, get away from individual VLANS, individual ports and individual problems, right? And start working on like app level problems and specifically how the apps talk to each other. And that's, I think that might be the biggest one I can think of, you know, as far as the mindset shift. What about you, Chris?

04:01
Yeah, yeah, I totally agree. I think kind of piggybacking on that. I think like, you know, when you're in the cloud, it's still focused on connectivity. If you're a network engineer, you're still focused on connectivity, providing let A talk to B, etc. Right? But you kind of have to also frame it in the sense of why did they move? Why does your enterprise, why does your company move to the cloud in the first place? So a lot of that is, you know, they're going to change the way that happens.

04:30
because it's probably not running in an optimized fashion in the cloud if you do a lift and shift. So you kind of have to think like a networker in terms of what effects that can have on the application in the first place. You know, typically it's one big monolithic thing running in a data center and you just need to provide connectivity. You know, maybe you're checking some, you know, a bit of the latency.

04:54
from end user to application. But now you kind of have to focus on, okay, what are all the latency concerns related to the application functioning itself? Because if you decouple it, that means you're adding quite a bit of delay into things that previously didn't have a delay because they're all running on the same system, right? So now there's services in the middle. What happens if those things fail? What happens if those things are delayed, et cetera? You've really got to kind of help design.

05:23
connectivity to accommodate for that. Yeah. And real quick to piggyback on that, because I love what you said there. Mindset shifts, it just occurred to me that a big mindset shift is the way we approach redundancy, right? Like if we're going to approach redundancy in the cloud, it's going to be, it's no longer like, oh, well, we'll just build two racks and we'll replicate two racks of routers and switches and application and VM hosts and everything. Now it's like availability zones and regions and stuff like that.

05:52
It's different, but it's kind of the same, but I still think it's different. I don't know, what do you think, Alex? Yeah, no, I mean, I fully agree with both of you guys. A lot of this is, like in Tim's words, you really have to be able to step back and look at application architecture holistically. And Chris said this as well, decoupling applications, right? Everything's not so tightly coupled. A lot of things are more loosely coupled. Everybody's talking about containers.

06:19
different ways to package up their applications. And I'm going to elaborate a little bit on Chris's point about there's a lot of services in between. Everything is an API now. Their services are all being consumed by an API. So there's just a lot of data flows. You really have to not just know networking. Like Chris says, not just A to B anymore. It's A to C to B to D to everything. There's so many more interconnected pieces because it's more of like a distributed system.

06:49
to some, you know, E to some PaaS service that you have no visibility on in the first place or... Yeah. It's absolutely true. A lot of these things also have like added components for security, like identity built in, right? That wasn't there before. That's more going to fall on the... Yeah, micro-segmentation. ..application developers for sure. But like, you know, that still comes into play with you. You got to be able to, you know, authenticate based on identities related to the CSP and their native constructs, right? So, yeah, you just kind of...

07:18
It changes the way you have to look at a problem. You definitely get to leverage the CSPs for their strengths, right? Like Tim brought up redundancy. That's a lot. A lot of that's built in for you. You don't have to mess with that. You don't have to focus on primary, secondary, tertiary so many times. It's really just like you highlight three check boxes and your redundancy is built in. But there's other major points that you have to focus on. It doesn't just get ultimately easier. It's a changing mindset.

07:48
And it's encouraged by the CSPs, right? They're like, please click these boxes. And you might not even know, right? That's what you should pay for. You know? Yeah. Right. Yeah. But, but, but you, I mean, that's, to be, to be honest though, you always paid for redundancy, right? Like if you build a second rack in your data center, you're still paying for redundancy. Right. Of course, the, that we get into the whole Opex versus CapEx model of, you know, you pay for redundancy once and then you depreciate it versus.

08:15
you're paying for redundancy as long as you're in the cloud. You know, that's a whole other thing. All right. What about what skills or mindset, you know, since we're on that theme, what kind of things did you guys bring with you transitioning? Yeah, so I can kick it off. So, you know, kind of just adopting from what I did as a networker in the on-prem environment. I think you have to just have a willingness to get your hands dirty with the technology. You gotta...

08:45
You gotta go full in and you can't just read theory and things like that. You gotta, you gotta get some hands on with it, just like you do in the on-prem world. The nice thing about it is that in the cloud, that nearly everything that you would want to test is ultimately at your fingertips as long as you got a credit card. You know, I mean, I can, if I wanted to spin up a, you know, a full data center to lab with in the on-prem world, then you know, that's, I gotta get on eBay, I gotta like buy some gear. I gotta, you know.

09:15
I got to have a rack running in my house and probably piss off the rest of my family. It's so loud. But like in the cloud, I can do that all in a day for a few bucks. You know what I mean? Like I can, you know, stand up a fully global network and, and, and just make sure, you know, my proof of concept is done within a few hours. Right. So it's, it's, but you got to be willing to go in and automate it. Yeah. I mean, that's, that's another piece. You got to be able to test that. Right. So you can run that, run the automation in your environment, make sure it works. And

09:44
and replicate that out to wherever you're going to take it. Yeah. So, yeah. I like what you said there, actually, with specifically having it all at your fingertips. There's things that you can play with in the cloud that you could never hope to even try to replicate in an on-prem or even in a virtual environment. You can't replicate a CDN. You can't do a virtual CDN where you're going to... A CDN, I mean, content delivery network, right?

10:12
you've got this global delivery network, you know, the CSPs have that at your fingertips. And how would you get that experience with a CDN type of thing outside of the cloud? It would be very, very difficult. So I think that's great. Yeah, I mean, that's great. The CDN example is perfect because I mean, how many people were dealing with a global network that you can just spin up with a couple clicks of a button? That's crazy. I mean, it's...

10:39
This point has been made a hundred times, but you also have to, you also have to be very careful. You don't leave said thing running or else you will pay for it. Yeah. There's, I think there's that meme where like the homeless guy is like sitting on things like, he was like, what did you do in a poem? He's like, I left an EC2 instance running for a month. You know, it's like, it's so it adds up. So you have to be, you have to be very, very dedicated to turning things off. Right.

11:08
That's the dark side of having everything at your fingertips is that it's that easy. It's like the first hit's free, they'll get you going and they'll be happy to keep taking your money. Yeah, absolutely. Yeah, I think for me, I come from a much more data center focused world. So a lot of this stuff is kind of things I've already been thinking about a little bit before the cloud, but it really amps up to another level like load balancing. Right? There's just...

11:35
Again, back to the looking at the application architecture. There's so much to think about that goes into how front ends and back ends and middleware, like everything talks to each other. And a lot of this, there's tools that these CSPs provide that make it even easier to do these things that you might not have ever had on-prem. What did you kind of bring with you there, Alex? Let's just keep you going with it. Yeah, I mean, I guess that is the main thing, right?

12:05
data centers is notorious for a lot of fabric type stuff, right? So a lot of these ideas of virtual and logical constructs and devices and stuff that's like, when you first start learning about it, it's kind of hard to wrap your mind around things. Uh, but the cloud is full of this stuff, right? Like you really need to know VWAN, virtual WAN, right? Like there's, there's all these things that are just abstracted away from the layers below them.

12:35
And you really got to look at that, that next level up, take a step back and look at it. Yeah. I mean, we live in a world of overlays, right? It's just, you know, building one thing on top of each other to solve a different problem. Right. Yeah. So it's like, I mean, even, even in the cloud, that's, that's no different. Like if you can't get something to work exactly how you want to build an overlay to, to add, to get the raven in the traffic to transition the way you want to, whether that's using IPsec or GRE.

13:03
wherever the CSP will permit you to get security, things like that, you know? So, yeah, so I feel like that's still very prevalent, but it's probably not the decision you should make every time, but it's definitely there. It's available to you. There's a, I got this mug from the other Discord server, and it says infrastructure never goes away, it just gets layered. And I thought it's perfect, right?

13:27
It's so true. We don't rip out the pipes. We just build new pipes on top of the old pipes, right? I remember Dave Smith from INE used to say, like, if you can't solve the problem with a GRE tunnel, you need to use more GRE tunnels. I don't know if you guys ever heard him say that. But it's absolutely true, right? And you're right. We live in an overlay world, especially, and the CSP is just one more, not one more overlay, but it's just like...

13:57
the enterprise or the place of overlays. You just don't even see the overlay. It's just part of the experience, right? And so you can build your own overlay on top of it, but the overlay itself is the experience, right? OK, so from a what did you bring with you perspective for myself, for me, and I think you and I probably have a fairly similar answer, Chris, because when we're learning, one thing that studying for the CCI will do for you

14:27
methodology for studying and learning new things very quickly. So, you know, I kind of came with this voracious appetite to lab, to read, watch videos and all of that and just kind of incorporate it into what I already knew. I mean, obviously, you know, we brought with us and I brought with me rather a, you know, a knowledge of, you know, routing and switching and all of that. But the routing is useful, the switching not so much, right?

14:57
I would definitely say the biggest thing I brought with me. Yes, exactly. Don't get me wrong, I'm fine to leave spanning tree in the trash heap of history. I long for that day. But yeah, if I had to pick one thing that I would definitely brought with me, it's that mindset of being able to quickly learn something and just consume it and become good at it. Right.

15:23
What about things you had to learn along the way? So Chris, let's kick us off with this one. Yeah. So I kind of had two things that really hit me. And the one was, you know, focused more on the technology side. And then, and then the thing was more on the, because I worked specifically in professional services, so I'm working a lot with, with specific customers doing designs, things like that. So another one was more project based, but from, from a technology perspective, I felt like.

15:53
You have to learn, you have to learn to design and solve your issues within the grounds of what the CSP exposed to you. Right? So like you, you don't get to tweak every nerd knob, use every protocol that you feel is best for the job, right? Like you, cause that's always going to be subjective in the first place, right? What's best. It's like, it's like that same thing as like, have you ever seen it? You ever moved on to an enterprise network where the guy was studying for, guy or gal was studying for the CCIE. It's like, he obviously just added all this shit in to like lab with it.

16:23
So you don't get to do every bit of that. And that's because I think that's ultimately because the CSPs aren't inheriting, you know, 40 plus years of technical debt from customers. They don't have to add. That's right. They don't have to run RIP or let you run RIP because they have some big customer that wants to want to run RIP. They don't have to do that. So you got to kind of work with that, right? You got to know how you're going to monitor things.

16:52
Sometimes that can be a very huge pain, you know, turning on flow logs and things like that. You don't get to see the level of detail that you can expect in the on-prem world sometimes. That is getting better for sure. But you really got to work within the constructs of what they'll let you do because you are doing it in someone else's playground, right? So that was specifically for the technology piece. Now on the more project side of things,

17:22
One thing that I did not expect that really floored me was in the cloud, projects move fast. Everything is like... Agile. Yes. It's definitely adopting that approach. Large designs can be fully put together, documented, and implemented within a matter of weeks. You're not waiting on hardware procurement. You're not waiting on shipping.

17:50
Ultimately, most of the time what you're waiting on is red tape. It's like some people, or some enterprises have a very heightened level of cloud maturity. So they have very strict processes that they need to follow. I'll be honest, that's the time when I'm twiddling my thumbs or something like that. But everything else is like boom, boom, boom. It's quite amazing. I don't know if you guys have had the same experience, but it's wild.

18:15
There's something to the, and I'll probably just keep saying this throughout the live of the podcast, there's something to the forced elegance kind of, you know, of designing networks for the cloud that means that you don't have to, you know, end up in a screaming match between three or four engineers about the best way to implement, you know, something. There's really going to be, if not a best way, because of course we know there's a hundred ways to do it, still, there's going to be...

18:42
ones that aren't going to, you're not going to get into an argument about whether OSPF or EIGRP is the right way to go, right? It's not going to get that granular. So yeah, I think I agree. The agility is a little line boggling. We can still have that argument. That's fine. That's for later. We'll do that in another episode. In that case, we're never going to fight because I think nobody here disagrees on that one. Yeah. I mean, I think like you guys are saying, it's much more...

19:12
architecture, architecture based, right? Like you're not, because you don't have all these extra protocol options, right? You're, you're much more focused on how to make an optimal architecture than an actual optimal OSPF design. So I thought it was funny too, Chris, when you're bringing up your technology section, something that always stands out to me is sham links. Oh man. I had said, I've seen some just crazy.

19:38
Crazy things that have taken me down some rebels in the past, right? Has anyone ever actually seen a sham link in production? It's one of those nerd knobs that I've just never actually seen in the wild. What? Really? No, I've never seen that. I've never seen that. I've seen a very over engineered network. I haven't seen that. Confederations, we can assume, it's just, it was just, you'd have to have a really good use case. Like you would have had to build it Greenfield with Confederation because, you know.

20:08
Anyway, sorry. Yeah, no, I, wow, sham links in the wild. I've never actually seen it. I learned it and I've never actually seen it. So, but anyway, yeah, so nerd knob wise, there's lots of those things that don't exist in the cloud. Like you said, Chris, there's no technical debt that we had to drag along with us to support, you know, IGMP V1 and like all these ancient protocols and design options that really aren't really good.

20:35
design options except for the one corner case they're built for that kind of stuff. Right. And that's not really even a stab at the on-prem vendors. It's just like, it's just that they- No, it is what it is. It's a problem. It is what it is. Like, yeah, like they probably have some enormous Fortune 500 company that needs this feature and it's got to go in, you know? Right. They can't get rid of that business, right? So it is what it is, but benefits us.

21:00
When I worked at Cisco, man, that's all you saw. You see it a lot actually. And I'm saying Cisco because I worked at Cisco, but I absolutely know this is every vendor, right? So it's like one of those things where, for example, IGMP v2 is still the default on all Cisco devices because think about the implications if they were ever to change it, right? It's because the config would drop out. The config, you know, and the new default would be like, say v3 and then all those configs that are in the wild and out there and on those devices would. Yeah.

21:29
would brick essentially because the default would change. So I see the challenge, right? It's a huge challenge. Yeah, it's probably why VTP is still out there. Man. VTP for life. Oh, man. I actually liked VTP when I first learned about it. I was like, that's actually a really cool idea. Oh, those people are in. Jeez. Version 3 was not that bad. They fixed all the problems. Version 3 was not that bad. Oh, man. You know?

21:58
Oh, so I didn't answer this. I just realized I didn't answer this either. So what did I learn along the way? I actually had for me it was more like unlearning. I don't know if you guys are into this at all. You know, you had to it was almost like you had to learn to let go right because you're you go in you know I went in looking for that level of granularity that level of control to build these networks and you know They're not there and so you kind of almost panic a little bit like hey, I got a how am I gonna do? I'm gonna make sure that this works, right?

22:26
And so for me, it was learning to let go, actually, was the hardest thing, was to unlearn that. So that was for me. I mean, for me, again, data center background, I didn't know a whole lot about WAN technology. So I'm not like a BGP guru or MPLS or any of this stuff, right? So taking away everything that I know, OSPF, you had GRP. I was like, what do I do? How do I connect everything right? No, it wasn't like that. But.

22:55
But you do have to pick up like more specific skill sets, at least in that regard. WAN definitely, WAN technologies definitely help a lot. Yeah, don't worry. We'll teach you MPLS, man. We got you. Yes, for all the times you're going to need MPLS on the cloud. We'll go ahead and help you out. Oh man. No, but yeah, it's so kind of, yeah, piggyback on what Tim said too, like as much as you had to unlearn, it was just like, you know, because we've gone through such...

23:23
so amount of detail with routing and switching over the last 10 years of my career type thing. That's ingrained in my mind. And there was a lot that I had to take out. Like, look, yeah, in the on-prem world, this particular behavior had to exist because of this RFC and this yada yada. But like I said, it's not your playground anymore. You're playing on someone else's terms, right? They get to call the shots on how things operate. Obviously, they want...

23:52
want the bar of entry to be relatively low. So they try to make, you know, it's going to be, it's going to be pretty like for like in most cases, but like, like just to call out an example, one thing I had to unlearn kind of is like every, like every NIC that exists in the environment basically has its own routing table. It's associated with like everything is egress-based. Like just because like there's no shared routing tables, ultimately whenever you're doing like

24:21
the routing perspective from the device. And it was, that was a very big, like the hard thing for me to grasp for the longest time. I don't know why, but yeah, I remember I was like, first really cloud based project I was ever on. It's like, I was doing the on-prem stuff, the SD-WAN piece, and we had an Azure platform architect doing all that. And, you know, he would explain things to me, and I was like...

24:45
I was like, why is that even a problem? It's like, I'm advertising the routes, like everything's there. And he's like, no, it doesn't, it doesn't work like that. Like, yeah. So it was a propagation and all that shit like that. So yeah, that was, that was a big, big shift. Don't forget to propagate the routes. Do the packet block, right? Like what's the most common interview question for a traditional network engineer. Right? Tell me the packet block. Hey, you're on the computer. What happens? Yeah.

25:13
I always like to get insanely specific with those questions that waste people's time. But yeah, so in the case of electricity, it goes through the wire. It's one and zero. Right, yeah, are you using 120 or 240, right? Oh, okay, I don't know. I don't know that either. It's electricity. Yeah, I joined. How old is it? It's electricity, I see.

25:39
I got into networking so late, I felt like all this layer one shit, I didn't have to learn any of that. I've never crimped a cable. No frame relay? Well, it's layer two, but yeah. Frame relay, I did have some layer two, but yeah. See, I miss that. Yeah. It's nice to leave some of that behind for sure and just let somebody else take care of that. Don't give me that. Yeah.

26:06
I mean, you still end up having to deal with it, right? Like if you're going to install a direct connect layer, one's kind of important, you know, later on, right? You can't leave it a hundred percent behind. Well, that's the whole thing of hybrid networking, right? It does. Yeah. Okay. Yeah. No, I mean, we'll get into that later. Swapping fiber pairs and shit like that. That doesn't go away. You're still doing that. So, all right. Hybrid's always a good thing. When you bring it in. Yeah, absolutely.

26:35
All right, what's something you wished you had focused on more when you started your transition? Tim, you're up. Yeah, I'll go ahead and kick us off on that one. So, when I started the transition, I wish I had spent a little bit more time probably working on the app layer. Like, what I mean by that is not working on the app layer, but like, understanding it, right? And you've mentioned multiple times, Chris, about the...

27:01
decoupling, right? And if you lift and shift your stuff into the cloud, you're going to be paying more. It's going to be familiar, but you're going to be paying more for it. It's going to be monolithic or near monolithic, right? But if you do it right, and if your workloads are good for the cloud, meaning that they can be elastic and everything, and part of that decoupling piece is elasticity, by building the app that way and doing that decoupling, you're also increasing the amount of...

27:30
of communication, right? So the way the app is going to communicate, the way the pieces of the app are going to communicate. And that's like 100% of what cloud networking is about, right? Like that's minus what goes back on-prem when we talk hybrid, right? When we're talking cloud to cloud, cloud inside cloud, multi-cloud, whatever it is, we're talking about apps talking to something. They're talking to a PaaS service, they're talking to a SaaS service, some data transformation type stuff or whatever, right? Just some pieces of the app.

27:59
And so if you're building for cloud scale, building for cloud architecture, the cloud networking piece, you know, fits right underneath that about how do things talk to each other. So what I wish I'd, so I dove right into the cloud networking piece. I was like, I'm going to learn everything there is to learn about cloud networking. I'm going to understand it. And I wish I had, no, don't get me wrong. I mean, I still needed to know all of that stuff, right? But the context would have been a little bit more useful, I think, of understanding a decoupled app.

28:27
How do they need to communicate? Like load balancers, private links, stuff like that, right? That context as I went, and I think I probably made this same mistake with my on-prem or CCNA or whatever, is I was so focused on the networking piece of it. How does the network work? How does it work? And I think a lot of engineers do this, and you guys can tell me if you agree or not. A lot of engineers focus on their piece of it, right? I live at layer three, I live at layer one to layer three, or layer four, I guess, and that's all I care about. That's what matters.

28:57
So I wish I had spent a little bit more time getting the context of it than just learning the cloud networking. Now, I've since come back and fixed that. But if I was going to give advice to somebody who was starting, I'd be like, don't... I know you want to roll right over this crap that you're not going to be responsible for, but you need to pay a little bit of attention about how those things talk because that's what you're going to be doing. So that's for me. That's my answer. Yeah. I mean, I think once you start even looking in the cloud, if you're...

29:26
If you have a networking background, hell even sometimes a security background, it's like, let's say you jump in, you go down a certification track. This is what I did. So I was like, when I made the decision I was gonna move to cloud, it wasn't really, like I wasn't working in cloud at all. Wasn't working with it, never logged into AWS ever. So like when you go down a lot of these training programs, I feel like, for example, let's say you do like the AWS Solutions Architect Associate or like the Azure Architects equivalent.

29:56
Um, that's, those are solutions architect focused exams for the, you know, the, that entire CSP environment, right? So they're, they're, it's not just networking networking is a piece of it. Um, and another one, and if, you know, they all release specialties around this, but like you, you are going to spend a lot of time learning about compute and storage and security and, um, um, I am, um, identity access management, which is, uh, I am in storage are two things that I never wanted to learn.

30:25
world and you're almost forced to. I think it's easy to, yeah, just felt like gag me with a spoon, man. I can't, I do not care about storage. I hate storage. And so it was like, I think it's easy to lose sight and maybe think that it's not for you or think that there's no place for you there because of how focused the other technologies are when you start those tracks. But yeah,

30:55
Get out of it what you need to, you know, like for me, if I'm gonna learn about the storage products that a CSP offers, what I'm gonna take away is how does it talk to the rest of the things? How do I need to integrate it? And that's it, that's all I need to know. I don't need to know, you know, the RAID configuration and all that shit, you know what I mean? I don't need to retain that, so. You don't need to be an expert, man, that's true. No, no, no, absolutely not. Certificate-based authentication with a laugh, right?

31:24
Yeah. Exactly. Generate your SSL cert and put it on the WAF and all of that, right? Yeah. I think that's great. What about you, Alex? I mean, I'm going to just, again, we're kind of piggyback right off of the same thing you guys are saying. I wish I did come at it much more from kind of understanding what the cloud does for devs, right? Because it's, I mean, I'm not going to say it's only for devs, but it's made for...

31:53
agility, they want to move fast, elasticity. Like they just want to get in there, deploy their apps and just infrastructure just needs to be there, get out of the way. Right. Like there's some paper, like your network is in the way of my application. I'll have to find that and put it in the show links, but it's true. I mean, it's, you know, you really have to come from a mindset of what it's enabling and what the pain points are for the devs and then understand why things are so simple.

32:21
that the CSP doesn't give you all these nerd-dums because they don't care. They just want you to get the infrastructure up and running as simply as possible. They don't need your corner case sham link, you know, BGP confederation solution, right? They just, yeah. It's very true. The cloud wasn't built for you, it was built for the developers. Exactly. That's true. And you need to know how to work with them. Yeah, the developers are the reason it took off in the first place, right? That shadow IT. All the shadow IT shit. Yeah.

32:49
It's because they weren't getting what they wanted from the IT segment of the organization. So they went out and bought it themselves. They built shit not in the best way from every... The computes now, how it should be, the storage, the networking, all of it is jacked up. Everyone else had to catch up because the devs are making the apps that make the money. Do you want to wait two months to...

33:16
you know, for a server and some firewall rules to be configured? Or do you want to just swipe and I got everything I need? There's there's a hard to swallow pill I hand out probably more than I should. But and there's no anyway. What I like to say is that basically, you know, for especially the network engineers that have that love to gold plate and like build these super complex designs, I like to say, look, look, man, I don't know how to tell you this, but the hard to swallow pill is that if the enterprise, if the business could get by without you, they would.

33:46
Right? Like you are, they don't care about your elegant design. They don't care about, you know, 10, you don't care about all the redundancy you built in, except as far as how it enables devs to build apps that generate revenue. That's what they care about. And that's just the way it is. And you just have to be okay with that. I will just add to that. Like maybe hybrid, there's more of an argument here, but look at companies like Netflix that are just in AWS. How many network engineers do you think they actually have on staff?

34:15
Right. It's like hardly any compared to the size of the devs they have. It's astronomical distance. Yeah. I mean, it's just the way that is. The same as on-prem, right? If networking is not the business, you don't get the glory, right? You're just a cost center. A plumber. Just how it is. Yeah, exactly. That one I don't agree with. I've never, I've never agreed with the whole cost center thing. And I get it that, you know, hey, it costs money, but like, and this one bothers me all the time.

34:43
Cause they'll say, Hey, you know, it is a cost center. I'm like, all right, it is a cost center. So let's go unplug the phones, unplug the, unplug their computers, turn off the website and let's start taking orders. You know? So anyway. What's up? What's a prettier way to phrase it then? What do you want to call it? What's that? If you don't want to call it a cost center, what do you want to call it? Pick a pretty. Oh, it's a cost. Oh, it's a revenue. It's a revenue enabler. It enables revenue straight up. It's straight up enables revenue.

35:13
or empowers, I don't know, whatever. Just I'm not a marketing person, okay? But it's not a cost-setter. It's integral to the foundation. Right, it's like plumbing in a house. You gotta have it. You can't do business without us, you know? I'm not a networking engineer. I'm a revenue strategist. There you go. Revenue strategist, there you go. Now we gotta go to marketing school before we can come up with some good names. Yeah.

35:38
So this actually dovetails into my last question, actually, pretty well. So I'm going to kick this off and tie it in. And the question is, what new things are you responsible for now as a cloud network engineer? And I'm going to go a little on the limb here and say a little, talk about a different topic. But I actually see the infrastructure as a whole combining more as it comes to the cloud. So much more like platform engineering teams.

36:05
So it's like all the pieces are brought together, right? You have like the server admins, the network admins, the cloud enables all of you to work together much simpler. And that's where a thing like a platform team would really shine. Cause you don't need a whole network team of 10 different network engineers tweaking everything. You need to be able to integrate just the infrastructure as a whole, provide it to the devs so that they can consume it. Yeah. I mean, you guys agree, disagree, Chris, Tim? Yeah, totally. Yeah. I mean, it's,

36:35
Yeah, it's definitely shifting towards a more platform-engineered centric thing, right? Yeah, absolutely. Well, especially because of the way the cloud is built, again, for devs, right? So much of that ends up in the cloud, kind of almost collapsed, right? Like load balancers are very... Like on-prem, you may or may not deal with load balancers, depending on who owns it on-prem. But in the...

37:03
In the cloud, it's very much a network, outside of the application load balancer, right? The one that actually terminates SSL tunnels and does all that. Any kind of load balancer is definitely well within the realm of network. So there's definitely some collapsing of infrastructure and in the cloud. And it's bringing in concepts, right? Like you got gateway load balancers now, you got just the normal network load balancer, but it's integrating a lot of these concepts that weren't really that...

37:32
well meshed together on-prem, you know, enabling more elasticity for the network, I guess is a way to put it. Yeah, elasticity and just that's pretty good. A lot of these like technology integrations that haven't been there in the last, you know, five, ten years, you know, like you mentioned Gateway Load Balancer, you know, that's adding that's adding Geneva on top of it. So like the, you know, the whatever the NBA you're going to use has to be

38:02
You know, it's just a... You want to tell everybody what Geneva is in case they don't know? Oh, yeah. You mentioned this. So I'm definitely... I'm not going to ask you. I'm just saying you mentioned it. Yeah. So I mean, Geneva is a generic encapsulation basically. So it's a tunnel protocol. Yeah, it's a tunneling protocol, but just, you know, the way AWS is using with gateway load balancers that basically if you send...

38:28
An endpoint, a gateway load balancer endpoint can exist within any VPC, any network that you have deployed in the cloud. Anything sent to the endpoint is basically encapsulated in Janee, sent through the load balancer to an NBA appliance, an NBA network virtual appliance. It could be a firewall. Usually it's going to be some kind of firewall or IPS type thing. Just that bump in the wire.

38:54
type behavior that you have on the ground. That's what they're looking to accomplish with that. So, you know, that was huge when that launched. And, you know, I feel like, you know, they're adding more and more things every day. I feel like I see a lot more IPv6 related news lately. So that's another thing to think about. Yeah, a lot of the time, yeah. Agreed. Yeah. Yeah, no, I mean, gateway load balancers are great, actually a great example, right? Like that...

39:17
doesn't exist and probably didn't even really need to exist on-prem because of the way that it's built on a you know CSP is built on top of a fabric right you know you don't really have that unless you had something like you know i guess and maybe maybe they did have something similar Alex with like ACI yeah like service policy yeah policy-based route of service chaining there's all kinds of okay integrations like that it is a service chain it is a geo geo game load balancer is a service chain so so that's

39:43
And we'll get into that, right? We're not going to cover that on this episode. We've got lots of episodes plans where we're going to get into that, hey, how does it work on prem and how does it work in the cloud and stuff? So don't want to get too far out of ourselves. But I, but just pointing out the way you mentioned about the collapse of infrastructure and kind of new infrastructure that's kind of come, that come into the cloud. It's, it's definitely interesting. That's the new stuff to be responsible for. Yeah, absolutely. Absolutely. All right. You got any other points? Yeah. I wanted to.

40:12
kind of home back to a previous point I made. So like, if we're talking about what new things are you responsible for, and I mentioned this earlier, but like a cloud, or sorry, an enterprise's cloud maturity really kind of governs this, but like, you know, some are very strict, have a lot of oversight that, you know, you got to follow these very, you know, closely documented procedures to deploy a VM in this account, et cetera. Some are flying by the seat of their pants, man. Some are just...

40:39
Some are just spinning shit up the same day, they're deploying to prod on a Wednesday morning. You know, they're, it's like you have both ends of it, or things are very rigorous or things are very loose. And I think as a network engineer, you kind of need to understand that that's potentially how the business is going to operate, right? It's going to want speed and you need to kind of enable yourself to accommodate that kind of speed. You got to be able to automate shit. You know, you got to be able to...

41:08
to turn things around very fast because you don't have to build a bill of materials and fire it off to the vendor and wait six weeks to get things in. You got to be able to turn things around, right? Because you don't have to wait. Yeah. Don't be the bottleneck, right? That's it. Don't be the bottleneck. You said it, Alex. Don't be the bottleneck. That's so true. It's a huge, huge deal in the cloud, even more than it was ever.

41:37
on-prem. Yeah, because now there's no excuse, right? Because devs are just like, oh, I'm done. I'm already done. I can spin up everything I need to while I was waiting on these guys. Yeah. But the good news is that the cloud does give you, as a network engineer, does give you that agility to be just as agile, right? You can be just as agile as the devs can be, right? Yeah. Just to add on that, you don't have to be the balance. I don't have to answer this question earlier, actually, but something I wish that I focused on more before I started the transition was...

42:06
was that idea of infrastructure as code in like CI, CD, five more years and things like that. I think I had issues understanding where it fit in to my day to day as a network architect or network engineer on, cause it didn't quite make sense to me, but in the cloud that is like, the devs have been using this stuff for years. Oh yeah. It's like, so we're trying to shoehorn. Table stakes. Sometimes they don't work. Like sometimes it's a little clunky, but you know, it's-

42:35
I've had to learn that in the recent couple of years. And it's a lot of trial and error. It's a lot of you doing things not how they should be done. But yeah, that was something I wish I had focused on prior to this. Did either of you go through the DevNet Associate, like the Cisco DevNet Associate? Did either of you actually do it? I don't remember. I did. I did fail that three times. Oh, that's fine. I'm sorry. I don't mean to bring up like, sword, sword. I learned a lot. I just never passed the test.

43:06
Okay, but the thing is you actually might understand what I'm talking about then when I say that actually the problem that I had with IAC from a traditional networking perspective was that I felt like the IAC was light years ahead of the actual ability to execute and do IAC with the gear. You know what I mean? The gear, again, we're dragging around 30 years of technical debt and trying to bring these IAC principles and it's tough. And so you end up working a lot.

43:35
There's a lot of massaging and there's a lot of stuff like a genie, like the templates and stuff for interpreting the templates and like, and like, you know, interpreting the output and turning it into something machine readable and all of that, like there's a lot of massaging that goes on. And you, and, and one more thing the cloud allows us to do is, is to not have to bring that kind of technical bet either. You can build a Terraform provider.

44:01
And the CSPs have these Terraform providers that you could just slide in like butter, right? Like it's that easy and you could instantiate and build these. So yeah, this is, oh man, I can, I can rant about this for hours. We should have a whole episode where we talk about this too. We'll have a whole episode. Yank, Yank, Netconf, RESTconf, like there's, there's just band-aids that we were trying to slap on and so that we could fit into these updated models. Yes. Yeah. So we can, we should do a whole episode about this and I think we will, but. Yeah.

44:31
I feel like that was the thing that kind of deterred me from the automation piece early on like in the early days. It was like half the stuff was being done via APIs and half of it was with, you know, Yeah, it was no standard. Yeah, no standard. Some kind of specific code that the vendor wrote, but then also like they didn't write it for this. So you're screen scraping for it and then they change the outputs and it breaks everything. There's a lot of screen scraping. Yeah. It's like, oh, here's a standard, but oh, by the way, every vendor has a different standard.

44:59
It's the point of the implementation of that. The screen scraping was probably the worst, probably the biggest example of the problem, if you will, is that if you have to resort to screen scraping and then using like Genie and different libraries that were written to interpret the screen scrape, if the vendor changes one thing, like you just blown up any kind of IAC you wrote based on screen scraping. And anyway, not to, again, we can rant about this all day.

45:27
We should probably, we'll come back with a whole episode on that, but we should probably wrap it up soon. Yeah, close to time. So yeah, that's our show for today. We want to thank you all very much for listening. Please reach out if there's anything we may have missed or you feel we should have added in. You can connect with us on social media. You can find us on Twitter at Cables2Clouds with the number two, Cables2Clouds. You can email us, cables2clouds.gmail.com.

45:55
Go to our website at cablestoclouds.com, as well as find us on the Art of Network Engineering website. And all the links and everything to the socials will be there as well. And also I want to shout out the A1 Discord. You know, all three of us are pretty much, one of us is probably always, is going to be on there at all times. So we're always on there. And we'll link to the server. Alex is the only one working. So we're all.

46:19
Yeah, that's true. Yeah, I'm on there all day. I don't, I don't, we're in between drinking. Exactly. Yep. So yeah, yeah, lastly, don't forget to share this podcast with anyone you think might be interested. Smash that like button. Oh wait, hang on, that's, that's YouTube. Yeah, there we go. It'll be on YouTube also. Smash it. Smash. Oh, that's true. We're on YouTube. So smash that like button, please. All right, guys. All right. Till next time.

46:48
Hi everyone, it's Alex, and this has been the Cables to Clouds podcast. Thanks for tuning in today. If you enjoyed our show, please subscribe to us in your favorite podcatcher, as well as subscribe and turn on notifications for our YouTube channel to be notified of all of our new episodes. Follow us on socials at Cables2Clouds. You can also visit our website for all of the show notes at cables2clouds.com.

47:16
Thanks again for listening and see you next time.