It’s obvious that there’s a relationship between NFV and the cloud, but for many the relationship is simply one of common ancestry. You host apps in the cloud and with NFV you host features there. Well, there’s a lot more to the cloud than just hosting apps or features. The cloud is the model of the network of the future, and so a vendor’s cloud-savvy may be critical to their credibility as an NFV partner.
If NFV was a simple value proposition, a single golden application that when implemented would suddenly arrest the convergence of revenue and cost per bit, we’d have it easy. The problem is that the “golden applications” for NFV that we see today are golden largely because they’re contained and easily addressed. Our experience with them, at the service level, isn’t going to take us to where we need to be. So we have to look to other value propositions.
We hear a lot about how service agility, service chaining, and SDN are going to create new opportunities for network operators. The net of this is the assertion made by many, that bit-based services can still be profitable. Well, the facts don’t bear that out. In the most recent quarter, for example, enterprise services for Verizon were off by 6% and made up only about 10% of revenues. My survey data shows that enterprises now have premises tools for firewalls, NAT, and so forth, and that the path to substitute carrier services for these tools is littered with delays caused by financial cycles (depreciation of the current assets) and fears of operational impacts. Operator CFOs privately think that service chaining isn’t going to make a meaningful difference in that converging revenue/cost curve.
The services most talked about today aren’t suitable for driving broad transformation simply because they’re not broadly consumed. They don’t impact enough total cost or introduce enough incremental revenue. That’s what makes NFV a kind of game of bridge. We have to build a future infrastructure that will make money, so we have to bridge between the implementation of our early services and the implementation of future services. We have to get to that future with some flair, meaning that we’ll have to build out the future-facing tools while addressing near-term costs and revenues. Where the features of NFV that we hear about matter is in that bridging.
The challenge is that you need both banks to make a bridge. We know where we are now, and we understand that things like service chaining can lead us forward. What’s less clear is what “forward” means in terms of features and technologies. We can’t expect operators to renew their infrastructure for every step of the transition. We need transitioning infrastructure, transitioning operations practices.
Saar Gillai, SVP and general manager of HP NFV Business Unit did what I think might be the first blog post made by a vendor on this topic. In it he lays out four phases of NFV as decouple, virtualize, cloudify, and decompose. This starts with breaking up appliances by decoupling function from one-off hardware, moves to virtualizing the software for the functions, adds in agile cloud hosting of both functions and applications, and finally decomposing both elements of services and apps to permit more agile composition of new stuff.
I think these phases are the right framework. Making them work in practice will involve two things. First, we really do need to understand the kind of network future we’re building. We cannot even recognize the right decisions without that standard of future mission to guide us. Second, we need to find a way to accelerate benefits to fund the changes. Without that, the first baby steps won’t provide enough benefit to justify broad deployment.
I’ve talked about orchestration of operations and its importance before, but I want to point out another aspect of orchestration that might well but just as important. It’s the other face of service management, which is service logic. We have to recognize a key point, which is that as we accelerate service cycles we reach a point where what we’re describing in a service model is how it works and not how it’s built.
Right now, we’re visualizing an implementation of NFV and orchestration that deploys stuff. It’s role is the service management side—putting resources into place, connecting them, and sustaining their expected operating state and SLA. Even this service management mission is broader than current standards activities can support, because we don’t fully control mixtures of legacy, SDN, and NFV and because we don’t automate the management processes along with the deployment. Taking orchestration to the service logic level seems daunting.
Well, maybe that’s because we’re thinking too narrowly about services. If you believe that OTT players have the secret to future revenues, then you believe in service logic. Most OTT revenues come from advertising, which is composed into web pages dynamically and delivered. That’s not management—we don’t build web pages and store them in anticipation of their being used. We look at cookies and decide what ads to serve, and we then serve them. Service logic.
Some of the implementations of NFV orchestration also touch, or could touch, on service logic. Overture’s Ensemble Service Orchestrator uses BPMN to describe a deployment workflow. Similar notation could describe service logic. In my original ExperiaSphere project, the alpha demonstration involved finding a video based on a web-search API, finding its serving location, and describing an expedited delivery plan. That could be viewed as deployment, but it is also very close to being service logic.
In fact, anything that can select processes based on state/event analysis can do both service management and service logic, which means that it’s likely that any NFV implementation that met current requirements for operations orchestration could become service logic orchestration tools too. That’s good, because service logic and cloud support for it is the big brass ring of the future that every operator and every vendor is trying (even when they don’t fully realize it) to grasp.
Service-logic orchestration means you could orchestrate the flow of work among service elements in real time. This clearly isn’t suitable for high-speed data-path applications but I think those applications are just a small step above pushing bits. What future services have to offer is some sort of functional utility, something like exploiting LBS to find things or serve ads, or exploit community behavior to do the same. In short, service logic is part of realizing mobile/behavioral opportunities.
Service logic is about handling events. So it service management. What separates the two (besides intent) is the performance requirements associated with something and the fact that service logic is likely to compose experiences not from things newly deployed but from things that are available as resources. These are the “microservices” I’ve talked about.
I think cloud-hosted microservices are the key to NFV’s future. There is I think some recognition that they’re important even in the ETSI ISG’s current work; multi-tenancy of elements of services are an issue under discussion. The challenge is advancing our thinking before we’ve advanced to the future we’re supposed to be preparing for.
NFV can’t be about building networks a different way, or building bit-based services a different way, or building services for a small fraction of the customers a different way. We need to make massive changes in both cost and revenue and that will take transformative architectures. Those are the architectures we need to be thinking about right now, because 2015 is grinding along and we’re running out of time before operators are forced to look beyond NFV and SDN and even the cloud for their transformation.