Arista Networks had a very successful IPO last week, something that’s sure to raise the hopes of VCs and startups in the networking and SDN space. Underneath, of course, are all of the usual questions—most significantly whether the strong showing in the stock can survive months of trading and the eventual release of restricted shares. One less-than-usual question is whether Arista proves anything about the SDN opportunity because, according to many, it’s not really SDN at all. One common remark is that the company is “more like Cisco than like Nicira”.
Arista’s own decode of the SDN acronym is telling; “software-driven-networking” rather than the traditional mapping of the “D” to “defined”. It’s never easy to characterize technology that’s not fully described at the technical level, but I think it’s fair to say that what Arista is doing is indeed aimed at a somewhat-Cisco-like SDN approach. It may not be fair to say that’s a pejorative statement, but clearly it drives us to look at the subtle differences and how they might be exploited.
What makes the whole SDN space complicated is the number of things that want to be called “SDN” these days. If we look at the field from the perspective of what gets sold and installed, we have three dimensions of classification. One dimension is the software/hardware dimension; to what extent does the product utilize custom hardware versus hosted software? The other dimension is the source of forwarding rules; are they adaptively derived from traditional per-device topology and discovery exchanges or centrally set by policy? The third dimension is the role that software can play in the process; do applications and services utilize connectivity or can they actually create services? I think Arista’s position relative to Cisco and the rest of the SDN and switching world is easier to understand if you look at these three dimensions.
Classic purist OpenFlow SDN presumes that there are simple commodity switches whose forwarding is controlled centrally. Either the controller establishes routes based on some master plan, then commands the switches to actually build them step by step, or traffic presented at the switches is used to invoke a central decision on how that traffic should be handled. That decision would be made based on the same master plan. This model works fine on a modest scale, but if you want to expand it to the whole of a major IP network you’d be treading new turf. IMHO, classic SDN needs to be augmented with specific domain-and-federation approaches to separate networks into chunks small enough for central control to be credible.
“Nicira” SDN is really largely about hosted virtual switching/routing as an overlay on traditional network switching. This basic overlay model has extended (via players like Vyatta, now part of Brocade) into what’s essentially a hosted switch/router product. In this model the “network device” is a software instance of switch/router code, and so there is no specific need for network hardware at all.
Both these two models of SDN provide some mechanism for applications/software to influence forwarding and virtual network segmentation. These come in the form of APIs that can be used to partition address spaces (virtualize) and set forwarding/connection policies. The differences in what’s offered lie mostly in whether forwarding control is truly centralized, and I think it’s fair to say that most of the current “SDN” vendors are actually supporting some form of controlled adaptive behavior at least as a parallel option to full forwarding control from a central point.
Cisco as the incumbent in switching/routing is hardly interested in creating products to speed the demise of its key market sectors. Their SDN strategy has favored the augmentation of basic switching/routing behavior by improved software control—likely through formal distribution of network policies that would control networks, zones, and devices in a hierarchical way. In theory you could make this process a complete “mother-may-I” network strategy but in practice it’s more likely that you’d want to add whatever additional capabilities you needed without compromising the basic nature of switching and routing—at least as Cisco sees it. Cisco is effectively proposing a “revolutionary evolution”, a change in top-level stuff that, for a time at least, leaves the bottom of the network intact.
Cisco has a valid point here; I don’t think that the switching market is ready for revolution and I don’t think Arista believes that either, only that the market is ready for anybody-but-Cisco. Cisco’s problem isn’t that it’s not radical, only that it’s not quite radical enough. Arista is an evolution of traditional hardware-based networking, based on a software-centric architecture that starts off with the need to support cohabitation between adaptive and centrally controlled behavior. They also took considerable steps toward focusing on operationalization, something everyone realizes is important.
Did they take enough steps, though? If Cisco wants to evolve to radicalism, is Arista trying to revolt to the status quo? The answer has to come from just how much Arista actually exploits their software-centric model. If that model doesn’t add much value, then it won’t have a broad market impact. And I think where the value has to come is in that area of operationalization.
Operationalization in the broadest sense, the creation and sustaining of services on next-gen infrastructure of whatever origin, still seems to me to be the missing link and both the great risk and great opportunities for the Ciscos or Aristas of the world. Central control doesn’t scale. Ceding network control to individual applications or users is clearly anarchy and would never work. What’s needed is some mediating function that operates to balance resources against needs collectively, based on “policies” in the broadest sense. Cisco is right that policies are the key but a bit vague on what policies are or how they operate. Arista is specific on the value of operationalization but a big vague on how they’ll achieve it. Yes, you can exercise it through the APIs, but there’s more to running an army than carrying orders; somebody insightful has to issue good ones.
Arista shows something very important; two things, in fact. First it’s demonstrating that Cisco cannot rest on its legacy laurels. It may not have to join the revolutionaries but it will have to shed the wig and robes. Second, it’s demonstrating that while software is the functional keys to the network kingdom, you don’t have to foreswear hardware completely. In fact, there are advantages in providing a mixture of fast-forwarding boxes and intelligent forwarding control. But all that means is that the bar for a pure software solution is higher, and those advantages will probably have to come in the area of operationalization.
I don’t think that Arista is currently threatening Cisco. The fact is that any new technology can find low-hanging opportunities to justify it over current technology choices. To change a whole market, to threaten major incumbents, you need to do more than that. Arista needs to make their differentiation versus Cisco more compelling. If they don’t then Cisco will evolve to cut them off, or another player will jump in with a truly compelling story. Either way, Arista has some work to do to prove its stock market success is an indicator of success in the market.