SDN: Seductive But Challenging

There is no doubt about the promise of software-defined networking. With explosive growth in server and storage virtualization, it's natural to look at infrastructure and ask: Can the advantages of speedier deployment, flexibility and cost be extended to the network? Most definitely, there are SDN benefits -- the technology is certainly seductive -- but it's not a slam dunk. There are some fairly challenging obstacles to SDN adoption.

First, let's look at the benefits. With SDN, central management via software of network data packets becomes possible. SDN removes the constraints of firmware in individual network hardware devices and replaces them with  the flexibility of programmable behavior. This decoupling of the control plane from the data plane means easier network traffic control, without the need to individually manage distributed hardware as is done today. 

Dynamic network provisioning becomes a reality -- architectures that can be easily reconfigured for performance or security reasons. Indeed, you could have rule-based continuous optimization of a network in real time, a far cry from the effort needed today to make changes to a complex infrastructure environment. 

If a new need arises, such as a QA lab asking for a particular LAN environment, some new load/flow-balancing need, a QoS or policy enforcement requirement, or a need to scale, voilà, the network admin becomes the fast-acting genie to make it happen. Connecting and reconnecting VMs becomes as natural as managing the VMs themselves. A key benefit: experimentation!  Much more can be tried out in an SDN environment than could be afforded traditionally. Agility results from fast feedback on changes that are made, and agility is what every business is looking for.

So what is in the way of this SDN seduction? Here are some of the hurdles:

• Interoperability is not where it needs to be for ease of adoption and widespread SDN deployment.  SDN controllers from different vendors are unlikely to work together.  The focus today is on north-south managing of network gear rather than cooperation at the top.
• Getting started is tricky. Companies have invested heavily in particular vendors and their devices.  It is unlikely that SDN comes in as a replacement to what is there; rather, it will likely be additive, “layered” on top of what already exists.
• What do you choose as the “right type” of SDN for your organization? There seems to be three flavors: overlay/additive; vendor-specific solutions using custom ASICs, with common APIs; and the “white-box” approach of relatively simple hardware acting as a commodity element designed to behave as switches, routers, etc., by their SDN controller. You need to know what kind of network flexibility makes the most sense for your environment,  but there are still few guide posts for figuring this out.

So should one take the plunge to software-defined networking?  SDN is still very new; there is certainly more talk than experience and products are few. That said, both established vendors like Juniper and Cisco have intriguing SDN products, as do newer companies like Plexxi.  This suggests that rather than being seduced into a deep dive, the best thing to do for now may be for IT departments to educate themselves, but also to start testing the waters.