Forum

A better mousetrap,...
 
Notifications
Clear all

A better mousetrap, or just a trap? Questions about Dish and AWS using the public cloud for 5G


shane
(@shane)
Member Admin
Joined: 1 year ago
Posts: 166
Topic starter  

By The Wizard of Roz Roz Roseboro, Consulting Analyst

I'm always happy to see CSPs pushing the envelope, raising the bar, taking the leap – pick your metaphor – and Dish's announcement of a strategic relationship with AWS to support its new 5G network is no exception.

Reliance Jio and Rakuten were among the more notable first movers on cloud-native mobile networks and Dish takes it to another level by using someone else's public cloud infrastructure. While Reliance Jio uses Microsoft's public cloud for internal functions, the Azure platforms supporting Jio's customer-facing cloud services are in Jio's data centers.

It's too early to say what lessons Dish's partnership will yield but it's worth noting that this isn't your typical telco-cloud partnership. Dish is a true greenfield opportunity, which simplifies things dramatically because integrating with legacy systems is off the table. Dish also doesn't have to worry about how to allocate resources across different lines of business, keep existing services running during a transition or maintain a hold on existing customers. Another way to think about it is, Dish is building a new plane in a factory while existing CSPs are trying to change engines mid-flight.

Here are three other questions my inner analyst-skeptic can't tune out:

How will Dish differentiate itself?

This is a question for all CSPs as they move to similar cloud-native architectures and functions, but seems particularly critical in Dish's case. Dish Chairman Charlie Ergen sounded like pretty much all of the other mobile network operators in the company's press release, calling out automation and time to market as key outcomes of its strategy, saying "leveraging AWS and its extensive network of partners enables us to differentiate ourselves by operating our 5G network with a high degree of automation, utilizing the talent of AWS-trained developers and helping our customers bring new 5G applications to market faster than ever before."

It wasn't clear to me in reading the announcements whether Dish plans to go after lucrative contract subscribers or more price-sensitive pre-paid subscribers. Contract subscribers look for value, too, but are willing to pay for what they want. Prepaid subscribers are more likely to churn for a better rate. How much customization can Dish do? Does it have the internal staff to do so? Will it rely on AWS or the developer community at large? In the near term, I expect it will leverage its (expected) lower cost base to aggressively price its services. As has been proven over and over, a race to the bottom may be disruptive and allow a new entrant to grab the low-hanging fruit, but it isn't conducive to the long-term health of a market.

On a related note, going a few layers deeper, I wonder how much needs to change to optimize for AWS infrastructure? I'm referring here to the cloud-native network functions (CNFs) that the vendor community is developing. It's not that the network functions can't run on AWS, but most if not all CSPs do some level of optimization to maximize performance on their infrastructure, and it's not clear to me who might do this or when. This leads to my next question:

Who will handle lifecycle management (LCM)?

I consider LCM among the most important wildcards when considering how successful this approach will be. Because Dish has run a network before, and AWS continues to fortify its telecom chops by bringing in experienced leaders from the industry, I expect that Dish and AWS are not minimizing the importance of LCM. I wonder, though, how it will work in a fully outsourced model. There are a lot of different entities involved with different types of responsibilities, and keeping everyone in alignment could prove challenging, especially since not everyone will have the same priorities. For years I've argued that a CSP would not relinquish control to a third party for critical network functions and operations. Is this somehow different because Dish will never have had that control? Regardless of the answer to this question, the next one remains just as relevant.

How risky is it to put all the eggs in one basket?

For good reason, much ink has been spilled discussing how vendor lock-in has/is moving from hardware platforms to cloud platforms, but I can't recall a situation where a CSP put so much faith in a single third party. Yes, there are plenty of examples of CSPs outsourcing network operations to their equipment providers, so perhaps I'm being hypocritical to harp on this as a risk. This feels, different, though. It could be because the technologies are still evolving. It could be because it's not clear who will be running the network operations. It could be because I'm not yet convinced that cloud-native services can show the same service resiliency as hardware-based services. While "five nines" may no longer be the expectation, telecom will surely continue to be held to a higher standard than Internet/IT companies.

Nearly as much ink is spilled each time one of the cloud titans experiences a service outage. Part of the appeal of cloud-native approaches is the ability to automatically recover from network errors, so perhaps this somewhat mitigates the risk. But it is still early days for cloud-native network functions, though, so I wonder how robust they will be at this point.

I'm as interested in this experiment as any I've seen in my 20 years of watching the telecom market, and I'm sure I'm not alone. AT&T, Verizon, Vodafone, DT, SK Telecom and others leading the charge to cloud-native must be just as curious to see how things unfold—and perhaps for a myriad of reasons.

For the US mobile operators, the entry of a new competitor with a vastly lower (presumably) cost base leads to a certain set of issues. For the broader telecom market, the results from the Dish/AWS tie-up could confirm there is a better way to build a network and accelerate existing trends or just as easily confirm that a go-slow approach to cloud-native might be prudent. More likely, though, is it lands somewhere in the middle, with some aspects working spectacularly well and others failing miserably. All eyes will be on this arrangement with the hopes that it serves as a model for others looking to transform how they build and operate 5G networks.

This topic was modified 3 weeks ago by shane

Quote