If NFV has a problem, then VMware thinks (or hopes) it has the solution. The company just announced a technology preview called “Project Maestro”, aimed squarely at breaking an NFV logjam that’s caused in part by the problems with integration and onboarding. This could be really big, or really dumb, and frankly I’m having some difficulty figuring out which outcome is most likely.
Network Functions Virtualization (NFV) has, from the start, presented telcos with two problems. The first is that the architecture model for NFV is monolithic, an anachronism for a concept that’s supposed to leverage the cloud. The second is that the elements of the architecture don’t hang together to support full service lifecycle automation.
Network vendors have largely blown kisses at the ETSI NFV ISG spec, and failed to make any progress in extending NFV concepts to create a practical and justifiable architecture model. VMware, a cloud software giant, would certainly be in a position to do better, and in particular to take a shot at a true cloud model for NFV.
I could look at their architecture picture (shown HERE) and explain how their approach is just what the market needs, and that’s actually a good way to start. The only problem is that I’m not sure that my explanation is really a description of VMware’s intent, or even capability. Refer, please, to the figures titled “Project Maestro for telco cloud orchestration” and “Project Maestro – Solution Overview” to follow my discussion, and remember this is an interpretation of my own! I’ve bolded my major assumptions.
There’s a video on the main Maestro page that’s worth watching, and its title frames the basic approach, which is Telco Cloud orchestration and not just NFV orchestration. The goal, then, is to build services from the combination of NFV’s VNFs and other cloud components, giving operators an opportunity to expand NFV beyond the keystone application of displacing purpose-built appliances with software components.
VMware’s centerpiece is the Telco Cloud Orchestration element, shown in the first figure and dissected in the second. This element is a kind of NFV platform as a service (NFVPaaS), a tool that provides interfaces to which various elements of NFV and VMware’s own cloud products. A generic VNF Manager and Orchestrator are part of the Telco Cloud Orchestration element, so NFV-ISG VNFs and MANO/VNFM processes can be integrated into this component and orchestrated along with generic cloud components into services.
There’s more. The entire Maestro ecosystem can be linked through standardized APIs to an external VNFM, element management system, OSS/BSS system, and automated lifecycle processes. That means that service collections created by the Telco Cloud Orchestrator can be presented as VNFs or NFV-orchestrated services to these partner systems. Vertically, it links through a multi-cloud, multi-NFV-VIM layer to any combination of clouds, data centers, and edge sites, and to both OpenStack and Kubernetes/container deployments. That gives NFV a cloud-native, container-driven deployment option.
Assurance, monitoring, and management are applied to the full Telco Cloud Orchestration ecosystem, which means they’re available at the service level no matter how the service is composed and what its elements happen to be. In effect, the model abstracts the entire telco cloud into something that can be presented as an element, a service, or a VNF orchestration, depending on what the operations people want.
This approach would be a true NFV revolution. It would combine two critical capabilities—the ability to orchestrate NFV orchestrations and cloud elements into a common service set, and the ability to represent any orchestrated service complex as an NFV complex to an ETSI-standard NFV management framework. It would give us, quite literally, the best of both worlds. The problem is that while this explanation of what VMware is doing is consistent with the material they provide, the material isn’t enough to say with assurance that this description is accurate.
Going back to the video, it’s tantalizing in its suggestions of capability, and it’s a solid reason why I think my interpretation of what VMware is doing is correct, but it’s still mostly glittering generalities. That’s also true of the rest of the material. We don’t see specific interface points, we don’t see the relationships between NFV-defined components and generalized cloud components mapped out, and we don’t see how all of this maps back to the hypothetical NFVPaaS model. That’s why I can’t say for sure that this is what VMware actually intends to do.
Which, of course, could also be different from what VMware ends up actually doing. Some of my operator friends who’ve seen the VMware pitches say that they think the story is a dressed-up version of vanilla NFV, something that won’t really move the ball much. Others’ take is more aligned with what I’ve presented here. And if Maestro is an experiment, there’s always the chance it will turn in another direction, even if it’s intended to get telco cloud right.
Through the entire NFV process, the industry has made it almost-policy to listen to and then ignore all the signs that they were heading in the wrong direction. Did that then immunize them to recognizing the right direction? Does the NFV model, with all its significant limitations, still set the minds of the CTO people who dominate the early technology transitioning we’re now seeing? If so, VMware would surely change focus to match what they hear.
Actual implementation is also another matter. I’ve thought as much about orchestration of complex multi-technology elements of a service as anyone in the industry, I think. There are a lot of wrong ways to do this, and a very small number of correct ones. If VMware’s actual technology roadmap is based on the same level of detail as the online documents on Maestro, there’s still a chance that they’ll pick a wrong approach and end up with a reinvention of ONAP.
VMware calls this a “cloud-first” approach, and what I’ve described would be just that, a way of building carrier cloud so that it can envelope ETSI-modeled NFV, augment it, or replace it, as the intrinsic value of NFV justifies. It would be a great advance, perhaps the most significant thing a vendor has done in the NFV space. If it’s true.
Since I post all my blogs on LinkedIn, I hope that VMware will comment on this blog, provide any guidance on interpreting the material, and tell me if and where I’m off-base. I didn’t ask for a briefing on Maestro because it’s my policy to judge vendor announcements based on hard copy only; it’s too easy to go off the rails when I’m interpreting some vendor interpretation of what they’re doing.
Better to have a solid foundation, I say, and that’s true in telco cloud and NFV too. This just might be one…or maybe not.
