A platform for intent-based networking development has some hidden gems.
Who Is Apstra?
Apstra is one of the companies I was looking forward to seeing at NFD16 (#NFD16). It has been mentioned by Gartner as a company to watch in 2017 because of its approach to multivendor, intent-based networking. I wasn’t disappointed. When you look at what it is currently doing, it appears the product only functions on a leaf-spine network — typically used in very modern data centers. However, the functionality it has built is extensible to other network architectures, such as those normally used in enterprise networks. A recent announcement extends support to VXLAN overlays. But that’s not where its capabilities end.
The Apstra Operating System
The Apstra Operating System (AOS) is actually a platform upon which intent-based network modules can be built and deployed. The VXLAN module is one example, as is the Layer 3 CLOS fabric (i.e., leaf-spine) support. This means it is possible to develop a module for other network topologies, such as the core, distribution, and access model that is used in traditional enterprise network designs. Apstra is wisely concentrating on the more advanced leaf-spine network market. My take on its choice is simple: Customers who are willing to use leaf-spine designs are more likely to experiment with something new that gives them a competitive edge over their peers.
Apstra told the delegates at NFD16 that it envisions the teamwork between a networking person and a software developer to create intent-based applications on top of its API. The networking person knows about network protocols and common network failures. The software developer brings software development knowledge to the team. A module development team consists of both types of professionals, working together to create an intent-based network application. This team is described in the demonstration recording, starting at 8:32. (Apstra’s NFD13 sessions talk about AOS for network operators.)
Internally, AOS uses a graph database to represent the network design. The graph is then queried to determine intent. Once intent is known, data collected from the network can be used to determine whether the network meets the expectation for its functionality (NFD16 Sasha Ratkovic defines intent, starting at 13:00). As Ivan Pepenljak observed in that segment, checking to ensure the network meets expectations is essentially unit testing. If the intent is to provide router redundancy, the check might be to verify HSRP/VRRP/GLBP functionality. This is the same testing methodology that software development teams use to help identify and correct software bugs.
Continuing the thought about validation, Damien Garros of Apstra provided a demonstration in which the schema was extended to verify the network connectivity of application servers. An interesting approach to multivendor support is that they model device roles in their reference design — not devices. For example, the model for a leaf switch would include only the functions that would be used in that role (see Jeff Tantsura’s question in the demo recording at 3:53).
The demo video includes another gem that easily could be missed. AOS is essentially a platform, much like SAP or Salesforce are platforms. Apstra has helped by building the basic leaf-spine intent-based logic. The demo showed how that basic logic can be extended to add server connectivity verification. This is why Sasha referred to the company’s demonstration as an example of AOS for the “Developer Persona” and that the NFD13 presentation was AOS for the “Operator Persona.” It is important to watch both sessions.
Slack as a CLI!
Damien surprised us during the demonstration by using Slack as the CLI to AOS (demo at 29:47). Think about the implication. Instead of using something like Postman to craft the API calls, Damien used a chatbot-style API between Slack and the AOS API. He didn’t have to write any code to handle the text input and command-line editing part of the CLI. Very cool. The mental twist here is to realize that tools with a REST API-calling mechanism can interface with the REST API of other systems.
Hidden in the discussion was another gem: A description of using Slack for network changes and verification. I highly recommend watching this demo and spending time thinking about how this part of the demo worked and how to apply this to your network operation.
Summary
A lot of capabilities within AOS may not be obviously apparent upon first exposure. It seems that every time I watch Apstra’s videos, I pick up something that I had previously overlooked. There is a great deal of capability in AOS. It is more than a network automation system that can automatically validate intent. I’m just beginning to appreciate its capabilities and look forward to the day when I can use it in a real network.
Disclosure
The vendors at NFD16 indirectly paid for my expenses to attend. There was no direct compensation or gifts outside of some inexpensive marketing tchotchkes, which don’t affect my opinions and blog posts.