¶ Cloud Network Engineering Overview
So there's the cloud network engineer that's managing the infrastructure that runs the CSP , and then there's , like the cloud network engineer that would say , build for enterprise , you know , using the constructs and primitives in the cloud . So yeah , so which one are we ? Which one or both are we ? Are you kind of thinking about here ?
Tim , excellent question , excellent question . So the one that I'm talking about today and we can talk about the other one as well the CNU cloud network engineer or cloud network architect he or she is responsible for the body of work . Where is the body of work located ? It starts from your edge device on the on-prem side .
Whatever you have could be a router , could be a firewall . Usually , that's pretty much the boundary that we define , all the way to the point where the cloud infrastructure engineer takes over .
Welcome to the Cables to Clouds podcast , your one-stop shop for all things hybrid and multi-cloud networking . Now here are your hosts Tim , chris and Alex .
Hello , howdy , good morning , good afternoon , good evening wherever you're at . Welcome back to another episode of the Cables to Clouds podcast . My name is Chris Miles , I will be your host for today and joining me , as always , is Tim McConaughey , everyone's favorite friendly face to see on this podcast . Today we have a really special one for you guys .
We're going to be revisiting a topic that we've kind of talked about a little bit , but we wanted to bring a blockbuster guest to kind of talk about this topic and if you're not familiar with Cam , he's pretty prominent in the world of cloud engineering .
I think he's one of the first people I've seen giving talks and things like that , talking about specifically cloud network engineering . So , cam , really excited to have you on to discuss what it takes to be a cloud network engineer . So before we hop into it , I'll give you a minute . Why don't you go ahead and introduce yourself to the audience ?
Awesome . Thank you so much , chris , and thank you so much , tim for having me today . So , yeah , as you mentioned , my first name is Cam and well , I've been in this field for about 23 , 24 years and right now , with Oracle Cloud , I'm responsible for the network engineering and the pre-sale side .
My teams are responsible for anything networking and team members are located in India , europe , us East , west and Central helping thousands of customers . Very happy to be here .
Awesome . Yeah , thanks for joining us . So , yeah , let's not waste too much time , let's get into it , right ? So we kind of started this whole podcast talking about cloud network engineering and our specific journeys into the realm . So for the listeners today , I think we want to get into you know , how exactly do you become a cloud network engineer ?
We've talked about this a bit in the past , but we want to expand upon it and kind of give a new , fresh take on it now that we've seen the career grow quite a bit since then . So let's start off with the definition , right ? So what is a cloud network engineer and how are they different from a traditional network ?
That's great question , chris . So to answer that question , let's just go back to maybe the 90s . Right in the 90s we had a job title I'm pretty sure some people remember that network admin or network administrator or system right , that person would be responsible for pretty much anything . He would do the printers , servers , clients , even sometimes cables .
You have storage . He would also configure the storage and pretty much anything . Well , the world changed toward the end of the 90s . Now you have the world of Active Directory , so another identity system , early 2000, . If you look at the job descriptions you'll see a little more toward the networking world and you will see networking keywords showing up .
Now you have more IGP and some BGPs . And on the one side still we have a lot of ATM and T1 , frame relay . I remember when I passed actually failed my first CCIE service provider . That was an ATM exam . So we configured ATM interfaces . We spent a lot of time on LS 1010 and platforms like that . That was early 2000 , kind of mid 2000 .
You can see our identity is shaping and forming . So now you have a lot more going on on the WAN side and LAN . On the WAN side , of course , cisco released Cisco WAZ , a lot of countries , including Australia .
Back when I was in Australia , there was a very , very popular platform alongside Riverbed , and MPLS started Takeover and on the land side we had quite a few new technologies . Back then we had OER , which later became performance routing . This was the world in 2000 .
So , as you see , the job description is kind of changing and the title official title of network engineer or senior network engineer now is being created Into 2010, . Now a little bit of automation . Before that , people would do automation using things like Perl . Now , 2010 , 2011 , 2012 , now you see a lot of Python coding and automation .
At that point , a group of network engineers started doing more coding and of course , we created a new job description for NDEs or network development engineers , but still we had traditional network engineers , people who would do core network engineering . I'm talking NPL , I'm talking BGP , ospf , isis , ripv1 , iv2 , erg , erp kind of stuff .
Around 2012 , 2013 , the cloud turned into something that we know today . Before that it existed , the concept existed for earlier editions of that , but 2012 and 13 , specifically March 2013 timeframe very important Because that's around the time where private cloud , virtual private cloud , the general term AWS has a VPC and of course it's related to that .
That was born and that's pretty much the same time that I joined Amazon and it's a very interesting time . So four or five years later , during that time now , if you look at the job descriptions , you can see you have more and more cloud-related keywords in your network engineering job titles Toward the end of 2010 , closer to 2017 , 18 , and 19, .
Now you have networking people with a lot of cloud expertise and it's a pretty hot topic . So I mean , four or five years later , it has become a thing . So it is possible to just just put up a job ad for a cne or cloud network engineer and look for people who do network engineering in the cloud . That's how it was born , how we got here today .
Hopefully answered your question , but a lot of more details . I'm pretty sure we're going to cover this as well , do you do .
you see , actually I've been looking around just out of curiosity , because I think we've been trying to figure out if cloud network engineering is really happening as a thing .
But I , you know , unless we're talking about like people that manage the underlay of cloud , it seems like and we should make that distinction right so there's the cloud network engineer that's managing the infrastructure that runs the CSP , and then there's , like the cloud network engineer that would say build for enterprise , you know , using the constructs and primitives
in the cloud . So yeah , so which one are we ? Which one or both are we ? Are you kind of thinking about here ?
Tim , excellent question , excellent question . So the one that I'm talking about today and we can talk about the other one as well the CNU cloud network engineer or cloud network architect he or she is responsible for body of work . Where is the body of work located ? It starts from your edge device On the on-prem side .
Whatever you have could be a router , could be a firewall . Usually that's pretty much the boundary that we define , all the way to the point where the cloud infrastructure engineer takes over and we start talking top of rack servers , virtualizations and NICs , any kind of GPU or GPU that we have .
So that body of work has a group of people responsible for it and they are the cloud network engineers . They do architecture on top of what's built by the infrastructure engineers . We still have infrastructure engineers , people who do all sort of on the lay , if you will , but we're talking about what's built on top of that .
That's how I define the C&E , and when I look at the job descriptions and I want to write one , yeah , that makes sense .
I think in that context , the traditional I shouldn't say traditional , but the infrastructure engineer that's managing the underlying hyperscaler network that is probably a little bit closer . I'm not going to say it's a one for one , but it's definitely a little bit closer to your definition of a traditional network engineer .
Day by day , right , they're managing physical infrastructure , but they've built this virtual framework on top of it . That then us as C&Es or cloud network are then consuming , right , but we're only able to consume what they've exposed to us to interact with that network .
We're only 100% and that's the trend . It's not just that part of the history , it's not just one episode . If you look at the world of AI and Alta , which is very hot , very interesting , we have the exact same trend . You have AI infrastructure engineers , people who understand the GPUs , the clusters , super clusters , all kinds of connectivity at the HPC level .
On top of that , you have people who understand how the workload works , how the workload should distribute or schedule . So these two layers still exist , even in the latest trend that's just coming out Okay
¶ Cloud Network Engineer Skill Set
.
so let's dive a little deeper here . Let's look at the skill set that someone you know . Now that we know what a C&E is and we're talking about interacting with the hyperscaler network off-structure itself , let's look at what does the skill set of a C&E or cloud network engine look like ?
You know , kind of what makes its way over from the traditional networking side and what gets left behind , and maybe what are new additions , what new skills do they need to take ?
Oh , that's a good question . Actually , that's a question I get very often and it's a very fascinating question . But at the same time it scares me because I know why the person is asking . 99.9% of people ask this question .
Of course they want to make a move or interview with someone or get a job and turn into , of course , which is great , which is absolutely perfect . The challenge here is , at some point it's going to be very CSP-specific or very employer-specific , if you will .
But generally speaking , since I answered this question so many times , I came up with my own sort of structure to answer that question , layer by layer . Let's just go layer by layer and you will see how the world changed over the past um , I would say 12 years .
So , physical layer what we used to have , psc or power and cooling that part is almost gone , a few exceptions . You still need to worry about how your carrier works and how you want to connect your carrier . Probably there's going to be some work on the on-prem side of this .
You might want to worry about regions from a physical perspective and how you define your overall redundancy strategy . That's as far as that layer one goes . So we don't spend much time on power , unless you're doing something very special . Let's say you're you know some specific cases .
Let's say you're trying to run a huge workload , ai workload , you're trying to train a model , huge model , like for 50 runs . Well , you're going to have to care about things like power , but for now you're not building anything , you're just using a cloud provider . So layer one is kind of out of it . I would not worry about that .
Layer two is an interesting one . We used to spend a lot of time on layer two . If you remember early 2000s , early 90s , we started networks . It would take minutes to converge because of the spanning tree , and then the PVS , cpvs , c++ and generation after generation . Now we got the overlays right .
So kind of layer two In cloud , I think the exception of Oracle Cloud , I don't think anybody else does layer two . We support layer two to support various specific cases , for example VMware , like OCVS , Vmotion , stuff . In some special use cases Firewall wants to do layer two , keep alive , right .
But layer two again 99% out of the picture unless you want to , you know , replicate something that you have on-prem and you've got to do something about that . L2 connection . Layer 3 is there . Layer 3 previously in our traditional world , which I kind of belong to all had two big buckets . We had an IGP part and a BGP part . The IGP part has changed .
We used to have a lot of knobs , a lot of configuration details . Look at the ISI levels , look at the OSPF levels , all the LSA types , all the link types , Interface types , lsa filtering All the details , right Timers , how to optimize ISIs to react faster , converge faster . You don't have to worry about 99.9% .
It's all gone and will be taken care of by your CSP . That's really good news . And will be taken care of by your CSP . That's really good news . You need to understand the basics and the foundation of routing to make sure your packets can make their way through your footprint .
But at the end of the day , you don't have to worry about convergence at the IGP level . That part will be taken care of by your platform . The BGP part that's interesting because , again , same as a traditional world . We have that , but with some changes . Traditionally we had to configure a whole bunch of things in BGP .
You wanted to filter a bunch of routes , you wanted to do aggregation , you wanted to play with the timers , you had BFD . You know , you name it . We all know . We all done BGP many , many times . A big percentage of that we replicated to this world . So we still have it . Why ?
Because your facilities , whatever you have data center , on-prem headquarters , you have to have some kind of connectivity to your cloud footprints and you have to have some kind of rack exchange . So BGP is still there and the attributes , the knobs , for the most part there .
You need to know how to configure those , but I wouldn't spend a lot of time on the details because it's configured once and you use it , unlike many networks that we traditionally ran and we had to reconfigure BGP because of many other things . In this case , since it's used for connectivity between your on-prem and the cloud , it's going to be pretty stable .
But layer four and seven and anything in between , that's an interesting part . It's something that the conversation gets a little muddy . Traditionally that part of the conversation , at least partially , would be handled by us network engineers . We would care about UDP , tcp , all the connections and stuff , some traditional environments .
The network engineers are the responsible for the load balancers , even the firewalls . Exact same conversation is valid today and exists . So , depending on your employer's policy , depending on what you're trying to achieve , depending on your team and other teams in your organization .
Some organizations and network engineers I see are responsible for load balancing and firewalls , anything security related , even WAF , some bigger organizations . They have specific teams to manage those .
So all these technologies from layer one to layer seven some of them are gone , some of them stay , some of them a little bolder than others , but we can talk about the specific cases . All there are really good resources out there . We will talk about those .
But pretty much 60 , 70% of networking we replicated , we carried over , and 30% we kind of left it on-prem and I hope I don't have to see them in a .
Something interesting that I had to think about when transitioning myself and it's something you talk about like how you leave a lot of the nerd knobs and the bells and whistles back on-prem and kind of hand over the keys , if you will , to the provider Something that I found actually more challenging than I expected when doing this transition was having to design
networking to be less what's the word I'm looking for , a lot less resolution , a lot less kind of the Fisher-Price model of the abstraction , the Fisher-Price model of networking , where it actually becomes in some ways a little bit more challenging , depending on what you're trying to accomplish , because you have to use it using the tools that you're given .
You know , you have to , so yeah .
That's 100% true . I talk to a lot of cloud customers and I totally feel that it's 100% true . Especially , it becomes really , really bad when you try to replicate your topology , your architecture , and build the exact same thing with that mindset . So that's , most cases that's not going to work .
But if you have the cloud native mindset and you can translate the two I mean one to another , you can come up with really smart solutions . But you're right , you are giving up part of the control to reach that level of abstraction which helps many
¶ Transitioning to Cloud Networking Skills
customers .
Yeah , I think we've kind of touched on this in the show before , but you know , I think I mean when we talk about migrations to the cloud , like no one's doing it because the networking is best of breed , right , it's not that it's top tier , which , when you look at the underlying components , when you look at it from an infrastructure perspective , the core
network that the hyperscalers have built across the globe is amazing . Like from a network engineering perspective , it is truly amazing . However , what is exposed to the enterprise portion of who's consuming , that it does feel a little bit like you know , it's like it's . You're like , oh , you guys , you can't even do this .
This BGP community , you know things like that . There's very , there's very rudimentary things that we've had in in networking for 20 plus years that that aren't yet supported . But I think that kind of comes back to what you were talking about with , as you went through , layer by layer , the technical depth .
Most CSPs out there do not support layer two , which they do , you know , obviously , layer two still , it still exists , right , but it's kind of abstracted by the way they're doing the software defined . So you covered quite a bit there . So I kind of want to go questions in layers as well , so layer two .
So you said Oracle Cloud actually does support layer two in certain scenarios for uniquely existing VMware environments .
In your personal opinion .
From my perspective , I was like I'm glad we're not extending layer two anymore . Let's keep that shit out of here , let's lock that away forever . But I'm curious what you're seeing in your day to day Is that more seen as a as a truly migration pattern to get away from extending layer two ? Or or where do you see that ?
exact same scenario . You're right , yeah , some very , very specific scenarios . Those cases , um yeah , we have . We still support some kind of layer two , especially vmware , but all the other cases we're kind of layer two , especially VMware , but all the other cases we're kind of cracking down on exceptions .
So if you Google , you will come across blog posts that we put together back in 2021 .
Yeah 21 .
And we use layer two to bring up firewalls and have layer two connectivity between the two . At some point we used that , we deployed it . We're not recommending so you're right . We're limiting that as well because of all the obvious reasons . But there is still some use cases . We support layer two , but even our own blockers I personally would not recommend .
Yeah , speaking of the whole transition thing one of the biggest things I think that the best advice to give to anyone going from the on-prem to the cloud world is to not think about the architecture the same right , like the connectivity is different , Like the edge is right next to your workload . It's not . You don't have this beautiful three-tier architecture .
You don't have this . You know crunchy . You know hard outside with the creamy inside type of security posture that you used to have . So getting people to break themselves out of that three-tier Cisco , you know , cvd approach to cloud networking would probably do more for them than just about anything else .
Exactly , oh yeah , and that's one of the challenging parts when someone wants to transition from this job family to the new job . Chris points it out as well you are giving up part of the knowledge . I understand people who spend years to learn those , to master those .
I remember the days people would make money by optimizing OSPF and BGP and ISI , timers and all the uh , uh even I forgot the names whatever it took to , uh , you know , minimize the conversion time . We did that too . But now , in this new world , you don't have to worry about those .
The whole goal is to get you off and running maximum redundancy as short as possible . And yes , network engineers , they need it , but you have to get used to the new , which is exactly .
And on-prem , right , you and on when people this is like the biggest one , I hear this all the time from customers when you're on-prem and you're building data centers , you're looking for sub-second convergence times , right ? Because the infrastructure that you can build is not resilient Not just the infrastructure , but even to the app level , right To the app layer .
They don't have the giant automated engine that the CSPs do , where it's very easy to do things like auto-scaling and just all of the bells and whistles that the CSPs do , where it's very easy to do things like autoscaling and just all of the bells and whistles that the CSPs provide to build application architectures that are loosely coupled right , to use the most
important word , loosely coupled . You can't really . I mean , you can do that on-prem , but people didn't do that on-prem , right , and so infrastructure ended up basically carrying the weight of making sure that those applications had their five nines of time , and that's just a total mind blow to switch that to the cloud .
That's right , exactly . And on the conversions point , keep in mind these days we are approaching one to five microseconds . No on-prem network side exceptions could converge in one to five microseconds . No on-prem network side exceptions could converge in one to five microseconds .
We're building those clusters and superclusters for AI workload , for ML workload , and it's really really hard to achieve anywhere on-prem . You have to spend massive amount of money to get close to that number and at the same time , you're going to have to worry about what you just mentioned the op time how many nines ?
As you increase the nines , you're going to have to pay exponentially more . So all these things factor in , I think , the cloud journey .
Yeah , 100% . So let's go kind of one step further . Let's talk about the skills that probably are much more prominent on-prem , like from experience . I actually just had to recertify my AWS advanced networking specialty exam . Thank you , thank you so , but I mean I remember , like going into that , I'll be honest with you .
In my network engineering , I haven't had to touch a load balancer in my life . Prior to being at , prior to being in the cloud , right , I was never affiliated with load balancing . I was purely wan , bgp , um , even touched on dns and apns and things like that , but never had to touch load balance .
So let's , let's kind of go over what that landscape looks like . What are the technologies you really need to be locked in on ? That might be , might be new , for for some people , right , right , well , that's a great point .
so , so you know , let's define some buckets and visit each one of those buckets . The first one , let's talk about systems , or traditionally what we call systems .
In that bucket you're going to have DNS , you're going to have DHCP , you're going to have anything systems related , all the servers that people would configure , and you know , again , in a classic sense , someone like me 20 years ago would not be responsive for those . Maybe a little earlier would have been .
But so that bucket , you need to know and you got to get out of your shell . That's one of those things that we were just talking about with Tim , part of that transition . With a little bit of open mind , I'm pretty sure you can overcome that challenge .
In that bucket I have a load balancer , and load balancers , just like many other technologies , you're going to see two different flavors when it comes to the cloud . You have a standalone load balancer , for example , you configure your own F5 or any other vendors . But vendors also have their own cloud-n extremely capable um platforms . You gotta know those .
But that's one of those areas that if you are working for an enterprise , anyways at the end of a day your work is going to be and you have to sit down with your application . You have to find out how the cookies should be configured . What kind of cookies , what kind of response time ? What kind of keep alive ?
What's going to be sitting behind these load balancers ? What port ? Are they changing the ports ? All these questions need to be answered . Dns is the same . Dns is pretty much the same . World got replicated to the cloud side and infrastructure is pretty easy . But again you've got to get used to it .
There are some easier topics , like how to send queries back and forth within on-prem and cloud , a little bit more complex topics like DNSSEC , but again that's part of the job , at least today . The expectation is you know how they work . That's about the systems bucket . There is another bucket , networking In that bucket . We talked about it .
You need to know foundations of routing . Bgp is a must . A little bit of static would help and you need to understand the concept of routing , because now that you're taking over the IGP from you , you need to know how you want to route your traffic . So you have to configure your route tables and make your resources reachable .
In that networking bucket sometimes you have other components as well . If you have any kind of overlay , you need to worry about it . But generally speaking , that's the favorite part when it comes to network . This is something that we've done for years . Everybody likes it . There is another bucket here . I call it security .
But we will talk about security today , hopefully at some point . But some organizations , some enterprises , network engineers are still responsible for configuring security appliances . I'm not talking about security strategy , I'm not talking about your overall posture . I'm talking about appliances , for example , the firewalls .
Same story low balancers applies to the firewalls as well . You're going to have standalone firewalls . You're going to have vendor-specific or cloud-native firewalls . You're going to have vendor-specific or cloud native .
So some organizations they expect you to be able to configure those , not just those , but also WAF and other denial-of-service protection systems that you might have in place . There is a fourth bucket that may or may not be part of your responsibilities , but sometimes you need to know .
And what is going on outside the world of networking and systems , for example storage , for example databases , other resources like SaaS and things that you want to connect to . We're not going to be configuring databases , we're not going to be creating tables , I'm not going to be dropping tables , I'm not going to be running queries , no .
But in many cases , network engineers are expected to be able to create that connection and make that database available to my resources inside my footprints . That's a big ask . It happens almost every day , on every single call . It's actually very hard to find a customer with no database requirement , a customer that says we don't have any databases .
99% of cases they have some kind of database . A network engineer has to create that connection and make that resource available to it . So these four buckets depending on what the job description says or what expectations are you need to master those . We can talk about each one of these , but that's kind of the big one .
Yeah , I think those four buckets are a great framework for how a cloud network can think about building connectivity in the cloud .
One thing that I will add to this and I'd be curious to get your I feel like there's also a fifth bucket that was introduced that probably wasn't in a traditional network engineer's purview nearly as much as it is now , and that's cost . So we've introduced this idea of paying per gigabyte on a lot of transactions , right .
So how much do cloud network engineers need to be cost aware ?
um , well , that's a great question . Um , I missed that because I work for a csv . I don't charge myself .
But to answer your question , network architects or designers , cloud network architects or cloud network designers one of the very first things , exactly when they're talking , thinking , redundancy , off-time , all these things they need to consider is cost Huge , huge difference between a well-architected and designed footprint as something that you just slapped .
So , from a cost perspective , there are many ways to optimize your costs and minimize your costs and , interestingly , many . CSPs . As far as I know , they're more than happy to partner with you and reduce your costs . So if you reach out and ask for help , I don't remember anything . Okay , is that someone said you have to like pay that big bill .
I'm not going to help you Get rid of that expensive neck ? No , there are ways to optimize those . But 100 . Every network architect or designer the moment they sit down and they try to whiteboard .
That's one of the factors they need yeah , I mean we always talked about costs on prem too , but it was more . It was much more of a very concrete you know , uh , the venn diagram of , you know , cost and resiliency and ease and complexity and pick two right .
It was much more of a very straightforward thing in cloud being a consumption based model , especially around things like data transfer , that often gets swept under the rug and very hard to find . You know , when you go back to try to , you know when the FinOps people are coming to you and saying why is it costing so much to do this ?
It's , it can be hard to trace that back . And I'm not throwing this at the feet of the CSPs and saying like you guys intentionally make it hard or whatever . I'm just saying it's that model , that consumption-based model of data movement , is extremely hard to unravel .
Exactly , exactly . That's very true , especially as you increase the number of users and the variety of services . Let me ask something interesting here . Some you know part of your audience might . There are some services every CSP has it . I'm not talking about any specific .
There are some services that an outsider start consuming by sending juncture and they can make you pay .
Like the S3 thing that just the Amazon just closed up , where people were finding unlisted on the S3 buckets and stuff .
There's a long list of those . You have the DNS , you have all sort of storage . So , yeah , that's .
¶ Evolving Role of Cloud Network Engineers
This level of concern never existed Probably I don't know in that world . If I wanted to be worried about something , maybe ban this . Someone is trying to saturate my circuits , but usually in the morning when I woke up , I would not think about my web server and someone's browsing too many web pages . But all those things .
Now you need to be mindful of those . Keep an eye on your costs , architect in a way that people cannot surprise you or minimize those opportunities and , of course , partner with your CSP and look for opportunities to minimize your costs . Once again goes back to a well-architected .
If you ask a junior person to design environments , he or she might grab a bunch of NAT gateways , a bunch of other gateways , just put them together . Yeah , things are going to work , just like the traditional CCIE exam . You're going to have end-to-end paying . Yeah , it's going to work .
But now , going back to Chris's point , someone has to pay and there's a huge difference within that architecture and something that you design of cost as a factor of mind . So , yeah , it matters .
Totally agree and I think it kind of calls back to your point that you know you kind of as a within the cloud . I think you need to be a little bit more application aware from a networking perspective than you probably ever had to be traditionally .
You know I've I've talked with customers that you know you could build the most opportunistic , you know best architected network solution in the cloud . And then you know , then they might , you know they start decoupling these on-premises apps , move them into the cloud and you know , maybe there's still some database resources hosted on-prem .
but then as you've moved it you've learned like the code for the application was written so terribly that they're sending millions of transactions into that database where it's not optimized at all , right , and then you know , then you have to kind of be like what the hell are you guys doing ?
you know we need , we need to change this right . That's a really good point , chris , and I'm not sure if you're going to have time today , but that is one of the multi-cloud challenges .
So in the next couple of years , a few years , you're going to hear this multi-cloud term a lot and , as people are moving toward multi-cloud world and trying to connect different clouds and one workload here , the other one , you're trying to split things or you're going to have challenges with those apps .
20 years ago , 15 years ago , your chatty application uh , you , you might have some problems with that thing , uh , when you had one and then we started using one optimizer .
Today , any of those applications those applications , if you're trying to , or databases , when you're trying to split those and implement any kind of multi-cloud , you have to take into it and potentially , you know , resolve that issue before splitting that or put them in one cloud and , just you know , get rid of that chatty conversation or chatty channel between the
two resources .
Yeah , you know , get rid of that chatty conversation or chatty channel between the two resources .
Yeah , what we see a lot is , um , people doing private circuit like 10 gig express route , 10 gig , uh , you know dx , 10 gig fast connect whatever you have down to a cnf like a cloud neutral , you know carrier , uh , and then bouncing it back up because it's actually a lot cheaper to use . That well cheaper and faster right to to use .
So so that's an example of you know people doing multi-cloud but being mindful and designing for data transfer costs .
Basically exactly , exactly . I think chris covered . Now in this world , I think we can add another point to the cn is responsibility . You need to be application , so previously you wouldn't care . I have 10 gig or 100 gig or 400 connections , it's land , nobody cares . But today , in this model , especially something like multi-cloud , you have to understand your app .
You need to know how chatty they are , how much latency they can tolerate and you need to answer all those questions . It's just , you know , probably sort of a space we never tried to enter , but now it's seriously . As network engineers , we need to understand .
Man , we need to say that one again for the people in the back .
Man , the latency tolerance you want to talk about , like hey , we've got these crappy applications that send 400 database calls , you know , to return data for a webpage , I mean , and then you , you take it out of the data center , you put it in the cloud and you find out very quickly , like how much latency can that application tolerate ?
You know , so it's huge . And then you have to get into the what the seven r's of , of , like , you know , should I rebuild it ? Should I you know , all all of that refactor ?
you know , whatever that's true that that's part of reality . You're right A hundred percent .
I know as much as I really want to go deep and talk about security and talk about multi-cloud , and that I think probably what the next thing we should do is probably pivot and let's give the listeners some action items , some places to go from here . So if you really wanted to be a cloud network , what does that landscape look like ?
Because I will say I've seen on LinkedIn I definitely see more cloud network engineer positions popping up here and there , which is a promising site . But what kind of companies need dedicated cloud network , whereas cloud network engineering just kind of a baked in function into the traditional network job posting , how common are you seeing completely dedicated ?
You nailed it Past years . It changed , actually it's evolved . Now I see a lot more , I would say today , medium-sized and above , but keep in mind four years ago you could not find . So that has changed . But again , c&e might be a little misleading . If your expectation is to be a network guy now doing the call for it , it's not true .
You have to understand a bunch of things , including applications , load balancers , areas that probably you've never explored before . But definitely I see a lot more job ads on LinkedIn .
Not to mention Realm as well .
That's another great example .
¶ Navigating Cloud Networking Career Transition
Let's actually talk about it for a second . So in the world of Kubernetes , if you go to any cloud provider , as usual the two different types of services you can build your own or you can use one of their pre-made services . In both cases , we still need network engineers for the connectivity .
You're still going to have to have your load balancers , you need to worry about security . You're going to have name resolution for those and probably some other things . It might be database connectivity , it might be some kind of storage connectivity , all kinds of connections . These still exist .
From my perspective , I mean there's a little difference from a network engineering perspective , when I look at a container and I look at a VM , 90% of services that I need to provide are kind of the same , but yeah , the specific details might change .
So it's again one of those things that you cannot cross off and say it's part of the app's responsibility and some app guy is going to do it . Say it's part of the app's responsibility and some app guy is going to do it . There's a lot of connectivity on the Kubernetes side .
Any kind of container you want to use , that you have to understand and at the end of the day it's going to be part of your responsibilities . So yeah , that's actually a really good example I forgot . I wish I'd talked about it , but that's reminding me Well good , I think we could probably go for five hours .
Yeah , kubernetes is , yeah , it's a whole thing . So , yeah , I guess , that being said , where in your , in your opinion , what would be your tips for someone you know , a traditional network engineer , wanting to , when wanting to get into the cloud space ?
I mean , we've already kind of touched on multi-cloud , which which kind of adds a new paradigm to what we're talking about . But what would your advice be to someone looking at ? Are you saying focus on one csp and go from there , or kind of focus on the technology pieces ? Uh , where would you direct ?
sure ? Yeah , that's a good question if you have the foundation . Let's say you're a network engineer with five years of experience . You're not super seasoned and you're not like starting fresh off college . Five years experience Probably .
If you look at the work I've done in the past , you'll notice I spent a lot of time on certifications Not just taking those , writing about them , blogging about them , books and creating my certification . I helped one of the teams to put together our networking certification , so that's a really good way to get us started .
Some people might not like it , but still , after all these years , I got my first search in 2001 . Still , after all these years , I think that's the structured way to approach a technical topic . You might say I don't care about the search , the knowledge matters . Yeah , that's true .
I mean it could be true , partially true , but creating the certs , they also create a very well-structured training program , some kind of program that you enter . You know what you're going to go through and you know what the output . We have that . Aws , hazard , gcp , azure , all cloud providers today have that kind of education .
You enter with that basics of networking knowledge and once you're certified , or even if you fail , you're going to have really good understanding of different services . So that is how I would . I'm not going to you know 10 or 5 random books or videos . Let's watch a little here , a little there . That's step one , step two if you want to learn more .
I talk about this a lot . Actually , I wrote about this a too . You got to get used to reading technical documentation . That's something that we did . I know , chris , you also work for Cisco . Back in the days we would spend hours on configuration guides . You would grab the configuration guide for code 11 , for 12 , for whatever that code was .
People would actually go through the configuration guide line by line , read and sometimes memorize . It was one of the smart ways to pass the ccie because back then many questions you could find them in the configuration guide . So that's an interesting point that still exists . With the , with the csps , spend time on the configuration guides . Some csps .
They also have blogging platforms . We do where w AWS as well . I know Microsoft has one too . There's a lot of good information . So these are all different tiers Started the search , entered the program , finished that program . Now go to the documentation , educate yourself , stay on top of everything .
But to be honest , with you saying all that , let me just wrap this up by saying in 2024 , your main concern should not be how do I study , or where do I study , or what am I going to study .
You know you have access to a lot of resources Chat GP , ask chat GP but the main question that we , carried over and , decades later , still have to answer is how do , how am I going to make that commitment to spend time on this ?
And here is the point If you are willing to put 30 minutes a day minimum , ideally one hour for the rest of your professional life . You're going to be top notch , you're going to be safe , you're going to be employed and if , in case , you lose your job , you're going to be back on market very quickly .
You're going to 30 minutes to spend time , educate yourself , but if somehow the paycheck tricks you that I have this safe job , I don't have to educate myself . I don't have to learn anything . That is not how this works , at least the world of it , network engineering , no exception . You have to be learning everything . That's that's how .
That's how things go yeah , I think that kind of goes with anything
¶ Continuous Learning in Network Engineering
you know . I know tim is a big proponent of this . It's a treadmill , right , you've always got to be . You can go at a pretty slow pace , but you always need to be . Yeah , I think that's really good feedback , tim . Anything you wanted to add there ?
No , I think you nailed it . Yeah , just never , especially these days , oh my God , with tech basically imploding into a black hole these days never , ever , feel that you're safe .
You always have to be learning something . That's . That's actually very true . Let me give you an example . A couple days ago , a friend of mine texted me and we're talking about things that , uh , he , I was about to study , I'm trying to . I was trying to test something and , uh , um , it's an interesting case actually .
If you want , I can show you what I was testing . It's something and , uh , um , it's an interesting case actually . If you want , I can show you what I was testing . It's here . You want to see this guy is there , our ducky , right ? So how is this thing related to network engineer ? This is a great educational .
So this , this gentleman here , this is our ducky . We're working on a project side , not a customer related project , fun project , but absolutely educational project . Let's design a system that we can scan a video feed on multiple machines and as soon as you detect a rubber duck , you take an action . For example , text someone .
What part of that is networking , I'll tell you . So this works with AI models . Grab a simple model , optimize it , just fine tune , ittune it , add this guy's picture to it . Probably you're going to need a few hundred pictures of this animal and train your model . Train it on different platforms . Try to train that on your MacBook , if you have M1 , m2 , m3, .
Capture the results . Go to RTX GPUs . Go one level up . Go to RTX 4070 . Go to 4080 . Go to 4090 . If you have access to those , then take it to the cloud . Grab one of the good GPUs . Could be 800 . Could be whatever H100 . Doesn't really matter . It's going to cost you 10 bucks , probably for one hour . Capture the results .
Now try and think and see how a distributed system would work , how a network engineer could optimize this process . What are the ways to minimize the time that I need to spend to train my model to detect this rubberback ? Part of that , of course , is machine learning . Yeah , again , that's part of the reality .
As a network engineer , I want to understand my workload . This is the trend . So if someone's curious , if the question is , what's the current trend right now ? I mean , what's the coolest thing ? What's the next thing ? This is the next thing , but you need to understand a little bit of machine learning . Not a lot , but a little bit .
What that's going to teach you is something like this and then , using your network engineering knowledge , you can understand the topologies . You can understand different ways to optimize those topologies , how to reduce latency , how to minimize it and how to distribute your workload . Well , that's what we were doing . And then he texted me back .
Seems like even at the age of 75 , you guys are going to be still learning . He's not the network . I said well , yeah , that's exactly how this work works . I enjoy this , but this is a cool project we're going to do . I don't know when other people are going to do this , but this is Bitcoin in 2012 . $10 .
If you buy this today , probably in two years , you're not going to regret it . You're going to be one of the very first people to join that journey before anybody else joins that journey Not anybody , but very , very few people have already started . You're going to be one of the very few people to you know . Experiment with something . This is cool .
This is like something that I don't know . Probably a few thousand network engineers all around the world would explore , would try to do .
Maybe a few hundred . Yeah , absolutely , I think that's . I think that's a pretty much a perfect example of what we said about being application aware . Right , ai is going to be the next iteration of the application . The data paths where things are going to go , the topologies in play , things like that . I think .
All right , so I think we're about at time here , cam . This has been great . I think we might have to have you on for another topic or two in the near future , but yeah , this has been great . Like I said , I've been following you for a while , so it was great to finally get you on here and talk about network engineering . Thanks for coming .
We'll put some show notes , some links , in the show notes for your previous work . Like I said , your Nanog talk , the blog that you've put on Packet Pushers about breaking into cloud engineering . I think that's really material for the listeners . Anything else you want to plug before we wrap up today ?
No , thank you so much for having me . Probably the only thing . Last word , last comment Sometimes I mean , I do give talks and people ask questions . One of the questions that people usually ask is what was the best piece of advice anyone ever given you ? In my case , let me ask the question . I'm going to answer it myself .
My case was just one thing Be curious as an engineer . I'm not saying network engineer , I'm not saying cloud network engineer . I don't want to be specific . As an engineer , you have to be curious . If you're curious , you're going to be successful . I'm not saying I'm successful or anybody else . No , if you want to be , you have to be curious .
As soon as you hear something , grab your phone , google that , put it in your GPT . Find out what it is . Find a couple of real-world scenarios about it . Any keyword , any keyword . Do not let one single keyword without you checking it out . That way you're going to be on top of it . So that's the probably final word .
Someone taught me that I enjoyed it for so many years . I did my best . I'm not saying I succeeded , but I tried my best and I would love to pass this on other engineers , especially younger folks . But thank you so much for having me . It's great talking to you awesome yeah , I think that's .
That was a great closing sentiment , um , so we'll leave it there . Um . So , thanks everyone , uh again for listening to this episode . Um , if you enjoyed it , please like and subscribe all that jazz and share it with a friend , and we just want to be involved in the community , like that . So if you have any feedback , please reach out to us .
We'd love to talk , but with that we'll take it away and we'll see you next week . Alrighty bye .
Hi everyone . It's Tim and this has been the Cables to Clouds podcast . Thanks , hi everyone . It's Tim 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 podcast catcher , as well as subscribe and turn on notifications for our YouTube channel to be notified of all our new episodes . Follow us on socials at Cables to Clouds . You can also visit our website for all the show notes at CablesToCloudscom . Thanks again for listening and see you next time .