The role of a network engineer has been pretty much the same since companies like Cisco worked out how to quickly and orderly punt packets down copper and optical cables, but things are changing.
The growing uptake of Software-Defined Networking (SDN) is driving the change, and engineers will need to adapt or be left behind.
Once controversial, SDN-based products have been on the market now for some years with an increasing number of production networks using them.
You’ll find SDN in products from vendors large and small (for example, Cisco, Juniper, Allied Telesis and NoviFlow), and it has become core infrastructure at major cloud providers.
Furthermore, SDN has been found in applications from data centres to the WAN, and even in the enterprise. SDN plays a central role in Facebook’s open-source 5G controller, Magma. You can even buy network devices specifically designed to host applications.
The concept of network devices being programmable computers that can be re-coded at will with new features and protocols just like the original IMP is back. That’s quite a change from today, but what does this mean for the network engineers of tomorrow?
Josh Bailey, who is an open-source developer in Wellington, New Zealand, and part of the team that develops the FAUCET SDN controller, explains that the field will change, and the future looks exciting for engineers.
“If you don’t have software skills now, then there’s never been a better time to learn. It’s maybe an understatement even, because those skills will be in high demand,” says Josh.
“The software and site reliability engineering communities are huge, and they have powerful tools and mature practices for safely managing many millions of computers,” he adds.
What SDN reminds us is that network devices are just computers. What’s more, there is only ever going to be more and more computers switching packets tomorrow.
Josh says these computers still need skilled operators and troubleshooters. Importantly, today’s network engineers have a key advantage over their software engineering peers.
They know not just what those ‘network computers’ are supposed to do today but also what they could do for us in the future. That’s the immediate future that we’re headed towards and it’s worth considering how that scenario differs from today.
“For non-SDN network engineers today, it’s possible to go an entire day, perhaps even an entire career, without looking at a line of networking code,” says Josh.
“That’s the principle on which the networking industry was built. Network engineers, vendors and researchers work together to create and refine interoperable standards in industry forums. Some of those standards make their way into products, and some of those products then end up in networks.”
Over time those many products implement many standards, some of them more or less interoperable in practice, and a community builds up around them. This practice has served us well, but also led to an unusual divide between software and hardware so to speak.
“Traditionally, if a non-SDN network engineer finds a bug in networking code, that person would not be responsible for fixing it,” explains Josh. “Instead, fixing the bug is up to developers at a network equipment vendor. This arrangement has advantages, including clear lines of responsibility and the network engineer doesn’t need to know how to write or read any code.”
If a network engineer is ultimately dissatisfied with a vendor’s products, they can choose other devices from another manufacturer that offer comparable functionality. Unfortunately, as Josh points out, it’s not always that straightforward.
“That is, as long as the needed standards are available,” says Josh. “Or, if they’re not available but you can convince a vendor to add it. Perhaps you can convince a standards body to establish an entirely new standard.
“With SDN you have another option: provide your own software that does what you want. Someone has to write that software but that someone can be you. You don’t need a vendor to provide it if you can code, and that’s empowering.”
This administrative dividing line of responsibility where engineers don’t read or write code is unique to network engineering. In comparison, that division never happened for other parts of the Internet software stack. Operators of DNS servers, web servers, compute clusters, and more have always had to be familiar with operating systems internals, writing their own tools, reading source code, and maybe even fixing bugs.
“Sadly, this administrative boundary between coders and non-coders holds us back,” says Josh.
“Network engineers don’t get to express their ideas to the full because they can only be expressed through code. That code is written by others.
“In a world where we encourage our youngest and oldest to write code, why exclude network engineers?” Josh asks.
Then there’s the issue of fixing others’ mistakes: network engineers are quite right to be concerned about the software on their devices because like all code, it has bugs. Some of that software is huge, and that isn’t necessarily something to be proud of; in fact, it’s quite the opposite and something to avoid.
Software has a well-established life cycle pattern: when it gets big, it gets complex, hard to understand, and hard to fix. That’s the time to consolidate what you’ve learned, discard the rest, and create better and smaller software.
SDN doesn’t mean ‘more software’. SDN recognizes that there’s an opportunity to make networking software better, more flexible and reliable, requiring less work to operate and ideally, smaller too.
Network engineers are needed more than ever to get us there, but they need to get coding.
Juha is a technology writer and journalist, based in New Zealand. He is a contracted contributor to the APNIC Blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.