What do UFOs, the Loch Ness Monster and intent-based networks have in common? These are all things that people claim to have seen, but no one can really prove it and their existence remains largely a myth.
While the good folks over at the X-Files will continue to try and prove the first two, start-up vendor Apstra appears to have licked the third, as its latest operating system release, AOS 1.2 is making vendor-agnostic, intent-based networking a reality.
You might be asking what exactly intent-based networking is? Think of it as a network where you tell it the “what,” and the “how” is determined by the system. A good example of this is a self-driving car where the driver puts in the destination address, and the car’s system figures out the details. The driver just gives it a command and then gets there.
Wouldn’t it be great if networks operated that way? That’s the idea behind an intent-based network. As an example, a network manager could issue the command “secure all of my production servers” and the system would take care of all the technical requirements.
To date, the demand for intent-based networks has been hindered by two factors: network operations teams could keep up with the needs of the business through manual processes and basic automation and a lack of solutions. This creates a bit of a chicken-or-egg situation where no vendor will spend millions of R&D money on creating something for which there is no demand. However, in this digital era with billions of IoT devices, where the winners and losers are defined by speed, intent-based networks are needed more than ever before.
It’s important to note that automation and intent-based networks are different. At a basic level, automation pushes configurations out to the network, and there’s certainly value in this, but the “how” still needs to be determined by an engineer. An intent-based solution would determine the “how” and use automation to configure the network.
How AOS 1.2 works
The “secret sauce” in Apstra’s AOS 1.2 is its closed loop system. AOS keeps a repository of all intent, configuration and telemetry information that is constantly updated based on the state of the network. By measuring telemetry, AOS safeguards that through a process of continuous validation, the network is always in the desired state. This confirms that the intent is relevant and the single source of information extends across the entire network lifecycle.
Apstra takes a top-down approach to the network, so it’s completely vendor agnostic. Network engineers think of the “what” and then Apstra uses APIs and other configuration tools to figure out the “how.”
Customers benefit greatly, as it evolves the network from being something that typically carried a tremendous amount of manual overhead to an agile and automated, “self- operating network.” Valuable engineer time can be freed up to focus on more strategic initiatives instead issuing repetitive commands into a command line interface.
The closed loop nature of AOS 1.2 enables it to automate the prevention and repair of the network, so uptime is significantly improved. Also, the network becomes a single system instead of a collection of discrete network elements.
Apstra also self-documents all the network state as changes are made, alleviating the automation concerns that heavily regulated verticals have regarding compliance adherence. Automation can be viewed negatively in verticals such as financial services and healthcare because it's nearly impossible for network engineers to keep documentation up to date when the network is configuring itself, but Apstra takes care of it.
Innovations in AOS 1.2
A major innovation Apstra introduced in AOS 1.2 is a representation of this state in a graph that models the dependencies between intent, topology, policy and telemetry. This enables network engineers to utilize a powerful querying language to get answers to any questions they may have about their network.
Another major innovation is the ability for operators with DevOps skills to activate arbitrary telemetry. AOS automatically stores this telemetry in its data store and adds it to the graph. These capabilities turn the network from opaque to fully transparent. This type of innovation makes it apparent that the time has come for the data center network.
This version of AOS is targeted at transforming the troubleshooting and operations associated with running a network. The graph shows user intent, topology, interfaces, links, policies and other information pertaining to the virtual overlays, as well as configurations for all devices. The blueprint also shows the results of the tests that run continuously in a closed loop to validate the intent. Engineers can access the blueprint via RESTful APIs and a streaming interface.
AOS 1.2 can help bridge the gap between the network and other parts of IT. Anyone who has access to the AOS libraries can now get visibility into the network. This includes the network team, but also compute, DevOps or applications. Historically, the network has been a black box, but now it is fully transparent to everyone.
One of the more powerful aspects of the blueprint is that it can be used to stage, commit and deploy configuration changes, as AOS can be used to streamline operational changes and minimize the risk of errors. AOS 1.2 allows customers to create a staging blueprint that is distinct from the active blueprint. Changes can be made on the staged one, and AOS automatically pre-validates the semantic consistency of these changes and flags any errors. The changes can then be committed to the active blueprint, and AOS will verify that the changes being pushed are consistent with the infrastructure under its control. Any inconsistency would be flagged. Once the anomalies are corrected, AOS pushes the configuration, activates telemetry and spins up its closed loop, validation process to ensure intent is being realized.
ApstraThe semantic validation built into AOS 1.2 can make operational changes fast and error free, so network engineers can spend less time doing manual tasks and more time on strategic initiatives. Some examples of semantic validation, change management and operational validation:
- Does the device I want to deploy in my reference design have all the capabilities I need?
- Do I have enough resources to deploy a new overlay network?
- Can I deploy a virtual network endpoint without violating a requirement related to isolation?
- Can I roll back to a version of intent that I liked?
- Is adding or removing a device violating some policy?
Intent-based networking has been theorized for almost a decade, but there hasn’t been a solution that could make it happen. Apstra has an impressive team, good timing, a very special architecture and early customer traction. The closed loop telemetry of Apstra’s AOS 1.2 makes it possible for it to “self- operate” the network now, but also into the future as things change. Definitely worth a closer look.