Chris Lauwers is one of the thought leaders on the TOSCA standard, and he has a nice blog on the way that TOSCA might fill the role of defining intent models. I’ve advocated the use of TOSCA and also the use of intent models in both SDN and NFV, and so I want to look at what Chris proposes and align it with what I’m seeing and hearing from operators. I think he’s on to something, so let’s start with defining some terms and dig in.
TOSCA standards for “Topology and Orchestration Specification for Cloud Applications” and it’s an OASIS standard that, as the name suggests, was created to describe how you would orchestrate the deployment and lifecycle management of cloud applications. I think the fact that NFV is a “cloud application” set is clear to most, and so it’s not surprising that vendors are starting to adopt TOSCA and operators are starting to think of their own service modeling in TOSCA terms.
An “intent model” is an abstraction of a system that describes it to its users by describing the properties it exposes and not by the way those properties are achieved through implementation. The ONF, which has been moving to intent models (influenced by another thought leader, David Lenrow, now at Huawei, and described in an ONF blog he did) says that they define the “what” rather than the “how” of a function.
TOSCA has what I think is the critical property for the proper expression of intent models, which is that it can define a model hierarchy where something abstract and functional can be decomposed (based on defined policies) to one of a number of possible substructures, all the way down to the point that what you’re defining is an application deployment, or in this case a VNF deployment.
If we accept the idea that TOSCA is a natural fit for deploying virtual functions because they look like applications, the question is whether it could be used to define intent models where there was no cloud deployment, and the answer to that is “Yes!”. Since TOSCA expects to be able to control SDN it’s perfect where an SDN controller can be used to control legacy elements and probably (with perhaps a little diddling) everywhere.
A great program for drawing organization charts won’t organize your business, and so with TOSCA or any other service model you still have to decide what exactly your model should look like. We’ve had relatively few discussions on this point, unfortunately. Once you know what you want, you can apply modeling principles from things like TOSCA to get you there. Do we know what we want?
As Chris points out in his blog, we need to visualize services as a hierarchical model, each element of which is an intent model that could decompose arbitrarily into a string of other models, a cloud deployment of VNFs, a management API call for a legacy network configuration change, or whatever. The openness of the approach doesn’t depend on the mechanism alone, though; you have to define your model correctly.
As a general rule, two different intent models are not interchangeable unless they were built from the same template and neither extends that template. Since an intent model is used based on its exposed properties, anything that exposes exactly the same properties is (normally) interchangeable. This means that if you define a template for the functional class “firewall” and if everything that implements a firewall conforms to that intent model template, you could presume them all to be interchangeable and your approach to be open.
If you define two intent models for “firewall” that do not expose the same properties, then obviously you can’t substitute one for the other, though you might be able to create a super-model above and harmonize the two different implementations there. Given this point and the one above, it would make sense to start your model-building process (with TOSCA or another suitable approach) by laying out these super-models or function class models. An implementation could then be based on that template, and if a given service had to accommodate multiple implementations of a single model, you could avoid having to re-spin the service model by having the super-model pick the proper lower-level model based on whatever criteria was appropriate. This is how you could deploy one kind of firewall in one area and another kind elsewhere, reflecting perhaps whether you had cloud hosting available, CPE hosting available, or had to send a real firewall device because nothing else was available.
It seems to me that this illustrates the importance of what in software (Java) would be called defining functions in terms of “interfaces” which are then “implemented” or “extended”. If you start at the top and say that services are created from features, you could start the service model with intent models that describe these features, then look down a layer at a time to define new structures and eventually implement them on suitable resources. If you follow this approach, then it’s relatively easy to map what you’re doing to TOSCA.
The notion of what Java calls “interfaces” is common to modern programming languages, and the fact that it’s applicable to SDN and NFV and to service modeling suggests that we should indeed be looking more at service models and orchestration from a software design perspective. It also shows that it’s really important to create the higher-level models correctly, by dividing services into “commercial feature components” and then defining those components as lower-level network functions. Each high-level element defines the properties that service architects (or users through self-serve portals) would “see”, and that each decomposition/implementation would be expected to deliver.
A service-model approach has to be more than a jazzy name. When you’re using service models, you are processing models in software, which is a different way of looking at software than the traditional flow-and-component approach. For example, the proper way to consider an “event” in a model-driven approach is that the event is steered via the model, not “sent” to a process through an interface. In fact, the software interfaces to operations and management processes should be defined in the model and opaque to those who use it. If you can define a model (in TOSCA, for example) that establishes a link to a software process using the native interface for that process, the application is no less open than one that uses a standard interface. What you have to focus on standardizing is the event, meaning what it represents and how the information that describes it is structured. Since an intent model has to define events it receives from the outside as part of its properties, that shouldn’t be an issue.
The issue of events and flows, and the nature of interfaces, is critical not only for data-modeled services but for SDN and NFV and operations orchestration and automation. The world is not a synchronized process—stuff happens. It’s very difficult to automate the operations of anything unless you accept that what you’re automating is the response to events.
From a data-driven software perspective, the functional model published by the NFV ISG is weak because it doesn’t specify an event-driven process. If you are interfacing between processes and not through data models, you’re not model-driven. By providing functional blocks linked together with interface points, the ISG has encouraged a literal translation of the functional into software structure. That leads to a serial workflow vision that, in places like OpenStack Neutron, has known limitations. It’s not that the ISG mandates the wrong thing, but their description has led many astray.
The TMF, interestingly, is supposed to be promoting the right thing in its latest evolution. The “Platform Economy” announcement just made is supposed to be an evolution of the original NGOSS Contract work that I’ve long said was the seminal development in operations automation. The NGOSS Contract was data-model-driven relative to event-to-process coupling, but it’s not been widely implemented. The TMF article I referenced here doesn’t describe a model-and-event approach either, but some of my operator friends tell me that’s what’s intended. I’m trying to get the TMF to release something about their initiative so I can blog on it, and if they do provide something that’s open and public I’ll do a detailed analysis. If it’s heading in the right direction it could be a positive for an event-driven approach, but of course TOSCA is already there and the TMF might still take years to get their latest approach finalized and implemented.
It’s been almost a decade since the TMF’s NGOSS Contract work launched respectable consideration for a framework of software automation of operations and management processes and we’re not there yet. TOSCA, at the least, can show us what a modern event-driven model looks like. At most, it could deliver the right approach and do it right now. That would save a lot of operator angst over the next couple years.