Introduction
As a CIO, you’re already used to the myriad of acronyms that have made their way into the IT lexicon and that you, as CIO, have to constantly convert to human-speak. Further, you’re used to having to come up to speed on the various concepts that accompany every new wave of acronyms. This article will take a relatively simplistic introductory look at a new one.
SDN hits the streets
Today’s acronym is SDN, which stands for Software Defined Networking. If, even after getting a peek at what the acronym stands for, you’re still in the dark about what SDN and Software Defined Networking actually mean, you’re not alone. In fact, you’re likely to see a lot of new acronyms that start with SD – software defined – over the coming months and years. It seems to be the new topic du jour in the enterprise IT world, but it actually means something.
In the context of the network, software defined networking brings a new level of abstraction to the physical network. Now, you may be thinking that this sounds strangely like server virtualization, which is also an abstraction technology. This line of thinking may lead you to compare SDN to VLANs, but it’s much more than that.
A step back
In order to really understand SDN, let’s take a quick look at how network traffic normally operates up to layer 3. In general, network administrators create rules that dictate how the network handles traffic. These rules are propagated to every device in the hierarchy. Once the rules are in place, a packet entering the switch waits while the switch uses its rules to determine the next location for the packet. All in all, it’s a relatively simple, predictable, straightforward process.
In this kind of design, even if an administrator creates rules centrally and pushes these rules out to the various devices, the operational methodology is still very manual, and it's very possible for others to make changes on individual network devices that can affect traffic patterns.
While there’s nothing inherently wrong with these kinds of network designs, they don’t lend themselves to immediate flexibility as business needs change. An administrator needs to touch a number of different hardware elements in order to make necessary configuration changes.
This is because traditional switches have both data and control planes residing inside the units. The control plane in the switch is responsible for making decisions about where to send data, which then becomes the responsibility of the data plane, which controls the actual handling of traffic in and out of the device.
In addition to this inherent limitation, data centers have undergone a sea change with regard to how network traffic flows. This is primarily the result of virtualization. Today, virtualized workloads are constantly shifting between servers in the data center and even between data centers. This is in addition to the natural client-to-server and server-to-client traffic that has always been there. So, instead of traffic just going in-and-out, it’s going side-to-side, too.
SDN centralizes control of the traffic patterns
With SDN, a central control device becomes responsible for the control plane, leaving just the data plane at the device level. This abstraction and centralization makes it easier to direct and redirect traffic down specific paths and allows applications to believe that they own the network.
It also allows for the deployment of hardware that is potentially much simpler but that runs a much more complex software stack to enable SDN’s functionality.
If that sounds a bit familiar, it should. When you think about server virtualization, something similar is happening. Rather than provisioning a physical server for an application, you’re creating a software-based abstraction of that physical container for said application. The application merrily moves along, believing it “owns” the hardware, even though there is a sophisticated and, to the application at least, invisible hypervisor that’s really managing everything.
SDN enables a primary focus on the application, not the network
Networking today is very driven by, well, the network. When users want to use bandwidth-intensive applications, there needs to be networking equipment that can support such use, and the equipment needs to be carefully configured to operate as expected. I clearly recall many, many times when my team and I needed to support what we considered an unusual setup in an unusual location. In these setups, we often had to install and configure networking equipment to support a particular need outside its “normal” boundaries. Perhaps, for example, we needed to stream live video from someplace other than the normal venue.
By removing the control plane from the hardware and moving to a more central location, SDN simplifies this situation. Just as administrators can very easily migrate running virtual workloads between host servers to meet new needs, network administrators using SDN will be able to retarget network resources at emerging and unusual needs.
In other words, the network becomes a true enabler of the application, not just a transport on which that application rides.
If it becomes mainstream, SDN will affect your personnel
Your network team is probably extremely well-versed in routing, switch, Cisco-ese and everything else that it takes to make sure that you have a robust network. And they’re probably not programmers.
Many have likened SDN to “programming the network” in the same way that one goes about programming the computer. As such, managing an SDN-based network will probably require either a number of additional or completely different skills than CIOs have in-house at present. For those wishing to go down the SDN path, that’s an additional hurdle that must be overcome.
OpenFlow = Abstraction even between vendors
It’s easy to see how quickly SDN could devolve into competing standards and proprietary implementations between vendors. But so far a number of big industry players have coalesced around OpenFlow. As long as these vendors implement OpenFlow completely and consistently, it is possible to manage the entire environment from a single location, even when the environment includes equipment from different vendors.
OpenFlow is the “S” in SDN. OpenFlow is one way to enable SDN in the enterprise, but the terms OpenFlow and SDN are not interchangeable. OpenFlow is an open protocol.
Through the use of a protocol like OpenFlow in a network based on SDN, administrators can gain more sophisticated management capabilities than is really feasible through the use of traditional networking tools such as Access Control Lists and legacy routing protocols. As a former network engineer, I, personally, love anything that can bring order to what can be chaos.
SDN could bring simplicity
I’m a huge believer in anything that can bring significant simplicity to the IT realm and allow scarce IT resources to be brought to bear on bigger business issues and enable additional flexibly in IT systems. SDN has the potential to help IT departments more easily manage their networks by normalizing inconsistent policies across the network, taming multivendor challenges, and making it easier to solve business problems.
Action Item: CIOs should closely monitor the SDN landscape and watch what their vendors of choice do in this space. Just ten years ago, x86-based virtualization came on the scene and, today, more virtualized workloads are deployed than physical ones and our data centers have undergone a massive transformation. Based on what I’ve learned about SDN so far – and there is a whole lot more to learn! – I see an interesting future for networking pros.
As a CIO, I certainly wouldn’t jump until standards have been further refined and network vendors have truly committed to SDN, though. While it’s something that I believe has potential, CIO’s should simply watch the space and take a wait and see approach for now.
Footnotes: Also see Networking Revolution: Software Defined Networking and Network Virtualization
