The announcement that Verizon is truly selling its cloud data centers, we now know to Equinix, has to put fear in the heart of carrier cloud proponents. It should, and it should even call into question the future of NFV. But all is not lost here; the fact is that Verizon was premature in getting into the cloud business and in the wrong part of it. This is the jumping-off point for lessons to be learned from the deal, and they’re not all negative.
For the telcos, getting into the cloud business was always a kind of love/hate thing. On one hand, providing cloud data centers seems a lot like providing connectivity. It’s a high-capex business, favoring those who can tolerate a fairly low ROI. Perfect, in short, for an industry made up largely of former public utilities. On the other hand, it seems to double down on a business model that’s based on someone else exploiting you. Not to mention that you don’t exactly have herds of experienced salespeople to sell it.
Nearly all operators had cloud plans five years ago, and most of them haven’t really followed through on them. Verizon, representing the highest-demand-density area of the US, was a bit more bullish on the concept. They believed that corporate America (who were twice as likely to have their HQ in Verizon’s territory than elsewhere in the US) would flock to them as a credible cloud source, favoring them over upstarts like Amazon.
What put all of this off track was simple; the cloud hasn’t really been driven by corporate America but by Silicon Valley. OTT businesses represent, I’m told, more than 2/3rds of Amazon’s cloud revenues. Not only that, enterprises were probably the hardest of cloud sells. No new business strategy can survive a protracted early failure, and Verizon’s cloud is no exception.
The first point to ponder is that cloud computing services were never a major credible driver of carrier cloud. The total contribution that cloud computing services could make to carrier cloud data centers in 2017 is only 11% of the total, and even at its best (in 2030, the limit of my modeling) it only reaches 27%. Thus, in the near term, operators don’t deploy a lot of cloud resources driven by cloud services. Given the small number of data centers, there’s no significant edge-hosting promoted, which means that nothing happens that could accelerate NFV anyway.
The second point is that for the business customer out in 2030, cloud services is the largest overall driver of potential carrier data centers, and it’s third among all the drivers. Cloud services could drive four times the number of business data centers as vCPE/NFV, for example. Thus, in the long term, cloud computing services is a very important driver of carrier cloud. What got operators so excited about cloud services was just this long-term value, and also the fact that the service framework was well understood. Contextual services, my own favorite, has more potential than cloud services but requires a lot more work on building a functional framework that could actually support its potential opportunity.
This is how the “Verizon was too early” view can be justified. The true trajectory of enterprise cloud services is really set by the pace at which cloud-value-added platform features like the rich set offered through web-service APIs by Amazon and Microsoft can influence developers. The future of enterprise cloud spending is determined not by what you move to the cloud but what you never had elsewhere and can now do using special cloud-distributed features. That could never have taken off as fast as enterprise commitment would have to have exploded to make Verizon’s early bet a good one. Nevertheless, cloud services could be responsible for a quarter of some telcos’ revenues by 2030.
Verizon can still get their share, but the problem is the real driver of enterprise cloud adoption is those previously-mentioned API-based services that will facilitate the creation of cloud-specific or cloud-exploiting applications. IaaS isn’t enough to get a seat at that table, and the proof is Amazon’s adoption of the API strategy itself. So Verizon would need to change its approach to the cloud, to focus either on those APIs or on creating an IaaS framework that API-and-middleware vendors would then augment to go after the enterprise. IBM has sort-of-committed to that model, promoting middleware that runs either in the cloud or in the enterprise and rebuilds applications to exploit the cloud better. It’s a viable model.
The biggest problem that Verizon’s turnaround could create is in the NFV space, even though the small 2017 cloud service opportunity wasn’t large enough to matter. There are three reasons for this. First, cloud computing services will always be a better opportunity to deploy carrier cloud data centers than vCPE. Since vCPE is supposed to be the prime driver for NFV if you read the rags, giving up cloud computing services could truly starve NFV for early hosting points. Second, cloud computing services are logically related to IoT and contextual services for the enterprise. If telcos want to succeed with IoT and contextual services, they’ll create cloud computing opportunities that they can’t afford to cede to OTTs. Worse, a package of enterprise cloud computing and contextual and IoT services from OTTs could make telco success in any of the three spaces problematic.
This doesn’t mean that in the end Verizon should have kept the data centers. The key for Verizon and for any telco is getting carrier cloud deployed in central offices and mobile infrastructure hub points where IMS/EPC elements are currently deployed. In 2019, when cloud services takes its first big jump in number of data center opportunities, it’s still only 12% of the total opportunities. What Verizon (and everyone else) needs to do is look at the other 88%.
This is where the third reason (bet you thought I’d forgotten it, or counted wrong!) comes in. It’s very likely that Verizon expected cloud service success to position a lot of data center assets for other applications to exploit. The marginal cost of hosting those applications would be reduced. Absent those assets, the other applications will have to be developed more efficiently to make their business case stronger and bear more of the first costs.
It may be harder for Verizon to come up with these other NFV drivers now. Not only has consideration of the other drivers likely gone fallow while people salivated over cloud computing services, Verizon’s SDN/NFV model bets on vendor support rather than on doing a roll-your-own open implementation like rival AT&T has elected to do. Vendors have been next to useless in NFV in general and at making a broad business case in particular, even those who actually have all the elements of a complete solution.
The net of this is that selling off Verizon’s cloud computing assets doesn’t really hurt its cloud computing strategy—that would have needed reworking in any event (which surely is why Verizon is selling it). The bigger issue is NFV, because NFV needs a jump-start in terms of hosting points to open a variety of VNF options in a variety of service areas. Otherwise the first cost and initial risk of any one of those service areas would likely outstrip credible early benefits.