Takeaways

Root cause identification: Apstra claims it can “pinpoint and isolate” the cause of data center problems including gray failures, poor performance, and outages.

How does it do this? Apstra’s software collects lots of metrics in at regular intervals about data center devices, including configuration, OS and version, telemetry data (CPU and memory use, buffer status, link status, bandwidth capacity, etc.), IP addresses, and even cable configurations.

Apstra puts all this information into a graph database, which serves as a source of truth for the overall state of the network. It can use this database, along with analytics software, to sort through layers of dependencies and hone in on the source of trouble.

vSphere integration: AOS 2.3 can ingest vSphere’s view of the network and look for mismatches between policies in the overlay and the configuration of the underlay or physical network.

Junos and Sonic support: A good IBN product should thrive in multi-vendor environments and be able to interoperate with, and extract information from, a variety of networking platforms. With support for Junos and Sonic in AOS 2.3, Apstra extends its multivendor capabilities.

Apstra’s Story: Utopia In Small Bites

Apstra’s grand vision is a data center that essentially runs by itself. Engineers express the business outcomes they want to achieve, and then the AOS software performs the requisite configuration, programming, and orchestration of network devices to achieve those outcomes.

In this vision, Apstra’s software continuously gathers information to measure policies and performance against actual conditions in the data center, automagically brings devices and services back in line if they stray, and heals any wounds that might occur in day-to-day operations.

In the long term, Apstra intends to extend from the data center to the campus, the edge, branch networks, and the cloud, all of it automated.

It’s a beautiful story of a network utopia. CIOs might weep with joy when they hear it, but experienced engineers roll their eyes and swap rainbow-farting unicorn GIFs.

My impression is that Apstra realizes they probably won’t get very far if they ask potential customers to swallow the promise of instant utopia.

So the company has developed a set of use cases that are more easily digestible. The use cases are organized like steps to lead the customer higher up the value chain. They are:

Analytics

Design

Intent-Based Networking

Self Operation

Unified automation everywhere

Source: Apstra, Inc.

For the analytics use case, Apstra says the system can be deployed to collect data and serve as that single source of truth for network engineers and administrators. The system will collect telemetry and state data that can be used for common operational tasks such as checking configurations, figuring out whether the correct OS version or patch is installed, and so on.

From there, the use cases get more complex, and begin to engage more automation and orchestration functions.

I think the stepped approach is palatable because it lets customers integrate Apstra into their operations environment without expecting it to take over from day one.

It also gives customers an opportunity to test Apstra’s claims, starting with the essential data collection that the entire platform is built around.

Drew’s View

On paper, the concepts behind IBN make sense to me. IBN essentially promises a gestalt view of the data center through continuous data collection, analysis, and verification or validation.

But paper is a long way from production networks.

When you run complex software on top of an elaborate system like a data center, you’re going to run into bugs, incompatibilities, poor integration, weird design choices, vendor hubris, marketing overreach, and human error—and that applies to every IBN vendor.

The trick is to bring that to the enterprise, which is likely still tied to the CLI and perhaps a handful of scripts. And unlike hyperscale networks, which were designed fresh with automation in mind, most enterprise networks struggle with long-accrued technical debt, have to support a host of legacy applications, and may have to account for design choices made long before cloud was a thing.

Those conditions complicate the introduction of a technology like IBN and its promise of data center utopia.

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. Follow him on Twitter @Drew_CM or reach out at [email protected]

Apstra is fortunate to have many production deployments of Asptra Intent-Based Data Center Automation which is built on Apstra Intent-Based Networking technology (Level 2 today and architected for Level 3) which we pioneered. These deployments include financial services, manufacturing, oil and gas, services industry, and even two of the Fortune 50.

These Enterprises are deploying Apstra to eliminate network complexity, increase application reliability, and reduce costs through sophisticated automation. They also run Apstra to accelerate time to deployment because Apstra pre-qualifies, pre-tests, pre-validates, and manages the network switches and device operating systems they deploy.

You might say that Apstra goes beyond paper by actually having production deployments of Level 2 Intent-Based Networking.