When I did a survey of operator priorities back in 2013, the top of the list was mobile broadband (88% of operators listed it) and second with 86% was cloud computing. At the end of 2015, mobile broadband’s score was almost identical but cloud computing had fallen astonishingly—to only 71%. Nothing in the history of my surveys ever sunk that far that fast. Is this another example of operators’ having little understanding of the future, or is there more to it?
Cloud computing got to its dizzy heights of operator strategic focus primarily because it was hot in the media. The most important thing to remember about network operators is that, as a class of business, they are behind the pack in terms of strategic marketing and proactive sales. The days when they were nothing but order-takers are gone, but they’re not that far in the past and their shadow still falls on the organizations today. The smart thing for an organization who can’t develop opportunity to do is to look to exploit it. That’s why cloud was hot.
If you’d asked people what percentage of IT spending would be directed at public cloud services in 2015 back in 2013, you’d have gotten numbers ranging from a low of 22% to a high of almost half. Actually the number is about 6% even today, and that includes money that might otherwise have gone to simple web hosting. One reason the operators lost some cloud enthusiasm was that real customer contact was telling them that the public perception of cloud adoption was too optimistic, but that wasn’t the only reason.
The big advantage operators would have in the cloud is their lower expectation for ROI. While companies like Google want ROIs in the 20% or higher range, most operators are happy to get 15%. If you presume that cloud computing adoption is purely cost-driven, which it is in today’s market, then the guy who can invest at the lowest ROI—all other factors being equal—wins in a price war and thus in the marketplace.
Nobody wants to win a market by commoditizing it, which means that operators really want to have differentiating features. For IaaS, the dominant cloud model today, that’s a tough row to hoe. Some have suggested that operators could position their server assets locally, which would give them better performance, or that they could use premium connectivity to achieve that same goal. Those notions seem logical but they ignore the fact that the big operators with the best cloud credibility are highly regulated.
Regulations complicate a lot about network services because they impose special obligations and restrictions on the major-market incumbents for basic telecommunications services. Generally, cloud computing is considered an information service, and generally it’s got to be offered by a separate subsidiary rather than the regulated entity. This creates issues when it comes to sharing real estate, which is a factor in forward placement of assets. Regulatory challenges vary by country, though, and are most likely to impact the developed markets. In the emerging markets, this is less a problem, which is why Tier Two and Three interest in the cloud has dropped only slightly in contract to the big decline among Tier Ones.
The next problem operators report in fulfilling their early cloud hopes is the challenge in building the resource pool. Cloud computing, as a cost-driven market, is critically sensitive to the cloud provider economy of scale, and that’s particularly true where you want to target enterprises. Since most operators would have difficulty in targeting lower-end market segments, this means that building a resource pool is a prerequisite for market entry. That makes it a big first-cost risk. You spend a lot to build your cloud data center(s) and then you hope you can fill them with paying customers.
When NFV came along, which was about the time that hopes for carrier cloud were highest, a lot of operators saw it as a way of creating a resource pool in advance of having to sell cloud services and with lower risk. There would be, for most major-market providers at least, a need to dance through regulatory hoops to avoid problems, but if you could harness NFV to build resource pools that would then be available as an element of cloud services, you’d have something great. Now, of course, we’re seeing the greatest level of NFV success in CPE-hosted VNFs, which don’t build cloud resource pools at all.
We could build resource pools by hosting vCPE functions centrally, but it seems likely that this will create a bootstrapping challenge. Where there’s a good density of vCPE prospects, you could expect to host functions centrally rather quickly if you could ramp up service sales quickly. If you were substituting vCPE for fixed devices, you might even be able to skip the premises-hosting step if you could sign on a critical mass of customers then deploy a data center to support them. But the time lag is significant, which means that as a practical matter you’d need to start with premises-hosted vCPE. Then you have to decide if there’s enough benefit to move to central hosting, which again would depend on customer density.
Even if you can justify feature hosting, some operators are concerned about the regulatory implications. Remember that services bundled with CPE were declared to be anti-competitive in some markets long ago. Can operators host CPE features, then, without making that capability open to competitors? And as you climb up from “firewall” to something that looks like a server, including DNS and DHCP, are you now entering the realm of information services? Who knows?
This all illustrates the challenge associated with efficient resource-pool building. It’s particularly acute for vCPE and mobile infrastructure, two of our NFV missions, because these applications are obviously linked to services that are considered to be “regulated”. The implications of sharing resources between these services and information services, as I’ve noted, is worrying, and that might make the IoT mission for NFV and the IoT service target for operators critically important.
If IoT is nothing but connectivity, as we tend to think of it today, then it’s not really much about NFV either. At least, it’s not about NFV any more than any other connectivity service. If, on the other hand, IoT is really big data and cloud analytics and so forth (as I believe it has to be to succeed) then it is an information service and a candidate to build resource pools that virtually any operator could leverage to offer cloud computing services.
IoT is an example of what I’ve called the “agent model” for services. You have an agent that’s responsible for browsing through information and calling for analytics. Something (the user, an application, whatever) communicates with an agent to secure answers, and the agent then does its thing. This separates user-to-agent connectivity and services (which are clearly “traditional” in all ways) and agent-to-processes-and-data connectivity and services, which seem to be something different. Is this cloud-like stuff now an information service, and thus in the domain of a subsidiary, or is it something like a CDN and thus exempt from even neutrality regulations? Who knows?
Among operators, some worry about this stuff and some don’t. Even inside individual operators, I’ve found that the CTO-level people don’t think about this much and may even be planning stuff that would give the Regulatory Affairs types some radical gastric distress. At the least, these questions illustrate the fact that our technology aspirations may have to wait a bit till public policy and regulations catch up.