TAGS: |

Arista EOS: Benefits & Challenges Of A Single OS

Drew Conry-Murray

Software has taken a front seat in discussions about networking. While hardware still matters, it’s software that provides operational flexibility and automation, and enables the network to better serve (or at least not get in the way of) applications and developers.

At Network Field Day 10 I had the opportunity to hear from several network vendors, including Arista. I knew  Arista touted its EOS operating system as a strength, but these presentations provided more insight into why that is.

I’ll summarize a few things that jumped out at me as a way to better understand the company and its position in the market, and share some thoughts about potential weaknesses of a single-OS strategy.

Sysdb

The foundation of Arista’s ‘software as differentiator’ edifice is sysdb, or system database. The system database resides in the kernel of the Linux-based OS and maintains state.

Arista then runs agents in user space on top of sysdb. Each agent has a different purpose or feature for the switch, such as SNMP, BGP, or Arista’s API. There are 110 agents in the most current release of the OS.

Sysdb updates the agents. Arista claims it can scale to millions of updates per second with its publish/subscribe model. Customers can also run their own code on the switch via an SDK (more on that below).

Arista also runs a single binary image across its entire product line. That has great benefit both for the company and its customers, because it dramatically simplifies bug fixes and OS management tasks.

A single image and the sysdb structure also offers other benefits. For instance, at its Field Day presentation, the company claimed it can support hitless updates in which it can fully reload the switch OS in just 17 milliseconds.

One more fun fact: EOS has 7 million lines of code, not counting the kernel.

APIs And SDKs

Arista has an eAPI, a JSON-based API that let third parties read and write to Arista’s libraries. APIs provide a mechanism for integration with tools to help streamline configuration, management, and monitoring. For instance, Arista integrates with SevOne for Sflow-based monitoring.

Arista also builds its own integrations, such as app for Splunk that feeds telemetry data from the Arista switches into a Splunk collector. An applet in Splunk will create dashboards and visualizations for the data.

And if you want to write your own applications, Arista has an SDK that lets you integrate directly with sysdb. As with Arista’s own agents that live in user space, your application agent will run directly on the box. The appeal here is for organizations with very specific use cases that may not rise to the level of a general feature that the vendor itself would develop.

As NFD delegate Matt Oswalt notes in the video (around the 7:25 mark), one takeaway of the SDK is that customers can develop event-driven agents that can take immediate action based on defined criteria, vs. a remote polling system that makes periodic checks.

Of course, when you write your own software, you have to be careful of unintended consequences of an application, not to mention flaws within your own programming.

CloudVision

CloudVision is Arista’s latest offering that takes full advantage of the company’s software strategy. It’s a set of software and services that provides a single interface to manage the entire network. CloudVision uses the same sysdb architecture as the switches, but runs in a VM.

The goal of CloudVision is to provide a mechanism for network automation and orchestration, and to provide an abstraction layer and integration point for third-party SDN controllers and cloud orchestration platforms.

CloudVision can integrate with third-party systems via its JSON API or OVSDB.

In the interest of length I won’t go into further detail, but if you want more information check out the Network Field Day video and this Packet Pushers podcast.

Walled Garden

While Arista’s single OS strategy makes excellent sense, it might get harder to maintain.

Now that Arista is publicly traded, it must grow. But given the saturation of the switch market, most switching deals will be displacement of a competitor. While Arista has proven it can sell this way, it’s a tough slog that doesn’t lend itself to the torrid growth that Wall Street prefers.

Failure to grow, or grow fast enough, will decrease the value of the company and its shares. If that goes on long enough, activist investors will clamor for leadership changes and new strategies (see EMC).

That means looking at adjacent markets for new business, such as routing, security, WLANs, UC, or SD-WAN/WAN optimization.

And there’s the challenge for Arista. If it wants to maintain its single-OS strategy, it has to build its way into every new market. I’m sure it’s possible, but it’s also slow, particularly when competitors (i.e. Cisco and Juniper) don’t hesitate to buy their way in via acquisition.

But acquisition means bringing in products on different codebases, which dilutes a key value proposition of an Arista purchase.

This conundrum isn’t an existential threat to the company, but it might make for some uncomfortable rationalizations—and additional efforts by Arista to provide useful management and operations tools—down the line.

About Drew Conry-Murray: Drew Conry-Murray has been writing about information technology for more than 15 years, with an emphasis on networking, security, and cloud. He's co-host of The Network Break podcast and a Tech Field Day delegate. He loves real tea and virtual donuts, and is delighted that his job lets him talk with so many smart, passionate people. He writes novels in his spare time.