Hello my friends,
Lately I have been thinking a lot about the future of networking and the career paths in this domain. As you probably know I like to guide and mentor people and with everything going on in the industry it can be confusing to find your way and to know what skills to work on to stay ahead of the curve.
I decided to reach out to some of my friends to ask them of their vision of the role of the future networking engineer and how to prepare for the changes that we are now seeing. First out is my friend Russ White who is also the co-author of the book Unintended Features that we wrote together.
Daniel: What are the major skills that people in networking need to learn to stay ahead of the curve?
Russ: Some of these have never changed — for instance, communication and abstraction. Some skills have been more important forever, such as people skills and project manage, but they never seem to really rise to the top in terms of actual demand. I don’t think this is going to change much; companies say they want people skills, and then recruit based on point technical skills, no matter how much they say they want to do otherwise. In fact, this tends to be what warps the entire technology market — we don’t go out looking for a good engineer, we go out looking for a person who knows a specific product. The engineering market isn’t going to change much until we separate product skills from engineering skills in an intentional way.
In the strictly technical realms, there is a stronger focus than ever on learning one vendor, because the market is fragmenting as we see people move away from open standards. There is a growing undercurrent towards more openness in other ways, particularly open source and hyperscale operators opening their work to widespread use, as well as the possibility of separating software from hardware, movements that drive skills towards understanding technologies, rather than vendor implementations. In the future, I would expect to see the engineering world bifurcate even more strongly between those who know a particular vendor product, and those who know the technology. Which will be better paid, or more in demand, is hard to judge, but it’s likely to be those who know the technology.
The one skill we really need, and never seems to be in the mix, is the ability to see how technology decisions today modify the direction of the business.
Daniel: Is this drive for automation and SDN really that much different than anything we have seen in the past?
Russ: Nope. We used to want to simplify in order to auto-configure. SDN sometimes just seems like an admission that we’re going to do unnecessarily complex things, so let’s automate them to cover up the complexity.
Daniel: What does the network engineer of the future look like?
Russ: I see the market splitting into different pieces, and all the different pieces will called “network engineer,” although they really deserve their own names. The first will be the person who buys vendor product, and moves towards “full stack,” which may end up meaning “buys and integrates hyperconverged products from vendors.” The second will be the person who focuses on the technology, and ends up disaggregating, mixing open source with white box and point vendor products to create solutions. These will both have engineering components, but they are different “kinds of things.” This is likely to be the same sort of divide we see with enterprise/service provider today.
Daniel: What does the network architect of the future look like?
Russ: As much as I might hope otherwise, probably much the same as today… What I would hope for is someone who’s moved from the second sort of engineer above — a focus on the technology, rather than product — into a mix of business and technology. What’s likely to happen is the word “architect” is going to be used for anyone who rises to a certain level or experience, rather than a specific mix of skills.
Daniel: How will the traditional networking skills such as knowledge of protocols be relevant in the future, if at all?
Russ: It depends on which side of the “great engineering divide” you fall on. If you fall on the hyperconvergence/move it to the cloud side, then protocols are just a curiosity that don’t really impact your day-to-day life. If you fall on the technology side, then protocols will continue to be the lifeblood of your day-to-day experience and engineering effort.
Daniel: Is it still valuable to learn traditional networking skills?
Russ: If you fall on the side of networking that’s building solutions, rather than buying product, then yes.
Daniel: Do all network engineers have to become programmers?
Russ: This is a fairly broad question, actually. Programming isn’t just knowing a language, it’s also a set of background skills mixed with a certain set of attitudes and thought processes. For any of these things, there isn’t one “right” answer in the world of programming, either. For instance, do you prefer waterfall or agile? There are algorithms, test frameworks, repositories, coding styles, languages, and a host of other things out there in the programming world that have developed over the decades. Which specific kind of “programmer” are we talking about?
I think learning a language is great — but I think learning the mindset of a coder is better than learning a single language. Many of the tools and ideas the coding world has developed can be applied to the world of network engineering. For instance, treating hyperconverged solutions as black boxes or components to be integrated can, perhaps be drawn in parallel with using libraries of existing code, or commercial frameworks. On the other side, the disaggregated world is going to need to rely on many of the skills of a coder to build repositories, test regimes, and the other components to make it all work.
Daniel: How should network engineers find interesting projects to work on if everyone will build their networks in a similar fashion?
Russ: It can be an interesting project to make the network as simple as possible. We focus too much on “deployed the latest whiz bang gizmo from vendor A across 5000 sites, finding and crushing bugs,” rather than on “I reduced our opex by 50% by simply removing a lot of stuff we didn’t really need, and worked with business folks to figure out what we really need.” We’re far too impressed with an engineer’s ability to deploy complex things than in their ability to make things simple.
Beyond this, though, there is always, in every business, something that makes that business unique in some way. If there is no snowflake in the business, there is no business, because there’s nothing to sell. Find that snowflake and figure out how to make it work with the network. Don’t integrate it wholesale into the network; you don’t want the entire network to be a snowflake. Rather, find a way to separate the snowflake out so the network can be simplified while that little snowflake becomes the point of connection between the business and the technology.
Daniel: Do you think we will see a move towards more standardized solutions where the customer buys compute, storage and networking in fixed packages?
Russ: In some realms, yes. In others, no.
Daniel: What is the next big thing that people should prepare for?
Russ: The networking field is splitting. Do you know where you want to be, and why? Do you know how to get there?
Daniel: How do you stop sipping from the firehose? It’s tough to keep up with automation, SDN, cloud and everything going on in the industry.
Russ: Rule 11 is your friend, particularly if you’re going to be on the side of networking that focuses on building solutions from open source and other parts, rather than the vendor/hyperconvergence focused side of the industry. Learn the ideas, not the implementations.
Thanks to Russ for writing such extensive answers. I think these posts will be very helpful for all the people in the networking industry.
8 thoughts on “General – The Future of Networking – Russ White”
Great insights. Thanks Russ, Thanks Daniel.
I see words like “old way” and “traditional” used instead of “basics” or fundamentals (Ex: protocols-well that is the basics of everything how can you skip these??)
The two trends (vendor solutions vs open source or custom solutions) have been around for ages. Big vendors in dominant position is not new. What is indeed new is using custom solutions and open source. Amazon, Google, Facebook are the big forces behind this current. Here is one interesting aspect: Amazon is using lots of average network engineers to good engineers this way: they hire them for 3-4 years, they squeeze them and then they let them go. Apparently a toxic way to use people but with unintended consequences: these guys become good at what they do and they learn about the other side of the coin -open source, custom solutions and so on. Then they are released back to the work with this new mind set and slowly but surely they will change the market. This is a major shift.
These days we buy Cisco switches and routers (true technology jewels) but we use very few of their features. It’s like everybody owns an F1 car. This will end when the above (Goolge, Amazon, Facebook and the likes) will release part of their technology to the market (I think it is already happening to some degree) .
We know how to deal with the old paradigm (vendor solutions) Where we need guidance and vision sharing is on the new paradigm which I just mentioned above. There is no point in wasting conversation time about the old paradigm unless that helps us to better understand the new one. I would have expected more about the new paradigm 🙂
The other major thing discussed above: Network Engineer with programming skills. I think that this whole thing is totally misunderstood by most of us. For most of us it will be Network Engineer and Scripting skills. As Russ indicated the programming mind set is vastly different and I don’t see the benefits of totally integrating the two because you will never be both: network engineer and programmer. We will need to learn about programming fundamentals and apply that to scripting but I doubt that we will write network protocol code in C/C++ The two trends mentioned above will impact this area as well. If you choose to go open source and custom solutions then you will need more advanced scripting skills.
For years the Microsoft products dominated the market for business solutions. Today Linux is a solid alternative which is not even questioned anymore, it is largely used as a solid, reliable, simple and cost saving alternative. Something similar will happen to the network operating system that we use these days. I would put my money on the second type of engineer, able the integrate open source solutions and operating with principles. Russ thanks, it was refreshing for me to see that I made the right choice (if there is one :-)) ) … Daniel thanks for facilitating this conversation
There is no reliable and well-packaged open-source solution like Linux for networking. So in the meantime the network engineers who want to deploy open-source solutions will have to get fairly deep into the code (not just some scripting) in order to troubleshoot the network. Also, Linux is somewhat self-contained, but white-box networking solutions rely on the forwarding ASIC which has only very recently started opening up its APIs. Until there is widely available knowledge and standardization of these APIs in the industry, the white-box model will not see much adoption.
That is because you believe that we have to be network programmers and we have to write code. I believe that we will need scripting. Arista is a good example of NOS with a Linux kernel. There will be more.
you can write protocol code, you can write code to control your network gear or you can write scripts to automate your work. We need to do the later, the programmers will be left with writing code. You can not have both, no matter how much marketing Cisco or others put in this. Split brain results in decreased efficiency. Of course we can continue to believe in surgeons with a CCIE in DataCenter technologies but …. they can do only one thing at a time
Pingback:On the 'net: The Future of Networking - 'net work
SDN is changing the world, and if u r to slow to adapting you can be left behind. I describe this in my book and show methods and direction of what you can do next, and how you can transition from network engineer into SDN engineer and other similar fields. I also describe special coding tactics that can help you quickly learn code. studyguide.net/SDN
Pingback:On the ‘net: The future of networking – rule 11 reader