creative soul - Fotolia
Most network engineers recognize the networking landscape is changing rapidly, as are the network engineering skills needed to run those networks. Software-defined networks promise to replace the distributed control planes that have been used for the last several decades with centralized controllers. Intent-based networks promise to replace network engineers with plain business-language interfaces that anyone who knows what should be done can use to create networks that do the right thing. The network engineers traditionally translated business requirements into network designs, equipment specifications and configurations.
In addition, disaggregation threatens to replace vendor-based networking gear, which most network operations personnel learned to use from the time they entered the field, with a mix of open source components and an interface closer to server operations. Finally, development operations, or DevOps, is replacing the command line with automation tools.
The networking landscape is littered with training to help network engineers learn new skills, but it allows little time or guidance for the retraining process. Far too often, retraining feels like leaving all your old network engineering skills behind and learning all new ones. The wide array of paths the average engineer faces, combined with the uncertainty of which path represents the real future, can seem overwhelming.
On the business side of retraining, companies also face a networking skills gap of massive proportions. Few qualified engineers are available. Most companies are just as confused about the future of the network as network engineers and are looking for skill sets that are difficult or impossible to fill. The gap among network engineering skills, training and cultural mindset seems to have reached peak confusion. To find a path forward, we need to bridge the gap.
Let's start at the very beginning
One suggestion might be to return to the beginning, which means returning to the basics of networking.
An illustration might help drive home the importance of the fundamentals. When you're playing soccer, basketball or any other sport where physical presence is an important factor, you need to know where your opponent is going. Anyone who has played these sports will tell you that watching the opposing player's arms and legs flailing around won't tell you much about the player's direction or intent. Instead, you need to focus on the opposing player's core -- the body parts that move the slowest.
The same holds true when trying to find your way to a location marked by a flag or searchlight. The motion of the flag or the beam will attract your attention, but the solidly planted flagpole or the source of the beam is the real location indicator.
A similar approach might work for network engineering. Perhaps we can bridge the skills, training and requirements gaps if companies and engineers change their mindsets to focus on the networking basics that don't change, rather than on things that do.
Ask the right questions
One path forward is to ask what problems network engineering solves. The answer might seem obvious -- networks transport data to make applications run. But this view of network problems and solutions is rather shallow. It's important to break this question into smaller pieces and deeper components. The following questions are good examples:
- How does the network know which application is running on which host?
- How does the network know which host is connected where?
- How does the network know how to encapsulate data so it can be transported?
- How does the network deal with data errors?
- How can two hosts adjust the flow of data across the network so the receiver is not overwhelmed, the transmitter is not starved and the network is properly utilized?
- How does the network know which path between two attached hosts to send any particular packet?
These questions represent the basic concepts needed to build a network. No matter whether software-defined networks or distribution control planes are deployed, each question needs to be answered. No matter what you call the protocol that carries traffic through the network, these kinds of questions must be answered.
In times of change, the way to bridge the gap between what's needed in terms of network engineering skills and what's offered in terms of skills and training is to return to the points that change the least. These points offer the most common ground between operators and engineers. The basic algorithms, processes and concepts can serve as a meeting point between the present and the future -- no matter what the future may hold.