James Sherlow, senior systems engineer at Avi Networks, discusses the rise of intent-based automation
IT is suffering a crisis of scale. In days past, managing IT was a human-scale job. It was taxing (as any IT person will tell you), but you could at least hope to get your arms around it. Now, with hundreds of applications running across thousands of containers and virtual machines, we’ve created infrastructure that mere humans can’t realistically tend anymore. There aren’t enough IT people to manage applications and infrastructure in real-time. There’s too much happening, too fast. Enter automation.
For the most part, automation has been and continues to be imperative (input-based). That is to say that the automation needs to be meticulously scripted based on predictable events. You still have to make all the decisions. This type of automation functions only based on human-crafted scripts and playbooks. It’s like configuring a smart light with Amazon Echo and saying, “Alexa, kitchen lights on”. It’s cool — maybe even convenient — but it isn’t that much better than flipping the switch manually. Imperative automation is a step in the right direction, but leaves a lot to be desired.
For example, let’s say developer 1 is requesting compute resources. Traditionally, developer 1 would submit a ticket and the IT organisation would spin up the necessary resources and services. This process may take a couple of days. Imperative automation could script actions based on trigger events. “If developer 1 requests XYZ, provide XYZ.” This takes a lot of scripting and APIs with your infrastructure, security, and application services systems. This can work, but what if developer 1 requests ABC? Or what if developer 2 has a request? You have to make decisions for each scenario and craft automation scripts for each—creating a lot of additional work for IT organisations.
Navigating intent-based automation
To compare input-based automation and intent-based automation, I like to use the analogy of self-driving car. An input-based car would script out each step and each variable… “start the engine, press the brake, put in reverse, release brake, accelerate to 5 mph while turning 45 degrees to the left for 15 feet, brake, put in drive, rotate steering wheel 90 degrees to the right…” And then hundreds of new scripts need to be written for various road, traffic, and weather conditions. Alternatively, an intent-based system is context-aware so all that needs to be stated is “drive home” and the self-driving car will figure the rest out and make the best decisions while adhering to the rules of the road and reacting to all the conditions around the vehicle.
Key criteria
More and more solutions are using the phrase “intent-based” to describe their services. For anybody to make that claim, they need the following:
Closed-loop analytics — Information about applications, infrastructure, network, and end-users all provide context so the technology can deliver on intent. Humans can’t make perfect decisions with partial data, neither can intent-based technology.
Infrastructure independence — Automation works best when it isn’t siloed within a single environment. As enterprises rely more on hybrid and multi-cloud infrastructure, they need to find automated solutions that are delivered consistently across these environments. If your intent is to work across multiple environments, don’t rely on platforms or solutions that are opinionated about how or where they are deployed.
API-driven integrations — Enterprise tech stacks in data centres and clouds are becoming increasingly more complex. In order to apply automation across the tech stack, these services need to integrate with each other. If there are solutions or services that don’t play well with others, they will be a stumbling block in your quest for intent-based automation.
Automating automation is the only way enterprises will be able to scale their IT operations to support the business. It’s time to abandon the input-based approach and adopt solutions that can deliver on your intent.
