Many SDN start-ups came out of stealth mode in 2012 and a few others are gearing up towards launch in 2013. As the momentum around SDN increased, so did the number of start-ups in this space. Keeping track of their development stage, their offerings, and more importantly the problem(s) they aim to address is a difficult task. This blog is an attempt at providing a snapshot on SDN start-ups worth watching in 2013.
Increasing SDN Innovation. I had the pleasure to interview 11 start-ups (see below) in Q4 2012. All were very supportive of this blog as they recognized the need for more education on SDN to help customers understand relative positioning..
Figure 1 – SDN Start-Ups Worth Watching in 2013
SDN is a broad and powerful concept but it can be implemented in many different ways. Each of these start-ups turns SDN into a reality but each innovates in a unique manner, supports different IT environments and solves a variety of customer issues. Each player addresses an important piece of the puzzle and can win a defined segment of the market.
Today SDN is still an emerging market and we cannot really talk about competition between these companies. For now, customers should focus on which one is solving their problem and work in their environment while investors should look at solidifying their portfolio across multiple complementary solutions.
Growing VC investment in SDN. Thirteen Venture Capital (VC) firms are behind these eleven start-ups. LightSpeed Venture Partners has the highest number of investments in this space with Embrane, Plexxi and Pertino and shows a great diversification strategy (their offerings – described later – are quite different). Koshla Ventures (Big Switch and Contrail), New Enterprise Associates (Embrane, Pluribus) and Northbridge Venture Partners (Embrane, Plexxi) have two investments each while the other VCs have invested in only one of the start-ups I interviewed.
Figure 2 – Amount of VC funding
On the figure above, comprehensive seed funding information is missing but can in general be assumed to be less than $2M. Lyatiss series A is not public information. Vello is owned by the management team and its employees and has no VC funding.
Start-ups with pure software offering have received series A and/or series B funding ranging between $10M (Contrail) to $39M (Big Switch). I expect Plumgrid, Pertino and Lyatiss to run for a Series B shortly. Contrail was acquired by Juniper in December 2012.
Higher investments and series C have been made for companies also delivering hardware in their portfolio such as Plexxi (with a total of $48.5M) and Pluribus (with $42M). Pica8 is the exception to this rule, thanks to bootstrapping and early generation of revenue from traditional networking products.
Figure 3 – Timeline of VC funding
Young, moving fast and evolving the SDN architecture. Most of these companies were created between 2010 and 2011 and six have already launched. Contrail, Lyatiss, Pertino, Plumgrid and Pluribus are still in stealth mode at the time of writing, though that should not last much longer…
Individual offerings will be described later but let’s start with the most common trends:
- Application Plane – In my previous blog, Network Virtualization was one of the possible applications developed on top of the northbound API offered by the controller. Many start-ups have also developed applications on top of network virtualization to create another application layer within this plane.
- Northbound API – As a result there are now two types of Northbound API: one at the controller level usually used for network services (like firewall, load balancer etc.) exposing more granular information, and one at the network virtualization level for more abstracted applications like cloud orchestration.
- Control Plane – Most of these vendors offer centralized access to the network control information but often with distributed logic behind it in the form of software or VM hosted across multiple servers or switches or appliances or mix of the above.
- Southbound API – To reduce complexity and dependency, several solutions often include some part of the forwarding plane (usually via software agents deployed directly on edge devices and/or network switches) removing the need to open up their southbound API to other vendors with OpenFlow. In all cases, OpenFlow is still a roadmap item tough.
- Forwarding Plane – Here the distinction between virtual and physical switches goes a step further than in my previous blog with, for instance, a virtual switch with an origin that could be different from the server OS or hypervisor vendor.
To illustrate these points and simplify comparisons, I will use the following SDN architecture as a reference to describe each vendor solution.
Figure 4 – Reference Architecture
SDN for the Physical Infrastructure
While many vendors plan to support OpenFlow on their switches, few switches are available today and most of them only support OpenFlow v1.0 (instead of v1.3, the latest standard version issued by the ONF).
Several start-ups have decided to build their own physical switches as show on Figure 5 (e.g. Pica8, Pluribus, Plexxi, Vello) to control and accelerate innovation on hardware components. Often they decouple the software hosted on these switches from the hardware itself to facilitate programmability. The separation between control and forwarding planes become blurred. In these configurations, the controller is no longer limited to just collecting control information and instead also handles the networking operating system of these switches managing firmware upgrades, for instance, or having services delivered on the switch itself (versus at the application layer). In other words, the switches themselves become programmable not just the network.
Figure 5 – Support of pSwitch and vSwitch
SDN for the Virtual infrastructure
Some start-ups have decided to focus on virtual switches only. Many are supporting Open vSwitch (OVS) or even packaging it with their offering, some added their own code to Linux bridge (less sophisticated than OVS) or interface with open APIs from VMware (for vSphere switches – former ESX) or Microsoft (for Hyper-V virtual switch).
OpenFlow proving to be a nice to have but not a must
As mentioned earlier, to remove dependencies or innovate faster than the current standard, many SDN start-ups do not support OpenFlow today unless they leverage OVS or other open source offerings. Since OpenFlow is the most frequent migration path of currently deployed physical switches (from Juniper, Brocade, eventually Cisco etc.), these solutions are targeted at customers expanding or replacing their physical network, or deploying SDN on their virtual infrastructure only. In the long run, all these companies plan to support OpenFlow to enable support for multi-vendor environments. Customers should then be able to deploy SDN by simply upgrading their existing infrastructure.
Figure 6 – OpenFlow Support
Open API but… open to whom?
While the majority of start-ups offer an open Northbound API, the proactive development of an ecosystem around it is usually still limited. At the moment, most companies focus on developing their own in-house applications and adding partners as dictated by customers’ production environments. As their solutions become more mature so will their packaging and go-to-market and more partnership announcements should be expected.
SDN and Cloud orchestration
Several of these start-ups integrate with cloud orchestration software such as OpenStack, CloudStack or vSphere. The level of integration and dependency varies a lot. Some offer a plug-in so any changes made by the user at the cloud orchestration level will be reflected on the underlying network while others use these orchestration applications as their own management interface.
Individual SDN Start-up Snapshots
This section is intended to show the variety and creativity generated around SDN by each start-up. A simple reference model (shown in Figure 4), a brief solution description and a highlight of their differentiators should help you get an initial overview. I have collaborated with each and every one of these companies to ensure that each snapshot reflects public and accurate information.
To limit the length of this blog, we will roll out 3 or 4 start-up snapshots a week in reverse alphabetical order. If you would like to see a start-up added into future blogs, please send your suggestions to email@example.com.
How to read the reference diagram
- Colored components are the components offered by the vendor.
- Grey components are components offered by partners via the vendor’s open API.
- Absence of components compared to the reference diagram means that they are not part of this vendor’s solution or do not require an interface (i.e. API).
- OpenFlow support is indicated by the OpenFlow logo on the southbound interface between the controller and the associated networking device.