There are a lot of ways to get to LA from NYC and a lot of ways to realize the service agility benefits expected for NFV. Some paths are likely better than others in both these examples, and in both cases it may be necessary to travel a little to know what the best choice is. Thus, it’s interesting to note that the two leading vendors in NFV have different approaches, and that we’ll likely see some proof points of both in the next six to nine months.
Service agility is one of the most credible goals for NFV, and it’s also the goal that could in theory generate the most benefit. Capex savings are unlikely to amount to even $20 billion per year. Opex efficiency-driven savings could reach $100 billion providing that NFV principles were extended universally to all infrastructure and all operations levels. The revenue stream associated with agile services based on cloud principles is, by my current modeling, over $2.5 trillion, with a trillion coming from the enterprise space and the remainder from consumer mobile and content services. Some of this could be addressed without NFV, but NFV would be critical in wringing the most profit from it all, and in addressing all but the low apples.
The problem we have is that most of the service agility discussions relating to NFV are crap. When you wade through the morass you find two basic ideas—adding higher-level network features to services and bandwidth on demand. Buyers have told me for decades that things like firewalls and NAT are per-site features that don’t change much once you have them deployed, and that their only interest in bandwidth on demand is lowering overall network spending.
I’ve speculated in the past that there are many new services that will emerge out of mobile users and their focused, contextual, view of network services and information resources. There’s little point in my going over this opportunity side again. What’s worth looking at is how vendors seem to be approaching the question of how you really could create services with NFV and grab some of those bucks.
From an architecture perspective, NFV isn’t enough to support highly flexible assembly of services from features. Yes, you can deploy and connect elements with NFV, but while “chaining” works for things that have a simple “cascade-in-the-data-path” relationship with each other, it doesn’t support microservices and APIs fully. Future services, that two-and-a-half trillion bucks, have to be seen more as transactional activities or workflows, not connections. So what you need is a kind of platform-as-a-service framework that lives on top of NFV, meaning that NFV deploys and manages it, but that provides services to build feature applications. Alcatel-Lucent and HP have each shown they have a vision for that.
Alcatel-Lucent’s approach is embodied in its Rapport product. Rapport is a session-services framework that lets operators or even enterprises build applications (especially collaborative ones) based on IMS mobility control. It leverages Alcatel-Lucent’s virtualized IMS/EPC elements and is compatible with CloudBand and NFV. You can manage services using the Motive operations tools.
Despite the fact that IMS is hardly news (it dates back to about 1999), the fact is that IMS has been a target for NFV from the first, and it is an asset that operators own and would like to leverage for differentiation. Rapport is also targeting the same opportunity that Google’s Fi MVNO strategy seems to target, augmenting basic mobile voice services with what are essentially extended forms of custom calling features (remember “custom local access special services?”) Since transactional services based on sessions would generate a massive increase in signaling traffic, agile and scalable IMS would make sense.
The HP approach is different. They see new services being tied at least in part to new exploitable information resources, most notably to IoT. In their model, the network connections to resources, their controllers, and repositories and analytics to store them are all bundled into a kind of “USB-of-services” that you can plug in as needed. Each of these plugins expose a set of APIs that then become available to service-creating applications.
This model is more “cloud-like” or “Internet-like” in that it exposes APIs for presumably open consumption either on the Internet or in some VPN subset of users/resources. For now, at least, there’s no specific model of how the services would relate to each other or to the plugin microservices. HP may have plans for “superservices” like IMS to plug into this (they’ve talked about MVNO-based IoT so they’re clearly thinking about it) but they’ve not exposed them as yet.
There’s a common thread in all of this, I think; several in fact. High-level services are going to be built more like cloud applications than like connection services. NFV can play a role in that where dynamism (either transient services or the need for scalability) is a significant requirement. High-level services are going to be built inside a “sandbox” of APIs. We don’t know what exactly will stick with respect to this approach. We’re hoping somebody will tell us. I like both the Alcatel-Lucent and HP approaches in no small part because they’re bold adventures into a world we need to get to, but don’t quite know how to describe.
Cloud services, to be optimally deployed, useful, and profitable, have to become highly agile and tactical. So do NFV-deployed features. So do SDN connections. The future differs from the present largely in that concentrations of humans, computing, and connectivity associated with traditional worker relationships and homebound consumers are increasingly irrelevant. With the elimination of natural human mash-ups we also lose opportunity to address those humans as a group. Personalization is a natural part of addressing mobility. Agility is the fundamental requirement of a personalized service set.
Network and IT/cloud vendors approach this differently, which is one of the interesting things about the Alcatel-Lucent and HP positions. It’s hard to say whether networking or IT has the most natural connection, or even to say that there’s enough of a difference to matter. If we have to transform both, then we’d end up starting where it’s convenient, or compelling.
It’s also interesting that both of these approaches nibble at the tenuous border between service management as a pre-service conditioning of resources and service logic as a real-time management of workflows. As networks and the cloud become more tactical, it’s going to get harder to distinguish between coordinating deployment and simply running the application. Might, for example, a transaction direct the deployment of its own resources? That will generate some interesting shifts in both worlds.
Alcatel-Lucent’s Rapport addresses the model for personal connection in a world without branch offices and couches (philosophically, at least) and HP’s IoT and plugin model for information-driven services addresses how those mobile/personal users interact with the world around them. We’ll have to do both of these things, and more. The winning approach may be the one that can validate its vision of the future and link it to profitable steps in the present.