Why Has Software Defined Networking Emerged?
SDN evolved from virtualization primarily because of its usefulness in public and private cloud scenarios. Running clouds involves an enormous amount of network configuration and planning. Especially in disaster recovery scenarios, it's especially valuable to be able to reconfigure networks on the fly from software.
In addition, most SDN implementations are open sourced-or at least based on widely accepted international standards-and thus are supported by a variety of different vendors. This sort of vendor neutrality is implemented by a set of APIs called OpenFlow. Think of OpenFlow as the engine and the mechanics behind implementing SDN. Most tools that let you administer and configure virtualized networks use OpenFlow to communicate with the various physical devices on the network.
In the past, a network might have had several different profiles of capabilities among the different vendors represented in the infrastructure. Having an SDN implementation lets an administrator holistically administer the entire network using a known set of universal capabilities without having to worry about some vendor gear only supporting some specific capabilities and not others.
SDN is taking on a particular prominence lately because it's essentially the last frontier of physical devices that have yet to be virtualized for easier management and usability. Hardware virtualization has been around for a while, software virtualization is ages old, but networks are the last stone that has been left unturned in this new "virtual" way of thinking. Additionally, mainstream operating systems are beginning to add direct support for managing and configuring software defined networking. Windows Server 2012 and the upcoming Windows Server 2012 R2 in particular both offer increased support for managing SDN implementations.
Drawbacks, Disadvantages of Software Defined Networking
The main issue with SDN is that it's new. Because of this infancy, many believe SDN implementations are not ready for prime time. Networks and backbones perform such a core and critical role in corporate IT operations. Plus, given the somewhat patchwork state of both OpenFlow APIs themselves and also vendor support for them, it stands to reason that you shouldn't plan to rely on network virtualization and SDN implementations fully at this time. (That said, as the OpenFlow stack of interfaces matures, and more network component vendors decide to fully implement SDN compatibility based on standards, SDNs will emerge into maturity.)
Where might SDN deployments be appropriate? If you're thinking of setting up a private cloud for a department or a given set of development projects, that would represent an excellent opportunity to pilot some of these technologies with good gear, good software and good practices. Additionally, if you're planning a major, entire network restructuring, it may make sense to plan for SDN and deploy it in certain spots with an eye toward expanding your implementation as your network grows. It wouldn't be wise to invest the kind of money that a major network overhaul would require without planning for SDN in some way.
Sign up for Computerworld eNewsletters.