Thank you to everyone who joined us for the DemoFriday on June 6, when Pluribus Networks demonstrated what it calls the industry’s first and only bare-metal, distributed network hypervisor OS. The Pluribus Netvisor demo highlighted the company’s distinct approach to SDN: Rather than using a hardware-based, fixed-feature-set model, the OS controls the network switch.
Pluribus CMO Dave Ginsburg and Software Architect Prashanth Prahalad showed how Netvisor extends network intelligence from top of rack into the rack and creates a richly programmable application fabric. The Q&A with participants after the presentation follows below. Watch the full presentation, or check out the teaser video and other resources.
You mentioned Tibco as a customer. How do they use your platform and why did they go with Pluribus?
Tibco is an example of one of the prime use cases for Pluribus — converged Layer 4-7 services and applications. With both the Tibco EMS (Enterprise Message Service) and FTL (Faster Than Light) platforms based on Pluribus, performance is key, and having both server and switch hardware integrated in the same appliance helps ensure the best possible end-to-end performance. Availability and disaster recovery are also concerns, and thus the Pluribus fabric-cluster and architectural designs, with two 2RU appliances at the primary site and at the DR site, help ensure that mission-critical messaging systems are always up and available.
When we started looking at merchant silicon SDKs, we found some opportunities for optimization, some of which made a pretty big difference. Developing our own SDKs allowed us to extract the best possible performance from the chipsets.
Most of the industry is talking about separating control plane, doing things like having an SDN controller on a different box, but you guys are doing the opposite, putting the control plane on the switch. Why?
Performance. We found that for some operations, the latency when using an external controller impacted performance, while an architecture where tables can be memory-mapped to the server can provide greatly enhanced performance. A decentralized controller architecture leveraging the Pluribus fabric-cluster capability provides the best of both worlds — high performance and cluster failover, offering greater reliability.
Arista talks a lot about programmability, and on the hardware front they even build FPGAs into some of their boxes. How would you compare and contrast their approach to what you are doing at Pluribus?
While both of us recognize the importance of programmability, one of the key differences is the Pluribus Netvisor. Arista and others are, at their root, conventional top-of-rack switches with limited control planes and control processors optimized to just run the switch silicon. We’ve taken an entirely different approach by fusing a high-performance CPU to the switch silicon, permitting the customer to deploy standard Linux applications. We provide standard programming tools as well as the ability to deploy “daughter” hypervisors such as KVM on top of the Netvisor but at bare-metal performance.
Approaches like the VMware approach result in two disjointed networks: your physical network and an overlay network. Adding this overlay to manage seems unlikely to decrease complexity or increase manageability. Also consider what happens should you have a problem with performance or connectivity and how a lack of single-pane visibility into overall network performance and health will impact things like troubleshooting and forensics. The Pluribus approach, in contrast, does not rely on overlays and is thus simpler to manage. Since the network hypervisor, our Netvisor, is wedded to the physical infrastructure, it provides unmatched visibility into everything happening on the network, allowing for sophisticated analytics and forensics out-of-box.
Intel has talked about “rack-scale” convergence. What sort of impact will that sort of evolution have on Pluribus?
We already have a very successful partnership with Supermicro where Pluribus Netvisor runs on the switches embedded in their Microblade server. As consolidation continues, we expect that the requirements for network hypervisors such as Netvisor will only increase.