The momentum behind software-defined networking (SDN) has been growing for the past few years. Today, SDN has arguably reached a tipping point in terms of maturity and acceptance, offering more options than ever for enterprises and cloud service providers looking to tap into the capabilities it offers to revamp their networks.

To understand SDN without the marketing mumbo jumbo, we spoke to Charles Ferland, vice president of business development at Nuage Networks. Ferland hails from a technical background with over a decade of hands-on experience as senior network architect and solutions engineer at places like Nortel and Telus.

Ferland explains what SDN is really about, predicts the end of vendor lock in and describes the top challenges when it comes to implementing SDN in the enterprise.

Understanding SDN

So what is SDN in a nutshell? Ferland draws an allusion to server virtualization, highlighting how SDN offers a way to similarly abstract the hardware and networking protocols. The idea is to cut away the manual process of setting up new firewalls, load balancers and other network appliances, and instead open the door to provisioning a new network infrastructure within a few minutes.

“What that really means is that network administrators and companies sort of got tired of programming very complex protocols,” explained Ferland. “They got tired of having to deal with one network vendor’s OS, command line interface for another vendor, and having incompatibility between the two. They got tired of managing network separately from the rest of the IT infrastructure.”

In an ideal world, SDN would allow IT departments to attain the same agility with their networks that they now have with servers. This agility is amplified too, when one considers how enterprises and cloud providers have traditionally been held back by the disconnect that exists between provisioning their server infrastructure and having to manually set up the physical network. Seen from this point, SDN allows businesses to leverage the benefits of virtualization far better.

Obviously, there are different ways that networking vendors are approaching SDN; some are adopting a more hardware-driven approach, while others are doing everything via software. Which brings us to the the question: would organizations end up swapping out a bunch of proprietary legacy networking gear for a sophisticated, highly agile SDN solution that is just as proprietary?

The end to vendor lock in?

Network vendors will certainly look to offer some added value to their solutions, said Ferland, which is another way to say that no two SDN solutions are likely to work or be configured the same way. Yet organizations are changing how they consume network resources, he added, pointing to how organizations are increasingly evaluating platforms such as OpenStack.

“When a virtual server is created [in OpenStack], there is a standard set of commands that are sent over to the networking plug-in … and we provision the virtual network based on this standard set of commands,” he told us. “From an orchestration point of view, it is the same command that we are passing down the network.”

So just as organizations would want to avoid solutions that only work with select hypervisors, the advice is to look for SDN solutions that offer support for platforms and orchestration tools that they use. Indeed, Ferland insinuates that the days of vendor lock in may be numbered, as he argued that SDN offers organizations more options than ever.

“What SDN offers our customers is to level the field [in terms of] the network infrastructure that they use. All we will be asking is basic connectivity between point A and point B,” he said, noting how having a specific hardware equipment is no longer an issue with SDN. “This opens up a lot of new possibilities to shop around for vendors for the best capability and functionality – and they are no longer tied to legacy hardware.”

Barriers to implementing SDN

Interestingly, one of the top challenges when it comes to implementing SDN lies not in the technology, but with the people. Specifically, the network engineers who are tasked with implementing SDN within their organization can sometimes be resistant to change.

“I can’t speak for all of them. But it’s perhaps the strongest pushback I have in meeting customers over the year,” said Ferland, noting that administrators tasked with handling virtualization, in contrast, often see the benefits of SDN immediately. “When I talk to the networking guys, they don’t feel compelled with the value proposition, they feel threatened that the control of the network is now slipping away from them.”

This fear is unfounded, he said, as there is still a need for network administrators to maintain the physical network. And while SDN greatly simplifies and speeds up the deployment of the network architecture, technical skills and inherent knowledge of the company’s requirements is still required to design and implement the new network infrastructure via SDN.

“First of all, we still need to have a physical network. We still need to build a network infrastructure,” said Ferland. “The second thing is we still need to have the network architecture skill, a network architect to design.”

Finally, Ferland argues that SDN offers a way for network engineers to do things faster, allowing them to focus on new strategic tasks that are “more meaningful” as opposed to solving the same network-related problems “over and over again”.

“Once they realize that they still need to do the network architecture, that it gets automatically applied and they no longer have to do it manually to each of them, they start to appreciate SDN a lot more,” he concluded.

Charles Ferland will be speaking at our annual DCD Converged conference in Singapore later this year, where he will share thoughts on building enterprise networks with workloads hosted in both private and public clouds. DCD Converged Singapore 2015 will be held at the Marina Bay Sands Singapore alongside Singapore Datacenter Week on September 15 and 16. You can obtain more information about the conference here.