We had a number of “NFV announcements” at MWC and like many such announcements they illustrate the challenge of defining what “NFV” is. Increasingly it seems to be the carrier cloud, and the questions that raises are “why?” and “will this contaminate NFV’s value proposition?”
NFV has always had three components. One is the virtual network function pool (VNFs) that provide the hosted features that build up to become services. Another is the resources (NFV infrastructure or NFVI) used to host and connect VNFs, and the last is the MANO or management/orchestration functions that deploy and sustain the VNFs and associated resources. It’s not hard to see that VNFs are pretty much the same thing as application components, and that NFVI is pretty much like cloud infrastructure. Thus, the difference between “cloud” and “NFV” is largely the MANO area. If MANO is there, it’s NFV. But that raises the first question, which is whether there are versions of MANO, and even whether it’s always useful.
Automated deployment and management is usually collectively referred to as “service automation”. It is roughly aligned with what in the cloud would be called “application lifecycle management” or ALM. This function starts with development and maintenance, moves through testing and validation, and ends with deployment. In most applications, ALM is something that, while ongoing in one sense, is episodic. You do it when there are new apps or changes, but generally ALM processes are seen as stopping short of the related process of sustaining the applications while they’re active.
MANO is a kind of bridge, something that binds the ALM processes of lifecycle management to the sustaining management processes. This binding is where the value of MANO comes in, because if you assume that you don’t need it you’re tossing the primary differentiator of MANO. So what makes the binding valuable? The answer is “dynamism”.
If an application or service rarely changes over a period of months or years, then the value of automating the handling of changes is clearly lower. Static services or applications could in fact be deployed manually, and the resource-to-component associations for management could be set manually as well. This is actually what’s getting done in a lot of “NFV trials”, particularly where the focus is on long-lived multi-tenant services like mobile services. It’s not that these can’t be NFV applications, but that they don’t exercise or prove out the primary MANO differentiator that is the primary NFV value proposition—that dynamic binding of ALM to sustaining management.
Applications/services become dynamic for one of two reasons. First, they may be short-lived themselves. You need service automation when something is going to live for days or hours not months or years. Second, they may involve highly variable component-to-resource relationships, particularly where those relationships have to be exposed to service buyers to validate SLA performance.
I reported that NFV is making better progress toward proving itself out at the business level, which is both good and important. However, some of that progress is of the low-apple variety. We’re picking applications that are actually more cloud-like, ones that represent those long-lived multi-tenant services that don’t actually require much ALM-to-management bridging. Full-spectrum service automation is less stressed in these services, and so the case they make for NFV is narrow.
You can absolutely prove out an “NFV” implementation of mobile networking, mostly because early operator work with these services demonstrates that there is a capital cost savings from the transition from appliances to servers, and that operations costs and practices aren’t much impacted by the shift because the hosted version of the service looks in a management/complexity sense much like the appliance version did. You can also prove out “NFV” implementations of virtual CPE for business users for much the same reason. The services are actually rather static over the contract period, which is rarely less than a year. Where dynamism is present, it’s often in the service-layer feature set (firewalls, NAT, etc.) and NFV principles here can reduce both capex and opex because they eliminate truck rolls.
There’s still a risk here, though, because we’ve provided only a limited validation of the full range of MANO “bindings”. The fact that so many vendors present a “MANO” strategy that’s really OpenStack is a reflection of the fact that many multi-tenant NFV trials are really carrier cloud trials. Is MANO more than that? If it’s not then a lot of people have wasted years defining NFV. If it is, then we have to be clear on what “more” means, and prove that an assertion of additional functionality is both true and presents value to justify its costs.
I think we have to get back to dynamism here. If there is a value to “network services” that can not only be sustained in an evolving market but grow over time, that value has to be derived from personalization or specialization. Since bits are neither personal nor special, the value has to come from higher layers. Some of these valuable services may be, like content or mobility, based on multi-tenant behaviors of facilities and components, but it’s hard to see how we can depend on new services of this type arising. What else of this nature is out there? On the other hand, it’s easy to see that applications and features built on top of both mobile and content services could be very valuable.
I’ve talked before about mobile/behavioral symbiosis for both consumer and worker support. It’s also easy to conceptualize additional services in the area of content delivery. Finding not only videos but portions of videos is very useful in some businesses. Hospitals who video grand rounds would love to be able to quickly locate a reference to a symptom or diagnosis, for example. In the consumer space, sharing the viewing of a portion of a movie would be as valuable as sharing a YouTube stupid pet trick—maybe even more so depending on your pet-trick tolerance.
Building upward from multi-tenancy toward personalization/specialization is what MANO should and must provide for, and we have to insure that we don’t get trapped in the orchard of low apples here. If we do, then we risk having NFV run out of gas.