Network Innovation competition: Plexxi Inc.

Plexxi Inc. is this month's recipient of SearchNetworking's Network Innovation Award for creating its innovative networking framework.

Network Innovation Award logo CM

To Plexxi Inc., the modern data center or enterprise network should be one of conversations and experiences, an application-first methodology that goes well beyond the conventional boundaries of networks being all about connectivity and reachability. Some conversations are long; others are short. Some require a lot of bandwidth; others do not. If the application can understand these dynamic conversations, or as Plexxi has coined them, affinities, then the network can be reconfigured, through Plexxi's optical switches and SDN controller, to optimally support both the applications and the devices that reside on that network.

That, in a nutshell, is the novel approach Plexxi Inc. of Cambridge, Mass. -- the winner in searchNetworking's Network Innovation competition -- is taking.

To get a better understanding of Plexxi's strategy, SearchNetworking site editor Chuck Moozakis spoke to Mike Bushong, Plexxi's vice president of technical marketing.

It's been about almost eight months since you first began shipping your products. Where do things stand today?

Mike Bushong: We have a handful of customers using our products in production and if you look at the next two to three months, we will be aggressively ramping up our presence in the industry. We're targeting two major verticals: cloud hosting companies and large enterprises, with a particular emphasis on financials. For the next year, in terms of our product availability, we will continue to add features and functionality into our first generation of products, primarily a software effort. We will then take a look at expanding our product portfolio with aggressive new products designed to scale.

Explain Plexxi's approach. What products do you provide and how are they designed to work?

Bushong: Our solution is made up of a switch and a software-defined networking controller. Typically we are deployed as a combination top-of-rack switch (ToR)/core switch. So in our customer deployments today, they are testing us out in that hybrid ToR/core switch area. From a technology perspective, there are two major technology trends that we are putting together. The first is SDN; the second is photonic switching, which is the idea of bringing in silicon photonics and optical networking into the data center. Our products take those two concepts and put them together.

What role does the controller play?

Bushong: We use the controller to have a global view of what's happening in the network, and that includes the traffic on the network and the overall capacity of the network. We use that controller to make capacity allocations to make intelligent pathing decisions across the network. Then the optical piece gives us the ability to move network capacity around as and where it's required.

Talk a little bit about affinities. What exactly are they and what do they do?

Bushong: Affinities are effectively a common description language used to describe conversations in and around the network. Who is talking to whom and what is important about that conversation. It's users talking to the application, servers talking to databases, it's applications talking to servers. Those conversations are described in what we call affinities. Once you have those affinities, then the controller is there to speak affinity. The controller takes that input of what is important in the network and translates that input into network-wide behavior, whether that's path optimization or topology -- a single point of management and [policy] enforcements that are based on these inputs.

Does this imply an application-aware approach?

If you view networks as being about connectivity and reachability, we view them as conversations and experience. You can't do that if the application is subordinated to the network. It's the application first and everything follows from that.
Mike Bushongvice president of technical marketing, Plexxi Inc.

Bushong: It's not so much application awareness. That examines traffic and then says, "I know how applications are trying to use traffic." Affinities are more about expectations and intent, and there is a subtle difference. If you are doing everything by test or by probe, it's like driving while looking at the rear-view mirror. When you are expressing intent and making proactive [network] optimization, that is like driving looking out the front window. So affinities are saying, upfront, proactively, what's important about this particular conversation and giving that information to the network. The second element of this is that you don't manage every application or every traffic flow on the network. You don't express every single one explicitly. What you do is manage by exception. You take the things that are the most critical, and you specify those and make them special while everything else is treated with normal networking technology. So you have affinities, then you have the controller that speaks affinity and translates those requirements to network behavior.

How does Plexxi view integration and the role your technology might play within a data center or enterprise?

Bushong: We recognize that capability in isolation is useless. The network by itself is a resource that exists in a wider context, so we look really hard at integration. It could be with things like OpenStack or provisioning systems like Puppet or Chef, but it could also be integrating with your helpdesk ticketing system; integrating with change management, login, auditing. We sort of view it as a set of things you have to be integrated with. Our hope is not to be integrated whole, which is having application program interfaces (APIs). We also want to be integrated -- taking that one step further.

Can you explain that a bit further?

Bushong: There will always be supporting systems not necessarily spun into the network directly for the purposes of moving traffic. A simple example: If something breaks, a large enterprise will enter a helpdesk ticket. If you could export data from the network when something breaks, you could more easily set up things like helpdesk ticketing. If something breaks you could put all the debug info into the ticket. Our hope is to take integration one step further. Integration for many is APIs and you call it integrated. It's more than having APIs. You have to do something with that information.

Although you say your approach isn't necessarily application-aware, the Plexxi blog does talk about how the "application is king." What's the difference?

Bushong: If you really want to change things, it comes from questioning not the solution but the purpose. For two decades the purpose of networking is connectivity. We look at it and say the purpose of the network ultimately is conversation. So, if the conversation is the most important, we should be designing networks in mind. Ultimately, we want to be application-driven but conversation-defined, the idea being that the application is the highest order and that the parameters, the requirements of those conversations are really what drives how the network performs.

The simplest example I can come up with is that we've all been on a conference call and someone is under water. You hear every third word; it's awful. You know the network is up, but are you getting the experience you want? The answer is no. So it's not about connectivity. It's about the experience. When you talk about connectivity versus experience or reachability versus experience, the whole language needs to change in terms of the focus on the application.

The basic premise is this: If you view networks as being about connectivity and reachability, we view them as conversations and the experience, and you can't do that if the application is subordinated to the network. It's app-first and everything follows from that, and that is really the big change.

Software-defined networking is confusing enough. Is one of your jobs to explain the rationale behind the technology?

Bushong: SDN is not a thing. At best, it's a collection of technologies. The discussion of SDN as a thing, as something you can pick up, hold and deploy has confused things. Customers are left to figure it out. The industry dialogue has been unnecessarily confusing. What we ought to be talking about is that it's great we have SDN, but what does it do? Do you build faster networks, bigger ones, less complex ones? How does that relate to the problem that customers are actually trying to solve; that is the biggest challenge.

Think of what the CIO cares about. You aren't being accountable to whether your network has SDN. The question is whether your network is delivering the experience you need. That SDN makes it more possible to do that, that's great. But let's talk about what SDN makes better.

And how does Plexxi make it better?

Bushong: We ultimately believe that the collaboration of the application and the network makes both the application and the network better.

There has been a lot of discussion about bare-metal switches and open-source software. How do you view this development in light of your proprietary and optical switch?

Bushong: If you look at the idea of that I want to build the same network today, but cheaper, those aren't our target customers. We are looking at building a fundamentally different network that is sensitive to application inputs and capable of optimizing underlying networks, based on real-time events on the networks. If what you need is a high-scale, low-latency ultra-responsive network that is fundamentally not the same network you have always been building, then come to Plexxi. If you are worried about reducing your Capex envelope, by all means call [another vendor].

Does SDN have to mature further before Plexxi's approach can gain additional traction?

Bushong: We happen to use SDN as part of our solution, but we aren't dependent on anything not happening for us to be useful in production environments today. What would be nice, when you look at ideas of affinities, this way of describing workload or application requirements, the more broad-based that is, the more applicable to different types of architectures, different controllers, then that data model becomes more ubiquitously adopted, and as that becomes adopted we can do more in our underlying network.

Any final comments?

Bushong: If there is one thing, the basic premise. If you view networks as being about connectivity and reachability; we view them as conversations and experience. You can't do that if the application is subordinated to the network. It's the application first and everything follows from that. The technology pieces are interesting, but technology itself serving the common purpose or the existing purpose, all we would have is the same damn thing with cooler acronyms, and that isn't the point. The point is not to have the same damn thing with a different set of acronyms.

This was last published in July 2013

Dig Deeper on Network Design



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.