If you’re like most IT professionals, you’ve noticed that your roster of third-party providers continues to grow.
- PilotHouse Vendor Rating
- Contact Center and Customer Engagement
- Cloud and Data Center
- Cost Models and Total Cost of Ownership
- Enterprise Trusted Advisor
- IT Innovation, Transformation, and Enterprise Technology
- Mobile and Network Services
- Security, Risk Management, and Compliance Research Initiatives
- Unified Communications and Collaboration
Enterprise Connect 2015 proved a popular venue for contact center and customer engagement announcements.
At the 25th anniversary Enterprise Connect this week in Orlando Microsoft took a bit of a gamble, walking away from the “Lync” name for its unified communications platform that it had adopted just
L'Etoile du Nord: Waiting for the Killer (SDN) App
There's some vigorous discussion and debate going on right now about the "northbound" interface in the SDN space, the one that sits between the network application and the network controller. And there should be! The main point of debate: should there actually BE a northbound API - a single, defined set of functions built around a single agreed upon data model - or should the application interface be left entirely up to the vendors and development communities working on SDN controllers?
The stakes are relatively high, because the application interface is where the rubber hits the road, in a way. Enterprise IT folks aren’t going to want to get into the SDN business just to have an SDN - they’re going to want to have an application they can use that the SDN provides. Those applications are coming up, from the likes of Big Switch and HP among many others, but they typically assume that the application is running atop the vendor’s chosen controller.
But, one of the underlying premises of SDN is that it will push network function interoperability further - that one vendor’s stuff will more easily be controlled by another vendor’s stuff. At the southbound end of the controller, this is playing out according to plan with the proliferation of OpenFlow controllers and OF-ready gear for pushing packets. At the northbound end, though, teams can and do go their own ways, with not broad interoperability in sight.
So, if someone that is not in the controller business has a neato-keen network application - let’s say, an application delivery optimization app that combines routing, load balancing, encryption offload, and traffic shaping – they have to either choose a controller to run on, limiting the number of SDN networks they can run in, or they have to port the app to each controller they want to support. And track changes to all those controllers over time, to maintain the compatibility. And do regression testing of changes against all those controllers, et-multiply-cetera.
As is probably clear, we are big fans of a standard, or set of standards, for the northbound API and an SDN controller data model to go with it, similar to the API and model embodied in OpenFlow. We don't expect one to appear very quickly. Something that might help push the process along would be a “killer app” for SDN, something that
- embodies a highly desirable set of network functions
- is available from a vendor without skin in the controller game
- requires a broad set of capabilities from the controller
The killer app – let’s call it The North Star (TNS) - would present a pull for controller vendors: if TNS was hot and much wanted, they would want to make sure their API was up to the task of supporting TNS. In so doing, they would move a long step toward being ready to support a standard when it emerged. Likewise, if lots of folks wanted to deploy TNS in their networks, then standards teams should be looking at it as a model for or source of requirements for the API and model they want to produce. Moving implementations and draft standards closer together should speed the process of standards making.
I haven’t seen TNS yet, but am keeping an eye out for it. I’m also watching for a “northern shim” to evolve, a very thin network application whose job is to offer an API and accompanying data model for other applications. The provider takes on the burden of porting it to run on top of various controllers, and the application vendors have something portable to develop against. (or maybe the shim is TNS…)
Without a standard (or a shim) SDN is not going to unleash the flood of interoperability and creativity that it could -- but that is a flood I, and many others, eagerly await.