• Login
• Become a member
• RSS
• Part of the TechTarget network

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

separate the control plane from the physical network (the way that OpenFlow vendors promise but seldom deliver). For example, an engineer can program the network to automatically react to moving VMs or provision network resources dynamically for cloud environments. Essentially engineers can build the kind of network that is reactive to their specific needs – something unheard of in traditional networking.
 

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 each other.
 

 

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 plan.
 

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 they do.
 

Gourlay on how an open OS changes traditional networking
 

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 this case.
 

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 disruptive.
 

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.
 

Juniper 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 achieve capability.
 

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.

Join the conversationComment

All Rights Reserved,Copyright 2000 - 2013, TechTarget