Aggregators are joining the Network API party!
From hyperscalers to aggregators – how are the likes of Amazon and Microsoft redefining the network API space? This can impact everything from evolution to innovation and anything in between.
While aggregators may not be CSPs, they do have the power and capacity to scale business models and help CSPs and enterprises overcome the operational challenges ahead. They also offer the required platform-building capabilities to innovate
We often hear of hyperscalers scaling the business models and operations for enterprises and CSPs. In this blog, I look at how players from outside of the service provider community could impact the evolution of network APIs.
When first considering network APIs, I immediately thought of a world where each service provider exposed its own, hopefully universal, APIs. But very quickly my thoughts moved on from this model. Where there are service provider groups, like Telefonica or Vodafone, why would they not consider a single API platform? And then, going one step further with the scenario where a third-party, non-service provider, provides an API platform that aggregates APIs across multiple service providers.
A service provider group API brings the benefits of reduced costs for its owner and greater simplicity and coverage for the application developer. The impact of the aggregator API is less obvious.
In some ways, the aggregator approach is like the electronic payments market dominated by Mastercard and Visa. In this case, the two aggregators sit between the banks and the service / retail vendors. In our telecom case, the aggregator would sit between the application developer (and/or its end-user) and the telecom service provider (who runs the network).
Aggregators of network APIs could come from a few places.
- Service provider – it could provide a platform to address the global API market. The existing service provider groups are well placed to do this, possibly with some added collaboration.
- Vendor – it could decide to build an API platform and run it as a global service. Ericsson has done this with its Global Network Platform. Twilio is an aggregator in the voice call & message handling market. These vendors are typically saying they will support the CAMARA / GSMA Open Gateway initiatives.
- Cloud hyperscalers – they could decide to extend their cloud platform API services (such as storage or AI or compute) to offer communications services via service provider APIs. With their dominance of application hosting, this must be attractive.
Both Microsoft and Amazon have joined the GSMA Open Gateway initiative and talked about offering the GSMA APIs in their cloud platforms.
Microsoft has already launched its cloud API platform – it is called Azure Programmable Connectivity (APC). It also has already announced an ecosystem of AT&T, Rogers, T-Mobile US, Deutsche Telekom, Telefonica, and Singtel. Also in the ecosystem are other technology vendors like Ericsson (Vonage Global Network platform), and Nokia (Network as Code platform). Microsoft plans to focus on supporting MEC and 5G connectivity APIs to enhance the third-party solutions that it hosts.
In Microsoft’s words – “We envision APC becoming the best place for developers to access network APIs and operators to distribute their APIs by resolving these competing requirements. Our approach to APC is guided by three design principles:
- Network-agnostic programming abstractions: APC code should run on any supported network.
- Network-specific adapters: APC should translate its simple abstractions into operator APIs and support “escape hatches” for operator differentiation.
- Azure-integrated billing and credentialing: APC should hide the complexity of billing and credentialing.”
There are significant questions yet to play out in the market with aggregators, including:
- Who owns the commercial relationship with the consuming application?
If the service provider loses this relationship to an aggregator, it may push the network towards further commoditization, driving its value down. One of the drivers for APIs was the opportunity for the service provider to get into the application vendor’s value chain; an aggregator-based architecture could keep them on the outside of it.
- How is one service provider’s network API chosen over another?
A broker could play one service provider off against another. With eSIM going mainstream it would be easy for the aggregator to buy in bulk from service providers and act like an MVNO for APIs. And then quickly move M2M applications/devices between the service providers offering the best value at that time. This could create extreme price competition.
- How is roaming managed?
Roaming while using APIs is likely to be commercially complex and potentially lucrative to the home network service provider. Moving an application from one network to another by an aggregator could bypass this.
- How are different levels of network API deployment exposed to the consuming application?
It is likely that the deployment of APIs will become a regionalized feature. We already see this with the cloud vendor services today. Applications will expect “a region” to offer the APIs universally, and cloud vendor regions are typically bigger and different from service provider markets.
- Should a service provider always have its own network API platform?
Subscribing to an aggregator’s API platform could result in the service provider being locked in. If the service provider has its own platform, then it can always negotiate directly – maybe with large enterprises - and use the aggregator’s platform for wider market access.
Because it is simple and therefore attractive for applications, it is likely that we will see aggregators having a good chance of making a success of this network API market. If they do, I believe it will put the service providers in a weaker commercial position. However, it is likely that the service provider groups are in the best position to counter this market outcome.
