Winding down 2016, I’ve participated in a few conferences, KubeCon / CloudNativeCon and the Gartner Data Center Infrastructure conference. I’ve also worked on the acquisition of AppFormix by Juniper to give us a leg up in cloud analytics based on big data and machine learning. The sum of my learning and conversations piqued my analysis and skepticism with some commonly encountered and complementary hyped topics:
- Intent-driven infrastructure/networking
- Machine/deep learning-based autonomous infrastructure
- Self-driving infrastructure/networking
- Declarative infrastructure and infrastructure as code
With more freshness and luster than the long-in-the-tooth SDN, NFV, cloud, XaaS, all of these topics are already well-traveled and racked up millions of blog and PowerPoint miles in 2016, but often I see these topics and terms conflated or interchanged like they are the same thing.
Based on my recent discussions at the Gartner conference and some of the networking pundits I read, the most anticipated and highest form of infrastructure enlightenment is intent-driven infrastructure. This is mostly covered as intent-based or intent-driven networking in my circles, but it certainly can be applied more broadly as an approach to systems. Unfortunately, “intent…,” in my observation, is the term with the most offenders misusing it, abusing it, substituting it or mixing it with terms like automated, policy-based, declarative, or smart/intelligent infrastructure.
Embellishments and lofty labeling aside, I believe the term “intent” is easily and often abused because it is a precarious business to understand intent at all. With the way I use the word “intent” normally, doing something based on intent, seems like it could be exercise in mind reading.
If you’ve seen that, and scratched your head, then you’re not alone. Seeking to better understand this myself, I undertook a journey of reading and research, but especially looking at intent in its truer form studied in psychology. In this blog, I suss out a few of the difficult aspects of understanding intent, searching for key tenets and considerations for constructing an intent-based and -driven technical system. However, instead of keeping it all technical, I look for support of these traits from reflection on and inspiration from the traditional intention of intent.
What is intent?
A logical place to start is in defining and really understanding the terms.
When one reads about intent, we find the dictionary definition, of one’s purpose or meaning. Have you ever been on the bad end of a miscommunication where the intent didn’t come across properly? It happens all the time because intent is generally communicated as much by what we don’t say and don’t need to consider as much as what we do express. Miscommunications and mistaken assumptions won’t do for technical applications unfortunately.
So can we apply intent or user intent to technical applications? Certainly not the general way that we define intent because intent is never outwardly expressed. Rather it is the internal precursor to what we say or do, or even more generally who we are. Nevertheless, technocrats are well-practiced at making inspired metaphors, so let’s go with it, and find out what we can usefully borrow from what we know of intentions in their true forms.
Studying intent a little deeper with the help of psychological research, we find out where intentions come from and some description of the unspoken context that makes up intention. Here’s a snippet lifted from Wikipedia, where there is copious more detail if you’re interested.
“intentions to perform the behavior appear to derive from attitudes, subjective norms, and perceived behavioral control.”
From this we can say a few things about the context surrounding intentions:
- Our intentions are shaped by the state of our attitudes (which may be capricious)
- We don’t usually intend to act outside of social norms, especially not outside of the law
- We don’t intend to act beyond our perceived capabilities and knowledge
What is intent-based and intent-driven?
To apply the idea of intent to a technical system, these two terms come up in recent language: intent-based and intent-driven.
When I hear these, I think of configuration in different regards.
With respect to intent-based, we can say that the basis of the system, that is foundational, more static configurations, should be in the form of user intent.
With respect to intent-driven, we can say that ongoing execution and more-dynamic control should be in accordance with user intent and the intent of interfacing systems that help “drive” the system. For technical applications, I take this to mean that how a system’s own APIs, self-feedback loops are interpreted and oriented are also re-configurations aligned with intent-based user configuration and intent of other system actors.
Of the two terms, let’s continue with intent-driven because it encompasses intent-based.
Expressing Intent to Technical Applications
Using the abovementioned definition and understanding of intent we can translate some the findings to come up with key tenets for intent-driven systems and their configurations.
If intent is a purpose or meaning behind a behavior, then it isn’t the behavior itself (words, actions…). It’s the meta behavior. It’s inherently abstract in the what, and doesn’t really consider many details of the how or the motives of the why, but will certainly have contextual requirements for the why, what and how. I believe the when, where and who, are usually abstract considerations as well, if not even explicit in our intentions, but this varies.
The first thing that falls out of this in many people’s observations is notion of something abstract.
Since in human communication, our words and actions closely approximate the intent, but we abstract away unnecessary detail, we can say that abstraction is an important aspect to translate to technical applications of intent.
Abstraction isn’t a new desirable tenet of technical systems neither. We talked about it for years as a desirable aspect of SDN systems in the networking industry. Abstraction is a double-edged sword however.
Abstraction allows us to encapsulate and hide detail which provides flexibility. Losing specificity, however, introduces unpredictability. Unpredictability and variability in the nature of acting out our own intentions is exactly why miscommunications happen. It is also why many of us never achieve our intents. Another interesting point borrowed from the psychology of personal development, is that a lazy man has intents, and an achiever has goals. When it comes to goals, the more clarity, specificity and measurability, the more likely we will follow through on course.
The difference with technical systems is that there is no question of follow through or execution in other words. Systems execute, and don’t have lazy days. The value abstraction provides is that for a set of abstract user input we have many ways to achieve a result without changing the input or its form. This flexibility is important because it allows us to avoid lock-in and innovate, creating new ways to get the same result. New and different results, however, that still meet the abstract intention, may or may not be so welcome, so we need to strike the right balance of abstraction and very likely ascend to grander abstractions in layers… more on this below.
Moving on, if we have to express the meta behavior, the intent, directly, then we should not specify the how, but rather the where, when, who and especially what. An intent can certainly embody these things, and of course systems deal in these too. This important aspect, points us to adopt the virtues of a configuration that is declarative for technical applications, as opposed to imperative directions that control the detail of the how.
We also learned that our own intentions are guided by subjective norms and law. If we had to expressly communicate those for a technical application, this translates to policy-oriented configuration constraints. Subjective norms may also change based on the environment, time, actors, etc. It would be useful if these variable norms, could also be policy adjustments resulting from the insight of self-learning technology with or without human verification.
When it comes to human intentions restricted by the possible and capable, I think the technical translation easily points to what is programmed and resourced for the system. I don’t think this is a key tenet by any means because it is so obvious. Interestingly, some technical systems can grow new capabilities through extensibility or training, and those new capabilities are basically new programming, and we would likely have to reshape the form of the input intent to take advantage of them. This is similar to how we change our own intentions based on new knowledge and capability.
What about our intents being shaped by our attitudes?
Just Deal with It
How could an attitude bias inspire a technical translation? Attitudes are our internal states, moods, feelings. Systems have internal states as least. This aspect could be simply mean when executing a system to realize an intent, there is a consideration of the internal state of the system.
Have you ever had to do something when you were tired, sad, frustrated? Sometimes humans also intend to achieve things that are in conflict with our own attitudes, and even require us to change our attitudes. This is kind of like a system dealing with its own internal state and feeding that back to itself to carry out the intention in spite of its state. To me this reveals, an interesting tenet of the inter-workings of an intent-driven system. They should be self-aware of their ability to meet their purpose using real-time telemetry and analytics about its own performance, scale, and productivity. They should automatically pace, scale, and heal themselves in accordance with the input intent they accept.
Architecting Intent-Driven Systems
Above, we covered where, when, who, what, and how, but not the why of an intent, and yet an important aspect of an intent is that it also embodies the why, the purpose or meaning behind. It’s not something we are as used to thinking about for technical applications. When we look at the why of any real intention we have, we can get another intention and can recursively ask why again, until we climb up to our core worldview, morals, values and beliefs. Taking inspiration from that, points us in the direction that I hinted at above when I mentioned layers. A system that is acting on an intent, is really just focused on a single purpose, but often in service of a larger purpose. This points us to architecting our systems with composability, and decomposing systems into services, subservices, and micro-services insofar as we can still clearly define small purposed systems without getting into the minutia.
Where to Start
There is a lot of intent-driven research and development happening in networking, but really that is a bad place to start thinking about intent overall because as above, when we ask why, for an intent-driven network system, we ascend to the higher level. There is no network built out of the intent to build a network, except as a pure science project. Intent never describes a network, intent designs connection and has explicit or implicit criteria like security norms, latency and bandwidth.
Of course that intent is in service of a larger intent. If we keep asking why, we will ascend to what is really of value. If we take an Enterprise as an example, the value a business gets from technology is derived from applications. Infrastructure and network connection is down the chain of value and intent past the apps and their development and orchestration systems that manage the infrastructure and connections they require.
In short, looking up is the best place to start. If a system is down the value chain, we need to consider what will encompass it. Generally, that points to the application stack first, and second to the ITSM or I&O management tools that should take business policy and governance intent as additional constraints.
In Summary
After a closer scientific look at intention, I’m now a lot clearer about intent-driven systems. We’ve extracted a few key tenets about intent-oriented system configurations and intent-driven systems themselves.
While there are values to each one of these aspects individually, it is only when applied collectively that we can really say intent-driven. So if we go and make intent-driven systems are customers going to be clamoring for them? It is worth a lot of the hype? I don’t think so. The systems developers will get value in organizing this way, but the users are never going to get out of bed in the morning and say to themselves, “I’ve got to get an intent-driven X.” Users and businesses are always going to be sold on meeting their own higher intentions.