Overshadowed by the widespread SDN-washing that is taking place with every product suddenly labeled as software-defined, there is at least one huge change sweeping the industry as a result of software defined everything that nobody's talking about yet. It turns out that if you take two disparate systems that both have a (logically centralized) controller and well-designed, abstract APIs (i.e. hiding much of the implementation complexity) the return on investment for integration work is dramatically better than with traditional distributed systems. With this approach, it is much easier to make disparate systems work together, which in turn completely changes integration investment, service introduction velocity, and the implications of vendor lock-in.

I have personally experienced the power of this approach related to some collaboration between a Software Defined Networking solution and a software defined storage solution  to build combined capabilities of the 1+1=3 variety. The two parties were able to quickly and easily develop software to allow the SDN-based data center Ethernet fabric controller  to coordinate with the Software Defined Storage controller to automatically adapt the network forwarding behavior to the dynamic needs of the user-provisioned, multi-tenant storage sessions. In this case, the amount of work required to develop and test this code was orders of magnitude less than would be the case with traditional systems. The developer who created the software didn't need to know anything about controlling the many switches and storage nodes in the network. The respective intelligent controllers hid all of this detail so that the developer simply used the two vendor's high level APIs to learn about the various storage sessions including SLAs, and to then teach the network controller about them. Having one company develop software to mess with the many devices from the other, the traditional approach in our industry, would typically have required several developer-years investment. The python script used to connect these two controller APIs took about a day. The result was an end-to-end storage/network co-orchestration feat that had never been achieved before.

Hiding the details of interaction with complex systems has direct benefits with respect to the dreaded vendor-lock concern as well. The degree to which one is vendor-locked is directly linked to the amount of per-vendor integration needed to deploy a solution. If integration with high-level APIs for a vendor’s controller changes the investment from months to days, the barriers to switching are correspondingly lower, thus providing maximum purchasing leverage for the buyer.

One of the reasons SDN increases innovation velocity is because it allows changes to be made in places where it is easier to do so.  Using traditional switches and routers, the development of interesting system-to-system integration often means changes to the embedded software running on the many devices. This is where most of the intelligence sits in traditional network equipment, so this is what most likely needs to change for new functionality. This process has a typical development-to-release cycle of 6 months to a year. If you have to ask a big network equipment vendor to change their embedded code to support your goals, the time to innovate will be somewhere between "sorry we don't do custom" and 2+ years, due to competing priorities. This was the only option available with the previous systems integration model.

A well-designed SDN solution will enable much greater innovation velocity.

The easy way to dramatically change the behavior of devices in an SDN is to use an application level API to tell the controller what you want, and let the service running on the controller mess with the devices. If the service abstractions exposed by APIs are well designed, most customization of the system behavior can be done via this method.   Such projects can have a development to deploy cycle measured in hours or days. You don’t have any dependency on a vendor to allow this innovation. Just get the API documentation and hit it.

In cases where it is not possible to achieve required functionality with the application level abstract APIs, it is often possible to still avoid the embedded firmware development timeline by making changes to the service code running on the SDN controller. The controller code can be expected to be deployed on industry standard server hardware with corresponding high-level OS, development and debug tools. The software development lifecycle costs related to controller code changes are much less than for embedded firmware. Full regression testing on embedded code for a standard layer 2/3 bag-o-protocols can take several weeks and massive test resources. Changing the SDx controller code provides an alternative innovation path for many complex innovations that won’t need firmware changes in a well-designed solution. Because the service APIs prevent direct access to the embedded devices, there is no need to retest embedded code when code changes on the northbound side of the controller.

These are examples of the powerful benefits from the promising new design pattern that is emerging. Now that we are starting to hide system complexity behind server based controllers, and to create new multi-system capabilities by connecting the controllers, it creates a whole new world. For companies seeking to collaborate, this heralds a sort of Partner 2.0 era, where it is faster and easier to connect disparate systems in ways that are meaningful and in some cases totally cool. In a totally self interested plug, I will suggest that you all be good to your partner/alliance team at work, because what they can increasingly achieve with other systems will spur innovation and make the pie bigger for everyone. It will be faster and easier to deliver innovation,  which will in turn deliver value to paying customers. Keep an eye on the new generation of solutions that expose features through APIs to an intelligent controller. You will see exciting innovation happen quickly as a result of this smart approach to building complex IT solutions.