SDN’s proponents claim its benefits are legion. Broad flexibility, rapid configuration, improved efficiency and massive scalability are only the tip of the iceberg. Freed from the tyranny of the conjoined control/data plane, the enterprise will supposedly be able to exist completely in software, with only the slightest nod to the attributes of the newly commoditized physical layer.
To get there, of course, SDN will have to embrace a high degree of openness so that the virtual architecture can work its magic across a wide range of switches, routers and like devices. But is this really going to happen? More to the point, is it even in the best interests of the enterprise?
Many of the newest SDN start-ups consider open SDN not only inevitable, but essential to their business plans. Companies like Pica8 tout the era of white-box switches that will do for networking infrastructure what commodity servers have done for processing centers: lower the cost of hardware while supporting an ever-increasing array of agile and expandable computing capabilities. As evidence, these companies point to the hyperscale data center industry, where white-box server makers like Quanta and Accton are already turning their attention to switches and routers for Google, Facebook and other leading customers.
Of course, the rules may differ for organizations that don’t produce economies of scale with their own capital budgets. For the mere mortal enterprise, it appears that there will be varying degrees of openness, depending on who’s defining the term.
Both Cisco and Juniper, for example, have made no secret of their support for projects like OpenDaylight, which aims for nothing less than a fully open source controller. But when it comes to actual implementation, both vendors demonstrate a preference for more integrated approaches, like Cisco’s new Application Centric Infrastructure (ACI) and Juniper’s MetaFabric. With a tighter bond between hardware and software, they argue, SDN becomes easier to implement and more manageable in the long run, because configuration settings and other parameters can be tailored to specific hardware.
In fact, if things continue as they are now, you can expect SDN to increase enterprise dependency on single-vendor solutions, according to Mike Fratto of Current Analysis. That’s because even with open standards and reference architectures, most vendors will include customized extensions to give their products an edge. And since SDN reaches into all levels of data infrastructure, from bare metal platforms to hypervisors to cloud platforms, simply removing one “open” component and replacing it with another is likely to produce a ripple affect up and down the stack.
This is probably part of the reason enterprise executives remain leery about SDN. According to Packet Design, more than half of survey respondents named system complexity as a top challenge to deploying SDN. More than quarter expressed vendor lock-in concerns despite the best efforts of groups like the Open Network Foundation (ONF) and the Open Network Alliance (ONA) to foster greater interoperability between networking platforms.
To some, no doubt, networking is simply too important to trust to the vagaries of a fully open environment. Remember that neither open source nor open standards produce a fully integrated, trouble-free environment, particularly once you start to tweak the system to improve performance for particular workloads or data patterns.
In these cases, it helps to have a top-flight networking partner who knows the platform in and out and top to bottom and can make changes with at least a better-than-average understanding of how a tweak here will affect system relationships elsewhere.
So for those who thought that SDN would unleash a wave of democracy in network architectures, ending the reign of top vendor solutions, sorry to burst your bubble. SDN implementation will be difficult enough with a single vendor, let alone a throng of providers all trying to get their systems to work in a coordinated fashion.
Photo courtesy of Shutterstock.
