Operators have told me a lot about cloud-native, probably because I’ve blogged a lot on the topic and written about it for other software-centric online publications. Since cloud-native is the number one priority emerging from operators’ fall planning cycles, I think it’s interesting to look at some of the questions I had for operators, and the questions they’ve asked me.
The question I usually asked to open a discussion is Why do you think cloud-native is so hard for operators? One thing I observed in comparing the way operators are reacting to cloud-native with the way enterprises are reacting is that operators are a lot more pessimistic about their pace of progress and the ultimate outcome of their efforts. Why? The answer is interesting because operators divide themselves into two camps on the point.
The majority of operators say that enterprises have engaged with the cloud longer, and engage more deeply, than operators. One operator told me that one of their largest enterprise customers, whose business was about half that of the operator in revenue terms, had two-and-a-half times as many cloud-qualified development and operations specialists on staff. That enterprise had relationships with two of the major public cloud providers and was actively deploying hybrid-cloud applications, more every month. The operator said that they had nothing going on in the cloud at all except some CTO-level experiments, and they see the problem as a simple lack of cloud knowledge in house.
The operator who talked about the imbalance in cloud expertise versus the enterprise also pointed out that lack of cloud skills made it difficult even to hire and manage a team of cloud specialists. “If you make pancake mix and you hire NASA engineers, how long before you land on the moon?” Obviously a long time. This is probably the root of what many have said is a “culture problem” for operators. It’s less culture than a systemic knowledge of cloud projects that can be exploited to plan and promote cloud-native.
A minority of operators report almost exactly the opposite balance of cloud expertise, but end up in much the same place. An operator in this group said they have almost twice the number of cloud specialists as their big enterprise customers, and they have a significant commitment to partnerships with cloud providers and to the use of the cloud for both their own internal business services and as elements of their connection services. But their cloud expertise isn’t helping them as much as they’d hoped.
The problem this group cites has two faces. First, a lot of their cloud skills reside in the CTO group, whose mission for the cloud is fairly consistent with traditional business applications. The problem is that for operators, the OSS/BSS systems that make up “traditional business applications” aren’t really a broad industry target of cloudification. There’s no widespread project model for these people to follow. The second face is that the main focus of operator transformation is network infrastructure, and they find no broad-market public cloud guidance on even the architecture of a cloud-native approach to network infrastructure.
The question most operators ask me is Do you think that SDN and NFV will be successful in creating a transformation model for network infrastructure? My answer, of course, is “No”, with the qualifier that it’s likely that the intent of both SDN and NFV will be incorporated in the ultimate architectural model for cloud-native network infrastructure.
I think this question demonstrates the impact of the situation I just described. Operators don’t think that public-cloud or enterprise initiatives in cloud-native are addressing their transformation needs, and they’re admitting that their own projects and standards efforts are producing nothing more than questionable results. If operators do have skills deficits in cloud-native (which they admit), then how do they think they can run standards or even open-source projects to exploit it?
This is why I think that the only strategy with a chance of addressing cloud-native transformation in any reasonable timeframe will have to come from vendors. I don’t necessarily mean that network vendors will lead the efforts, but that software/cloud vendors are already seeing the dollar signs that would be associated with major transformation initiatives, and they’re starting to assemble the pieces. I think that VMware’s latest Project Maestro stuff could be critical—if it means what it could mean. I asked VMware to comment on my blog on Maestro to check my interpretation, and sadly they did not. Does that mean I’m too optimistic, and they don’t want to admit that? Could be.
The next question I had for operators was How does 5G transform your vision of the network of the future, and your own profit picture? Here, operators fell into three different categories. One could be called the Optimists, the second the Realists, and the last the Pessimists.
The Optimists, about 40% of all operators I talk with, say that the new services of 5G will raise their profits “significantly” (but they wouldn’t quantify what that meant). They also think that 5G will pull through NFV, and that 5G mobile infrastructure will combine with 5G/FTTN hybrids to build a new model of network that will be cheaper to build (capex) and operate (opex). The big driver of all of this is IoT, which will generate “millions of new cellular customers” that operators will be able to charge for service.
The Pessimists, who number only 25% of operators, believe that in the end, 5G is going to be nothing more than a RAN upgrade, and that if anything the marketing of 5G that stresses higher speeds will end up encouraging demand for more bandwidth, but not with any increase in service price. Thus, revenues with 5G will not go up, costs will go up, and if anything, the profit-per-bit will be worse. This group doesn’t believe that there will be a significant uptick in 5G IoT service points.
Which leaves the Realists, about a third of operators. This group believes that 5G NSA (the RAN upgrade) and FTTN hybrids (millimeter wave fixed wireless) will deploy “by 2022”. They do see an opportunity for 5G core deployment “a couple years later”, but they’re not really sure what will drive it, and whether 5G Core would really add to revenues. They do think that there’s a capex/opex benefit to a unified infrastructure, and they do think that, overall, 5G will improve their profit per bit “somewhat”. Not enough to mean no further transformation is required, though.
Their next question operators asked me was When do you think that vendors will adopt an open-network model. This was an important question, because behind it is the thought that the network of the future will be largely the network of the present, but with cheaper open-model devices replacing expensive proprietary (vendor) technology. My answer? “For network vendors, never. For IT vendors, probably by 2021.”
Flash: Most operators see an open-model network and cloud-native infrastructure as different things. Most, now, seem to favor the open-model approach. The obvious question that raises is…
…my next question to them: Why do you seem to like open-model networking more than cloud-native infrastructure? A small number (less than 10%) of operators said that wasn’t the case; they were happy with both models. Interestingly, none said they liked cloud-native more. The only question for most was whether they had any favorite (a third) or favored cloud-native as I’d suggested (well over half).
There weren’t a lot of specific details offered as an answer to my question, which means it’s hard to provide a clean set of classes of response. The sense of the majority of answers was “because we know how to do it.” Operators were comfortable with the process of network-building and their current network management techniques, both of which depend on having boxes in specific places, managed with familiar interfaces and tools. The next-most-common response was that cloud-native and open-model networking really differed only based on whether you hosted software networking features on servers or on white boxes.
To me, these add up to a common view, which is that a “network” is a mesh of service feature instances, and that all the fuss is really about how the instances are created. As I’ve commented in the past, cloud-native network infrastructure would have to decompose the features of the traditional devices, not just host them. You’d need virtual services not virtual devices, and operators either don’t see that or don’t accept it. I think the latter.
You can’t build carrier cloud from white boxes. If operators are reluctant or unwilling to adopt cloud-native virtual network infrastructure, then that potential early driver of carrier cloud is off the table. That might well mean that cloud-native infrastructure planning will be delayed until some credible mission driver emerges. If that’s 5G IoT, we shouldn’t expect it to emerge soon, unless vendors can somehow move the ball here.
There are other drivers, of course, but they depend on operators raising their sights for future services above the network layer. Can they do that? Nearly 80% of operators say they can…eventually. We’ll see. It would have been great if we could have had a cloud-native network-layer approach to move things further, and faster, but operators don’t see that happening now, and I have to agree. Vendors? It’s up to you.
