Software-defined networking is enjoying a lot of attention lately -- and a lot of that is generated by vendors...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
who see an opportunity to chip away at the stranglehold Cisco Systems has held on the networking space for the last couple of decades.
The questions for data storage professionals are: What exactly is software-defined networking (SDN), and why would you -- or should you -- embrace it?
There are plenty of people claiming to provide the only clear way to define SDN. Most of their definitions seem clear as mud to me. We hear SDN separates the network control plane from the data plane, prying the control logic of the network out of the switch or routers and placing it into centralized servers. This way, data-forwarding decisions can be made based on holistic views of the information distribution needed, rather than assessments of physical ports and pathways between connected devices.
Why do that? Because some vendors say today's network management is too labor-intensive and inefficient, requiring a lot of hand tooling, programming and administration of tens or hundreds of thousands of network devices. As with storage, network vendors have placed only a modicum of standards-based interoperability into their gear, but have piled on proprietary technology designed to lock customers into their products and out of their competition. As with the rhetoric around server and storage virtualization, SDN advocates seek to abstract "value-added" functionality away from the hardware, (which is increasingly commodity) and centralize this functionality on a server. This would happen in the form of a software controller that enables the allocation of network services to application data in a more efficient way.
In principal, that all sounds great. Such a separation might enable server-to-server traffic to flow directly between servers without utilizing less direct routes through core network devices. That would certainly free up some bandwidth. Also, adds, moves and changes could be handled in a more centralized and efficient manner, according to some advocates.
However, the real problem innovation is seeking to address is a burgeoning issue with server virtualization: the inability to adapt networks on the fly to the sudden rerouting of network traffic brought about by fielding a bunch of guest machines on a virtualized host. Traditional networks aren't designed to handle such flaky workload reconfigurations readily, advocates say. So, network resource provisioning can lag behind virtual server instantiation by several weeks. And SDN, evangelists argue, is required to "remove the network bottleneck" in the transition to the brave new world of virtual servers and clouds.
Blurry SDN vision
Framing the value of SDN within the already questionable context of server virtualization (leading analysts say that as of 2012 server hypervisors were only deployed on 17% to 20% of the server install base worldwide) and clouds (another poorly defined term that has seen far less adoption than cloud enthusiasts originally predicted) is troublesome.
And it will probably not help VMware to recoup its $1.2 billion investment in SDN pioneer Nicira, which it acquired last year. That purchase single-handedly touched off the whole SDN craze, and encouraged the co-opting and recontextualization of the way many vendors define SDN over the last few months.
Still trying to define SDN? Check out these links for more information
CTO explains the basics of software-defined networking
Exploring SDN architectures
Understanding SDN in your network
The resulting confusion may well limit SDN adoption. Frankly, I believe the evidence that SDN will return its investment sufficiently to offset the rip-and-replace method of implementation is weak. Moreover, Cisco seems to be encouraging those in its massive install base who are interested in SDN to embrace a slower, less disruptive and more evolutionary path to this architectural model. Cisco, for example, is trying to advance the SDN goal by improving control-plane connectivity by improving access and manageability to its gear via more open application programming interfaces.
The question of whether to evolve to SDN or implement it in a disruptive way comprises much of the back-and-forth between vendors and their mouthpieces in the analyst community, trade press and blogosphere at the present time. Competing alliances are forming and recruiting adherents as this piece goes to press.
Is there merit in the notion of taking Quality of Service managers, load balancers, identity managers, antivirus, antispam, intrusion-detection functionality, intelligent queuing and buffering and other functions off of their pre-integrated switch router platforms? Will it be less expensive to buy gear without these functions and to provide the functionality instead from a centralized shared service provider? Or are we simply transferring our network control (and budget) to another, potentially more demanding, master?
Drawing parallels to virtualization
We can discern some cautionary parallels between SDN and server virtualization. For example, we have already seen problems emerging from competing server hypervisors and the challenges that can arise when their proprietary stacks provide the infrastructure for cloud services. In many ways, we have gone backwards to a time before Samba, when asking Microsoft how to share data with a Sun Microsystems platform received the response, "That's easy; just get rid of all the Sun stuff."
More to the point, server virtualization analysts were saying in 2005 that the Capex spending to virtualize servers would end by 2009 and companies would realize huge savings in Capex and Opex from that point forward. As of 2012, even early adopters of server hypervisors were spending hard-to-come-by Capex dollars to keep platforms operational. Would SDN actually reduce costs in a consistent manner while improving throughput or capacity utilization efficiency, or are the gains to be realized too small to make the effort worthwhile? Fortunately, more and more firms seem to be asking these questions.
The best guidance I have seen thus far comes from the Open Networking User Group, which takes the position that purported Capex cost savings are irrelevant because networking gear doesn't cost that much to begin with. Clearly, doing incremental deployments to test the impact of the technology on current problem areas in your network is the best way to dip your toe in the SDN market.