Network APIs: The missing pieces of the $300B puzzle
May 22, 2024
I won't go into much detail about what network APIs are, as there are plenty of other resources available. However, for clarity, let's break down the acronym:
Network - Application - Programmable - Interface.
In simpler terms, these are interfaces (like a language) that application programmers use to communicate with networks. This blog is specifically aimed at network operators and vendors, those who develop and expose these APIs.
APIs to the rescue!
Network APIs are the promised saviour of next-generation networks. Network investments are drying up as telcos are not making a good enough return on investment from 5G (and perhaps also fiber deployments?). A combination of increased cost of capital and no willingness to pay extra for 5G is leaving the telcos in a tight spot.
Network APIs promise a new way of monetizing, which will drive demand and growth, and McKinsey estimates a market of $300B.
This blog will focus on what I believe are some missing pieces of the puzzle.
Why I get a say
At Domos, we made our first network APIs (Home Broadband/Wi-Fi troubleshooting within Chrome) through a network API from the home router nearly two years ago. This was showcased at the Telecom Council Innovation Showcase in Silicon Valley. This year at MWC, we demonstrated a project with KPN using our own network APIs combined with CAMARA Project QoD APIs. See a video here or read Michael Philpott's brief in Omdias here.
So, I do consider myself something of a network API hipster, with bragging rights on being there before it was cool.
Apparently this is what I look like (ChatGPT render for Network API hipster).
Some use cases and why developers will hesitate
The idea is simple: make network functions available as APIs and app developers will come. Then the money will come as well. Some example use cases:
Your app needs the location of the user, ask for SIM location.
Your app needs the user's identity, so you ask for it from the network.
Your app needs a very good network, ask for better network performance on demand.
The avid developer reader will no doubt have noticed these examples can be handled in other ways:
You can get location with GPS.
You can get identity with 2FA SMS or email.
You can simply display "poor network", "network issues" or something along those lines when the network quality is insufficient.
This is why telcos can't just build and assume developers will come. The entire point of this blog post is the next sentence:
Telcos have to create a better developer experience, or allow the developers to build better user experiences, without increasing hassle.
So, let’s explore some challenges that are holding back the developer experience (DX) or the user experience (UX).
"The Wi-Fi"
Most people are clueless about the differences between networks. My mum refuses to call any network anything other than "the Wi-Fi" (actually in Norwegian it is “Wi-Fien”). If you, as a telco guy or gal, ask your average developer about networking, you would be shocked by the lack of understanding and how little they care.
A huge blind spot in the network API vision is other networks than 5G. Home Wi-Fi and Enterprise Wi-Fi are the biggest missing pieces.
How are developers supposed to create, for example, a gaming or productivity solution relying on a network API when it breaks down when moved inside the home or into an office? Note, I am not nearly the first one to point this out. Geoff Hollingsworth points this out in his blog on trying network APIs, which is well worth the read, and Dean Bubley has been hammering this point for a long time (just take a look here and here).
This should be an opportunity for operators who love the double, triple, quadruple play convergence, yet most (not all) APIs are currently 5G-focused.
There are, of course, outdoor-only use cases such as drone delivery and whatnot, but by not including other networks enough, many use cases, and almost all direct-to-consumer use cases, go out the window (or actually, they struggle to enter the window).
Consumer app developers will not want to deal with a network API that only works in a subset of use cases. Too much hassle!
Developers got trust issues
Quality on Demand (QoD) is the most obvious use case. There is no other way you can increase the network quality as an app developer. All you can do is reduce the bandwidth requirements of your app (which hurts the user experience).
The idea of QoD makes a few assumptions:
The network is not good enough.
The network quality can be improved sufficiently by applying QoD.
First, we have to address: Are the networks bad enough? (Please don’t take this as a challenge and make it worse!) While we can all acknowledge that there are times when our apps don’t work perfectly, how often is this for most apps?
On the second point, we know that if signal strength is poor, no amount of QoD will help. Additionally, if there is enough congestion, the performance can only be improved by reducing some other app's network quality. (If not, then what is the point of Quality on Demand? Why can’t you just make the quality great for everyone if there is no trade-off?)
The questions developers will have are:
How do I know that QoD will improve the experience?
How much will it improve the experience?
Are there many levels of QoD?
Can someone outbid me?
While this may seem nit-picky, you can be sure that these are the types of questions developers need answers to before they can justify implementing anything. Especially if there is a price tag attached to it. Developers all hear horror stories about bugs racking up $$$$ in AWS bills.
Developers need (what we in Domos call) Proof of Enhancement. They need to know that if they pay for something, or ask someone else to pay for something, that it actually makes a difference!
Without something like:
If I pay $0.01, it will improve the likelihood of my app being perfect by 55 percentage points.
No sane developer is ever going to implement it! With this, developers can easily set thresholds, quantify improvements, and perform cost/benefit analysis.
As Geoff pointed out in his blog, there are few use cases (at least mass market) where guarantees are possible!
Guarantees are most often impossible; you can increase probabilities!
I highly recommend looking into the IETF Quality of Outcome (QoO) for this (I am totally not biassed).
User experiences
A cool showcase of Quality on Demand was shown by my friends at Broadpeak. They deliver video streaming solutions and asked for QoD when live streaming buffers were close to getting empty.
This is very cool, but what happens to this solution when the telco wants to charge for the QoD? Whether apps will actually pay for improved performance for the users is very much unclear. Will the end-user want to pay?
I have personally encountered situations, such as trying to have a video conference from an airport with very poor network quality, where I would be willing to pay A LOT for 30 minutes of higher quality network.
When the end-user is involved, we need to think seriously about the UX. How can this be presented to an end-user? (Using "end-user" is a broad term here. It could be an IT admin, a drone administrator, or any typical person.) Of course, it would be great if there was a consistent UX across apps with the same language, symbols, and cost structures.
For user experience and earning trust from the user, consistency is key.
You’ve seen this before, and you trust it to log in to different sites.
If you see something like this, you rightfully should be sceptical!
The UX also needs Proof of Enhancement. With Proof of Enhancement, telcos can build trust within apps. If Microsoft Teams or Zoom told me I needed to buy a premium network to get a great call and made it easy for me, I would buy it!
You Get an API, You Get an API, You Get an API…
Telefonica, Orange, Vodafone, DT, AT&T, etc., all have their own developer hubs. That’s great for the operators, but it is not convenient for the everyday developer to communicate with all of these. Remember, telcos can’t increase the hassle; developers are lazy (in a good way). Having to implement different APIs for each operator would drastically reduce the developer experience.
However, hyperscalers and a couple of telecom vendors are already hard at work implementing these, so it is far from my biggest worry. As is IETF (API Catalog).
However, I still want to make this point to ensure that no telco makes it difficult to share network APIs across their competitors. Network APIs should not be about winning customers per se, but to ensure that when they want something extra, they get it from the telco and not somewhere else.
There are a few pieces of the puzzle that need to fall into place for network APIs to become a success story.
Understand Network APIs
Getting the hang of Network APIs can be tricky, and a lot of developers and operators are missing out on the key insights that really make them shine. If you want to dive into Network APIs and truly grasp what they’re all about, our upcoming webinar series with CAMARA is the perfect starting point. This is a pure knowledge-sharing event happening on June 12 and July 10, and any developer or operator is welcome.
I won't go into much detail about what network APIs are, as there are plenty of other resources available. However, for clarity, let's break down the acronym:
Network - Application - Programmable - Interface.
In simpler terms, these are interfaces (like a language) that application programmers use to communicate with networks. This blog is specifically aimed at network operators and vendors, those who develop and expose these APIs.
APIs to the rescue!
Network APIs are the promised saviour of next-generation networks. Network investments are drying up as telcos are not making a good enough return on investment from 5G (and perhaps also fiber deployments?). A combination of increased cost of capital and no willingness to pay extra for 5G is leaving the telcos in a tight spot.
Network APIs promise a new way of monetizing, which will drive demand and growth, and McKinsey estimates a market of $300B.
This blog will focus on what I believe are some missing pieces of the puzzle.
Why I get a say
At Domos, we made our first network APIs (Home Broadband/Wi-Fi troubleshooting within Chrome) through a network API from the home router nearly two years ago. This was showcased at the Telecom Council Innovation Showcase in Silicon Valley. This year at MWC, we demonstrated a project with KPN using our own network APIs combined with CAMARA Project QoD APIs. See a video here or read Michael Philpott's brief in Omdias here.
So, I do consider myself something of a network API hipster, with bragging rights on being there before it was cool.
Apparently this is what I look like (ChatGPT render for Network API hipster).
Some use cases and why developers will hesitate
The idea is simple: make network functions available as APIs and app developers will come. Then the money will come as well. Some example use cases:
Your app needs the location of the user, ask for SIM location.
Your app needs the user's identity, so you ask for it from the network.
Your app needs a very good network, ask for better network performance on demand.
The avid developer reader will no doubt have noticed these examples can be handled in other ways:
You can get location with GPS.
You can get identity with 2FA SMS or email.
You can simply display "poor network", "network issues" or something along those lines when the network quality is insufficient.
This is why telcos can't just build and assume developers will come. The entire point of this blog post is the next sentence:
Telcos have to create a better developer experience, or allow the developers to build better user experiences, without increasing hassle.
So, let’s explore some challenges that are holding back the developer experience (DX) or the user experience (UX).
"The Wi-Fi"
Most people are clueless about the differences between networks. My mum refuses to call any network anything other than "the Wi-Fi" (actually in Norwegian it is “Wi-Fien”). If you, as a telco guy or gal, ask your average developer about networking, you would be shocked by the lack of understanding and how little they care.
A huge blind spot in the network API vision is other networks than 5G. Home Wi-Fi and Enterprise Wi-Fi are the biggest missing pieces.
How are developers supposed to create, for example, a gaming or productivity solution relying on a network API when it breaks down when moved inside the home or into an office? Note, I am not nearly the first one to point this out. Geoff Hollingsworth points this out in his blog on trying network APIs, which is well worth the read, and Dean Bubley has been hammering this point for a long time (just take a look here and here).
This should be an opportunity for operators who love the double, triple, quadruple play convergence, yet most (not all) APIs are currently 5G-focused.
There are, of course, outdoor-only use cases such as drone delivery and whatnot, but by not including other networks enough, many use cases, and almost all direct-to-consumer use cases, go out the window (or actually, they struggle to enter the window).
Consumer app developers will not want to deal with a network API that only works in a subset of use cases. Too much hassle!
Developers got trust issues
Quality on Demand (QoD) is the most obvious use case. There is no other way you can increase the network quality as an app developer. All you can do is reduce the bandwidth requirements of your app (which hurts the user experience).
The idea of QoD makes a few assumptions:
The network is not good enough.
The network quality can be improved sufficiently by applying QoD.
First, we have to address: Are the networks bad enough? (Please don’t take this as a challenge and make it worse!) While we can all acknowledge that there are times when our apps don’t work perfectly, how often is this for most apps?
On the second point, we know that if signal strength is poor, no amount of QoD will help. Additionally, if there is enough congestion, the performance can only be improved by reducing some other app's network quality. (If not, then what is the point of Quality on Demand? Why can’t you just make the quality great for everyone if there is no trade-off?)
The questions developers will have are:
How do I know that QoD will improve the experience?
How much will it improve the experience?
Are there many levels of QoD?
Can someone outbid me?
While this may seem nit-picky, you can be sure that these are the types of questions developers need answers to before they can justify implementing anything. Especially if there is a price tag attached to it. Developers all hear horror stories about bugs racking up $$$$ in AWS bills.
Developers need (what we in Domos call) Proof of Enhancement. They need to know that if they pay for something, or ask someone else to pay for something, that it actually makes a difference!
Without something like:
If I pay $0.01, it will improve the likelihood of my app being perfect by 55 percentage points.
No sane developer is ever going to implement it! With this, developers can easily set thresholds, quantify improvements, and perform cost/benefit analysis.
As Geoff pointed out in his blog, there are few use cases (at least mass market) where guarantees are possible!
Guarantees are most often impossible; you can increase probabilities!
I highly recommend looking into the IETF Quality of Outcome (QoO) for this (I am totally not biassed).
User experiences
A cool showcase of Quality on Demand was shown by my friends at Broadpeak. They deliver video streaming solutions and asked for QoD when live streaming buffers were close to getting empty.
This is very cool, but what happens to this solution when the telco wants to charge for the QoD? Whether apps will actually pay for improved performance for the users is very much unclear. Will the end-user want to pay?
I have personally encountered situations, such as trying to have a video conference from an airport with very poor network quality, where I would be willing to pay A LOT for 30 minutes of higher quality network.
When the end-user is involved, we need to think seriously about the UX. How can this be presented to an end-user? (Using "end-user" is a broad term here. It could be an IT admin, a drone administrator, or any typical person.) Of course, it would be great if there was a consistent UX across apps with the same language, symbols, and cost structures.
For user experience and earning trust from the user, consistency is key.
You’ve seen this before, and you trust it to log in to different sites.
If you see something like this, you rightfully should be sceptical!
The UX also needs Proof of Enhancement. With Proof of Enhancement, telcos can build trust within apps. If Microsoft Teams or Zoom told me I needed to buy a premium network to get a great call and made it easy for me, I would buy it!
You Get an API, You Get an API, You Get an API…
Telefonica, Orange, Vodafone, DT, AT&T, etc., all have their own developer hubs. That’s great for the operators, but it is not convenient for the everyday developer to communicate with all of these. Remember, telcos can’t increase the hassle; developers are lazy (in a good way). Having to implement different APIs for each operator would drastically reduce the developer experience.
However, hyperscalers and a couple of telecom vendors are already hard at work implementing these, so it is far from my biggest worry. As is IETF (API Catalog).
However, I still want to make this point to ensure that no telco makes it difficult to share network APIs across their competitors. Network APIs should not be about winning customers per se, but to ensure that when they want something extra, they get it from the telco and not somewhere else.
There are a few pieces of the puzzle that need to fall into place for network APIs to become a success story.
Understand Network APIs
Getting the hang of Network APIs can be tricky, and a lot of developers and operators are missing out on the key insights that really make them shine. If you want to dive into Network APIs and truly grasp what they’re all about, our upcoming webinar series with CAMARA is the perfect starting point. This is a pure knowledge-sharing event happening on June 12 and July 10, and any developer or operator is welcome.
