Everyone loves to talk about APIs, so much so that you could be forgiven for thinking that they were the solution to all of the problems of the tech world. I did a straw poll, and wasn’t too surprised to find that only about 40% of network professionals had a good grasp of what APIs were and could do, and that almost 20% couldn’t even decode the acronym properly. All this, and yet there are many who say that APIs are the key to monetizing service provider networks, or the key to new services, or both. Are we leaping to API conclusions here, based on widespread misunderstanding? To answer that we have to dig into that “what-are-the-and-what-do-they-do” question.
API stands for “Application Program Interface”, and the term has been used for decades to describe the way that one program or program component passed a request to another. The concept is even older; many programming languages of the 1970s supported “procedures” or “processes” or “functions” that represented semi-independent and regularly used functionality. And even in the 1960s and the days of assembler-language programs, old-timers (including me) were taught to structure their logic as a “main routine” and “subroutines”.
All this shows that first and foremost, APIs are about connecting modular components of something. Back in the older times, those components were locally assembled, meaning that an API was a call between components of the same program or “machine image” in today’s cloud terms. What happened in the ‘70s is that we started to see components distributed across systems, which meant that the APIs had to represent a call to a remote process. The first example of this was the “remote procedure call” or RPC, which just provided a middleware tool to let what looked like a local API reference connect instead to a remote component. Web services and Service Oriented Architecture (SOA) evolved from this.
The Internet introduced a different kind of remote access with HTTP (Hypertext Transfer Protocol) and HTML/XML. With this kind of access, a user process (a browser) accessed a resource (a web page) through a simple “get” and updated it (if it was a form that could be updated) with a “post”. This kind of thing was called “Representational State Transfer” or REST. Most procedure calls are “stateful” in that they are designed to transfer control and wait for a response; RESTful procedures are stateless and the same server can thus support many parallel conversations.
So we have APIs that can represent remote processing functions or resources. Why is this so hot? The reason is that businesses that have processing functions or resources (cloud providers, web providers, and network operators) could sell access to these functions/resources. For network operators in particular, there’s been a theory that selling access to network services/features through APIs instead of selling traditional connection services, could be a new business model. Some pundits think that exposing all the network and management/operations features through APIs might be a significant revenue source. Could it?
Well, it depends. You can sell a service feature profitably if there are buyers and if the price the buyers are willing to pay generates a profit for you even after you factor in any loss of revenue created by having the features either create competition for or displace higher-level services you sell. In other words, would others leverage the stuff you sell through APIs to either compete with you broadly, or replace a composite offering you make with a cheaper set of piece-parts. We can see this in two examples.
In our first case, Operator A exposes operations services via an API. These provide for robust service ordering, billing, and customer care. A startup operator might never be able to establish these services on their own, but could they add them to a bare network and create a credible competitive offering? Yes, they could. Thus, the cost of the services delivered through the API would have to factor in this risk, and that might end up pricing them out of the market.
In our second case, Operator A exposes a simple message service among sites via an API. A customer who purchases connectivity services could take this message service and use it to carry transactions, which might allow them to replace the connectivity services. Unless the message service was priced higher, the result would be a net loss to the operator.
The point here is that the most likely way for APIs to pay off is if they represent new capabilities rather than exposing old ones. In the latter case, there will always be some risk that the exposure will in some way threaten the services that contributed the capabilities in the first place.
APIs that represent new services open a question, not of just what the APIs should look like but what the new services really should be. An example is IoT. Should an operator build a complete IoT service, or provide a set of low-level features for sale, enabling third parties to turn those features into a complete set of retail offerings? In short, should the operator use APIs to create retail-model or wholesale-model services?
The “classic wisdom” (which, I’m sure regular readers of my blog, I’ll contend isn’t wisdom at all) has been that operators should fall into a wholesale API model and expose their current service components. In other words, get a fillet knife and cut off pieces of yourself for OTTs to eat. The smart money says that operators have to get quickly to new features to expose, new service components, and then make a retail/wholesale decision based on the nature of the element.
IoT represents the best source of examples for that smart-money choice. Operators could look at the entire IoT event-to-experience food chain, and formulate an architecture to host key processes. They could then see how much work it would take to turn that into a retail service, what the revenue potential might be for that service, and whether there would be a risk that others might pick a better retail service choice to fund their own deployment of the basic processes.
IMHO, operators should look at something like IoT to frame a vision of an event-driven, context-enhanced, service future. That would give them a retail outlet on one hand, an outlet that might have enough profit potential to significantly reduce the magnitude of investment in infrastructure that operators would make before they saw enough revenue to break even and then show a profit. That’s “first cost” in carrier parlance. They could then, with retail value established there, expand at the retail level where they had market opportunity to exploit, and at the wholesale level where others could do it better.
The value of this approach is clear; you have a specific service target and revenue opportunity with which to justify the deployment of servers and software. The problem is nearly as clear; you need to convince the operators of a linkage, and that’s something I think vendors would ordinarily be expected to do. They’ve not done it yet, particularly in NFV, and while things were fiddling, the operators were focusing on an open-source solution. Today, five times as many operators think NFV will emerge from open-source projects like ONAP than from vendors. That’s bad because it would be very difficult to get the right architecture out of an open-source project.
It’s not that open-source isn’t a player. Most of the technology that will shape the kind of service-centric software infrastructure I’ve described comes from open-source. What doesn’t is the glue, the organized middleware tools and application notes, and that will require a unique marriage of software and network expertise. I don’t doubt that most vendors have the right individual skills somewhere, and that it exists in the open-source community, but the combining of the skills is going to be a challenge, particularly in development activity that has to start from scratch.
So, are APIs over-hyped? Surely; they are not a source of opportunity but rather a step in realizing a revenue model from new service features. In that role, though, they are very important, and it’s worth taking the time to plan an API strategy carefully—once you have planned the underlying services even more carefully! A gateway into a useless, profitless, service isn’t progress.
