This syndicated post originally appeared at Zeus Kerravala's blog.
A few weeks ago, I wrote a blog post defining what “open networking” really meant and how it should be defined. On Monday morning, one of the companies I mentioned in the blog, Pica8, announced its vision and reference architecture for software defined networks (SDNs). While I believe that we’re very early in the cycle for SDNs and most enterprises will look for fully integrated, complete solutions, large, network-centric enterprises, cloud providers and service providers will lean towards open, agile platforms to create competitive differentiation.
Pica8’s solution is designed to be a network development platform for cloud providers and includes a physical switch with an integrated hypervisor virtual switch and an SDN controller using OpenFlow 1.2 as the communications protocol between all of the components of the solution. The Pica8 PicOS operating system utilizes both the Open vSwitch 1.7.1 with OpenStack and the above mentioned OpenFlow 1.2 protocol and integrates with the Ryu controller designed by NTT, specifically for cloud providers.
While the initial use cases of the open Pica8 SDN platform involve building a flexible, agile network, the long-term vision is to allow developers at the cloud providers and large enterprises to create applications that are highly customized and work with the network. This is the key to the long-term success of the Pica8 strategy, which relies on the creation and fostering of a developer community. The company seems to understand this well as every time I have spoken with them, they’ve brought up the success of the Red Hat community and seem content to follow that model. Communities are generally slow to get off the ground, but once there’s a few hundred members they wind up becoming self-fueling groups that provide ideas and support to one another.
The relative new-ness of SDNs and the design of the Pica8 platform makes this an ideal match. Pica8’s products are software running on generic hardware platforms. This means any change that needs to be made to the product is purely done in software, giving networking the flexibility and adaptability that the software world has had over the years.
Again, this kind of networking model isn’t for everyone, particularly not those with small operations teams. Those that have the resources to dedicate to an SDN implementation should get much greater leverage out of this model.
Latest posts by Zeus Kerravala (see all)
- Forget Heliocentrism-Embrace the cloud and Zeus-centrism - April 17, 2017
- Avaya’s post-bankruptcy plan should not impact customers, partners - April 14, 2017
- There’s never been a better time for Cisco Services - April 12, 2017