In 1986’s Star Trek IV: The Voyage Home, Scotty blithely picks up a mouse from a 1980’s Macintosh and attempts to speak instructions into it, expecting the computer to follow them implicitly.
Good for a laugh back in the day to be sure, but today, we’re surprisingly close to realizing this vision for computing.
The voice control part of this story is now de rigueur, of course, with Alexa and OK Google now part of our collective consciousness. More challenging, however: how does a computer understand and act on the intent of the user?
Intent-Based Networking Sets the Stage
The networking world has already tackled this thorny question. Faced with network configurations that consisted of dozens and then hundreds or even thousands of separate, arcane instructions, leading networking vendors developed Intent-Based Networking (IBN).
With IBN, the instruction consists of the business intent for the network – say, ‘deliver error-free video to our conference rooms’ – and then the IBN infrastructure translates that intent into the specific technical configurations that drive the necessary network behavior to achieve it.
However, there is one important additional element of IBN: assurance. It’s not good enough to configure the network according to the business intent at one point in time. The network must also continue to deliver on that intent into the future, even though other changes may also impact the network configuration over time.
In other words, the IBN infrastructure must continually check that the network is still meeting the business intent, and if it isn’t, then it must automatically take steps to bring the network back into conformance with that intent.
From IBN to Intent-Based Computing
While IBN is rapidly becoming an established networking best practice, for those of us outside the networking world, what we really want is to control computers the way they do in Star Trek, am I right? Express your intent and let the computer do all the work.
To achieve this admittedly lofty goal and go where no one has gone before, we must generalize the principles of IBN to the broader notion of Intent-Based Computing (IBC). Given the limitation of this Cortex newsletter, I’ll constrain this discussion to three areas: intent-based infrastructure configuration, intent-based application creation, and intent-based customer experience.
IBN is a special case of intent-based infrastructure configuration. Can we express the business intent for, say, our public cloud account or Kubernetes deployment, and then expect it to conform to that intent?
What will it take to be able to say, ‘OK Kubernetes, give me an environment that can run my big data analyses at scale,’ and then have it comply with that intent – and provide assurance it will continue to do so as my data sets change and other people in my organization call upon my Kubernetes instance to do other things for them?
Intent-based application creation, in contrast, is a natural evolution of low-code/no-code platforms. Most of these platforms already give application creators the ability to express the behavior of their applications declaratively – an important element of any intent-based approach.
What’s potentially missing from the low-code/no-code picture is the assurance piece: once the creator has deployed their app, is the platform able to guarantee it behaves as the creator intended, even as inputs to the application as well as the overall application environment change?
Of the three intent-based approaches, then, intent-based customer experience is perhaps the most fascinating, as it provides a consumer context we can all relate to. If I ask my phone to order me a milkshake, is it able to identify which milkshake store I’m next to? Does it know based on my past behavior that I want chocolate?
Autonomous driving, in fact, is on the bleeding edge of intent-based customer experience.
If I’m driving and I turn the steering wheel to the left, the car knows my intent is to turn left. But when I tell an autonomous vehicle my destination, it has to translate that intent into all of the various individual commands that drive the car, while taking into account all of the continually shifting environmental factors, in real-time.
Furthermore, if the vehicle has to take an unplanned detour or suffers a malfunction, it must be able to get back on track – an example of assurance.
Breaking Down Intent-Based Computing
If you look closely at what IBC vendors must actually do to comply with the user’s intent, it becomes clear that there are different approaches to achieving the goals of this new technology. However, if we roll them up and generalize them, certain patterns emerge.
Following this approach, here are the six essential components of any IBC strategy.
- Translate intent into machine-interpretable policies and constraints. A policy describes the specific functionality that would constitute the intent, while constraints act as ‘guard rails’ that keep the intent from instructing the system to do something that would take it off the rails. If the intent were to configure a cloud instance to run a particular application, the policies might include the specific provisioning parameters (instance type, memory, database, etc.), while constraints might keep the deployment from costing too much.
- Model the intent. Implementing business intent never works in a vacuum. Rather, it’s important for the IBC platform to understand the context for intent based upon an abstracted model of the overall deployment. What are all the other requirements for the system beyond the specific intent of the moment? How do all of the elements of the environment impact the ability of the system to comply with the intent of all relevant users, not just one of them at a time?
- Validate the intent. Is complying with the intent feasible given all of the factors in the model? If not, does the system require further information from the user or some other source? Are there conflicting instructions that would be impossible to comply with simultaneously?
- Implement the intent. At this point the system will have executable instructions that it must put into practice via new configurations or the deployment of software, which it must be able to handle in an automated fashion.
- Orchestrate the intent. Concurrent with implementation, the system must coordinate and sequence the necessary interactions across the various components of the environment to insure compliance with the intent. Think of the autonomous vehicle: intent specifies the destination, while the AI in the vehicle has to break that intent down into all of the various actions it must take at the right times in the right sequence in order to get to the destination safely.
- Assure the intent. After all the other steps are complete, the system must continually validate that it remains in compliance with the intent, and it must take any steps necessary should it deviate from that intent.
Of all of these priorities, assurance is the trickiest. How frequently should it check for compliance with the intent? How much deviation is acceptable before a mitigating action is called for? A simple example: how much can a workload exceed its capacity thresholds before the system triggers an autoscaling event?
The answer will depend upon many factors, including the intent itself, the cost of compliance, as well as the performance impact of the assurance. If the assurance activity itself is so processor intensive that it bogs down the overall performance of the system, then clearly the system won’t be able to effectively implement the desired business intent.
The Intellyx Take
There’s no question that IBC is a complex challenge. That being said, and given that AI will drive many of the steps, there is really nothing I’ve described in this article that is beyond the current state of the art. Vendors simply need to step up to the plate to assemble all the pieces.
One interesting effect of IBC: it will disrupt the entire notion of the infrastructure service-level agreement (SLA). Instead of expressing a business priority of, say, 99.999% uptime, the business will instead expect the system to comply with its intent. The SLA question will therefore focus on the specific assurance parameters, like how long between checks that the system is in compliance with the overall business intent.
The entire notion of ‘five nines’ uptime, after all, is a relic of the pre-cloud days. Today we’re more likely to focus on resilience metrics like mean time to restore (MTTR). IBC provides an end-to-end approach for specifying and complying with such metrics – not just for infrastructure, but for application behavior and customer experience as well.
In other words, expect IBC to be the primary approach for modern IT to deliver value to the business in the digital era.
Copyright © Intellyx LLC. Intellyx publishes the Agile Digital Transformation Roadmap poster, advises companies on their digital transformation initiatives, and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credit: Matt Brown.
