Published: 03 Mar 2014
There used to be one question Randal Echterling could ask himself every day and know whether he was doing his job correctly: How's my network doing?
But that started to change a few years ago as more advanced applications crept into an increasingly virtualized data center. Echterling, a network architect at WellSpan Health -- a regional healthcare system based in York, Pa., that spans 120 patient facilities and has almost 12,000 employees -- has become responsible for ensuring the performance and security of a growing number of network-connected medical devices.
Network health is now almost a secondary, perfunctory concern for a networking team that finds itself increasingly focused on application performance. The team has become involved in application troubleshooting and worries about application design. One of WellSpan's network analysts is now writing Perl scripts and .NET code so he can better work with the application team.
Now, like many network engineers, Echterling is evaluating software-defined networking (SDN) and considering how the increased complexity that accompanies more abstraction, automation and orchestration will affect how he and his team do their jobs.
"I didn't really know what was flowing around in my network. All I had to worry about was the links," Echterling said. "Now all of a sudden, as part of SDN, you're going to get visibility into stuff you never saw before. It's like exploring a tomb -- just when you thought you got to where you were going in the last chamber, you find another door."
While widespread adoption of SDN and similar emerging technologies like network virtualization are still several years away, there is little doubt they will soon change -- but definitely not eliminate -- the roles of networking professionals across all industries.
"You're still going to need in those organizations [that adopt SDN] somebody who has an implicit and complete understanding of how the physical network operates -- what protocols operate on that network, how it's cabled, where the gateways reside, how the gateways work," said Brad Casemore, a research director at Framingham, Mass.-based analyst firm IDC. "But it's now incumbent on network engineers to keep pace with the change and learn the [newer] technologies, and if they haven't already learned about virtualization, then get more familiar with it."
Programming skills not required for most
It was a statement that at first sounded too radical to be taken seriously: Network engineers were going to be forced to become programmers. But as excitement built last year around what SDN could achieve through open standards like OpenFlow and northbound APIs -- and as Cisco Systems, the biggest vendor in networking, had yet to release any commercial SDN offering -- the idea that programmable networks needed network engineers who knew programming seemed reasonable. The Greek chorus of networking bloggers and technology journalists joined in, with commentary ranging from prudent advice about the basics of Python all the way to premature eulogies for the command-line interface (CLI).
Steven IvesonNetwork architect
Steven Iveson, a U.K.-based contract network architect in the financial services industry, was one of those bloggers. He wrote a four-part series of posts in early 2013 for Packet Pushers -- a podcast by network engineers that also hosts a blog on its website -- on why and how networking professionals needed to get comfortable with the very basics of programming.
But over the past few months, Iveson noticed a shift. It had become clear that, when uptime and reliability were at stake, most enterprises would rather purchase networking gear with commercial interfaces and support than rely on their engineers' budding coding skills, he said. Some vendors, including Cisco, have responded accordingly. Echterling, of WellSpan, is leaning toward Cisco's Application Centric Infrastructure for that exact reason.
"I've certainly changed my mind and don't believe programming is going to be an essential requirement for most anymore," Iveson said. "I've not seen many products or announcements that suggest programming will be necessary for them to be implemented. Products that do require it -- LineRate Proxy or [OpenDaylight], for instance -- are not aimed at network staff, [but rather] developers."
Teren Bryson, an IT director for a multinational company in the energy industry, agreed that the average network engineer can survive in a post-SDN world without becoming a programming whiz.
"People say, ‘Now there's going to be no command-line interface anymore, so everybody needs to know programming.' I say no, because these companies shipping controllers and software are not going to ship an empty, blank canvas [and force you] to completely write the interface from scratch," he said. "There's going to be a framework. There's going to be functionality out of the box, so I don't think you're necessarily going to have to know how to make your equipment function."
Bryson got into programming as a hobby before embarking on a career as a professional network engineer. Although he's refreshing some of his skills and has also written about the new role of "network programmers," he isn't training his networking team to become programmers in anticipation of SDN.
Bryson is, however, training them to think like programmers.
"I tell my people that programming requires a certain type of logical thinking that's actually really healthy for a network engineer to understand," he said. "I have found a lot of self-taught network engineers skip those fundamental critical-thinking aspects of solving a problem … [so] I'm trying to help people on my team understand the small component pieces."
That said, getting familiar with a few programming languages that have become popular in SDN projects, such as a Python, certainly wouldn't hurt, said several networking professionals.
"I think scripting and a bit of programming of sorts will be used for improved administration, management and monitoring in some fashion, as is already the case. The opportunities for this will increase," said Iveson, who recently published a book on programming basics for network engineers using the iRules scripting engine on F5 Networks' BIG-IP Local Traffic Manager software. "But ultimately, anything else will get left to the ‘pros.'"
New directions for networking pros
Not all network engineers are allergic to programming, however, and those willing to start learning development languages will find career opportunities to delve into programmable networks, according to IDC's Casemore. But he also sees another career path for networking purists. Engineers will likely have a chance to move into architectural roles that focus on how SDN abstraction layers and overlays affect network design and functions.
Moreover, not all disciplines within networking will fade into irrelevance. As IT organizations embrace more virtualization overall, having a greater understanding of network design and knowing how to troubleshoot with limited visibility will still be valuable, Casemore said.
"There's obviously still a role for the network engineer, but in some ways they have alternatives now, in terms of where they want to go with their careers," he said. "They're getting away from a lot of the cumbersome, repetitive tasks that the CLI involved … and in some ways, this can be very liberating if they embrace the change and really want to learn some new skills."
Echterling doesn't see SDN as a threat to anyone's job in his IT department at WellSpan, and predicts the technology will ultimately play a "minor role" in his network, with the prime benefit being the orchestration of many time-consuming administrative tasks via an SDN controller.
"You're not going to downsize the team, and you're not going to change the core focus, but you're going to expand it," he said. "And some of the stuff that was mundane, day-to-day administration -- moves, adds and changes -- we can orchestrate that a little bit better with SDN."
Randal EchterlingNetwork architect
It's all part of a professional growth process that was kicked off by server virtualization years ago, as the technology added new challenges for networking professionals who eventually adapted its effects on data center networks, Echterling said. SDN is merely the next step.
"It's going to change our roles and what we're doing, and we're going to be more application-focused than we are network-focused -- and that's just the nature of the evolution of the network team," Echterling said. "We are going to have to understand more about how the application works on the network than just how the network works."
It's a shift that many IT shops will undergo, according to Casemore.
"Roles and responsibilities will become -- I don't want to say blurred, but they'll become more collaborative," Casemore said. "That's a natural path I think every organization will traverse as they begin to adopt greater degrees of virtualization."
Rick Drescher, managing director of technical services at Studley Inc., a commercial real estate services firm in New York City, doesn't have any plans for his organization to adopt a full-scale SDN strategy. But he acknowledged it will likely force a market shift that requires most networking professionals to at least become more comfortable with virtualization and software environments.
"I do think that it's definitely going to continue to blur the lines, and it's going to require a workforce where engineers are a lot more well-rounded," Drescher said. "I think the super, super niche stuff like ‘wireline security programming for firewall ASICs' -- yeah, that's a special guy. He's probably not fun at parties, and he's never seen a girl naked before, but that guy is going to be very specialized still."
Others aren't fully convinced that many network engineers won't be edged out of their jobs, however. Iveson contended that the very same efficiencies SDN will bring to the network may make midlevel network engineers redundant in some IT shops, predicting senior- and entry-level networking jobs won't be hit as hard.
"If you can ‘set it and forget it' from a physical and basic IP perspective, and then the rest is ... abstracted, automated and orchestrated by ops or the server team, where's the work? Provisioning VLANs [and so forth] is boring, mundane and repetitive -- but it keeps people in work," Iveson said. "The common argument is that server virtualization didn't result in the server team being decimated, so why should that happen in networking? [But] along with the move to cloud-provided everything reducing the desire for in-house IT in general, I'm not so sure."
New skills that won't be found in textbooks
Although much of the discussion around the changing role of network engineers has focused on the technology, some networking professionals maintain that the philosophical changes will be just as significant.
"I think the mentality would have to change a bit. Today, we typically have this mind-set of, ‘We touch every device in the network,'" Bryson said. "It's a very tedious, one-by-one sort of mentality. I think with SDN, as it becomes more widely adopted, we're going to have to back off that mind-set … and look at the more holistic picture of what we're trying to accomplish with the network. We're going to need a macro-level approach."
The broad acceptance of virtual network appliances like virtual switches and load balancers suggests that shift in thinking may not be so challenging, Drescher said.
"We've already jumped over the mental block of, ‘No, the network is just hardware,'" he said. "Networking IT professionals in general have gotten to the point that they're already over that mental block."
Read about SDN projects on SearchITChannel