Does VMware have a plan to transform the carrier cloud? It’s far from an idle question, especially now that IBM has acquired Red Hat. Cloud computing is transforming under the stimulus of “cloud-native” thinking and planning, and there’s no vertical market where that’s needed more than the carrier cloud space. Network operators have been locked in the dark ages of cloud thinking with NFV, and they’ve failed to really exploit any of the other half-dozen drivers of carrier cloud. Could VMware have a plan? Light Reading did a nice piece on their recent M&A, and it’s worth taking a deeper look at the topic overall.
The thing we call “carrier cloud” is really a combination of a single truth, six demand drivers, and a rather fuzzy set of technical visions. The single truth is that connectivity services cannot possibly sustain operator profit goals over time, which means that operators need to climb the value chain by providing more than just bit-pushing. The six demand drivers are virtual CPE, video/advertising features, 5G transformation, operator cloud computing services, contextual services, and IoT. The fuzzy technical visions are…well…fuzzy.
Most operators realize that they need to exploit hosting features and functions better. One mission, defined by NFV, is the replacement of legacy appliances/devices by hosted function instances—virtual network functions or VNFs. The other missions, defined by the other drivers, are related to providing non-connection services, what we customarily call “higher-level” services. Most operators had hoped that NFV would rush onto their scene, reducing costs by replacing expensive devices with commodity servers, and build out a pool of hosting resources that could then be exploited (via NFV technology) by the other higher-level demand drivers. That was the plan.
The problem is that NFV hasn’t been particularly impactful as a driver of carrier cloud. In fact, some operators (see HERE) doubt that NFV’s approach is the right one, and as that same article and many of my blogs show, so do I. Since operators had generally seen the NFV work as driving both near-term appliance replacement and long-term higher-level services, that puts the whole carrier-cloud-transformation scheme at risk.
I’m getting into this background, because it’s relevant to VMware’s carrier-cloud aspirations. If carrier cloud equals NFV and NFV equals a market bust, then VMware has to pursue carrier cloud in such a way as to accommodate that truth. If it doesn’t then the failure of, or even slow-roll of, NFV could be a disaster. That’s particularly true given the fact that VMware competes with IBM/Red Hat, who also have their eye on the carrier-cloud space, and may move quickly once they get themselves organized.
What, then, is VMware doing? Most obviously, they’ve put together a group responsible for the carrier cloud/service provider market. They offer service providers an opportunity to resell VMware cloud technology, of course. Most recently, as the first Light Reading piece I cited shows, they’ve done some M&A that seems directly aimed at operators, and perhaps in particular at the cloud-native aspects of carrier cloud.
Avi Networks is an application delivery controller (ADC) vendor, which in a practical sense means they’re a load-balancer. One of the critical pieces of carrier cloud is a service mesh, and load balancing is central to service mesh technology. If VMware wants to support true cloud-native development, then Avi is a critical part of that picture. In addition, it’s already integrated with all the major cloud providers, which is important in that it would let carrier cloud public cloud services play a role in multi-cloud enterprise applications.
The Bitfusion deal is something I mentioned in passing when it was first announced. Bitfusion virtualizes specialized processor resources, like GPUs and even FPGAs. There are a lot of applications for these specialized processors, but surely they could play a critical role in virtualizing data-plane functions in a carrier cloud. I think VMware will be extending the original Bitfusion approach, and also its target markets.
Uhana is the most carrier-specific of the acquisitions, one VMware specifically aligns to their Telco Cloud and Edge Cloud activities. They use AI to analyze telemetry from all parts of a mobile network in order to determine optimization practices appropriate to changes in the overall subscriber distribution, traffic distribution, trends, and so forth. Uhana is also a powerful stream processor, capable of analyzing traffic flows in real time. This could be critical for things like real-time massive multiplayer gaming and even IoT, but it could also be put into service as part of any event processing application, and even for service lifecycle automation.
Only Uhana of the three is explicitly put into the carrier cloud space, but all three would have obvious applications there. However, I don’t see the three as indicating a specific and coordinated carrier cloud push, as much as I see them as a specific and coordinated counterpunch to the IBM/Red Hat thing. It’s very clear that IBM is preparing for a big cloud-native push, and where carrier cloud comes into the picture is that it’s the largest prospective source of new cloud data centers for the next decade…if it happens.
Let’s dissect that statement. “Cloud-native push”, meaning that both IBM and VMware understand that the big push in software is cloud-native development and deployment. It’s a step of such magnitude that enterprises are less likely to try to assemble their own toolkit for it when a vendor steps up to offer a complete and supported solution. “If it happens”, of course, reflects the uncertainty that the carrier cloud will ever live up to its potential. You can’t ignore a potential hundred thousand incremental data centers, but you can’t bet on a vertical market that’s disappointed more technology sellers more times than perhaps all the other verticals combined.
That’s the dilemma that VMware and its competitors all face. Cloud-native is becoming more than a slogan, thanks to the pace of advance in the tools that relate to microservice-centric development and containerized deployment. However, the service provider space has hurdled down the wrong path on virtually everything it’s undertaken in the cloud area, which means that it’s been diverging from the technologies it will depend on in the long term. Can vendors present the truth to the telcos now, and hope they’ll see it, or must they blow kisses at NFV and ONAP and hope the telcos will come to their senses on their own, in their own good time?
Logically, the answer is “do both”. Telco, or carrier, cloud depends on getting the right answer soon enough to be able to apply it. Waiting for the earth to take a couple of whirls won’t cut it, but neither will sticking the telcos’ collective noses in the excrement they’ve created for themselves while hoping for their repentance. An evolutionary model, something that redeems at least some of the vision of the current path while getting things on the right path, is essential. That’s where VMware would have to apply its planning and thinking.
Open-source software has been an astounding technical success, but from a promotional sense it’s been appealing more to technicians than to senior management. In my own surveys and contacts with enterprise management, I’ve found few who can articulate the value proposition of cloud-native, much less explain the technical features. In the service provider space it’s even worse, in part because cloud-native is fighting a culture that’s perhaps more entrenched than any tech culture in the market. As I’ve said in the past, we don’t even have the words to explain the cloud-native features and benefits, or its application model. VMware, or a competitor, is going to have to provide them, and more.
The current M&A is a good thing. It makes sense to build out a solution you can sell before you start stimulating evolutionary buying. However, “selling” is more than “having”. VMware will need to be more evangelistic regarding its new cloud-native model, more explicit in defining how they believe telcos will adopt it and how the benefits will accrue, or whatever they do to actually create deployable assets won’t matter. Nobody will try to deploy them.