Network Engineers: Don't Be The Dinosaur

The way networks are conceived and managed is no longer about the individual components; it’s about the whole. Vendors want IT consumers to see their networks as integrated systems providing an end-to-end group of services that work centrally together to deliver an application. For network engineers, this means big changes ahead.

Most network pros are used to point solutions: Firewalls go in certain places; network switches are sized for port density, throughput, and function, and placed accordingly; and WAN routers connect non-Ethernet circuits to enterprises and campuses. For the most part, each of those elements is managed individually.

The implications of this go beyond daily network operations; the greater challenge is that of executing a network design across a diverse infrastructure. This is a difficult task, requiring that an architect intimately understand application requirements and behavior, as well as the abilities of network hardware and software to deliver those requirements. Consequently, network designs often stop at connectivity: It's good enough if the network is delivering IP relatively quickly. This is the plumber’s perspective, and it’s the wrong one to hold in the context of modern IT.

Unification of IT policy delivery up and down the stack is the wave of future. Networking can take its cues from the virtualization and automation folks. Those people can create deliver new instances of applications in minutes, automating the installation of an operating system, storage, and virtual network connectivity.

The challenge is for networking to catch up to this way of doing IT. Firewalls, deep-packet inspection devices, application delivery controllers as well as garden-variety routers and switches need to be provisioned in the same amount of time that applications can be spun up on a hypervisor. As a result, software-defined networking (SDN) has come into the spotlight.

I don't think there's much question that SDN will become a normal part of networking’s future. IT is an engine, and networking is a part of what enables that engine to power organizations. It’s time for networking to stop being aging oil in need of a change and start being a superior lubricant that helps the engine rev to its maximum capability -- that means a change in the way network operations is done. SDN appears to me to be the way forward.

While the industry doesn’t know all of the details yet, what’s clear is that much of networking will be automated -- an expression of policy or intention that is defined at a high level and pushed down into the network infrastructure via software. If that big idea comes to pass (and it already has in the approaches of certain vendors), then that means the way networking professionals do their jobs will change also.

[Get tips on how to start down the road to software-defined networking in "Making the SDN Transition: First Steps."]

The biggest change in the profession will be the need to be cross-disciplined. While it has always been helpful to me to know a thing or two about DNS, HTTP headers, the darker details of proxy servers, and scripting, I posit that these skills and many others like them will become necessary. The networking professional of the future who only understands packet delivery will be incomplete. He or she will also need to understand virtualization, storage, automation, and application programmatic interfaces (APIs).

In other words, to understand what the network is doing, the future networking pro is going to need to understand both the tools that configured the network as well as the methods those tools use to perform that configuration. Plus, all of that knowledge must be understood in the context of the application that the network has been asked to deliver.

That’s a lot to know. But this way of thinking isn’t that different from what highly competent network engineers drive themselves to understand today. Networking should never be just about the network. Rather, networking should always be about the level of service the network is delivering to the applications that ride on top of it. Why? Those applications make an organization run. The very best network engineers know how to tune a network to effectively meet an application’s needs. Implicitly then, these engineers understand applications.

The change SDN is bringing is in how this tuning will be done. An SDN controller will take policy from an engine, abstract that intention into programmatic instructions, and then tell the network infrastructure how to behave. Network engineers will need to understand policy engines, comprehend how the controller works, be able to effectively second-guess the controller’s attempt at programming the network, and debug the inevitable failures.

They'll also need to write code that allows them to express their own policies or integrate antiquate network gear into the software-defined paradigm, gather controller data to demonstrate the network is performing as defined, and harvest network data to update policies for handling unusual situations or peculiar traffic flows.

All this will require new skills and perhaps the retirement of old skills. It's clear this change isn’t going to happen overnight. Despite several bold pronouncements of the end of the expert-level network engineer, the flow of recruiter mail to my inbox hasn’t slowed. And they aren’t asking me to build a software-defined data center yet.

Still, network engineers with an eye to the future are getting serious about understanding SDN, getting a handle on automation techniques, and contemplating that virtual switch with a little more soberness than they once did. Let’s not be dinosaurs when the meteor hits.

[Ethan Banks will participate in what is sure to be a lively panel discussion, "Will SDN Make Me Homeless?" at Interop Las Vegas, which begins March 31. The panel will look at the changing role of network and IT pros as automation alters the networking field. Register for Interop today!]