Technology planning, for operators, is the traditional start of their budget cycle. While budgets are usually calendar-year, technology planning typically starts in the second half of September and runs through mid-November. The priorities for each of these planning seasons sets the tone for spending not only in the coming budget cycle, but for several cycles beyond.
I usually do a fall planning analysis (THIS is the analysis of last year’s results), sometimes early in the cycle to look at things that operators are already watching. This is one of the years I do that, because there are a lot of questions and issues on their minds. What I want to do here is introduce the only really new issue operators mentioned, then explore where operators are on the technologies they focused on during the last planning cycle.
The new issue is SD-WAN. Operators were not really looking at SD-WAN last year because they saw it as another of those annoying over-the-top, leverage-my-services, exploitations. Most still do, at least in part, but all the Tier Ones and about a third of Tier Two operators are thinking they may have to be a bit more proactive with SD-WAN.
One reason is the recognition that SD-WAN is going to happen whether the operators offer it or not. In fact, a couple of Tier One service strategists told me they now believed it was a mistake not to have jumped aggressively on the SD-WAN bandwagon as soon as the technology emerged. “If we’d entered the market ourselves, we might have discouraged competition in that critical early period,” one strategist said sadly. Instead, the operators let managed service providers and enterprises disintermediate them, then belatedly realized that they’d lose less if they displaced their own MPLS VPNs than if they let others displace them.
A better reason is defined by AT&T’s comments on achieving over three-quarters replacement of MPLS with SDN in the core. A service, operators are coming to realize, is the demarcation interface and the service-level agreement (SLA), not the internals. Virtual networking can offer lower capex and opex, but you have to preserve the service interface to the user. SD-WAN can, in theory, run over any transport technology that provides connectivity among the sites being served. Operators know that even without SD-WAN from MSPs, enterprise price pressure on VPNs was cutting profits alarmingly, demanding a corresponding reduction in cost. SD-WAN could provide it.
The question is how SD-WAN should be positioned. The conservative operator planners think it’s a pure low-end VPN offering, something that companies would embrace (reluctantly) for sites where MPLS VPNs were too costly or unavailable. The very aggressive say it’s the foundation of a whole new service vision, something that lets them add security and other features to gain revenue, without adding a lot of cost. The middle-ground operators say it’s the model for future VPN services, a model that displaces MPLS eventually and lets things like SDN in. This planning cycle, operators hope to dig out a strategy for the next couple years.
Last year’s big question was 5G, and while there’s still a lot of budget interest in 5G, the technology planning for 5G isn’t showing very much change. Operators are committed to a 5G RAN, and many are also committed to millimeter-wave, but few have committed to 5G core. What I’m hearing now is that 5G core is a bit of a back burner for now, at least in a general case, because operators don’t expect much from it prior to 2021.
There is one question that’s emerged relative to 5G core, or at least one related to it. Many operators recognize that the current structure of the mobile metro infrastructure, which is what “core” really means in mobile terms, is based on a fairly primitive view of virtualization. 5G Core, which mandates NFV, is based on a model of virtualization that operators, at the very least, are skeptical about. They wonder whether there’s a virtual-network model for metro in general that would “subduct” the 5G Core issues. I hasten to note that this isn’t a universal concern; about a third of my Tier One contacts have it, but few Tier Two or Three operators are thinking about universal metro infrastructure now.
Millimeter wave is also an issue that impacts mostly Tier Ones, and impacts more where video/TV delivery competition is a major issue, as it is in the US. For decades, everyone accepted the view that TV was the golden goose of wireline, the service that justified the connections and kept the lights on for operators. Over time, video margins have shrunk, partly because of competition and partly because OTT streaming services that don’t mimic fixed linear-TV schedules have combined with mobility to disrupt viewing habits. Networks are also seeing revenue pressure as advertisers shift to cheaper and more easily targeted online ads.
The video problems are one reason why companies like AT&T and Comcast have been buying content companies—networks or studios. As pricing pressure mounts, consolidation in the value chain is inevitable, and smart at least to a point. However, it’s clear that broadband Internet is becoming the flagship of wireline, and in order to keep profits up, operators need to get costs down. Millimeter wave promises high bandwidth at a much lower cost than fiber to the home (FTTH), using a hybrid of 5G radio and fiber to the node (FTTN). Verizon just said that most customers will be able to self-install, which could be a major boon to operators.
The question for many operators in 2019 is whether the 5G/FTTN hybrid will cut costs enough, and the answer will of course depend on the nature of the service area. Where demand density (the measure of infrastructure to “pass” revenue opportunity) is high, 5G/FTTN is almost sure to deploy. As it declines, the problem is that even its pass cost relative to FTTH may not be enough, particularly if there is already CATV cable deployed. DSL against CATV is, in the long term, a losing battle.
There’s also a linkage between the virtualization and 5G/FTTN issue and last year’s second priority, which was carrier cloud. The questions operators had last year were primarily circling around the drivers of carrier cloud. Operators now admit they were hoping that early drivers would solidify the technical framework for carrier cloud, but they also admit that they didn’t get any early drivers to speak of. Thus, they don’t know what the technical model for carrier cloud should/will be.
This is where “cloud-native” comes in. Last year, it wasn’t a term that operators were using much, but this year most Tier Ones realize that it’s not enough to “migrate” to the cloud, you have to develop for it. That, of course, makes the technical model for carrier cloud critically important. It’s even more important when you consider that, lacking any single and convincing early driver of carrier cloud, cloud infrastructure and strategy for operators is at risk to being dispersed to death, dividing among a lot of implementations that don’t establish economies of scale in opex or capex.
Carrier cloud is important this year too, with cloud-native the leading topic, but even Tier Ones don’t seem to have a handle on things. One important development the operators themselves see is that some vendors are clearly interested in promoting what might be called a “cloud-native” ecosystem. There was a time when containers and Kubernetes defined the cloud, as far as operators were concerned, and so also defined “cloud-native”. Then they realized you had to supplement Kubernetes, what I’ve called the “Kubernetes ecosystem”, to make cloud-native complete. Now, some are thinking that perhaps we’re looking for a “cloud-native ecosystem” instead of a Kubernetes ecosystem.
The good news is that operators also think that vendors are moving in that direction. They cited IBM/Red Hat and VMware/Dell as examples of companies that, to them, are positioning a cloud-native framework and are large and credible (big enough to sue and collect) companies. These vendors were among the list that operators wanted as NFV partners during NFV’s heyday, in fact. Now they seem like they’re sprouting cloud-native wings.
But are the operators ready to take flight? Last year, the technology planning cycle seemed to have both a sense of purpose and a sense of urgency. This year, I’m getting a mixture of frustration, boredom, and cynicism. More planners are saying in 2019 that they don’t really know for sure what to be planning for in the coming year than said that in the last fifteen years, back to the dawn of “transformation”. They know what’s happening, they know they don’t really like it, but they don’t know what they should really be doing…yet.
This is what, in my view, the vendors (and VMware in particular) are trying to address. Operators have long seen their role as applying the technology made available to them, rather than influencing what that technology was and did. In something like cloud-native, where there’s no question that the industry in general is struggling, operators are struggling more. Many, perhaps even most, would love to adopt a model of cloud-native and base their future “carrier-cloud” deployments on it. If only they had one to adopt! Vendors would love to have them commit and spend, of course, and I think where VMware is leading the pack is in combining these points. Give the operators something they can believe in, and they’ll adopt it.
Enterprises are in the same boat, of course, which is why the ecosystemic approach to cloud-native makes so much sense. There are literally hundreds of thousands of data centers, a trillion incremental revenue dollars, and whole ranges of applications like IoT that depend on a cloud-native approach. Operators are usually laggards in adoption, but they represent such an enormous piece of the pie and they’re under such stringent profit pressure in their own businesses that they could look very promising indeed.
Cloud-native and carrier cloud, overall, are the big technology planning issues, because they raise the most technical questions. They also frame the way that things like 5G and IoT are likely to develop, which frames future revenue planning. For all their importance, though, operators (somewhat ruefully) admit they’ve not made much progress in prior years. They hope 2019’s cycle will be different, and of course, so do the vendors who hope for relief from budget constraints and pushed-out project plans.
They may not get that relief. I don’t see many vendors effectively pushing an ecosystem for cloud-native and carrier cloud. Without that vendor support, I don’t think the technology planners can really frame a model for the cloud in time for financial budgeting in early 2020. With all the political and economic distractions that year will bring, technical uncertainty certainly won’t be a help, so if vendors want a rosy 2020, they probably need to get their positioning in order.