I swear it’s impossible to keep up with the networking industry. Just when I think I have it figured out, a technology hits the market that makes me rethink my life the past 10 years. It’s not fair! Apstra, a newer start-up company out of Silicon Valley, is guilty this time with their brilliant new approach to integrated closed-loop networking that will likely revolutionize the way we think about data center networks in the future. Like Spartans that followed a strict system emphasizing duty, discipline and endurance, Apstra is building structure and reason in a network of chaos.

Apstra – Melting Snowflakes

Apstra is an intent-driven data center networking company. What does this mean?

For ages, network engineers have been designing, deploying and operating data center networks on a node-by-node basis, spanning multiple device models, vendors and services. These networks are often built based on some sort of a validated design guide, but this can vary from vendor-to-vendor. An expert-level skill-set on a multi-vendor scale is needed to appropriately design and configure the network. These people exist, but they’re valuable and spend far too much time memorizing multiple vendor languages, often making errors in translation.

What Apstra did was take a step back and look at this peculiarity from a different angle. What if we instead built models based on our intended purposes of the network, and deployed these intents to our network devices on behalf of us, regardless of the vendor platform. This would free up time, money and resources spent arduously deploying networks that we almost blindly design as a catch-all for various business and application needs.

Each and every network is a special snowflake, unlike any other. While this is cute, it’s also troubling. Programming, automating and supporting varieties of snowflakes is increasingly challenging. Apstra is overcoming this obstacle by blueprinting the network, steering the industry in a positive direction by creating a pseudo-standardization of network architectures, such as L3 Clos fabrics. In the fluent words of the great Ethan Banks…

https://twitter.com/ecbanks/status/799429475930763264

Apstra Operating System (AOS)

Apstra makes a compelling case for intent-driven networking, sharing that most outages arise from living systems, and not initial deployments. This is interesting to me, for when I first starting researching Apstra I had this skeptical blockade in my mind, thinking that this would really only function for greenfield data centers. This is not the case, however. Apstra expects increases in complexity as networks evolve. Their answer for this is a distributed network operating system, leveraging the vendor-agnostic infrastructure to provide consumable services based on specified intent.

AOS follows a composability design principle whereby components within the system can be selected and assembled in countless combination in order to satisfy the specific user requirement. Take a Cisco Nexus 9K or an Arista 7K, for example. You might have varying features — some of these features are similar, while others are non-existent from one platform to the other. AOS turns these features into services, making them composable in the AOS reference architecture.

This abstraction methodology is something entirely unique to Apstra. I’m both philosophically intrigued, and intelligibly clumsy when it comes to this concept, which is a great combination for healthy curiosity!

AOS Architecture

Apstra strongly feels the days are numbered for legacy configuration and monitoring tools like ICMP and SNMP, especially in the data center. Data center demands are higher and far more complex than these protocols were built for.

Each network node in your data center that’s part of the AOS fabric will have an agent installed. Much like you’d load Puppet or Chef on a device, instead, Apstra is loading AOS. What this gets you is advanced configuration and telemetry capabilities in a distributed model.

It’s important to understand why the distributed model with AOS agents is so critical. Remember, if our goal is to deploy and maintain business intent, we must continuously validate the operational state of our network. Is it configured properly? Is it performing as expected? Are we learning about any anomalies via real-time telemetry? Can we automate design-validated configuration changes triggered by these detected anomalies? Constantly achieving expectation is the ultimate goal here.

Not all devices support agent installs, however. No sweat, as Apstra and it’s growing community are building software adapters to gain that same level of distributed architecture. They encourage network engineers and developers to build backend configuration, telemetry and state streaming modules that’ll interface with the AOS APIs. Follow Apstra on GitHub for some of the work they’re doing with Ansible and Python.

A practical example

This product is so much more than I can discuss in a single blog post. I’m sure Jeremy Schulman (@nwkautomaniac) and Derick Winkworth (@CloudToad), presenters at Networking Field Day 13 thought the same thing after a short 2 hour demonstration of Apstra magic. You could tell they were excited about this technology, and could run through countless hours of demos and use cases had time not been an issue. Definitely check out their videos when you get a chance.

In one of their demos, the showed us how you can swap out any (supported) vendor equipment in your data center with some other vendors equipment, while still maintaining your design requirements. Oh, and all configuration was done automatically even though the device swap resulted in an OS and CLI-syntax change.

Vendor independence is a good thing. @ApstraInc can enable that. In demo, they painlessly swapped a Cumulus switch with Cisco. #NFD13

— Scott McDermott 📡 (@scottm32768) November 18, 2016

It was quite impressive to see them go through the design phase, to build, to deploy. At one point, they show you the configuration changing in real-time from IOS, to EOS to JunOS. That’s an insane amount of logic to build, but they seem to have done it. This gets us closer to the days where knowing rarely used CLI commands on 5 different OSs becomes unnecessary. I have to agree with Bob McCouch on the build approach – it was reminiscent of Cisco UCS, except AOS doesn’t care if it’s Cisco, Juniper, Arista, Dell, Celestica, you name it.

.@ApstraInc’s resource pools & templates for deploying remind me a lot of Cisco UCS. That’s a compliment. #nfd13

— Bob McCouch (@BobMcCouch) November 18, 2016

Current Thoughts

I’ll be keeping an eye on Apstra. AOS is currently version 1.0, with 1.1 coming out very soon. They have an excellent team and they’re backed by a genius billionaire, a recipe for success. I hope they return for future Networking Field Day events with additional use cases. I see the value if you’re managing many data centers, or you’re constantly deploying data centers and you need to ensure the numerous networks you manage are meeting business intent, regardless of vendor hardware. I have personally never run into such a crisis of a situation, but what I’ve done thus far in my career is peanuts compared to these guys. One day, one day.

In my experience, true value would immediately be seen if I were to slowly migrate my data centers from one hardware vendor to another in a phased approach. I’d have more confidence that my design and configurations are on point. I see value even if I were to run a single vendor shop, adopting an intent-driven methodology with continuous validation. Also, that real-time telemetry is oh-so desirable.

Apstra is set to be a great leader in the revolution towards intent-driven networking, echoing the ambition and power of disruptors like Sparta.