Inhibitors To SDN Deployment
IT organizations that are evaluating SDNs need to understand the availability and scalability characteristics of the particular SDN designs that they're evaluating.
One of the concerns with a controller-based approach to SDN is availability; that is, what happens if the central controller goes down? Another is scalability; that is, how many packets, call setups, processes, or flows can one controller support? To respond to those concerns, several vendors, including Big Switch, NEC, and Vello, support a clustering of their controllers. While that approach can mitigate availability and scalability concerns, it still leaves open what happens if the network elements somehow lose their ability to communicate with the centralized controller cluster. One network design option that addresses this concern is to implement a redundant link between the controller and each switch.
Another factor that limits the deployment of SDN is that there is no widely agreed-upon model for how SDN and OpenFlow-enabled networks will interface with existing network management platforms and troubleshooting tools. IT organizations that are evaluating SDNs need to have a solid plan for how they will manage and troubleshoot those networks.
We asked our survey respondents to indicate the primary inhibitors to their companies' adoption of SDN in the next two years. Their top three responses reflect a typical factor in an emerging technology market: product immaturity and confusion. The top response was the immaturity of current products.
However, the second-highest response was "confusion and lack of definition" in vendor strategies. Such confusion is understandable: As we've laid out, there are at least three viable approaches that can rightfully be considered software-defined networking.
Interoperability is also a concern. At present, any IT organization that tries to take an SDN controller and connect it to three or four vendors' OpenFlow switches would either fail or would, at a minimum, spend a lot of time and resources working with the vendors to make those devices work together because the OpenFlow protocol is still so new.
Given such growing pains, IT organizations may decide to wait and see how SDN develops. But vendors aren't waiting. They are trying to define SDN in a manner that best suits their own interests.
There are significant differences in the various approaches to SDN, so IT must make the effort to determine which one will yield the most benefit. The fact is, SDN has the potential to make your next network more flexible, more automated, and easier to manage. That's certainly worth the effort.
Jim Metzler is an analyst and industry consultant at Ashton Metzler and Associates. You can write to us at email@example.com.