There are numerous impediments to the adoption of software-defined networking, one of the major ones being cultural. In this case, the culture is one in which the network staff avoids the use of automation tools. This culture is based on the premise of: "Don't use anything that can break the network faster than I can fix it using the manual methods I know and currently use." SDN won't be successful in these environments until the network teams become comfortable with the use of automated network configuration tools.
Another form of cultural barrier is organizational inertia. As Network World writer Jim Duffy points out in Enterprises Hesitant on SDNs, the risk of change is causing organizations to proceed slowly. It is difficult to assess the impact of changing the fundamental network technology when the organization is running many applications, each of which needs to be validated.
A rule of thumb regarding technology improvements is that any new technology must provide ten times (10X) the benefits of the current technology to make the adoption of the new technology viable. Frankly, most enterprises don't see a 10X benefit from SDN over what they are already doing.
What about application agility? Many enterprises don't need to have new applications deployed any faster than what they are doing now. The current deployment process provides time for them to understand the application, create deployment plans, and understand how to diagnose problems when they occur. These organizations will need to develop new processes to rapidly deploy new applications and they are not prepared to spend the time to do this development.
A lot of planning will be required for an organization to migrate from an existing to new infrastructure. As an example, I worked with a customer who wanted to understand SDN and whether its recent investment in one type of network technology was now outdated. The plans that the company had developed over the past five years had it buying another round of non-SDN equipment. Its vendor was pushing the company to buy into the first generation of SDN-capable products.
Our approach was to look at its business processes to identify where SDN would be beneficial. Application agility wasn't a factor because its application deployment process hadn't changed. The business had over 75% virtual servers, but its existing processes wouldn't benefit from an SDN approach. The eventual conclusion, after reviewing the benefits of SDN, was that it wasn't quite the right time to switch to SDN. The company could wait for a second generation of SDN hardware, start learning more about SDN, and plan for a lab environment in which hands-on experience with some non-critical applications could be gained.
Use cases are going to be a critical requirement of enterprise acceptance of SDN. Without examples that clearly demonstrate value, enterprises will continue to do what they have historically done. So let's look at some:
A Network Packet Broker (see a definition at AndyHuckridge.com) allows the network administrator to select and forward packets to network analysis tools. A single, central set of analysis tools avoids the costs of maintaining multiple copies of expensive tools. The NPB forwards network traffic from anywhere in the data center to those tools. Probably the best-known NPB in the SDN space is Big Switch's Big Tap product. These products are in competition with the traditional packet brokers like Gigamon and VSS Monitoring.
Reducing human error through automation is one of the most-often mentioned use cases around SDN. But that goes back to the cultural change impediment that I mentioned previously because the network staff must become familiar with automation tools and get comfortable using them. New processes must also be developed to make automation effective and lower risk than manual processes. I don't see this as a strong tie-in to SDN, however, because automation can be adopted without SDN through automation tools like NetMRI.
Related to automation is network agility. Data center work-loads can move from one hardware platform to another as VMs are migrated. The network needs to be able to quickly adapt to the server's new location, creating a service chain of network services like load balancers, firewalls, VLAN definitions, and router connections. Relying on the network administrators to manually reconfigure the network will prevent the network from being as agile as is required by the IT systems. Container technology like Docker will exacerbate the problem, as I explained in a post on the NetCraftsmen blog .
SDN will provide the most benefit when applications are integrated with the network. An application will inform the network of a new data flow prior to the flow starting. The network can then route the flow based on network policies that are defined by the network administrator. Or, if there isn't sufficient bandwidth available, the network can inform the application, which can then take appropriate action.
The example that I used in my presentation at Interop 2015, on using SDN APIs in communications shows a unified communications application requesting that the network apply a dynamic Quality of Service marking to a new voice or video call. Both HP and NEC have demonstrated this capability with Microsoft Lync. Conversely, the network can inform the UC controller of changes that impact existing calls.
If bandwidth is constrained by a link failure, the UC controller can tell endpoints to switch to a lower bandwidth codec. On the other hand, if more bandwidth becomes available, the network can inform the UC controller, which can allow endpoints to switch to higher bandwidth codecs or to handle higher quality video. In another scenario, if there is insufficient network bandwidth to handle a call, the network can reply to the UC controller's request, indicating how much bandwidth is available. The UC controller can then inform the endpoints to use a codec that makes the best use of the available bandwidth. NEC talks about enabling priority calling, perhaps in a hospital setting, where an emergency call gets priority over other calls, set dynamically instead of statically.
At the other end of the interactivity spectrum, a disk replication application or VM migration could ask the network for a separate path suitable for a large flow. A benefit of a true SDN is that it can make dynamic forwarding decisions based on more than destination IP address. Including source IP address, protocol type (TCP or UDP) and port numbers provides the tools for finer-grained forwarding decisions -- although this may require hardware designed to handle the additional fields.
Other applications will have their own requirements to communicate to the network. I'm sure that we will see data base providers creating SDN API connections that will improve their functionality and performance. The integration of applications and the network requires that both the applications and the network change, which is one of the reasons why it will take time for this to occur.
One word: Competition. When a competitor identifies a use of SDN that provides a clear advantage over the non-SDN competition, then everyone in that market will adopt SDN. A few early adopters must demonstrate the value and an approach that works. The risk of not adopting SDN will then outweigh the risk of adopting it.
