Hardworking network admins for years have been eyeing the flexibility, cost reductions and automation of server virtualization and the cloud. We knew there had to be a similar answer in networking, and SDN technology emerged. Software-defined networking isn't a solution looking for a problem; instead, it's a real opportunity to transform the way we build and manage networks. It also can improve the daily lives of administrators. But...
for SDN technology to take hold, it'll need to be universal, vendor interoperable -- and most of all, not side-lined to the role of middleware.
SDN must be as ubiquitous as SNMP but a whole lot better
I recently attended Network Field Day 5, where one of the best things I heard went something like this: "App guys got interactive debugging and virtualization support in less than 10 years. It's been 20 and still all we have is SNMP."
The ubiquity of the Simple Network Management Protocol (SNMP) -- and its admittedly unsexy utility -- stem from it's being baked into pretty much any network device -- not from it's being in a box attached to the device. And all vendors do it the same way, which eliminates any possibility that potential customers can't integrate it into their management systems.
For SDN to succeed in its grassroots promise of finally delivering something far better than SNMP, it's going to have to be just as universal -- and it'll have to be mandatory for hardware vendor to provide it in every environment. The problem is, most vendors don't see it that way today.
SDN land rush: Will network vendors ever attain interoperability?
One reason network admins love the idea of SDN technology is that it effectively turns an entire ecosystems of gear into white boxes, allowing easy swap-outs with little manufacturer consideration or loyalty. That poses a bit of a problem for hardware vendors.
For network admins, SDN on white boxes could mean shopping for campus switches based on price and performance with little concern about management features. After all, when it comes to servers, you don't have to spend time comparing every feature of HP versus Dell. You don't have to closely examine price and bundle. HP and Dell accept that sales model and compete accordingly. But that's not nearly the case for network hardware vendors, who have no interest in seeing their hardware commoditized.
The same problem exists in the hypervisor market. Look at VMware, the granddaddy of virtualization. Does vCenter manage Hyper-V? No. VMware not only has zero incentive to participate in a truly agnostic management capability, but also has clear reason not to. Extending vCenter to manage Hyper-V makes would encourage Hyper-V adoption.
Yet, for SDN to fulfill its promise, vendor interchanges must be seamless. If an HP SDN controller is reconfiguring ProCurve rack switches as a vMotion shuttles virtual machines (VMs), it must have the same dominion over the Cisco data center router in order to provide a whole-architecture solution.
That then begs the question: Are major vendors joining consortiums like OpenDaylight in an effort to stack hands and quickly usher in universal OpenFlow application programming interfaces (APIs) that make networks plug-and-play? Or are they just making sure they have a seat at the table while they protect decades of product feature differentiations and ecosystems in an SDN landscape? I hope the first, but I fear the latter.
SDN technology is good news for third-party management vendors
For third-party management companies, SDN is good news. Wherever there is new IT complexity, there is a new opportunity for management. Did hypervisors reduce the number of managed devices? No, they reduced overall costs through concentration, but they actually created yet another set of things to manage.
Read Patrick's Fast Packet blogs on SearchNetworking
Got IPAM problems? Think trifecta
Tackling network security administration
IPAM solutions: To go overlay or replacement?
When it comes to SDN, the management vendors that are the most agnostic have the most to gain. They will be able to integrate SDN frameworks from different vendors with existing non-SDN management technologies into a single pane of glass. Even better, they can do it iteratively based on real customer need, with the added efficiency of fresh APIs rather than old, quirky and expensive-to-integrate legacy technologies.
However, where SDN could be relegated to the scrap heap of a million other great technologies is if vendors propose the technology as middleware. If you have to buy something that "charms" gear to provide SDN, it's middleware. If it's a "free" box that lets SDN enable a particular bundle of specific components (purchased together, of course), it's middleware.
The true test of SDN as the legitimate replacement for SNMP is simple: It must not increase the cost of the overall hardware solution, and it's got to be so baked-in that vendors can't imagine life without it. Only then will we know the hardware vendors embraced our better way.
About the author:
Patrick Hubbard is a head geek and senior technical product marketing manager at SolarWinds, with 20 years of technical expertise and IT customer perspective. His networking management experience includes work with campus, data center, high availability and disaster recovery, and storage networks, as well as with VoIP, telepresence and VDI in both Fortune 500 companies and startups in high tech, transportation, financial services and telecom industries. He can be reached at Patrick.Hubbard@solarwinds.com.
Dig Deeper on SDN management applications
Patrick Hubbard asks:
Will SDN forever change network managmeent? Why or why not?
0 ResponsesJoin the Discussion