I blogged quite a while ago about “intent-washing”, the tendency to use the terms of intent models and modeling where that’s not really the story being told. Like all “washing”, intent-washing is driven by a desire to ride a positive news wave even when you’re not really doing exactly what the term means. Cisco is one of the most recent intent-washers with its “intent-based networking” but they’re far from the first or only of our washers.
Part of the problem here is that “intent” is perhaps a poor term to have chosen to describe the original model concept. As I’ve noted in several blogs, intent modeling is a form of function abstraction where a network or application is modeled as a series of interdependent functions, each of which are known by the properties (the features and interfaces) they expose while the specific implementation is hidden. Presumably these functions and properties are the “intent”, but intent in a strict sense is “intention or purpose”, and thus doesn’t convey the notion of a whole being assembled from modeled parts based on functionality. I intended to mow the lawn, so is it (or the mower) an intent model? The intent of a network is to connect, so does that make all networks that support what the user intends “intent-based?”
Cisco’s take on this is embodied in the introduction to the referenced Cisco document: “Intent-based networking is the difference between a network that needs continuous attention and one that simply understands what your organization needs and makes it happen. It’s the difference between doing thousands of tasks manually and having an automated system that helps you focus on business goals.” They also say “It allows you to continuously align your network to your organization’s needs.” From an implementation perspective, it’s a feature or property of Cisco’s Digital Network Architecture (DNA).
DNA, in my view, is best visualized as a distributed-policy system for controlling network behavior. There’s nothing wrong with that approach, in my view; certainly centralized policy control with local enforcement is a very reasonable way of achieving “software-defined” networking. It has plusses and minuses with regard to the other approach that’s gaining popularity—the overlay SDN model—but it’s easier on current infrastructure investment and offers a potential for deep service control integration. You can say that “intent” sets policies, which then define network behaviors.
Is this enough to make it “intent-based”, though? What I don’t see from Cisco is functional modeling according to intent-model principles, or model-driven service lifecycle management. Those are the things that I think really define intent-based networks, or at least what differentiates them from implementations that seem to say that you’re intent-based if you recognize intentions.
You might wonder whether I’m splitting hairs here, or whether I’m just picking on Cisco, but neither is the case. I believe firmly that a data-driven model of service lifecycle management, meaning service automation, is absolutely critical. Without that, I do not believe that we’ll make significant strides in dealing with the additional complexity that virtualization necessarily brings to all things networking. A data-driven model is a way of describing intent-based functionality, and by this I mean real intent-based functionality.
This intent-washing thing is also demonstrating a problem we have in the industry, which is the growing gulf between the technologists who are bringing us new and critical concepts, and the whole process of buyer education and enlightenment, from the media/analyst community right down to the person who signs the checks. People can’t adopt what they don’t understand, and it’s fair to say that the vision I’ve advocated for service management and intent modeling isn’t one that’s easily understood. That lends itself to casual omission of the details that are critically important.
Education in the details isn’t something that vendors are happy to help users with overall. I’ve noted as recently as yesterday’s blog that the larger and more successful network vendors are incentivized to stay the course with technology based on the reasonable argument that’s where they’re winning. Why promote revolution if you’re the one in power? This is another reason why “washing” is popular and at the same time destructive. If you think you’re getting the future technology from your vendor because you see the terms you recognize, and if you can’t understand the details, then you are lulled into believing you’re ready for what’s to come. Maybe you aren’t.
It’s not terribly difficult to create real intent-modeled networks. We have standards like TOSCA that can describe them fully as intent models. We have guidance from people like the TMF in how to use intent-modeled data structures to create event-driven implementations of service lifecycle management that are both resilient and fully distributable. We know how to build current technology into these futuristic models. Or, perhaps I should admit, some know those things. You can get a better look at “real intent” in a network-centric model-driven form (TOSCA) from Cloudify or Ubicity.
Another truly interesting source for a more general software vision is Avi Networks. Avi has what’s essentially the same policy-based, intent-driven, approach as Cisco but it also has all the software elements needed to deploy network applications in an event-driven form. Avi defines their progression from the perspective of a “declarative model” but they don’t provide much detail on what the model looks like. If they had that, I’d say they were a formula for successful building of generalized intent-based software, not just network software.
The full execution framework is important. My early projects in networking were state/event oriented but were based on the architecture of the time, which was a monolithic application and an event queue. Avi takes event processing to a microservice level, and includes the ability to scale software and load-balancing to millions of transactions per second. I’d like to see Avi get more detailed on its declarative modeling and state control. I’d sure like to see somebody build a service lifecycle automation system based on the Avi platform’s principles or the platform itself , because (if they have the right modeling) I think they have all the pieces to do what’s needed.
One reason I’m bringing Avi up here is that Cisco is an investor in the company. Perhaps we can expect Cisco to do a management system using their technology, but Avi’s also a partner with Nokia/Nuage, and they could learn some techniques from Avi’s approach too. Somebody will have to build model-driven networking around Avi, rather than use a more architected strategy like Cloudify’s or Ubicity’s, but I think the result would be very interesting. Cisco, Nokia/Nuage? Want to start a service automation arms race? Here’s your chance!