Software defined networking is one of the most misunderstood concepts in infrastructure computing. It's a phenomenon that's growing in relevance, but it's still mysterious to many CIOs, particularly those who were not reared in overly technical practice. Many myths still surround SDN. What exactly is the notion behind the technology? How can you apply SDN at your business? And how can your organization benefit from it.
Software-Defined Networking Basics
Essentially, SDN takes the virtualization phenomenon that's been sweeping datacenters around the globe for the past several years and extends it from computing hardware and storage devices to network infrastructure itself. By inserting a layer of intelligent software between network devices (such as switches, routers and network cards) and the operating system that talks to the wire, software defined networking lets an IT professional or administrator configure networks using only software. No longer must he travel to every physical device and configure-or, in many cases, reconfigure-settings.
SDN achieves the same abstraction that hardware virtualization does. With hardware virtualization, the hypervisor inserts itself between the physical components of a computer (the motherboard, main bus, processor, memory and so on) and the operating system. The operating system sees virtualized components and operates with those, and the hypervisor itself translates the instructions coming to these virtualized components into instructions the underlying physical hardware can handle.
As a result, you can move virtual machines to different computers made up of different underlying hardware as long as the hypervisor is the same or is compatible. That's because the operating system in the virtual machine has to know only how to talk to the virtualized components; it can't see or interact directly with the underlying hardware. This abstraction provides a freedom and more capability to configure and reconfigure computers and servers as ongoing operational needs dictate.
This abstraction idea is the same in SDN. It just involves different pieces of hardware. Networks are virtualized so software can configure how networks are built, routed and configured. While the underlying physical network components still route the actual traffic, the place where that traffic flow is controlled-which is called the control plane in SDN parlance-moves from the hardware to the software running on top of it.
Analysis: Exploring the SDN WAN Use Case
This is useful because the network then transforms from a bunch of wires physically connected to a lot of different devices-as you might guess, this is the data plane in SDN vernacular-into a quasi-intelligent fabric that can be controlled, rerouted, redesigned and troubleshooted (troubleshot?) from a software console.
In particular, it allows for self-service network reconfiguration. When users request resources for themselves, the network can automatically accommodate connectivity for those requests-even if the resources are located in different physical areas. The network appears to be one "unit" to the end user, a main benefit of this type of virtualization.
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.
News: Intel Lays Foundations for SDN Gear That Could Shake Up NetworkingMore: Intel Invests in SDN Pioneer Big Switch Networks
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.)
Related: Network Administrators Look to SDN With Hope, ConcernMore: Opendaylight is Building on Our Work, SDN Group's Director Says
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.
Software defined networking is a concept that still has a ways to go before it should be considered mature. Standards are evolving, vendor support is patchy but improving, and many administrators simply don't have enough impetus to really get the ball rolling on proper deployments.
For companies that have, or plan to have, extensive private cloud implementations, SDN provides a way to squeeze more usability and flexibility from existing network component infrastructure. Companies running public clouds, either from themselves or for paying customers to use for their own hosted infrastructure, already know this material and are well positioned to take a leadership role in pushing for standards to mature and manufacturers to support OpenFlow and other industry SDN efforts.
The SDN concept is still forming, but it will play an increasingly important role in networks around the globe in the next two to three years. Be ready.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.