You probably know how fond I am of classic quotations. One I’ve always particularly liked is in Latin: “Quis custodiet ipsos custodes”, which translates freely to “who will watch the guards themselves?” We might be heading for a knock-off of that in zero-touch automation (ZTA). How do you like “who will orchestrate the orchestrators themselves?”
The issue here is actually related to another old saw: “You can’t see the forest for the trees”, which reflects on the problem of tunnel vision. Focus on details and you lose the big picture. Logically, ZTA means you have to orchestrate every aspect of service lifecycle, which you might expect would mean a single approach with that goal. Not so. With ZTA, we have two powerful drivers of tree-focus, one the desire of vendors to get something out to sell quickly, and the other the tendency of standards bodies to create little enclaves of activity, one for each body. Thus, we are likely to end up with an embarrassment of ZTA riches, in quantity but not in quality.
Despite the trends, there’s considerable question as to whether ZTA is meaningful if it’s applied only to a tiny piece of the service lifecycle process. We already have plenty of tools that automate a few routine tasks to the point where human intervention isn’t needed. Every data center or network operations script does that, every system that responds to any event does it too. The problem is, and has been, that a service lifecycle is a complex sequence of things that have to be done, and to get one or two of them done without a human intervening only means the human has to figure out where the automated process left off, then pick things up. That’s likely to be a lot of touching.
We actually sort-of-have a solution to the problem of tree-focus in ZTA, which gets back to orchestrating the orchestrators. It’s intent modeling, if properly applied. An intent model is a black box abstraction of a component of something, like a service. The intent model represents the “something’s” intent, meaning what it does. It’s inputs and outputs are defined, but the interior of the black box that contains the implementation is up to the implementer. Any two implementations that satisfy the intent are equivalent.
What makes this important for orchestration and ZTA is that you could have a bunch of dissimilar orchestration or ZTA models living inside an intent model, and they’d be just like each other and anything else. Tiny functional pieces could be orchestrated as “trees” while a higher-level, intent-modeled hierarchy could orchestrate the forest.
Most of the modeling work now being done isn’t working this way, of course. There’s a tendency to focus on what happens inside one of those functional black boxes. That may build a bigger tree, but it still doesn’t look at the service as a holistic forest. Perhaps the reason for this bias is that vendor and even operator attention has focused on low-apple, easily justified, automation projects rather than on creating a broadly useful/efficient approach.
Part of the issue is also jurisdictional, meaning that many standards bodies see themselves as focused on a specific task. ETSI’s own recent ZTA efforts are, in my own view, slaved to the NFV activity that declared its own operations model out of scope. In other words, NFV plus ZTA equals an actual solution. Except of course that very little networking or hosting is NFV. Those bodies that have broad missions for modeling, like the OMG, tend to be regarded as abstract pie-in-the-sky kinds of people. Sad, given that abstraction is actually what we need to have here.
Call me a radical, a heretic, but I think the biggest problem with intent modeling is the dogma of modeling languages. I happen to be a fan of OASIS TOSCA as a vehicle for defining intent models, but I’ve also used XML to do the same thing and it’s fine. Intent modeling is a principle, and while there may be benefits associated with any particular modeling language over others, as long as one fulfills the requirements of expressing the “outside” of the box and identifying the implementation automation or orchestration tool used to fulfill intent on the inside, it should be fine. We need to be looking at what the outside/inside requirements are in abstract first, and then worrying about the language to express them in. The majority of people I’ve talked with in both vendors’ and operators’ organizations admit that they don’t see that kind of discussion happening today.
A set of inside/outside requirements, stated in plain language, could provide the basis for judging how well a given modeling language would work in conveying the necessary information. You could do a trial expression of various services and models using candidate languages, and the result would provide a means of comparing them. If we don’t have that plain-language start, how do we know what we’re asking a model to model?
Here’s an example. Take a “model” of a firewall function. We could express as the interfaces, three options: Port, Trunk, Management. We could express for each of these the interface type (IP Data, CLI Text, SNMP, whatever), and we could express for structured APIs like SNMP the model reference for the structure. If we liked, we could provide a Rule interface and structure what we expected a firewall rule to look like. If we have that, we could then translate each of our “from-the-outside” interfaces to a modeling language. We could also then say that if we had an inside rule that “realized” the function through a call to another orchestration process, we’d have an implementation of “firewall”.
The implementation might be a further decomposition into a set of lower-level models. It might be the orchestration of a uCPE deployment, or an automatic order generation to ship a physical device to the user. Thus, we could use this approach to tie together disparate orchestration/ZTA initiatives to create a complete service lifecycle automation strategy. Orchestrating the orchestrators then becomes a path to ZTA, and also a set of requirements for modeling languages that might be helpful in ZTA overall. Those that can’t describe this process can’t do multi-tree forests.
Another critical piece of this is the contextual orchestration of service lifecycle tasks. Rarely does one thing not impact others in a complex service, which means that an intent model has to have “states” and “events”, and these have to be organized to coordinate activities across various pieces of the service during changes in state, due to service change orders from one side and faults and reconfigurations from the other. The modeling language also has to be able to express states and provide a means of linking the state/event combination with a target process set. As I’ve said many times before, this is what the TMF’s old “NGOSS Contract” approach did (a TMF insider said in a comment on another of my blogs that the TMF might revive NGOSS Contract, which was rarely implemented).
You can do state/event descriptions in abstract too, using text in a table. That means that we could go a long way toward defining a good intent-based lifecycle automation system without getting jammed up in the specific modeling language. In fact, I think it means that we should. This whole process of intent modeling is getting jammed up in a religious war over models, delayed by a bunch of people waiting to develop modeling language approaches. First things first; let’s decide what kind of forest we want before we start planting trees.