- SDN will increase lock-in rather than decrease it because of integration and interdependencies.
- Standards and reference architectures will not help, as support for extensions creates dependencies to begin with.
One of the wishes, hopes, and dreams of SDN is that the technologies will free enterprises from vendor lock-in. That’s not the case. SDN will increase vendor lock-in for most enterprises, because the dependencies that will accrue will be difficult, if not impossible, to shake.
There are many reasons why enterprises stick with their existing network vendor. Sometimes it’s due to long-term contract commitments. Sometimes it’s due to the operational costs required to migrate from one product to another. Sometimes it’s due to existing operational and technical requirements that are in place. Regardless of the reason, the common perception remains that switching from one networking product to another is fraught with risk and complication. Migration doesn’t have to be that difficult, because with today’s networking, nearly all of the technical and operational hurdles can be easily overcome and networking vendors are more than happy to help you make that transition. The costs and disruption can be managed.
SDN changes that dynamic in significant ways; the integration required between multiple networking products to bring an SDN to life and the nature of market dynamics that limit partnerships to a subset of all vendors will create technical dependencies that will be highly disruptive to change later. Vendors will embrace standards and reference architectures to remain relevant. They will extend those standards and reference architectures to add value for their particular product line, and finally, they will extinguish commoditization and freedom from lock-in. No, I don’t think vendors are evil or even doing this on purpose; it’s simply a natural evolution that will occur organically.
Consider this: An SDN requires integration that touches every single facet of the data center, including: network protocols supporting virtual and physical networking; integration with hypervisors and cloud platforms to dynamically respond to service changes; integration with other network Layer 4-7 products such as firewalls and application delivery controllers for service insertion; integration with one or more controllers to manage the SDN; and support for systems management to monitor, report, and troubleshoot the SDN. The dependencies that are built up are interwoven so deeply that removing one component has a cascading impact on everything else.
Standards and reference architectures are being developed to support integration at all levels of the SDN stack, which is fine, but those same standards and architectures include extensions for customization so that product vendors can integrate their particular product features into the SDN. Similarly, the collective hand waving over open APIs really means vendors are providing web services-style integration and making the APIs public, but since there are no standards on the horizon (and even if there were standards coming, there would be options for custom extensions), all integration will be specific between products.
Lock-in isn’t inherently bad, but it is a fact of enterprise IT, and no amount of standards and reference architectures will make lock-in go away. Recognize it’s there and choose accordingly.