General – The Future of Networking – Russ White

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.