News Stay informed about the latest enterprise technology news and product updates.

In software-defined networking, complexity...what a turnoff

In all the excitement over software-defined networking and network programmability, one problem is often overlooked -- code complexity. Is SDN complexity worth it?

The basic belief behind OpenFlow and/or software-defined networking (SDN) is that the controller and applications ecosystem will flourish once SDN-friendly switches are available. But there is a greater SDN barrier to overcome -- complexity.

Ironically, one of the goals of SDN is to lessen complexity in network management by decoupling the control plane and centralizing its decision making into a controller. That could mean, for example, that uniform policy could be pushed down to groups of network devices.

F5 blogger Lori MacVittie points out in a blog this week that the other main goal of SDN is to enable programmability in the network -- and that never comes with simplicity. With SDN programmability, engineers could, for example, spin up multiple virtual-network instances on top of one underlying physical infrastructure, and then use SDN controllers to program Quality of Service (QoS) for each segment individually. This would enable new levels of flexibility for virtualization and cloud networking. Yet, as MacVittie points out, that's a lot of code -- and a lot of complexity.

She writes, "Most folks understand higher complexity incurs higher risk. This is not only an intuitive understanding that transcends code outwards all the way to the data center architecture, but it has also been proven through studies."

Read more software-defined networking opinions

Cisco software-defined networking: OpenFlow alone won't cut it

Welcome to the software-defined networking holy war

Why software-defined networking is becoming a reality

As we wait for SDN-friendly switches to become available, companies like Big Switch are using network overlays to let engineers build SDNs over any underlying physical infrastructure using tunneling. This means customers may no longer be forced to wait on switching vendors to step up with OpenFlow switches. However, this also means that network engineers will be managing not one, but multiple networks, including the physical infrastructure and every SDN built on top.

In his reporting on Big Switch's network overlay application, SearchNetworking's news director Shamus McGillicuddy asks Big Switch co-founder Kyle Forster one crucial question: "Is the pain of managing two networks worth it?" to which Forster fairly answers: "It depends on how many virtual machines one must support. In other words, if there's enough need for virtual networks, the complexity may be worth the trouble."

Forster's answer is telling about the state of SDN in general. Is it worth wading into complex code that could make networks unstable in order to introduce programmability? It really depends on how badly one needs that programmability.

For cloud providers, the need for programmable, virtual networks that can be used for internetworking data centers is pressing. For the typical enterprise data center, that's not the case just yet. On the other hand, that doesn't mean enterprises won't want to begin working with SDN. They'll look for ways to use SDN to manage parts of the network -- intrusion prevention in the campus LAN, for example. In those ways, SDN really might introduce the ease of management it promises. Over time, though, both start-up and conventional networking vendors will have to address the code complexity bound to be related to SDN and network virtualization.

Dig Deeper on Software-defined networking

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.