What exactly is a PaaS in function hosting? I mentioned the term and concept in my Thursday blog (https://blog.cimicorp.com/?p=4162) and I got some questions from my contacts and clients. What I’d like to do here is summarize the notion of PaaS (Platform-as-a-Service) in function hosting, in part to prepare for what I hope will be more detailed exploration of the CableLabs/Altran Adrenaline project.
In cloud computing, a “PaaS” is a cloud service that’s based on a platform that includes not only an operating system but also middleware, so that the service looks like an application platform of the sort you’d write code for on a PC or server. In function-hosting terms, that would mean that a function host would assert a set of APIs that would expose useful function-hosting and service-creation features.
The classic vision of function hosting, from the ETSI NFV project, is that you have a set of external interfaces that define the information flow among discrete components of a hosted function or a function orchestration and management system. The software you use in either case is pretty much free to work as it likes as long as it connects through these interfaces.
This has proved somewhat-to-largely ineffective in the real world. First, the virtual functions have too much freedom to define how they work, how they’re managed, how they’re parameterized, and how they deploy. Since VNFs were presumed to be sort-of-transported physical network functions, meaning extracted device logic, that flexibility assisted in making VNFs available, but it made it impossible to frame a standard means of deploying and managing them. The “onboarding” process, the conversion of function software to running VNFs, was almost a per-VNF systems and software integration task.
Too many unconstrained variables create operations chaos, so the obvious answer is to start constraining them. One step to do that is to mandate container use, something that’s already sweeping cloud computing and even data center applications. Containers are a kind of canned deployment framework, one that presumes a specific way of deploying and connecting related elements. This can then be combined with an orchestration tool (and Kubernetes is the de facto industry standard) to simplify operations.
The problem with containers and Kubernetes for virtual functions is that the latter introduce a requirement that traditional applications don’t have. We don’t expect every implementation of CRM or ERP or payroll to work exactly the same way, but every implementation of a given class of virtual function (like “firewall”) should in fact work the same way so that the deployment and operations practices are standardized for the class. This is where the notion of a PaaS comes in.
All network devices could be said to deliver functionality at three levels. There’s the data-plane stuff where bits are pushed here and there. There’s the control-plane stuff that supports cooperative behavior of systems of functional elements by providing a means for them to communicate. Then there’s the management-plane stuff that allows for control of devices, networks/systems, and services. If we could define some specific APIs that would define all these layers of behavior, we could then take a powerful step toward operationalizing complex combinations of devices and hosted functions/features. That would define a PaaS, or more explicitly, a “VNFPaaS” or (more generally) a “VFPaaS”, since some of the functions are likely not to be specifically network functions in the NFV sense.
Having this kind of VFPaaS would also facilitate portability across devices and migration or scaling of functions between the user edge, carrier edge, metro, and even deeper. If virtual functions talk to their hosting hardware via a set of APIs, anything that can assert these APIs looks like any other function host. This is what I believe Adrenaline does, at least to a degree. The obvious question is how one defines a VFPaaS in the first place, meaning how the APIs are selected and then detailed for use. One way is to follow a convention that’s not only popular in programming, it’s built into application-modeling tools like OASIS TOSCA. That’s called “inheritance”.
In Java, you can define an object called an “interface”. This definition describes the inputs and outputs, meaning the API, of the object and at least references its function or purpose. We could define, in our VFPaaS, an “interface” object called “virtual-CPE”, for example, to describe a general device that provides some inline network functionality at the user end of the service demarcation. But that’s not all. We can (maintaining Java reference) define another object that extends our first one. Say now that “firewall” is a subclass of “virtual-CPE”. The properties of our new object are additive to those of the object it extends, so those things that are common to all virtual-CPE are provided in firewall.
The value of this in defining a VFPaaS is that if you start “extending” your basic elements, you could learn a lot about what your VFPaaS should look like. One thing we might learn is that our “virtual-CPE” isn’t high-level enough. There’s really another level above it, one we could call “virtual-data-plane-element”, that represents anything that serves as part of a data plane of a network. This is a useful piece of portability insight.
We can also learn that there may be two (or more) “inheritance trees”, and my virtual-CPE example demonstrates this potential. We have our virtual-data-plane-element, that we now see could be “hosted” on a virtual-CPE element. That means that we should have a dual set of base objects, one representing the “function” and the other the “platform” or “hosting”. A given virtual function always exposes its own APIs, but what it’s hosted on also exposes a set of APIs that permit that particular thing to be managed. A CPE “platform object” would present a customer-facing management interface, where one embedded in the network would likely not.
The APIs needed for VFPaaS can be determined by cataloging the features of the “platform” that the full set of service/function objects consume. This lets us build an API set that fully supports the virtual functions, standardizing how they interact with their environment, and also how they interact with any general provisioning or management features.
Why “redefine” things at all? If everything that’s a virtual-data-plane-element has (for example) the same basic API, differing only in how it’s parameterized, why define a “firewall” or a “switch” or a “router” as subclasses? The answer is that we could presume that all “firewalls” should be freely substituted for each other in a service, but not a “firewall” and a “router”. We may then want to make it impossible, through modeling or composition tool features, to make these illogical substitutions invalid. But we also want to avoid, in defining our VFPaaS APIs, needless explosions in the number of objects we use, or any hiding of what should be common relationships. Otherwise we end up with VFPaaS APIs that do almost the same thing as another of the APIs, complicating implementation of the platform as well as its use.
Things obviously get more complex when you leave virtual network functions for the more general virtual-function level. While network services can be broken down fairly easily, you may have to get more creative if you decide you want to define a “content-deliver-network”, and surely more creative if you want to describe “personalized-ad-service”. The need for “creativity” here means that you can’t set a fixed structure of element/object classes, you need a technique you can extend as required.
Programming languages work like that, and so does TOSCA, but you have to be careful in how you do all of this if you’re talking about a VFPaaS. For each defined object, you need to have associated APIs, and if you keep defining new stuff you risk creating too many APIs. It should be a goal to define the minimum class hierarchy that covers the functional and hosting requirements. Minimal class hierarchies define minimal API sets.
Modeling isn’t necessary to exploit a VFPaaS, but it’s helpful in managing it. The model, if it reflects the same class hierarchy, synchronizes operations processes that are model-driven with the platform relationships that are essential to deployment and operations. We should therefore think of the class hierarchy as having two outputs, the model and the API set.
TOSCA isn’t the only modeling approach that offers class inheritance, nor is Java the only programming language. With the almost-universal support of the approach in modern thinking, it’s amazing to me that we’re not thinking more about it in the broad issue of function hosting, where it offers considerable benefits in operations simplification and onboarding of functions. I’m hoping that we’re going to see more attention paid to the concept as things like the cable-network initiative, Adrenaline, mature.