On the other hand, Arista has to walk before it runs. We've been growing at the rate of one new customer a day since we started shipping. We now have 1,700 customers. Deployments usually start small, then they get really fascinated and intrigued and appreciative of EOS, and all of its operational advantages, how open it is, how easy it is to use. The training is very easy and a Cisco CCIE expert would be able to use Arista right away, because we have similar command-line interfaces and operational look and feel. Where we don't have to invent, we don't. Where we had to invent for these specific use cases we do, so most often it's a use case or a project. Sometimes it's a data center build-up. After they use us in one project, they'll say they want to consolidate data centers. I would say 10% to 20% of them are now standardizing on Arista as their data center strategy.
You mentioned about 1,700 customers. Give me a sense of your business progress to date.
We're not supposed to [talk revenue] but the company is very young, it's only 5 years old. We've gone from 30 employees when we started to more than 500. I guess the biggest thing I'd leave you with is that in the beginning we were a market leader for financials and high-frequency trading which, as you know, is a tough customer. We've always had to go into mission-critical [environments] and we didn't have it easy ever. It wasn't like we were in a little lab somewhere. We believe we are today 70% to 80% market leaders in high-frequency trading. In 2008, 2009 and even part of 2010, that was 70% of our business. Today it's diversified nicely into three areas. The first is financials. The second is what I call Web 2.0, and the massive scale of their deployments, the cloud scale, really. The third is cloud and service providers. Every service provider is looking to be a cloud vendor. In all of these three cases we are being looked at as the innovative alternative to traditional legacy players.
You were at Cisco for a long time.
Yeah, 15 years. I intended to be there two years. But I was there 15 years, two years at a time.
So how did your experience at Cisco shape this?
I had a big hand in shaping Cisco's enterprise switching strategy, and it helped me appreciate what to do and what not to do. At some level I don't feel we compete with Cisco because we're not taking on the traditional enterprise market. But at other levels I feel like I learned a lot about what not to do and how to do [things] better, by being more application-focused and really taking advantage of the market disruption from enterprise to cloud, and then to big data and network virtualization. Cisco, in my view, will always be the enterprise market leader. Arista is inspired and aspires to be the cloud networking leader and really be a complement to Cisco.
Other networking companies have tried to address the needs you have described. Let's take a case in point: Juniper seemed to be targeting the same kinds of problems, so why did the company struggle with its QFabric?
Without making it specific to one vendor, I would say three or four years ago, you rightly pointed out that the market was very crowded. There was Juniper, HP looked like they were coming on strong, there was Force10 that then got acquired by Dell, and then there was Brocade that had acquired Foundry. They have taught me that focus is important. We stayed relentlessly focused on building a standards-based open architecture for data centers. I think many of these vendors, they get distracted by growth. It's a difficult call, in the public market especially. It's easy to do when you're private and you don't have to explain things to people. But do you go broad and wide or do you go a mile deep? My belief is I am participating in one of the largest total available markets in the history of networking. The 10G market is going to go from a couple of billion to $15 billion in 2016. I should not be distracting myself with other markets. I should relentlessly focus on doing my one market very well. I would say that is the failing of many competitors who don't have that kind of focus.
How has the strategy changed since launch? What have you learned in that time period?
We built a point product then and our strategy has changed to a portfolio. We have gone from a top-of-rack (48 ports) to 384 ports in a chassis. Secondly, our software has evolved, not just in millions of lines of code, but in terms of the agility and innovative features. We've been putting out releases practically every quarter since then, to the point that some of our customers say: "Hey, slow down a little! We're unable to absorb it as quickly as you put it out." One customer said to us: "We have all these data centers and we're racking up our servers, we're connecting it to a VLAN and we're enabling DHCP, this whole process is taking us two hours." With our zero-touch provisioning we were able to cut that down to 20 minutes. You think of this in one data center and how you replicate it, it's a huge multiplier. The third area I'd say we have really evolved is partnerships. We've gotten closer to the big data companies like Cloudera and the virtualization companies like VMware. Because we are best-of-breed, we are in some ways less of a threat and more of a partner to many. The security companies, like Palo Alto Networks, the application delivery companies like F5, view us as a friendly face.
What do you do with Cloudera?
We have actually installed joint networks for big data together. The biggest issue with using these kinds of direct-attached Hadoop systems is that you have to have a network with fast failover characteristics, the right buffering characteristics, and you actually almost have to have a Hadoop tracer-like function between the storage and the network. Because, remember, all of a sudden you wiped out the concept of a storage-area network, but you still need to have the resilience of a storage-area network. We're in several joint customers together, particularly in mission-critical financials.
I want to go back to EOS for a bit. There is sort of this myth of the unified operating system in networking, but competitors and customers are all running multiple versions and flavors of these OSes. What makes this software different? Why would somebody believe that you have a single unified network operating system where people have struggled with that?
We've proven it. Even though we've been here five years and we've done all the software releases, we still have one single binary image. Nobody has to get a Ph.D. on our software releases because we've kept one single unified code base. Secondly, when people play with the software, they realize that: "Oh, this can do Python scripting, I can write agents to it." So the power that we've given them to enable things that even we don't enable is like no other. Now, I could tell you some people love it. The engineering community loves it. The CIO community is afraid of it. So we also have a lock-down mode where we can have all the security and people can't go in and simply start writing.
[ Read more IDG Enterprise CEO Interview Series articles ]
At the same time, I would say we are a little bit of a Sybil with our EOS. One side of us looks just like a Red Hat or Linux, and the server guys have fun with it. They can do TCP and dump and bash. It's a Linux kernel, right? Then the other side, for a Cisco administrator, looks just like a Cisco network. When we work with VMware, we talk straight into vCenter and vSphere. So I think the flexibility that we have offered in being open, at the same time not destroying the paradigm between the virtual admin and the sys admin for the server, and the network admin has been unique.
Let's go back to SDN. What's real and what's false about SDN?
If you ask 10 people what SDN means they'll give you 10 different answers. But if I had to describe it in one or two words, I would say: open and programmable. There's been so much vendor lock-up in networking, with the huge operational cost of being locked in with one vendor. That mainframe model in networking is what SDN is challenging. Why is SDN fever and hype so high? People are sick and tired of the vendor lock-in and proprietariness and they are looking for a movement. Now, how and when will that movement happen? Like anything, you have to be pragmatic about that. When the hype is so high the market isn't that big, right? But in my view, SDN has a tremendous opportunity to succeed if we're pragmatic about the use cases. Is SDN OpenFlow? No, it's not just OpenFlow. Is it OpenStack? No, it's not just OpenStack. Is it VXLAN or network virtualization? Understanding what you can actually do with SDN is the key here.
Let's talk about that programmability aspect. When I talk to people in the market, there are some who are really excited about that piece, but others who think there are only a limited number of things you would ever want to program the network to do. What do you envision people programming the network to do?
I think they're both right for different reasons. In a traditional network, no one is looking to toss their IP out any time soon, so whatever you do you've got to make sure your IP network is up and running. But say you're going to do a green field [installation]. This is how the OpenFlow SDN movement got started at Stanford. [Professor] Nick McKeown was doing this project called Clean Slate, where he was telling his students: "Imagine a world with no IP. How would we define it?" That's all great for vision and strategy, but we've got hundred of thousands of customers operating networks, so you have to understand that no matter how inflexible and how much of a headache your current architecture may be, TCP/IP does work. Then you look at the model that SDN is coming up with, which I call the controller, overlay controller model. That's a controller for OpenStack, OpenFlow, network virtualization, each of them is a use case -- it's a specific case where you need programmability. I agree that you shouldn't go and mess with the big IP network. If it's not broken, don't fix it.
Understand what are the use cases you're trying to augment with programmability. I can think of three or four use cases. One of the ones that we found, especially with OpenFlow, but also in IP networking, is data tap aggregation. When you're running at the 10G speeds we are, everybody is looking for traffic visibility and understanding what's going on in the network. You can build an out-of-band controller with OpenFlow, whether it's Big Switch Networks or open source controllers from Floodlight or NEC, and have an OpenFlow agent on our switches, and have a very simple SDN network that's highly programmable, and still works in hybrid mode with your IP network. That could be one case. There's the Nicera case, which is also, in my view, a programmable use case, but it's for strictly network virtualization. You keep the IP running, but you need a network virtualization platform that can program your virtual switches, whether they're VMware switches or open virtual switches from an OpenStack environment. Today, this is literally like two islands; there's the physical switch and the virtual switch. With Arista working closely with VMware and Nicera, we can transcend the virtual-to-physical islands, where every VXLAN vSwitch port automatically maps to a hardware port. Now you've got network virtualization not as two separate failure domains, but transcending virtual-to-physical, potentially even to a cloud, architecture down the road. This is in a VMware environment, but there's no reason you couldn't do it in an OpenStack environment with quantum plug-ins as well. So that's another use case.
Do you believe SDN fundamentally changes the competitive landscape?
Yes, but I believe the controller vendors in isolation won't succeed. The networking vendors, if they get defensive with just IP won't succeed. You have to have the Arista view, which is have two personalities. Work in a controller mode, but work also with your IP network. That's the mistake I think SDN is making, in that they're thinking of it as only green field. In reality there's a whole world of IP there that you need to work with while you're trying to develop the use cases.
Server virtualization was essentially owned by VMware and the software vendors, not the server vendors. Who ends up owning SDN?
[The server vendors] got defensive. If the networking vendors do not embrace it because it requires a new software paradigm that they haven't built, then they stand to lose, because over time there will be more and more use cases that disrupt them. Customers like that. I was talking to a customer today who said: "The most liberating feeling for me now is I can be multi-vendor, and it hasn't cost me that much money. I don't know if there are that many SDN use cases, but I love it." Arista feels very fortunate that we got an eight-year head start. We spent four years building the software, four years commercializing it, and now we're sitting in the middle of an SDN momentum and a switch momentum that puts us on the natural cusp, if you will, where we can be working with the old and still developing the new.
Does Arista have its own controller?
No.
Is that something you're going to have?
Our control plane and data plane will be open, and we will work with all the controller vendors that you deploy. HP Opsware, vSphere VMware, Nicera, Big Switch, Floodlight, NEC, IBM Tivoli, EMC Smarts. These are all to us controllers. We don't view ourselves as the management expert. Now, if you want to go develop specific use cases for a controller on our switch, we can do that too. And people do that. Like for example, we worked with Splunk very closely to develop a configuration management tool with them.
If you're a CIO or a senior IT executive, and you are on the sidelines looking at SDN and wondering what it's all about, what's the 30-second answer on why they should care about it and start thinking about it now?
Because it unshackles their traditional networking decisions from their application and helps them develop new use cases that they couldn't do before, or only had to do with traditional vendors. The key for them is to understand what problem they are trying to solve. Solve that out-of-band and work with the existing [network].