Clik here to view.
Mike Fratto
- SDN will create varying degrees of product dependencies for enterprises.
- Enterprises need to plan for and create processes that support multi-vendor SDN.
It’s no secret that I think SDN Will Lock Enterprises in Tighter Than Ever because of the dependencies that are built up with software integration and I don’t think many enterprises have quite grasped the amount of stickiness software integration has.
Naturally, there is a continuum of SDN implementations, ranging from very basic integration with just enough touch to automate networking provisioning for VMs to fully automated, application-level provisioning that includes service chaining and follow-me functions for traffic monitoring and packet capture, and seamless integration of physical networking without the intervention of a human operator. Depending on where an enterprise is on that continuum the amount of stickiness will vary from “not much” to “a great deal”.
At the most basic end of the continuum, replacing network equipment or running a multi-vendor environment isn’t too difficult because the main level of integration is mostly at the virtualization layer with the hypervisor manager or orchestration system. But in this case there are only a few variables to contend with because solutions like VMware, Microsoft and OpenStack have already developed some form of integration with networking vendors. The only difficultly lies in understanding any gaps in their capabilities or learning some new knobs to twist. Both of those challenges fall well within enterprise IT’s wheelhouse.
But as enterprises get closer to the other end of the continuum—the fully automated data center—the deeper and more complex the integration becomes and the more difficult it becomes to replace key components. This increasing difficulty has nothing to do with proprietary protocols or technologies but it has everything to do with the dependencies that ultimately develop within the increasingly complex web of integrated systems.
But open – as in openly developed, open sourced, and openly available – will save you, right? Not so fast. While commitments from companies like Extreme and IBM to implement their SDN controllers based on OpenDayLight in a manner that doesn’t break the project’s APIs are laudable, the reality is that integrated products will very likely be dependent on particular controller versions and it is possible that improvements to the controller software by vendors may introduce subtle changes that will be difficult to find, which would disrupt existing product integration. Built-up dependencies are often a natural side-effect of implementing software, as opposed to some nefarious plan to lock-in customers via proprietary functions. When you think about it, your data center network closely resembles an interlocking puzzle and all of the pieces have to be aligned in order to dismantle and rebuild it correctly.
These are not reasons to turn away from SDN, but enterprise IT administrators and executives that expect SDN to reduce vendor dependency will need to change how they acquire and deploy IT products, rather than rely on some overblown notion of “open.” This means that planning for a multi-vendor SDN goes beyond simply updating runbooks, but also calls for establishing a clearly defined list critical product requirements necessary for future components to ensure feature parity for similar products and account for any gaps that develop along the way. Remember: Process, People, Product. In that order.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
