Arista Networks dares you to break your network. Go ahead, play with the code, screw it up, then start again. After all, that's what it takes to build a network that can support dynamic provisioning in the cloud. More importantly, that's what open source networking software will let you do.
When Arista emerged in 2004, its chiefs, former Sun Microsystems founder Andy Bechtolsheim and Stanford professor David Cheriton, drew plenty of media buzz. The two had sold their company Granite Systems to Cisco and then had been executives at the networking giant. Out of the gate at Arista, they proceeded to poach Cisco heavy hitters, including former switching head Jayshree Ullal, who became Arista’s CEO.
Beyond the buzz, though, Arista has built a solid reputation on its Linux-based Extensible Operating System (EOS) that runs across all of its products (similar to Juniper's Junos). Because EOS is Linux-based, however, it is open for programming, and engineers can
Because of this, SearchNetworking sees Arista as the mother of
software-defined networking. Before the hype of OpenFlow, Arista dared its users to dig in and
develop new networking applications that could be both swiftly launched and just as quickly fixed
if there were errors. This leadership earned Arista the first SearchNetworking Innovation Award for
advancements in data center networking. The award recognizes the work of vendors who have changed
the course of networking technology in a variety of ways.
In this Q&A, we talk to Arista vice president of marketing Doug Gourlay, who at the time of this interview was visiting a Hadoop conference in New York City. Hadoop is an open source management/library system for distributed processing of big data (think large-scale cloud computing), so Gourlay's presence at the conference alone was indicative of Arista's role in forward-thinking cloud computing technology. Here's what Gourlay had to say.
SearchNetworking: There is a lot of talk these days about Software-Defined Networking (SDN) and OpenFlow, but Arista's EOS has always been open and programmable. Can you talk about why Arista originally went that route?
Doug Gourlay: When Arista was conceived, the premise was to build a software stack that we could run on a variety of hardware platforms, but to be honest, nobody wanted to be the IBM of the Microsoft-IBM relationship. So we ended up [building hardware] with a software architecture that was designed to take advantage of modern software design principles, and that included things like separating state from process, just as web architecture was forced into in the '90s.
Gourlay on Arista's network automation and testing
DG: When we looked at construction of software, thinking
about network operations, we realized that the biggest cause of problems was human error. If human
error causes network outages, how do we eliminate humans from as much of the critical development
process as possible? In our current system database architecture, about 40% of code is
machine-generated -- automatically generated based on the different processes that communicate with
Also, there has always been this dichotomy in networking companies
where there was the engineering team and then the software engineering team as different
organizations. The blame casting between them was immense. We decided we wanted to follow extreme
engineering problems where every engineer would write their test plan, and they would write their
test automation, and then they would write their software to meet the expectations of that test
We also automated 100% of our testing infrastructure. As a result,
our testers never quit; they never complain; they never get lazy; they never decide they ran the
test 500 times and don't want to run it the next time; they also never fail to document every test
Gourlay on how an open OS changes traditional
Traditional networking operating systems are the most closed
systems I have ever seen. The development process usually started with a customer having a
requirement. They would go to their systems engineer. Then they might call in the client manager,
who might bring in the sales manager. Then they might get in touch with some engineers, and [the
team] would then decide whether this was business critical or not. Translation: Is the customer
going to put in a purchase order on the feature or not? At that point, it would have been at least
a year, and then we would start developing it if we decided it was worth the money. Then it might
be two to three years before the customer would see this feature delivered. That's not acceptable
at the pace of business we are seeing in cloud computing.
[So Arista] created and then published and documented a set of APIs
so third parties could access the same tool-chains and toolsets that our developers do. There is no
special sandbox they get to play in, no abstraction layer that keeps everything separate. By giving
access to the same rules our engineers have, but giving the same protections our engineers use,
they don't make mistakes.
SN: What are some of the developments that have come out of an
open network operating system?
DG: A good example is what we've jointly built with VMware
called VM Tracer,
which takes an external third-party software controller and physical switch and ties them together
with a published and structured API based on SOAP in
As things change in the virtualization platform, the network
automatically reacts in a prescriptive and deterministic manner. [It can] change segmentation,
access control and network policy based on what's being seen in vSphere.
This links to an external controller that defines policy, that
abstracts networking complexity from the virtualization administrator, and that is seamless. The
network team gains visibility into the virtualization environment and the virtualization
environment gains capability in dynamically provisioning the networking. The network works better
because it changes faster, and it's more dynamic. We can solve a problem in seconds that would have
otherwise taken days to troubleshoot.
SN: Is there concern among users that this type of automation will be unmanageable or lead to issues they can't yet foresee?
The DevOps and cloud computing model are much more, build it fast and break it, and adjust it, and then break it, adjust it, nail it on the third time. But have it working at scale with full intimate knowledge of how it's built.
Doug Gourlay, Arista vice president of marketing
DG: There is always the risk of the unknown. This is one of
the boundaries that enterprise computing is pushing. It used to be, build it once to never break
and then hopefully never have to touch it again. The DevOps and cloud computing models are much
more: Build it fast and break it, and adjust it, and then break it, adjust it, nail it on the third
time, but have it working at scale with full intimate knowledge of how it's built [including]
applications and the infrastructure. It's a new world order in development IT methodology that is
The other thing in opening up the OS … one third of customers will
say, "Over my dead body. I will never do anything that isn't just in that switch CMI because I
don't want to take the risk.” That's more of the traditional enterprise customer. And hats off to
them; we support them. Then there is the gooey middle. These guys say, 'I am willing to try
something if somebody else wrote it, but I don't trust myself to write it.” They are looking for
Linux tools to provide incremental capability above and beyond what features we've delivered. And
then there is the radical left. This third says,"Oh hell yeah, I am going to customize it, I am
going to hack it up, and I am going to make an automated system.' We let them start building custom
reactors into the network infrastructure so that if three of these four ports go down, it sends an
email to operations automatically to adjust the routing and take the fourth port down for good
measure. If new virtual machines come up, automatically it takes these access controls and it
applies the MAC address of that new virtual machine.
SN: Most of Arista's competitors have a network fabric story to
tell. What's Arista's response to this?
DG: I look at this network
fabric term that everyone is throwing out and it gets kind of comical.
Customers want to move virtual machines from one physical server to another and not have IP
addressing limit them, and that's a reasonable request.
has Qfabric, Cisco
said FabricPath, Brocade
said VDX. These are three different ways of building a large, flat Layer 2
network, but every one of them is proprietary and only works with that vendor's equipment. The path
that the other three companies are on is one that says, "I can solve this customer problem, but I
can solve it in a way that makes them all mine. Once I get that first box in, all the next boxes
will be mine." This is the worst of the behaviors from the '90s in networking. We don't want to go
that route. A change in customer requirements doesn't mean you have to build a proprietary,
locked-in architecture to solve it. Let's build the best architecture we can, but let’s build it in
an open way.
SN: As other SDN or OpenFlow products start to be released, why
go with Arista?
DG: I think it comes down to what the customer's use case
is. The most common use case I see today for OpenFlow as a superset has been people saying in
government [for example], they may want to identify a small number of interesting traffic flows.
Say you're an intelligence agency and you want to identify a few phone call flows from one place to
another. A 10 gig probe is super expensive. Instead of buying a probe, which is cost prohibitive,
they want another application that is dynamically programming those. I think of it as IDS or IPS on
steroids. That's the best use case I've seen so far.
Others companies are discussing other applications. BigSwitch and
Nicira are building on top of it. Those guys all started with OpenFlow for better private cloud
segmentation or scalability of public cloud. They have all extended it in one way or another to
What is the role of us in OpenFlow and SDN? What is the use case for the customer to solve? Our goal is to be the best hardware and software architecture for software-defined networking and we can do that because of the programmability of our network software.