SDN: Programming Skills Needed - Or Not?

A lot of discussion around software-defined networking has focused on the future of network engineers and how they will need to develop new skills to adapt to the future of automated and programmable networks.

Indeed, the topic came up at a panel keynote at Interop Las Vegas on Wednesday. Steve Shah, senior director of product management at Citrix, said networking pros need to evolve their skillset for automation. Right now, there aren't many IT folks with both networking and skills in programming languages, such as Python, he said.

Arpit Joshipura, vice president of product management and marketing at Dell Networking, agreed. "You need the network to be programmed, not provisioned," he said. "That is the fundamental change that will happen in five years."

But Dominic Wilde, vice president of global product line management at HP Networking, said the notion that "all of the sudden you have to become programmers overnight" is false.

"That's the fallacy we need to move away from -- you don't need programming skills," Wilde said.

While there will be a number of large enterprises that want to programmatically go in and code to northbound APIs and get deep into the details, the majority of companies are looking for simpler SDN products, he said. HP is working with more than 35 partners to create turnkey SDN systems that don't require programming skills, he said.

But Shah noted, "If you want a more malleable network, then that programming skill comes into play."

He cited PCI compliance as involving a lot of applications and complexity; in a programmable network, a script that instantiates devices needed, such as firewalls for PCI compliance, could be tested and rolled out in a week.

The panel, which was moderated by Eric Hanselman, chief analyst at 451 Research and SDN track chair for Interop Las Vegas, also addressed the state of SDN, how companies can get started on the transition, and obstacles.

Panelists agreed that SDN has moved past the "wild fantasies," as Hanselman put it, to actual products and deployments. Wilde said SDN has gone beyond discussion of pieces like controllers to practical solutions for business problems such as better quality of service and security.

"I think people are seeing the potential" for how SDN can simplify network operations, he said.

But Hanselman noted that there's still plenty of healthy skepticism surrounding SDN. Networking teams have been able to perform quality of service and isolation previously, so what's different with SDN, he asked the panelists.

Wilde said automation and abstracting network complexity for greater agility is key. For years, network virtualization has been accomplished via VLANs, he said. With SDN, network virtualization doesn't require reconfiguration of the underling topology of the network and can be done at greater scale, he said.

Companies face plenty of challenges in transitioning to SDN, panelists noted. Organizational issues and a lack of interface standardization are two challenges, Joshipura said.

He said there are three approaches to SDN -- proprietary, overlay and open source. "The fragmentation of how to get there is one of the challenges as an industry we need to address," Joshipura said. "We want to give customers a choice on the path to migration. It's not that a protocol is better than an overlay... It's a choice."

Wilde said customers need to understand how to apply SDN concepts to their specific environments. Networking teams also will need to change the discussion at the C-level when requesting more resources, he said. That means showing how investment in applying policy directly to the network will help create new lines of revenue.

In terms of next steps towards SDN, organizations need to look at software integrations and who is partnering with whom, Shah said. "This is fundamentally about software orientation, about making it all software... If you choose something, will you get the integrations you need?" he said.

Wilde advised companies to start small with SDN by using it to address a specific operational issue, such as malware at the network edge or a poor user experience with UC applications.