This blog was originally published to the Apstra website – in 2021, Juniper Networks acquired Apstra. Learn more about the acquisition here.
Modern automation systems have two fundamental characteristics — they are Intent-Based and they are Closed-Loop Network Automations. Yet it is only today, and with Apstra’s Intent-Based Self-Operating Network™ that these concepts are being introduced to network infrastructures!
Intent-based
“Intent-based” is the notion that the user interfaces with the system by specifying their intent, in the context of a specific function.
Let’s take the example of a simple automation system — a climate control system. You interact with a climate control system using a thermostat. The thermostat allows you to input your desired temperature — that is, your “intended outcome”, or your intent.
Before climate control was automated, we had a more painful system. You would have to struggle with various knobs in an attempt to achieve your intent: should I turn on the AC, or should I turn on the heater? What speed would I like the fan to run at? Do I like the air to be recycled or not? In those older systems, you tweaked those various knobs that control specific components in an effort to get you close to your desired intent — in short, you were asked to be involved in the “how”, not the “what”.
Because of this, there were several problems: It was hard to tell whether you reached the right temperature. Often the system over-cooled or over-heated the room, and the user had to continuously adjust accordingly. In short, those older systems were time-consuming, hard to use, and error prone.
Closed-loop
Once you have specified your intent, the climate control system goes about implementing your intent, that is implementing the specifics involved in “how” it will deliver on your intent. In order to do so, the system configures some components — either the heating system or the air conditioning system. But critically, it also needs to measure the current temperature — that is collect information on the current state, and then compare it continuously to the desired state (your intent, that is the temperature that you have specified).
Measuring the state continuously is a critical step in achieving your intent. The job of the climate control system is now focused on ensuring that the actual state (the actual temperature in the room) matches your desired state (your desired temperature). It does that by simply injecting the appropriate configurations into the right components. Namely, if the actual state indicates the temperature is too low, then it will go ahead and configure the heating system appropriately to heat up the room; and if the temperature is too high, then climate control will configure the air conditioning system to cool the room. When the actual temperature (as measured by the system) matches your desired temperature, then the climate control will stop its process of configuration.
It doesn’t stop here. After the desired state matches the actual state, the climate control system continues to monitor the actual state. That is because, at any point, the desired state and actual state could diverge. The actual state could change — i.e. the room temperature could deviate from your intent — say because the sun sets and outside temperatures cool. Or, you may choose to change your intent and would like the desired temperature to be different by simply changing the setting on the thermostat.
In both cases, the climate control automatically and in real-time detects deviations from the desired state. Automated climate control systems automatically adjust both heating and cooling systems to achieve the desired outcome — smart ones take into account outside factors such as changes in weather, sunlight exposure, and time of day to be increasingly predictive and autonomic.
Anomalies
Let’s assume that in the example above, your desired temperature is lower than the actual temperature, but the air conditioning system is broken so the configuration of that component does not yield a reduction in temperature. In this event, the climate control system detects its inability to adjust the temperature to match your intent. When the system detects this anomaly, it sends the user an alert. Anomaly detection is when the user needs to get involved — in this case, to restart the A/C system or schedule to get it repaired.
What about self-driving cars?
Those concepts we described in the context of a relatively simple climate control system are in fact ubiquitous in automation systems. I bet that if you looked around you, you would find many examples of intent-driven, closed-loop automation systems: the video camera hiding in your microwave oven (joking), your refrigerator, your GPS-based navigation system you use to get to your destination, your water heating system, just to name a few.
Self-driving cars are of course much more sophisticated than climate control systems — yet they use the same intent-driven, closed-loop approach.
The driver interfaces with the car by specifying its intended destination (the intent). Ideally, the driver is not concerned with “how” the car gets them to their destination. They only concern themselves with the “what”. And this interface is incredibly simple — you don’t have to steer, or brake, or accelerate, or decelerate. You simply enter your destination.
The car “machinery” is concerned with the “how” of getting you to your destination. And in order for the car to achieve this, it too collects telemetry, and continuously measures the actual state with the desired state making the appropriate adjustments to all the components involved — the steering, the engine or electric motor, the brakes, the suspension, etc. to match actual state and desired state.
In order to achieve the desired intent, a self-driving car measures hundreds if not thousands of parameters continuously in real-time and compares the actual state and desired state at an extremely fast rate of thousands of times a second for all those parameters.
And if the car detects a failure in a component or any other situation that prevents it from achieving the goal of ensuring that the actual state matches the desired state, then it detects an anomaly and alerts the user — in this case the driver, who will then need to intervene manually.
This machinery is truly an operating system for the car, enabling the car to act as one intent-driven system, operating all components — the engine, brakes, suspension, and transmission in a harmonic whole in service of user intent. And as is demonstrated from Intel’s $15B acquisition of Mobileeye, this type of self-driving technology is extremely valuable, and the way of the future.
A self-driving car is a lot more complex than a climate control system, yet the approach to automation is the same: intent-driven and closed-loop.
What if closed-loop systems didn’t exist?
It is interesting to consider for a moment how complex a thermostat would have to be to function without monitoring; without this closed-loop. It would have to compute how long and how frequently to run the furnace based on the thermal output of the furnace, the volume of the environment being heated, and the thermal loss/gain of the environment, a much more sophisticated and complicated device, further complicated if it also handles cooling.
This task becomes that much more complicated, if not impossible when you factor in equipment degradation and failure as well as variations in the controlled environment. In sum, without closed-loop, a relatively simple device like a thermostat becomes amazingly complicated to carry out your intent.
State of networking today
Surprisingly, this is where we are with networking today! Data center networks are highly complex and mission-critical. Yet legacy automation system approaches focus on helping users automate the complex minutia of the “how”. Telemetry and configurations have traditionally been disjointed, and there have been no attempts to close the loop in the context of network intent.
Well no longer. The Apstra Operating System (AOS®) is a distributed operating system for the data center network, the same way self-driving software acts as an operating system for the car. AOS delivers a self-operating network — enabling the user to operate their network at the intent level as one system as opposed to box-by-box.
You can now state your intent for the network e.g. “I’d like to connect 1000 virtual machines in the most cost-effective way”, or “I’d like to connect 5 compute racks, and 1 storage rack with 1Tb/s of east-west bandwidth”. Or “I’d like to create five groups, drag and drop endpoints into these groups dynamically, and set the policies using which these groups can communicate.” Once the network is operational, you can then make changes by stating your intent — “I’d like to swap a Cisco switch with an equivalent Arista switch”; or “I’d like to create a new virtual network”. In all cases, AOS takes care of the “how”, including generating cabling diagrams and specific configurations for all devices in the network. And AOS then validates through continuous closed-loop telemetry that your intent has indeed been realized.
We have been excited by the industry’s reception to the Apstra Self Operating Network™ concept defined in my earlier blog, and have seen other industry leaders concur, including Arista and Juniper, as well as industry forums such as the Stanford Computer Forum.
By deploying AOS, you gain the ubiquitous benefits of an intent-driven, closed-loop approach — applied to your own data center network infrastructure. As with the self-driving car and automatic climate control and our other examples, a self-operating network frees up your time to focus on what you want to achieve rather than how to achieve it. It also offloads you from the error-prone task of dealing with the minutiae of how, including across different vendors’ switches. And, it involves you intelligently when failures or other changes truly require your intervention.
The result is a more reliable and more agile network that demands far less of your time while providing you with all the benefits of a multi-vendor network.
