The cloud and NFV have a lot in common. Most NFV is expected to be hosted in the cloud, and many of the elements of NFV seem very “cloud-like”. These obvious similarities have been explored extensively, so I’m not going to bother with them. Are there any other cloud/NFV parallels, perhaps some very important one? Could be.
NFV is all about services, and the cloud about “as-a-service”, but which one? Cloud computing in IaaS form is hosted virtualization, and so despite the hype it’s hardly revolutionary. What makes the cloud a revolution in a multi-dimensional way is SaaS, software-as-a-service. SaaS displaces more costs than IaaS, requires less technical skill on the part of the adopter. With IaaS alone, it will be hard to get the cloud to 9% of IT spending, while with SaaS and nothing more you could get to 24%. With “platform services” that create developer frameworks for the cloud that are cloud-specific, you could go a lot higher.
NFV is a form of the cloud. It’s fair to say that current conceptions of function hosting justified by capex reductions are the NFV equivalent of IaaS, perhaps doomed to the same low level of penetration of provider infrastructure spending. It’s fair to ask whether there’s any role for SaaS-like behavior in NFV, perhaps Virtual-Network-Function-as-a-Service, or VNFaaS.
In traditional NFV terms we create services by a very IaaS-like process. Certainly for some services that’s a reasonable approach. Could we create services by assembling “web services” or SaaS APIs? If a set of VNFs can be composed, why couldn’t we compose a web service that offered the same functionality? We have content and web and email servers that support a bunch of independent users, so it’s logical to assume that we could create web services to support multiple VNF-like experiences too.
At the high level, it’s clear that VNFaaS elements would probably have to be multi-tenant, which means that the per-tenant traffic load would have to be limited. A consumer-level firewall might be enough to tax the concept, so what we’d be talking about is representing services of a more transactional nature, the sort of thing we already deliver through RESTful APIs. We’d have to be able to separate users through means other than virtualization, of course, but that’s true of web and mail servers today and it’s done successfully. So we can say that for at least a range of functions, VNFaaS would be practical.
From a service model creation perspective, I’d argue that VNFaaS argues strongly for my often-touted notion of functional orchestration. A VNFaaS firewall is a “Firewall”, and so is one based on a dedicated VNF or on a real box. We decompose the functional abstraction differently for each of these implementation choices. So service modeling requirements for VNFaaS aren’t really new or different; the concept just validates function/structure separation as a requirement (one that sadly isn’t often recognized).
Managing a VNFaaS element would be something like managing any web service, meaning that you’d either have to provide an “out-of-band” management interface that let you ask a system “What’s the status of VNFaaS-Firewall?” or send the web service for the element a management query as a transaction. This, IMHO, argues in favor of another of my favorite concepts, “derived operations” where management views are synthesized by running a query against a big-data repository where VNFaaS elements and other stuff has their status stored. That way the fact that a service component had to be managed in what would be in hardware-device terms a peculiar way wouldn’t matter.
What we can say here is that VNFaaS could work technically. However, could it add value? Remember, SaaS is a kind of populist concept; the masses rise up and do their own applications defying the tyranny of internal IT. Don’t tread on me. It’s hard to see how NFV composition becomes pap for the masses, even if we define “masses” to mean only enterprises with IT staffs. The fact is that most network services are going to be made up of elements in the data plane, which means that web-service-and-multi-tenant-apps may not be ideal. There are other applications, though, where the concept of VNFaaS could make sense.
A lot of things in network service are transactional in nature and not continuous flows. DNS comes to mind. IMS offers another example of a transactional service set, and it also demonstrates that it’s probably necessary to be able to model VNFaaS elements if only to allow something like IMS/HHS to be represented as an element in other “services”. You can’t deploy DNSs or IMS every time somebody sets up a service or makes a call. Content delivery is a mixture of flows and transactions. And it’s these examples that just might demonstrate where VNFaaS could be heading.
“Services” today are data-path-centric because they’re persistent relationships between IT sites or users. If we presumed that mobile users gradually moved us from being facilities-and-plans-centric to being context-and-event-centric, we could presume that a “service” would be less about data and more about answers, decisions. A zillion exchanges make a data path, but one exchange might be a transaction. That means that as we move toward mobile/behavioral services, contextual services, we may be moving toward VNFaaS, to multi-tenant elements represented by objects but deployed for long-term use.
Mobile services are less provisioned than event-orchestrated. The focus of services shifts from the service model to a contextual model representing the user. We coerce services by channeling events based on context, drawing from an inventory of stuff that looks a lot like VNFaaS. We build “networks” not to support our exchanges but to support this transfer of context and events.
If this is true, and it’s hard for me to see how it couldn’t be, then we’re heading away from fixed data paths and service relationships and toward extemporaneous decision-support services. That is a lot more dynamic than anything we have now, which would mean that the notion of service agility and the management of agile, dynamic, multi-tenant processes is going to be more important than the management of data paths. VNFs deployed in single-tenant service relationships have a lot of connections because there are a lot of them. VNFaaS links, multi-tenant service points, have to talk to other process centers but only edge/agent processes have to talk to humans, and I shrink the number of connections, in a “service” sense, considerably. The network of the future is more hosting and less bits, not just because bits are less profitable but because we’re after decisions and contextual event exchanges—transactions.
This starts to look more and more like a convergence of “network services” and “cloud services”. Could it be that VNFaaS and SaaS have a common role to play because NFV and the cloud are converging and making them two sides of the same coin? I think that’s the really profound truth of our time, NFV-wise. NFV is an accommodation of cloud computing to two things—flows of information and increasing levels of dynamism. In our mobile future we may see both services and applications become transactional and dynamic, and we may see “flows” developing out of aggregated relationships among multi-tenant service/application components. It may be inevitable that whatever NFV does for services, it does for the cloud as well.
No comments:
Post a Comment