Software Defined Networks: part 2

On my last blog, I introduced the topic of Software Defined Networks (SDNs).  The promise of SDNs are a much more elastic and responsive network infrastructure based on the following:
1)      The separation of the control plane from the data plane
2)      The opening up of the network equipment with a set of APIs that create a platform that can be built upon

I believe SDNs will closely follow the path that Ethernet took from a technology perspective.  Ethernet started in the data center with LANs, then moved into metro networks, and finally into a true viable WAN technology. SDN deployments have started and will continue to be deployed in mass in the data centres, and their promised value will be delivered in these environments especially towards single tenant use. According to analyst firm IDC, the worldwide SDN market for the enterprise and cloud service provider segments is forecast to grow from $360 million in 2013 to a robust $3.7 billion by 2016[1] – you can see, SDN is here to stay.

However, an area worth debating is how deep SDNs can or will go in a service provider’s network.  Once you introduce multi tenancy, the technical complexity of which features to support to ensure you can meet most customer needs will be a challenge.  Then once you get that done, how do you properly build and test something that is designed to be very dynamic on a large scale like a service provider’s network?  When you restrict the problem to single tenancy, and a well understood feature set, SDNs will help revolutionise how networks adapt.  For a service provider, I think the problem is more difficult.  In my next blog, I’ll explore my view on how SDNs will impact a service provider network and how I see this evolving.