I was at a tech conference recently – one built by (and for) networking professionals – chatting with another attendee about the usual mix of news, tech challenges, and hobbies when the conversation took a sudden and sobering turn:
“I guess I have a lot more time for side quests these days. I got laid off a couple months back and can’t seem to land even a solid conversation, let alone a job offer. I thought it would be easier than this.”
Those of you who catch my writing on my personal blog will know that job hunting has been a common topic for me. Everything from how (and why) to fix up your resume, to creating a worthwhile collection of interview questions to simply sharing the job listings that come across my email, Slack, Discord, and social channels each week. So, when the topic came up, I didn’t shy away from it.
We spent some time discussing the mechanics of resumes, online profiles, and networking (the people kind, not the route-and-switch kind).
The cloudy elephant in the room
By this point, a decent-sized crowd had gathered around. This was partially because we were camped out in front of the coffee station, but also because the hallway track is definitely a thing. And that’s when the conversation pivoted to the elephant in the ballroom.
The elephant in question was brought to this event by the inimitable Corey Quinn as part of his keynote speech: TCP Terminates on the Floor: The Ebbing Tide of Networking Expertise.
After pointing out a brain-meltingly stupid architectural decision he’d seen, Corey commented, “The real problem is that the companies that are responsible for doing these ridiculous stunts all needed a network engineer on the team when there very clearly wasn’t one. Because those job postings don’t exist anymore. They don’t really call the skill set ‘network engineering’ in a lot of these companies; they call them SREs or DevOps or special engineers or god knows what.”
Toward the end of the talk, Corey pivoted to describe current challenges companies that are (or wish to be) cloud-native experience and how someone with a background in so-called “traditional” networking would have an advantage: “These are things that most of you in this room already know how to do, which puts you in a rarified group. These are all things you can take to a cloud-native company, who will value what you’re bringing to the table if you talk about it a little bit differently.”
And that’s where Corey lost me (only a little, but it’s relevant to this blog). To offer career options, he suggested “meeting developers further up the stack” and “start moving into the application space,” which sounded—both to me and to other attendees—suspiciously like the oft-repeated call to “learn how to code” and “become a developer.”
This isn’t to say it’s fine to eschew learning code at any level. As I’ve written before, everyone in tech should develop a “sense of code” – the ability to look at an existing piece of code and understand what it’s trying to accomplish. That’s not the same thing as being able to fix a bug, optimize, or create the code. But it’s nevertheless important. It strikes closer to what I believe Corey was talking about with regard to moving up the stack to find a comfortable middle ground to meet with our application developer colleagues.
Pivoting into a dead end
On the other hand, clinging to the past – whether we’re talking about old relationships or old technology – doesn’t help anyone. As Evelyn Osman, platform engineering manager at AutoScout24, pointed out to me, “One of the first rules of cloud migrations is ‘don’t fire your network guys, yet.’”
I’ll be honest, the “yet” part of her comment really bothered me. When I asked for more information, she elaborated that after a company goes through a so-called “digital transformation,” “the data center teams are either retasked as DevOps or shown the door. SysAdmins transition into these new roles easily, while data center/network engineers do not so much. It all comes down to OSI: They’re too far down to readily contribute post-migration. The end result is they’re critical to making the migration happen. We don’t need that deep networking knowledge in the cloud as IaaS simplifies it all.”
But, like Corey, Evelyn offered a way forward for network folks: “IMHO, what may be beneficial is to start looking at how services are expected to communicate, help figure out that dynamic security nightmare. Go deeper into CDN and learn how to really tune things there, and dabble with serverless to see how to optimize at the edge because dev teams are shit at it.”
This brings me to the crux of this post: Cloud isn’t that hard. It’s not even significantly different from what we already know as networking experts. It’s made up of techniques and technologies we’re intimately familiar with, but it seems inscrutable due to jargon and (possibly) the world’s worst UI. And once you make it past that hurdle, the stuff that’s actually new will be far more accessible and approachable. The barrier to entry for network veterans will have been lowered.
Keep calm and reload in 5
Before we start to dig deeper into what cloud networking really is, and whether it’s new technology or just the same sh…tuff with different names, and how to go about learning it either way, I want to make a few things absolutely clear:
If you’ve been working with traditional networking for any length of time, you already have all the knowledge, skills, and insights needed to understand cloud network architecture. Once we peel back the jargon and the shamefully poor UI, it’s all just routing tables, forwarding, ACLS, and tunnels—the same as any other network.
But to break all of that down, we have to re-educate ourselves.
Line up for cloud class
If you’ve gotten to this point in the blog and are shouting, “ZOMG, THIS IS TOTALLY ME! What can I do or read or watch to get myself over the cloud education hump?!?” I’m not going to keep you in suspense. Here are some resources that my friends and I have found to be a Rosetta Stone, translating old-school networking knowledge into modern-day cloud architecture jargon:
Let’s start with a two-part blog series from Nick Matthews, which is both free and written for network folks: Part 1 | Part 2.
Also free is a talk by Shean Leigon, a friend and former USAF buddy of my colleague Doug Madory. In it, he speaks about his transition from network engineer to cloud engineer in this podcast.
Staying with resources specifically designed to help networking folks, there’s Tim McConnaughy’s book The Hybrid Cloud Handbook for AWS: AWS Cloud Networking for Traditional Network Engineers. The reason I’m including it is right in the title.
The last resource I want to share (for now) is less specific to (or for) network professionals and more geared toward learning cloud essentials: the AWS Ramp-Up Guide. It’s a PDF list of over 70 courses and labs, some of which have a cost, but many of which are free.
For those who want a cloud hall pass
I expect to lose some readers at this point because the previous section is what they needed most. I can accept that. My hope is that you will stick around, and those who clicked away eventually find their way back so we can talk about how the cloud - which ostensibly uses the same networking technologies and concepts as its on-premises predecessor - could have come to feel so foreign.
Cloud class is in session
This blog isn’t meant to teach everything needed to immediately pivot to a role as a cloud engineer (network or otherwise). Instead, I’m going to share three conventions used in cloud architecture and describe their similarity to standard networking concepts to make the point that a lot of what happens in cloud architecture is stuff you already know.
Doing so will create a level of comfort and familiarity so you can start your journey to the cloud from here.
Lesson 1: It’s called “cloud” because it obscures your vision
(Not really. The name is derived from the term “TAMO Cloud.“)
It’s not that cloud providers intentionally make their interfaces confusing; it’s that humans aren’t the target market. The primary “user” of the cloud is actually a program. What I mean is that the expectation is that someone will be writing a program that requests cloud resources and manages the lifecycle of those resources – whether that’s seconds in the life of a microservice, hours of ephemeral containers, or the long operations of a persistent system.
In that context, everything – from processors to storage (and, yes, networking) – exists and comes to life as a line of code in a program. While not exactly an afterthought, the UI built for giant ugly bags of mostly water to use is definitely not the cloud provider’s primary concern.
Adding to the obfuscation is that every interaction you will have with cloud networking architecture will be at layer 3 or higher. You’ll never be able to see or affect layers 1 or 2, so stop looking for them. Everything starts at layer 3.
Finally, I want you to start thinking like an MSP (managed service provider). If you’ve worked in tech for any length of time, you already understand the MSP mindset because you’ve either worked with them or for them (or both). MSPs have “service offerings”—packaged bundles of technology that have been standardized and operationalized so that the MSP can quickly roll out the service for a new customer.
Of course, those service offerings connect back to hardware, configurations, and such. But much of the nuts and bolts have been curtained off from the paying customer. The customer is paying for the privilege of being shielded from the technical minutiae of routing, active directory, IP addressing, firewall rules, and such.
Cloud is doing the same thing. So, as you look at each screen in AWS, GCP, Azure, or the rest, remind yourself that you are, in fact, sitting in the MSP customer seat. You need to learn how to see past the GUI.
Lesson 2: Cloud is actually fabric
Tim McConnaughy put it best in his book The Hybrid Cloud Handbook for AWS: “Broadly speaking, a cloud fabric is an arbitrary network topology based on creating tunnels over an underlying physical topology. … Basic connectivity [in the cloud] is established between an ocean of network devices, and on top of that is orchestrated this arbitrary fabric that serves as the customer-facing ‘cloud network.‘”
The “fabric” in this question isn’t based on a single protocol like MPLS but may include any (or all) tunneling protocols, including IPSec, GRE, VXLan, and more.
But I need to refer back to the point I made earlier: Your interactions with this network fabric start at layer 3. So, much of what we network professionals understand about fabric (the hardware layer of the mesh) is completely obscured from view, making it hard to identify that this is what’s happening under the hood.
Lesson 3: “VPC” is just a router
Or, more accurately, a routed domain.
Again, the issue is the interface—you just see a screen that lists out IP ranges, and unless you visualize what’s happening in your head, it can feel very disconnected and random.
What you see is a screen where you divide your VPC (virtual private cloud) into one or more subnets of the CIDR block you picked when you initially set up the VPC. So if your initial selection was 10.1.0.0/16, you might see the VPC contain:
- 10.1.2.0/16
- 10.1.16.0/20
- 10.1.32.0/20
- and so on.
But in the middle of all those subnets, think of them as individual LANs, and you’ll be on solid ground. It is a router. Not a real flesh-and-bloo… I mean silicon-and-copper router, but the programmatic equivalent of one. This router is doing all the same things a router would do, including DNS, DHCP, and even ACLs.
Once you can visualize that device in the middle of everything, the options and commands make infinitely more sense.
The next step is always the most important one
It’s time to review and reflect. If you’ve made it to this point in the blog, you know that I’ve offered both educational resources and a short explainer that introduces cloud network architecture from a “traditional” network point of view.
What comes next is largely up to you. You might jump in with both feet, picking up some free courses, books, and blogs, and begin to marinate in all things cloud. Or you may dip your toes in, asking folks you already know and trust about their experiences and getting a more personalized sense of which aspects of cloud platforms make sense to (and for) you.
Or you can stay where you are, educationally speaking. I don’t say that as a slight on your judgment or that doing nothing is some kind of IT booby prize. There are many solid, valid reasons to hold off diving into a new technology. When Steve Jobs said, “Everybody in this country should learn to program a computer” in 1995, he was wrong. Likewise, anyone who says, “Everyone should learn cloud architecture today” is equally wrong.
That said, you need to decide what your next step will be. I hope this post and the other blogs, videos, and training from Kentik will be helpful as you forge your path forward, regardless of what direction you choose.
Check out a recent demo here to learn how Kentik provides network observability for hybrid clouds.
Top comments (0)