Apstra, which makes intent-based networking (IBN) software for data center automation, has announced new features and product upgrades in version 2.3 of its AOS software.
New features include:
- Root cause identification
- vSphere integration
- Support for Junos and Sonic
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:
- Intent-Based Networking
- Self Operation
- Unified automation everywhere
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.
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.
We know it’s possible to build and operate highly automated networks; hyperscale and cloud providers do it.
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.