SHARE
Uncategorized / April 16, 2014

Putting the (Whitebox) Cart Before the (SDN) Horse?

The network today is more critical to the success of IT than ever before. As such, any disruptive change in networking has to be one that is assimilated into the production environment using a measured and carefully phased approach.

We are early in the SDN cycle and the deployment challenges associated with making SDN mainstream, including areas such as security, resiliency and scale, are still in the process of being ironed out.

One area that is still quite nascent when it comes to SDN is the area of monitoring, troubleshooting, and instrumentation. The ability for tools to monitor and manage SDN deployments is evolving, and with it, the ability to troubleshoot, manage, and respond to network issues in real time. All of this points to the fact that the success of SDN will largely depend on the quality of the implementations, the support model behind those implementations and the commitment of vendors to invest in quality, scalable and enterprise or carrier class SDN implementations.

However, we are seeing a big push towards cheaper bare metal and whitebox types of solutions leveraging merchant silicon in parallel to the interest in SDN. In isolation, these are both powerful and empowering trends; SDN for the operational simplicity it brings to the table, whitebox technology for driving down cost and opening up an eco-system of vendors.

But, this is worrisome because if history is any indicator, the adoption and maturing of a new disruptive technology or set of technologies, such as SDN, has typically preceded the commoditization of that technology. In other words, gaining a good understanding of a new technology, securing it, scaling it, and having the ability to manage and troubleshoot it, need to be resolved before the technology can be successfully commoditized.

Are we putting the whitebox cart before the SDN horse?

In my blog post on SDN Central, I explore why I think whitebox networking combined with SDN concurrently seems like taking on too much risk.

For the full blog post, visit SDN Central.


Back to top