What this points to is the relatively straightforward nature of implementing the OpenFlow protocol (a plus) and a desire to innovate and explore by the community (another plus). To date, aside from open-source virtual switches/routers, innovation on networking equipment has primarily been limited to networking vendors and very large Web properties such as Google and FaceBook, who are assembling their own network hardware. We believe that’s why we are seeing the community respond by innovating at the next logical layer in the technology stack–at the controller level.
At the same time, with that increasing choices within the controller market, new SDN practitioners might be confused about which ones to use or try out (potential minus). Clearly, not all controllers are alike and each one is at a different level of maturity. At SDNCentral, we expect the number of controller projects to grow before consolidation happens down the line. We also think we’ll see specialized controllers for specific applications and generic ones for more general-purpose deployments. Finally, we anticipate more orchestration frameworks forming around the controllers, such as FlowVisor and perhaps HP‘s upcoming Hercules.
While we keep hearing questions about what SDN use cases and applications make sense, as well as laments over the lack of northbound API availability and standardization for applications, we think it’s natural and normal in the evolution of any technology framework and protocol. This is not unlike the evolution of TCP/IP and sockets and streams APIs. It’s just an indication of where we are in the technology maturation process.
And so, for now, we say let a thousand* FlowERs bloom!
* Yes, we are aware the right number should be a hundred (see http://en.wikipedia.org/wiki/Hundred_Flowers_Campaign) but a thousand sounds more poetic!
Check out more Technology on SDNCentral: