VMware came out with an announcement of their 5G Telco Cloud Platform, the latest step in the developing battle for all those carrier cloud applications. Their press release is a bit difficult to decode, but it’s worth taking the effort because the company is presenting what’s perhaps the last chance of network operators to take control of their cloud destiny. The biggest question, though, is whether they want to do that. As I said in yesterday’s blog, operators now seem determined to avoid carrier cloud. Does this impact VMware, then?
Almost every network operator (“carrier”) has a transformation vision that includes, and is often centered on, a shift from specialized appliances to some form of hosted-feature framework for their network infrastructure. This has come to be known as “carrier cloud” because all of the approaches involve some form of cloud computing. I’ve modeled the opportunity for carrier cloud since 2013, and the “optimum” deployment (the one that returns the best ROI) would create about a hundred thousand new data centers by 2030, the great majority qualifying as “edge” data centers.
In 2019, as I’ve noted in prior blogs, enterprises had an epiphany about their use of the cloud, recognizing that most of their cloud benefits would be derived from a split-application model that hosted the GUI-centric front-end piece in public cloud facilities while the transaction processing back-end piece stayed in the data center. The carriers had their own epiphany that same year—they realized they didn’t really know how to go about building carrier cloud and the cost implications were frightening.
The result of this realization/fear combination was that operators suddenly started seeing public cloud providers as partners in carrier cloud applications, a way of dipping their toes into the waters of the cloud without risking drowning. Operators were more than happy to take advantage of the interest, an all the cloud providers have carrier cloud programs, focusing primarily on 5G Core feature hosting as the early application driver.
The problem with this, from the operators’ perspective, is that the cloud provider solutions are complete enough to put operators at risk for vendor lock-in, and also create (in their minds, at least) the risk that they’d get committed to a public cloud transition strategy, only to find they can’t transition because they never developed a path in the self-hosting direction. That pair of concerns is what VMware seems to be focusing on.
The 5G Telco Cloud Platform is a platform, not a 5G-as-a-service approach. Its primary virtue is that it can host any cloud-open solution to a carrier feature-hosting mission, meaning that it forms a kind of carrier-cloud middleware. You can deploy it on your data center and in one or more public clouds, and the carrier cloud solution is then non-specific to partners or to the extent to which the operator wants to commit to public versus private hosting of carrier cloud. In short, it removes both of those risks.
Why, then, is this approach not sweeping the markets and dominating the news? The press release was dated September 1st, and it was picked up in Light Reading’s news feed, but not on their homepage as a feature story. I think a part of that is that the VMware carrier-cloud position was covered earlier by some media in connection with the Dish adoption of the platform. Another reason, I think, is that the positioning in the release doesn’t capture the reality of the situation.
Let me offer this quote as an example: “As CSPs evolve from NFV networks to cloud native and containerized networks, VMware is evolving its VMware vCloud NFV solution to Telco Cloud Infrastructure, providing CSPs a consistent and unified platform delivering consistent operations for both Virtual Network Functions (VNFs) and Cloud Native Network Functions (CNFs) across telco networks. Telco Cloud Infrastructure is designed to optimize the delivery of network services with telco centric enhancements, supporting distributed cloud deployments, and providing scalability and performance for millions of consumer and enterprise users. These telco centric enhancements enable CSPs to gain web-scale speed and agility while maintaining carrier-grade performance, resiliency, and quality.”
This is arguably the key paragraph, but what the heck does it mean? First, telcos are not evolving from NFV networks to cloud-native. They have no statistically significant commitment to NFV anywhere but stuck on the premises inside universal (white-box) CPE. Second, there’s nothing less interesting to the media than a story about how you’re evolving your solution, which is that the release says. Revolution is news, evolution takes too long. Finally, all the descriptive terms used are pablum, they’re table stakes for anything.
And here’s the best part; the link in the release for more information is broken (that appears to be a problem with Business Wire, not VMware; you can get to the target by typing in the text, or clicking HERE). From there, you can eventually get to the detail, which is really about the NFV solution that the new approach is evolving from. Still, in that detail, you can dig out some things that are important, perhaps not to the media but to the buyer.
Here’s why I think this is important, regardless of positioning. The buyer matters. What operators actually need at this point is a way to hedge their bets. They really want to be in the clouds, but they’re more than wary, they’re frightened. Right now, the cloud looks like this giant foggy mess that obscures more than it resolves. Operators have jousted with cloud concepts for a decade and had absolutely no success. They’re still among those who believe that you make something cloud-native by stuffing it in a container and perhaps using Kubernetes to orchestrate it. “CNF” stands for “Containerized Network Function”, not “CNNF” for “cloud-native network function”. If you think the cloud is fog, after all, what do you think of cloud-native? Properly applied, VMware could give them that.
“Properly applied” is a critical qualification here. The CNF versus CNNF thing is one of my concerns with the VMware story. The operator use of “CNF” to mean container-network-function is well-established. That VMware uses it in the quote I provided above raises concerns that they’re redefining “container” to mean “cloud-native”, and sticking with the old NFV evolution story. More on that in a minute.
Carrier cloud middleware could be a revolution. You can deploy it in any public cloud, or even all of them, and so you have that toe-in-the-stream option that seems popular right now. You can’t be locked into a cloud provider because it runs on them all. You can’t be held hostage in the public cloud forever, seeing your profits reduced by public cloud profits on the services you consume, because you can move the stuff in-house.
Microsoft, as an example, is providing a 5G solution that includes 5G functions. How portable that will be remains to be seen. VMware is partnering with various players (as their Dish deal show) to create 5G solutions that are portable. This approach could give VMware a direct path to the hearts and minds of the carriers who are looking at virtual-network technology to transform what they have, and build what they’re now getting into. They’ve just got to sing better.
NFV’s goals are fine, but there’s no evolving from it in a carrier cloud sense because it’s only broadly used, as I’ve said, in CPE. Yes, the operators want to shift to cloud-native, but they need more than containers to do that. VMware needs a true cloud-native vision, and they need to explain it clearly and make it compelling. Then, they have to be prepared to do a fair amount of executive education in their buyer community.
There are some technical shifts needed too. VNFs are old; not only obsolete but never really helpful in carrier cloud. Containerizing, meaning CNFs versus VNFs, are only a transitional step, a pathway to a true cloud-native (CNNF, in my terms) goal. The transformation to CNNFs has to be accompanied by a shift from NFV-specific orchestration and management to cloud orchestration (Kubernetes) and management. VMware has the platform in place to support the strategy, but they need to develop and then advocate the strategy or nobody will care.
The beauty of VMware’s partner approach to the network functions/features themselves is that if VMware is prepared to advance its platform to support CNNFs, CNFs, and VNFs, it can find partners in each of the areas and promote the cloud-native transformation in a way that acknowledges reality (the CNNF approach is the only cloud-native approach) but also blows the necessary political kisses at NFV proponents who want to justify all the time and effort spent on NFV and its evolution. Politicians know they have to kiss all babies they’re presented with; vendors marketing to as diverse an interest group as the network operators should do the same.
But what exactly is a CNNF? That’s perhaps the key question for VMware, because it’s difficult to see how a model of decomposed cloud-native features could be created without in-parallel conceptualizing of the way it would be hosted and the middleware needed to support it. Obviously, because VMware is supporting an “embedded” or edge-ready version of Kubernetes, they see Kubernetes as a piece of the story. How much real experience do we have with Kubernetes in cloud-native deployments? Is most of the heavy lifting done in a service mesh layer instead? Lots of questions.
This is the big barrier for VMware because they have to answer these questions or they have no end-game to present to the operators. That their positioning doesn’t depend on operators deploying their own cloud is great, but it’s critical that operators have a vision of what they are deploying, as much as where. Defining the next step isn’t enough. Evolution as a long battle for local feature supremacy is an unattractive picture to present to a telco CFO. Better to show progress toward a goal, and so that CNNF end-game play is where VMware needs to focus.
The challenge in focusing there is that while there’s no question that VMware’s platform can support CNNFs, there’s a lot of questions regarding what a CNNF is, and how one is architected into a service. A critical first step in that, as I’ve said many times, is recognizing that the control and data planes of an IP network have to be separated in order to optimize cloud-native deployment. The data plane is a simple forwarding process, linked pretty tightly to trunk locations. The control plane is where cloud-native implementation could shine, but is it separated in VMware’s vision? Because VMware is talking platform and not service implementation, we don’t know. That could make it hard for VMware to promote a CNNF-based approach to infrastructure, and without that, their challenges with their 5G Telco Cloud Platform could be significant.