Software- defined networking is at the beginning of the critical "show-me phase." Sprinkled between vendor hype articles, we're starting to see a handful of successful real-world SDN implementations. Yet even with these early use cases, one thing is clear: An open API or framework does not a revolution make.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In fact, some network engineers are not yet ready for the kind of network programmability SDN promises. What's more, while SDN has the ability to alter network management strategies and make them more productive, we've seen other such attempts fail in the past. The only way to make real change with SDN is with sustained enthusiasm and careful discipline on the part of all parties, including vendors, standards groups and practitioners.
Engineers cling to network management strategies they know
I am about to sound like I'm picking on Cisco Systems, but I'm not. I helped build the first third-party integration demo for EnergyWise, and we enabled network power management out-of-the-box in the GUI of the Network Performance Monitor. I know that open APIs result in better weekends for all of us. And Cisco has created many more open APIs than people give it credit for.
Yet, essentially, we learned from Cisco UCS that dumping good old SNMP and replacing it with an API-based management platform hasn't worked.
Indeed, one of the most exciting aspects of UCS wasn't the platform technologies like the flexibility of Fabric Interconnects; it was the promise of UCS Manager with its API-based, rich integration model that would make management easy for everyone. SNMP was officially protocollo non grata. Why would anyone bolt old and crusty onto new and shiny?
But that didn't stick. With the latest release of UCS Manager, Cisco has expanded SNMP to monitor the bulk of the platform. That's because we now see UCS in places we never expected, such as smaller IT shops that would never forklift a Vblock into their data center. Those customers rely on a diverse array of third-party management tools, all speaking the lingua franca of SNMP.
So if the bully pulpit of a dominant vendor and a great platform can't repulse legacy incursion, the outcome of programs like OpenDaylight will have to be nothing short of miraculous to drive real transformative adoption and prevent backsliding.
Network programmability threatens network admin's control
Network administrators will also find it challenging to accept the scope and autonomous change authority that SDN relies on in order to accomplish its daily work. Going way further than the knobs and levers inside UCS, technologies like OpenStack and OpenFlow will have authority and provide automation over the most critical components of enterprise services. Without tools that allow them to drill down to familiar, minute details, admins will have reservations about SDN.
But network engineers don't like config changes they can't approve. If the SDN platform makes unseen QoS policy changes to accelerate application delivery, but gives CEO telepresence the jitters, it's going to be a very bad day. Worse, it could mean the admin must troubleshoot the very platform that was supposed to simplify administration. Network administrators are engineers, not physicists, and we don't enjoy spooky action at a distance. Quantum service entanglement gives any admin the heebie jeebies.
Beyond that, Cisco's original take on SDN in 2012 was unsettling to many admins. The Cisco ONE pitch was network programmability. But what do network admins really think of programming? Programming is what happens inside app boxes that tend to break in weird ways. Network admins will have questions that demand concrete answers. For example, what happens when one vendor's SDN controller is focused on application performance management and conflicts with another vendor's controller that is trying to manage WAN costs or QoS? Who will program and QA that?
SDN has the potential to change the world or at least the part of the world where packets flow. However, to be successful, we'll have to learn one important lesson from the past: The publication of an RFP won't be enough. Enabling OpenFlow in a switch won't be enough. Creating a brilliant control application chock-full of logic harmonizing proprietary extensions won't be enough. One big vendor won't be enough. It will take impassioned adoption by real-world practitioners -- along with many of these initiatives -- to truly take a giant step forward.
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, disaster recovery and storage networks, as well as with VoIP, telepresence and VDI in Fortune 500 companies and startups in high tech, transportation, financial services and telecom industries. He can be reached at Patrick.Hubbard@solarwinds.com.
SDN applications go far beyond the data center
Northbound APIs make the software-defined network
How Microsoft is using OpenFlow for network monitoring
SDN for network management can't just be middleware!
Dig Deeper on SDN management applications
Patrick Hubbard asks:
Are you ready to trust network automation?
0 ResponsesJoin the Discussion