Everyone in NFV is jumping on “service agility” as the key benefit, and I don’t disagree that the value NFV could bring to launching new services could be the best justification for deploying it. Wishing won’t make it so, though, and I don’t think we’ve had enough dialog on how one makes a service “agile”. So…I propose to start one here.
The first point about service agility is that it’s going to be a lot like software agility, and in particular what I’ll call “functional” or “app” programming. Traditional software is written by programmers who write specific instructions. Modular software, a trend that goes back over 40 years, initiated the concept of reusable “modules” that were introduced into a program to perform a regularly used function. This was enhanced about 20 years ago by the notion that a software function could be visualized as a “service” to be consumed, and that was the dawn of the Service-Oriented Architecture or SOA. Today’s web-service and PaaS models (and many SaaS models) are another variant on this.
In all these approaches, we get back to the notion of abstraction. A programmer consumes a service without knowing anything about it other than the API (application program interface, meaning the inputs and outputs) and functionality. The service is a black box, and the fact that all the details are hidden from the programmer means that these services make it easy to do very complicated things.
To me, this is a critical point because it exposes the biggest truth about service creation in an NFV sense. That truth is that there are two different “creations” going on. One is the creation of the services, which if we follow software trends are assembled by assembling lower-level services. The other is the generation of those lower-level services/abstractions from whatever primitives we have available. I’ve categorized this in role terms as “service architect” and “resource architect”.
An agile service, I think, is created first by identifying or building those lower-level services/abstractions from the resources upward. A VPN or a VLAN is an example of an abstraction, but so is “DNS” or “firewall”, or even “HSS”. Once we have an inventory of this good stuff, we can let service architects assemble them into the cooperative functional systems that we call “services”.
There are a lot of possible slip-ups that can happen here, though. I’ll illustrate one. Suppose I have a need to deploy virtual CPE but I can’t do it everywhere I offer service, so I have “real” CPE as well. I have two options. One to define a low-level service called “CPE” and let that service sort out the difference between virtual and real. The other is to expose a “virtualCPE” and “realCPE” service. Let’s see how that plays out.
If I have a CPE service, then the decision of whether to use cloud principles to host and connect software elements is invisible to the service architect. The service definition includes only CPE services, and they don’t care because the underlying service logic will sort out the provisioning. On the other hand, if I have virtualCPE and realCPE, the service definition has to know which to use, which means that the details of infrastructure differences by geography are pushed upward to the service level. That means a much more complicated process of service creation, which I contend means much less agile.
But even my virtualCPE and realCPE abstractions have value over the alternative, which is to define the services all the way from top to bottom, to the deployment level. If I have a pair of abstractions I will have to reflect the decision on which to use into the service orchestration process, but the details of how it’s done will stay hidden. I can provision different CPE, deploy on different virtual platforms, without changing the service. That means that changes in real devices or virtual infrastructure are hidden from the service orchestration process. If I don’t have those abstractions then any change in what I need to do to deploy (other than simple parameter changes) would have to be propagated up to the service definition, which means the change would change all my service order templates. No agility there, folks.
The point here is that an agile service has to be agile through the whole lifecycle or it’s not really agile at all. I cannot achieve that universality without following the same principles that software architects have learned to follow in today’s service-driven world.
If you map this to the current ETSI work and to other NFV activities you see that it means that things like OpenStack are not enough. They can (and will) be used to decode what to do to deploy “virtualCPE”, but I still have to decompose my service into requests for realCPE and virtualCPE somewhere. Further, if I decide to get smart and abstract two things that are functionally identical into “CPE”, I have created a level of decomposition that’s outside what OpenStack is designed to do. Could or should I shoehorn or conflate the functionality? I think not.
Network resources, technologies, and vendors create a pool of hardware and software—functionality-in-waiting we might say. An operator might elect to harness some of this functionality for use by services. If they don’t then service definitions will have to dive down to hardware detail, and that creates a service structure that will be a long way from agile, and will also be exceptionally “brittle”, meaning subject to changes based on nitty-gritty implementation details below.
Do we want to have every change in infrastructure obsolete service definitions that reference that infrastructure? Do we want every service created to do direct provisioning of resources, probably in different ways with different consequences in terms of management properties? Do we want horizontal scaling or failover to be mediated independently by every service that uses it? Well, maybe some people do but if that’s the case they’ve kissed service agility goodbye.
And likely operations efficiency as well. Abstraction of the type I’ve described here also creates consistency, which is the partner of efficiency. If all “CPE” is deployed and managed based on a common definition, then it’s going to be a lot easier to manage the process, and a lot cheaper.
Next time you talk with a purported NFV provider, ask them to show you the service modeling process from top to bottom. That exercise will tell you whether the vendor has really thought through NFV and can deliver on the benefits NFV promises. If they can’t do it, or if their model doesn’t abstract enough, then they’re a science project and not an NFV story.