We just can’t shake stories that relate to public cloud providers and their possible interest in hosting network operator applications that would otherwise justify “carrier cloud”. It would be easy to read Microsoft’s rumored interest in Jio Platforms as a further indication that it covets the carrier cloud space. Jio is a giant in digital services in India, majority-owned by Reliance Industries Limited and with a lot of recent prominent investors, including Facebook. It has a lot of the stuff that would make up “higher-layer” services, they own a big mobile operator, and they already have an Azure relationship with Microsoft. The question, though, is whether Microsoft is taking a stake in Jio for platform reasons, or just to buy into India’s digital services space. The answer may lie in what we think “higher-layer” services should be.
Jio is a kind of OTT success story. The parent company (Reliance Industries Ltd.) wanted to own India’s online experience, but realized that there wasn’t enough connectivity to create the experience in the first place. While Google in the US toyed with becoming a network operator (considering bidding on spectrum and actually moving ahead with limited fiber broadband) they never really committed. Jio’s parent did, obtaining wireless spectrum and becoming a successful mobile operator, but also promoting those higher-layer digital services. Some might see them as an example that established operators could follow, and that “some” might include Microsoft, already committed to hosting some carrier-cloud functions.
Pretty much everything we do on IP and the Internet is a “higher-layer” service. Web hosting and viewing, video and music content, digital storefronts, chat in any form, and even email are part of what most users think of as the Internet, and thus “over” IP. These are all services we have and use now, and they happen to be the higher-layer stuff that Jio offers too. However, everyone knows that network operators (the Internet service providers or ISPs) aren’t exactly giant players in these service spaces. For decades, operators have grouched over having been “disintermediated” by over-the-top (OTT) players, in fact. Could Microsoft be seeing Jio-like stuff as a conduit for operators to get into the OTT services?
A possible data point supporting the notion that Jio might be seen as a source of “OTT application platform elements” is Apple’s rumored interest in the cloud. Apple, as I noted in the blog referenced here, seems unlikely to be thinking of getting into the platform business. They’d be more comfortable with a service business anchored in some new device or device set. If the stories about Apple and the cloud are true, Microsoft might be wondering if apple plans on helicoptering to the summit of Everest while Microsoft slogs up the snowy slopes. You can’t get disintermediated at the top of the food chain; the retail service positions.
The flip-side question goes back to carrier cloud and the six justifying drivers that operators have accepted for almost a decade. If we forget “higher-layer” and look instead at what operators thought/think could justify major data center deployments, the items on the list are less services direct to customers than they are “services” as feature elements or foundation pieces of something else. Things like IoT and 5G are on that list, for example. If operators are thinking “platforms”, then they believe that they have to build a retail service story from the bottom. A cloud provider like Microsoft, going after OTT applications, might actually be taking a risk by looking like they might be trying to leapfrog their prospective customers.
How valuable might Jio be as a platform? It’s difficult to say how their digital services have been built, and whether they are based on reusable components that could become carrier cloud ground-floor technology of the kind operators seem to think they want. I don’t have a lot of contact with the internals of Jio, but industry-wide, it’s been rare for people to develop retail OTT services based on a grand architecture to promote reuse. Competition in the space demands quick action.
There’s also a problem with what a higher-layer service platform would even look like. Jorge Cardoso, years ago, working in an EU university, did a prototype application framework built on a combination of TOSCA and USDL. This framework was tied to examples of retail higher-layer services. Initiatives in operator standards groups have tended to focus on how to deploy higher-level services as a set of cooperative components, but not on defining the services themselves. NFV described how to do virtual functions, but not what to do with them, and TMF work has a similar deployment-versus-functionality bias.
The key point, though, is that there’s a hole-in-the-middle here. The Cardoso model and the operator model (or the cloud container/orchestration model) leave a gap, which is the way that retail services relate to platform features. Service middleware, in other words.
We have “service middleware” in public cloud computing. All the dozens of web services offered by the cloud providers are tools from which cloud applications (or services) can be composed. If you look at the set offered by Amazon, Google, and Microsoft, you see that some are generic (database, compute) and some are specialized (content, IoT). Anyone who wanted to build a generic platform for credible higher-layer services would need to define middleware, and to do that would also need to frame an architecture that ties the pieces together.
“Cloud-native” is not that architecture, nor is it a useful step toward functionally derived middleware. What good would Amazon’s or the other cloud providers’ web services have been if they didn’t map to functionality cloud buyers would build into their applications? You have to have functionality in mind, and we’re still missing that piece.
Interestingly, the same TOSCA that Jorge Cardoso used could actually help create functional models. I’ve been talking with a long-time “virtual friend” and TOSCA expert, and I’m working through the notion of doing a TOSCA guide for service planners. In the process, I realized that when you attempt to model a service, you’re forced to consider functional blocks. Model several services, and you start to see the potential for creating common/shared elements.
I think this could be another avenue for operators (at least those serious about “higher-layer” services) could pursue. Service models are, as noted earlier in this blog, a bit “in-the-middle” with respect to the work on higher-layer services. You have to see the top layer to do the model, and you have to understand the goals of the lower (hosting and connection) layers to realize those goals. The models let you play in abstract rather than getting bogged down in details.
Because TOSCA supports the concept of “inheritance” common to programming languages, TOSCA could also encourage network operators to think about defining a hierarchy for device and service types. For example, “Edge_Device” might be a superclass, subdivided into things like “Firewall”, “Access_Router”, and so forth. Things that implement a given device type would be expected to fit into a TOSCA-defined deployment without tweaking, which would simplify the onboarding issue. Subclasses would be expected to implement the properties of the superclass hierarchy above, which simplifies model-building and management.
But to get back to Microsoft, I think the model-and-middleware approach suggests a pathway that Microsoft could follow to leverage Jio to play a role in platform-building. A role like that would have greater value to Microsoft if they believe that they have a shot at hosting a bunch of operator carrier-cloud missions. But whether Jio could contribute significantly to a middleware strategy is difficult to say. We’ll have to await further developments.
