May 2, 2017

Delivering on the Apstra Mission with AOS 1.2

aos_logo_rgb_tm.pngDelivering on the vision of a Self-Operating Network™ is the core mission of Apstra. As we have made clear, this is not an easy challenge, but one that requires careful steps forward that address customer requirements. Today, we take a significant step forward in our commitment to this challenge by releasing Apstra Operating System (AOS®) Version 1.2. It is an exciting release because it includes significant capabilities you, our customers, have told us were most important to you since GA of AOS 1.0 nine months ago. Together we have made a big leap forward towards our mission of delivering a Self-Operating Network!

What have we heard from you, our customers? Well, you told us, as a network engineer, you spend a lot more time operating your networks than building it the first time. Operating your network mainly includes the tasks of managing change operations and troubleshooting your network when problems arise.

In 1.2, we have made significant enhancements to AOS’s day two operations capabilities — both change operations and troubleshooting activities. Here are a few new capabilities that I am super excited about:

Full network transparency with powerful graph queries

The blueprint in AOS represents all the state associated with a specific infrastructure (say, a POD) under the control of AOS. It captures user intent, the topology, the specifics of the device roles and their positions in this topology, interfaces, links, the cabling diagram, all the policies pertaining to virtual networks, and all the resulting configurations for all devices. The blueprint also captures all the telemetry and the results of the tests that run continuously in closed-loop to validate intent. We have always stored this blueprint as state in the AOS distributed data store, and it has been accessible through RESTful APIs and a streaming interface.

In AOS 1.2, we expose the blueprint as a graph, and integrate this graph representation as part of the state-driven distributed data store. In addition to the RESTful APIs and streaming interface, you now have the ability to visualize these relationships with ease; and use powerful graph queries to traverse the graph and get answers to any question you have about your network: intent, topology, policies, telemetry, and how they interrelate.

Anyone that has access to the AOS libraries can now get visibility into the network — the network teams, but also the compute teams, devops teams, or application teams. The network, which is traditionally an opaque entity is now fully transparent to everyone!




Extensible telemetry

You know that telemetry is important to understand how well your network is working, and we delivered on this in our previous release. In AOS 1.2, we made this telemetry extensible. Let us consider a scenario whereby you realize that it would be really nice to correlate the telemetry collected by AOS with some other piece of telemetry, say CPU on a server or latency parameters from your business application. With the extensible telemetry that we have productized as part of AOS 1.2, you now can use the Apstra development environment to collect any arbitrary telemetry of your choosing! Through its libraries, AOS will create the appropriate structures to store this telemetry within the AOS distributed data store, and you are now able to correlate this telemetry with all the other parameters tracked by AOS.

And as with AOS 1.1, you can stream all this telemetry using Google protocol buffers to any third party system of your choosing. With AOS 1.2, we have built integrations with InfluxDB and you can use Grafana for visualization.

Stage/Commit/Deploy day-2 operational workflow

You have told us that you are making 1000’s of changes to your network in any given month — adding servers, racks, virtual networks, and network policies. You have told us that you would like AOS to help you streamline these change operations, while minimizing the risk of error.

We have listened to you. AOS 1.2 now allows you to create a staging blueprint that is separate than the active blueprint. You make your changes safely in the staged blueprint. AOS algorithmically pre-validates the semantic consistency of these changes and flags any errors. These changes can then be committed to the active blueprint — at which point AOS activates the appropriate telemetry to verify that the changes you are pushing are consistent with the infrastructure under control. For example, AOS is able to tell you if the switch you plan to add is really there, and whether all the cables are connected as they should be. Inconsistencies are flagged as anomalies. Once you resolve these anomalies, you are ready to deploy — at which point AOS pushes the appropriate configurations, activates the full set of telemetry collection, and enters its closed-loop, continuous validation mode to insure that your intent is indeed being realized.

With AOS’s enhanced day-2 operational workflow, our goal is to make your change operations as streamlined as possible, while minimizing the risk — this way, you can spend less time orchestrating change operations manually, and more time for other responsibilities. You can also potentially reduce the intrusion of operations on your always-important personal time! You may even have time to take our trainings to learn devops tools and Python to expand the set of telemetry that AOS collects, or learn about AOS’s powerful graph queries.

In addition to these major enhancements, we have also added new enterprise features such as the ability to snapshot various versions of AOS and the ability to restore previous backups. We have also included neat new visualizations including topology heat maps, as well as improved WebUI workflows.

Delivering on the Apstra mission

When we launched Apstra, we took on the mission to enable Self-Operating Networks. We recognized it as an enormous challenge. We were upfront that we could not deliver on the whole vision in one step — it would be a journey, just as it has been with self-driving cars. We also told you we had made a major investment in building an intent-based distributed operating system which acts as the foundation. It would scale to the largest data centers, support all your data center use cases, and allow for full extensibility. Now, with AOS 1.2, this major step forward validates our investment in our distributed operating system and shows our commitment to our core mission.

We invite you to try AOS 1.2, and experience the power of the platform. See how it can help you streamline your change operations, and get unprecedented visibility into your infrastructure. See for yourself how it advances your goals towards a self-operating network.

View our webinar on Disaggregating Data Center Networks with Cumulus  icon-arrow-right-double-24.png

Read white paper “A Next-Gen Vision for the Next-Gen Network”  icon-arrow-right-double-24.png


Mansour Karam

President, Founder