What is Apstra Operating System (AOS)?

Apstra Operating System (AOS) is a Distributed Operating System for the data center network. You can deploy AOS across a network infrastructure that comprises a wide variety of name-brand or white-box network hardware, decoupling your network service design and operations from the lower-level, error-prone, manual workflows required by vendor-specific networking hardware. It reduces network services delivery time, outages and cost by 50-90%.

Who uses AOS?

Anyone who wants to massively reduce the amount of effort involved in designing, building, deploying and operating a data center network. You can declare vendor-agnostic service intent at the network service level, deploy AOS-rendered configurations to your chosen vendor hardware options, and let AOS continuously validate the network state against your intent. The results are massively improved service agility and reliability.

What are the benefits of using AOS?

Improved service agility: Enables networking team to rapidly design, build, deploy and validate network services
Reduced risks: Greatly reduces human error, loss of visibility, configuration drifts, and big data telemetry dumps — fundamental sources of outages and application performance issues
Reduced costs: Reduces CapEx due to vendor hardware lock-in and OpEx spent on inefficient manual operations

How does AOS accomplish this?

AOS gives you an interface (Web GUI or RESTful API) to declare your network service intent, i.e. desired outcome (service) at the network level, using human language — not prescribing vendor-specific device-level jargon. A vendor-agnostic intent example: Build a L3 scale-out fabric with VXLAN overlay providing inter-rack L2 segments, for 100 servers, with 1:1 oversubscription.

Build: AOS presents you the choice of reference design templates that can meet your intent. AOS then allocates resources to your chosen template, resulting in a blueprint. Finally, AOS uses the artifacts in the blueprint to fabricate the network service configurations and telemetry expectations.

Deploy: With the push of a button, AOS deploys desired configurations (configuring resources according to the reference design).

Validate: AOS auto-validates your service expectations, executes test cases, and generates alerts and telemetry.

When you make changes dynamically — either to the physical infrastructure (add a rack, replace a switch) — or virtual network (add a VXLAN or VLAN, delete virtual network, add end-point to virtual network), AOS implements these in an intent-driven, closed-loop manner.

When the user changes the intent, AOS implements the change and validates that the change was indeed implemented as intended.

Why should CIOs care about AOS?

Many CIOs want to build private clouds rapidly without Amazon-like investment in people, process and technologies in order to achieve network service agility, and without being locked into a specific hardware platform.

CIOs also want to move to modern L3 leaf / spine fabric for agility and scale, but are being held back by legacy L2 applications. AOS allows the networking team to design, build, deploy and validate underlay and overlay (VXLAN) as a single integrated autonomous system, without being locked into a vendor hardware platform and massive do-it-yourself programming.

What alternatives exist in the market?

While there are technologies that can address aspects of what AOS can deliver, there is no comparable offering available. There are home-grown tools that attempt to automate specific use cases, separate configurations and state, and require a lot of integration work that doesn’t scale operationally. There are also server infrastructure tools on the market that do not integrate configuration and telemetry in a continuous validation loop and that do not start with business-level intent.

What are AOS’ key differentiating attributes?

Intent-driven: Network engineers interface with AOS by specifying their desired service outcome, without prescribing imperative, device-level commands to achieve the desired outcome.

Closed-loop: Network engineers’ intent, network configurations, and actual state (telemetry) are continuously validated by AOS in a closed-loop.

Vendor-agnostic: AOS allows you to completely decouple your services and operational model from vendor specificity. You can express your intent once, and then render and re-render detailed configurations for any vendor of your choice — without having to modify your intent.

What does intent mean in the context of AOS?

Intent is a network engineer’s declarative specification of desired outcome (service), describing the need for cooperative behavior of the network system infrastructure, without prescribing imperative commands to achieve it (the desired outcome).

An intent example:

“Provide connectivity to 1000 servers, using L2 and/or L3 access at the edge, with oversubscription in the core of 1:1 (no oversubscription), with endpoints such as hosts, VMs or containers grouped into isolation domains (including both traffic and address space isolation). Have some endpoints reachable via the rest of the world and some not, with policies associated with isolation domains governing both security and load balancing, with connectivity to the rest of the world via at least n links to support the external traffic and protect from possible failures.”

What is closed-loop telemetry?

AOS uses a device telemetry agent to collect statuses, leveraging native protocols supported by devices and compares them against expectations, generating an anomaly if there is a mismatch. With agents running on the devices, collected data can be processed as close to the source as possible. This results in less big data telemetry, and more knowledge-enriched information across the network.

Is vendor-agnostic the same as multi-vendor?

No, they are not the same. Many networking tools support multiple hardware vendors, but typically require network engineers to create, maintain and debug a set of commands, scripts, playbooks, or programs that work only for a specific vendor. These playbooks or programs do not work for other vendor hardware platforms. You will have to write an equivalent set of programs for other vendors. Furthermore, you can't mix-and-max different vendor's switch hardware platforms for different spine or leaf switch configurations. In fact, you can’t even mix-and-match the same vendor switches if they have different OS versions or hardware models.

Vendor-agnostic allows you to completely decouple your services and operational model from vendor specificity. You can express your intent once, and then render and re-render detailed configurations for any vendor of your choice — without modifying your intent. You can render configurations for vendor A leaf switch interoperating with vendor B spine switch. You can swap out vendor A switch with an equivalent vendor B switch — all without changing your intent.

You can certainly change your intent — which can be done with a few mouse clicks — and have AOS auto-render new configurations for any vendor of your choice.