A long time ago in a galaxy far, far away
A few years ago, I had another blog with a few pieces of content on it. One of those pieces of content went by the same title as this post, “The three paradigms of networking”. I’ve decided to re-write that post since the old one no longer exists. I also believe that my views on this, while they haven’t changed too much, have matured quite a bit and I’ve gained a lot more experience in the field and a bounty of knowledge that has helped shape my opinions. So, without further ado, let’s get into it.
The three paradigms
I believe that there are currently three paradigms of networking. What I mean by this is that the field of network engineering is essentially split into three areas right now. They have some similarities but I think overall they are very different and require very different skillsets. I’ll go through each one and explain what I mean. Again, this is just how I currently see the field of networking, and I’m sure there are many other ways to look at it. I reserve the right to change my opinion again in the future 😁
The first paradigm: The traditional on-prem network engineer
Yes, I say on-prem and not on-premises. I’m not real sure what the argument around this is but I’ll be using on-prem going forward.
This is probably where most of the readers of this post will fit in. These are the network engineers that cut their teeth mostly in the enterprise space, and most likely on some sort of Cisco gear, with a few others growing up on Juniper gear or even Arista gear. This type of engineer might have started in the arcane arts of “programming” a router or switch CLI to do basic things like change a hostname, or configure a port with VLANs, or add a description to it, or whatever other task was assigned to them through their lovely ticketing system. After this they likely moved on to more advanced things like configuring routing protocols such as OSPF, EIGRP, or even BGP. They might have even learned how to configure MPLS and various flavors and methods of setting up VPN’s. Eventually, buzzwords like SDN and automation started to become more prevalent and they started to learn how to use tools like Ansible or python to automate some of their basic tasks or fact gathering. This is when operating systems like Cumulus Linux, which has since been bought by NVIDIA and SONiC, which is becoming more and more prevalent in larger enterprises and in the cloud space, started becoming more popular and the network engineer started to learn how to use Linux and bash scripting to do things like configure a switch or router. Eventually everything started looking like a fabric and the network engineer started to learn how to use tools like EVPN and VXLAN to build one. To be fair though, lots of vendors started putting out tools to help with this, such as Cisco ACI. The point of a product like ACI is to abstract away the complexity of building a fabric and make it easier for the network engineer to operate. In the case of ACI, this can be done through a GUI but ideally it’s done through an API using some of the methods mentioned already.
As you can see here, the real key to this paradigm is that it is encompassed by all the basic networking skills that a network engineer would learn while on their path of say, obtaining a prestigious certification like a CCIE. These skills will be useful pretty much throughout their whole career and will be the foundation of their knowledge. Continually building on this foundation will be key to their success.
I think one of the jobs that isn’t talked about much that would fall under this paradigm is the network engineer that moves to working for a Cloud Service Provider (CSP), specifically managing the enormous underlay networks that are required for these CSPs to operate. This is a network engineer that is working for a company like AWS or Azure or Google Cloud. These engineers are still doing a lot of the same things that they would be doing in an enterprise environment, but they are doing it at a much larger scale. They are also doing it in a much more automated fashion. This work is largely invisible to the end user, but it is the backbone of the CSPs and is what allows them to operate at the scale that they do.
The second paradigm: The cloud network engineer
This is the paradigm that I’m most partial to. So much so that I am a cohost of the podcast Cables2Clouds where we discuss this very thing. Our mission statement in simple terms is to bridge the gap that exists between the on-prem network engineer and the cloud network engineer. Some might call this a hybrid cloud network engineer. There are way too many buzzwords in all of these spaces so I will try to stay out of that conversation.
A lot of people seem to see this part of the field as a separate thing (admittedly in some aspects even myself), but I think it’s really just an extension of the first paradigm. Regardless, there is a lot going on in this space currently and you can still make an entire career out of networking without ever touching the cloud so I will consider it a separate paradigm.
I have found that there are quite a few different paths from which one gets into this kind of work. The majority of traditional network engineer’s that have moved into this space almost all seem to have some kind of WAN or Service Provider background. This makes sense because it will usually be someone already managing the WAN that will extend a network into a cloud site. There are many ways to integrate something like SD-WAN into a CSP’s network for example and this is something that would likely come easy to someone with a WAN background.
On the other hand, there are others like myself that took the ideas and understanding from building and operating data center fabrics and applied them to the cloud. As you will learn over time in this field, there are so many abstractions and learning how to do it one way is usually beneficial when you see a different but similar approach done elsewhere. I’ve personally spent quite a few years learning the ins and outs of Cisco ACI and while that product has many faults, the knowledge I gained from understanding a data center fabric has helped immensley in understanding how to build and manage a cloud network.
To put it simply (and I’m generalizing I know), those with a WAN networking background will likely understand networking TO the cloud, while those with a data center networking background will likely understand networking IN the cloud better. Both are equally important and both are needed to build a successful cloud network. The more you know about both, the better off you will be.
The other way that I see people getting into cloud networking is someone who comes from a general infrastructure background that just gets thrown into doing the networking as if it’s just a simple bolt on to the rest of the work that they’re doing. I do think this approach is becoming less and less common as more places are coming around to the idea that cloud networking can be very complicated (not to mention extremely costly) if you don’t have someone with a networking background to help you out and architect your networks optimally. Luckily, at least from my point of view, it seems that network engineers are starting to get a seat at the table now.
Now, I have plenty of upcoming posts and ideas for content around what I’m about to say next, so please stay tuned if you’re interested. You can of course use each CSP’s cloud native networking constructs- think things like CloudWAN for AWS, vWAN for Azure, and NCC for GCP. The main issue that I have with this approach though is that I believe in a hybrid, multi-cloud future. None of the CSP’s networking products are intended for use outside of their own cloud and especially not intended to work with on-prem vendors gear either. Due to this, there are a good handful of companies that have popped up to work on making multi-cloud networking easier. There are four main ones that I’ve been keeping an eye on- Alkira, Aviatrix, Prosimo, and F5 with their newer distrubed cloud (XC) product. I’m sure there are others that I might not know about or didn’t add for various reasons but these four seem to be the ones with the most steam behind them right now. I believe this “sector” of networking is primed and ready to blow up at any moment in the next couple of years. They’ve all been raising quite a bit of money and are releasing new features all the time. I’m excited to see where this goes and it’s definitely something worth keeping an eye on.
The third paradigm: Application networking
This is the paradigm that I’m least knowledgeable about but at the same time I’m very fascinated by it. I try to keep up with all sorts of companies and trends in this space though because I think it’s going to be a very important part of the future of networking. I’m also very interested in learning more about it and I’m hoping to get some guests on the podcast to talk about it in the future.
Application networking is what I’m calling all of the hype around things like service mesh’s that are used in microservices architectures. Side note- as a network engineer, it’s a bit frustrating to see most in this space just call it networking and then there’s basically no network engineers working on any of these products. From what I’ve seen, it’s mostly developers and SRE’s. I’m not sure why this is but I’m hoping it changes in the future. I think it’s important to have a network engineer’s perspective on these things. To me, application networking is really all about allowing services to talk to each other but higher up the stack than traditional networking engineering. For example, while the networking we all know and love mainly deals with layers 2 and 3, application networking deals with layers 4 through 7. This is where things like Istio and Envoy come into play. These are the tools that are used to build a service mesh.
There are quite a few companies to watch out for in this space. Some of them being; Isovalent- with their very, very popular Cilium project as well as ushering in the “era of eBPF”, Solo.io, Consul which comes from one of my favorite companies- Hashicorp, and Buoyant who creates arguably the fastest and most lightweight proxy out there- LinkerD. There are many others but these are the ones that I’ve been keeping an eye on.
Some final thoughts
Network engineering is a constantly changing and evolving beast of a field to be in. I think it’s important to keep up with the trends and try to stay ahead of the curve as much as possible. Like I mentioned earlier on, you could still make a career just out of the traditional on-prem network engineering stuff without ever touching the cloud or application networking. In my view though, those days are numbered, and while it won’t just happen overnight, I’d recommend being prepared for when things really do start shifting. I believe that in the future, network engineers will be increasingly involved in all three of these paradigms and will need to have a good understanding of all of them to be successful. I’m excited to see where this all goes and I’m excited to be a part of it. Stay tuned for many more posts coming diving a bit deeper into each of these paradigms and the companies and their products that are involved in them. Please feel free to reach out if there is anything in particular you would like me to dig into some more. I’m pretty easy to find on both Twitter and LinkedIn so feel free to reach out and just start a conversation. Thanks for reading!