VMware is launching a program to bring carriers to the NFV-enabled cloud, one that would eventually shift to OpenStack as applications become ready for the cloud management platform.

VMware calls the offering vCloud for NFV. It's the first product from the company's Telco NFV Group, which was announced earlier this month with Shekar Ayyar at the help as general manager. And it's going to be VMware's primary message at Mobile World Congress this week.

The offering is meant to help carriers make the transition to cloud-based infrastructure. Carriers want to do that, especially for the sake of NFV, but the changes required to operations, as well as the relative immaturity of OpenStack, makes it hard for them to decide the pace of the cloud transition.

Even deciding what to do first can be a stickler, says David Wright, vice president of operations for VMware's Telco NFV group.

"One predicament we see carriers fall into is not so much analysis paralysis, but talking paralysis," he says. "They reach so far into various different solutions" and end up deciding on none of them.

Seeing an opportunity, vendors have begun offering most or all of the NFV cloud as a product. Juniper's Contrail Cloud, announced in November, is a turnkey rack of gear meant to power NFV. And at last year's Mobile World Congress, HP introduced its OpenNFV Reference Architecture spanning OSS; management and orchestration; virtualized network functions (VNFs); and network infrastructure.

vCloud for NFV consists of virtualized compute, storage, and networking (meaning VMware's vSphere, Virtual SAN, and NSX network virtualization platform) plus network management options that include vRealize Operations and the VMware Integrated OpenStack distribution.

It's well assumed that NFV will reside in the cloud, and it's often assumed that that cloud will be based on OpenStack. VMware, though, doesn't believe applications, let alone the carriers themselves, are ready for OpenStack.

Most applications right now can scale up easily — they can be clustered to run bigger and bigger jobs. Databases and SAP installations come to mind.

OpenStack, though, is expecting applications that are made for the cloud — applications that scale out, distributing their reach around the network. Telecom applications aren't built like that yet, Wright says.

Wright doesn't feel this is well understood among service providers. "Too many of them are looking at OpenStack thinking it's the same thing they do with cloud APIs," he says. There isn't a realization that they should rewrite applications to accommodate OpenStack.

The pragmatic approach, then, would be to base the NFV cloud on an environment more proven environment than OpenStack, such as vCloud and its APIs, he says. That's where vCloud for NFV is intended to start, but the architecture is also poised to replace that environment with OpenStack, gradually if necessary, as OpenStack matures and as applications start looking the way OpenStack expects them to.

The resulting product does put a lot of the NFV infrastructure into VMware's hands. That might scream "vendor lock-in" to some. But given NFV's immaturity, the proper unit of abstraction — the level at which customers should be able to swap one company's products for another — is at the NFV infrastructure itself, not down at the hypervisor, Wright says.

It's a theory of his own, and not VMware's official philosophy, although the thinking is baked into the vCloud for NFV.

What it means is that Wright doesn't see the value in companies replacing bits and pieces of their NFV architecture — for instance, using one company's OpenStack Nova adapter for compute and another's OpenStack Neutron adapter for networking.

Instead, what they would replace is an entire platform, he says — for example, deciding between vCloud for NFV and Juniper Contrail Cloud.

In that regard, it's important that credible, open OpenStack APIs evolve, Wright says, "so that we could be replaced ultimately, if we don't do our job," Wright says. "It does no good if they've got all these VNFs [from different vendors] and they're locked in to one platform."

The OPNFV group is doing work toward making NFV components, such as VNFs, interoperate. Wright isn't discounting that work. But he believes it will be best if a customer can turn to one vendor to make the whole NFV package work properly. That's what vCloud for NFV is doing, Wright says.

One aspect that won't come from VMware is the orchestration; the vCloud for NFV is meant to connect to other vendors in that regard. Amdocs and Cyan, potential orchestration partners, are both quoted in VMware's release saying nice things about the new product.

VMware also isn't providing the VNFs. VMware vCloud for NFV is like an empty kitchen waiting for someone to make a meal out of VNF ingredients. To that end, VMware says it's launching vCloud for NFV with 40 VNFs provided by 30 vendors.

VCloud for NFV also has at least one customer being announced this week: Vodafone.

MWC Disclosure: Craig Matsumoto was rejected for a Mobile World Congress press pass and is attending MWC 2015 on a pass supplied by Brocade.