APIs pose the latest threat of networking-vendor lock-in

In my surveys of enterprises, the number worried about vendor lock-in has hovered around 90% for 30 years.  When you ask enterprises how they avoid it, they respond “standard interfaces” or “open-source”. Even today, the percentage who include “managing APIs” in their list of lock-in avoidance measures is in the statistical noise level, but APIs are perhaps the fastest-growing lock-in problem today, and they’re surely going to become a major problem in the future.

API stands for “application programming interface”, but the term is broadly used in software today to describe the interfaces between all the software components used in an application, a cloud, or even a network. APIs let pieces of software talk with each other, and they’re essential in every situation where software components rather than hardware devices are connected. What’s creating a challenge in lock-in from APIs today is the fact that networking is shifting more to software, which means it’s shifting to a model where APIs are just as important as those standard interfaces, and enterprises aren’t tracking that important shift.

Inside a network device, you can expect to find four layers of software. At the bottom, there are drivers that provide a general way of linking things like Ethernet interface chips to the rest of the software. Above that, there’s a network operating system (NOS) that provides general hosting capability, and above that is “middleware” that handles the specific network features needed. On top of it all are network-dependent applications, including management and service features like unified communications or denial-of-service mitigation. Each of these layers exposes APIs to the other layers.

We’re used to different hardware interfaces, Ethernet or passive optical networking or even wireless, and everyone understands that you can’t plug a goes-into into the wrong goes-out-of any more than you can plug an Ethernet cable into a USB port.  What makes APIs different is that there’s no physical connector to stop you from trying. An API represents a message exchange specification. Every aspect of message format, data structure, request/response synchronization, and so forth, are set forth in API specifications, and they all have to match or the software using the API won’t communicate correctly.  In other words, mismatched APIs break software, including the software inside devices and network management centers.

Vendors know this, and many (particularly in the network-management space) license their APIs.  That means that an enterprise can only use the APIs based on the license terms. It may be impossible to attach software from another vendor to a licensed API, even if you develop the adapter software to do that, without violating the license terms. If you build software to a licensed API and later change the software, you may lose the right to use the API.  I saw this particular problem in action at a financial services company, and it took them months to work through the issue.

Even when vendors aren’t using APIs specifically to lock you in, APIs can create accidental lock-in. Remember those four software layers? It’s likely every layer uses NOS APIs. Most NOSs will use driver APIs, and middleware will likely use both NOS APIs and the APIs of other middleware packages. All this creates a web of interconnection, right? Now suppose that your NOS vendor changes its API. Your primary middleware vendor picks up the change and supports it, but one or more of the other middleware providers doesn’t. If you install the new NOS, you’ll break all the middleware that doesn’t support the API change. If you don’t, you’ll lose the new NOS features and any new features of the single middleware provider that does support the new NOS API.

Even open-source software has an API problem. Most open-source licenses don’t forbid customization, they only mandate that the source code be made available. A supplier of an open-source NOS or middleware, or of a network-management software tool, could customize some APIs, release the source code, and be compatible with open-source licensing terms. But other software, still expecting the standard APIs for the software, would no longer work with it.

I’ve seen this problem with Linux, which has a number of distributions that include Linux and various middleware components. You might have an application you want to run on Linux that uses Python, for example. Distro “A” might include a version of Python, and Distro “B” might include another. If you acquire an application/tool that uses Python, and if Python APIs change between versions, there might be no way to write software that could be portable across the multiple distros.

You connect hardware with physical interfaces. You connect software with APIs. If networking, both at the network operations level and within disaggregated devices, is separating software from hardware and building functionality by combining software packages, then you need to be paying just as much attention to APIs as you do to physical interfaces, maybe even more.

How?

The first step is to require that all software products include a full description of all the APIs they expose and consume. That description has to include a reference to any standard they claim to support, and a full description of any enhancements or extensions.  It also has to include the license terms, if any, associated with each of the APIs, and you should ask for sample code that uses the API to confirm how it works.  Obviously, if you plan to connect Package A and Package B via an API, their API descriptions have to match fully, or you have to be able to avoid situations (like specific features or commands) that would invoke an extension that both packages don’t support.

The second step is to obtain version histories on the software when any API changes are made. What you’re looking for is the schedule of how the changes percolate across multiple software packages. If the vendor of Package A is very fast in supporting new APIs, and the provider of a competing Package A is slow, then you can expect problems to arise if an API change is made, and you select the slow-responding vendor. You may not be able to update your software without breaking some API connection until all the vendors who use the API are on the same page.

The final step is to contractualize your assumptions. Even the best research can miss changes in policy or direction, and if a software vendor changes an API, the result could break an application or a network. Get promises written into a contract clause.

A network device or application is an example of the classic definition of a “black box”, an object that’s opaque and so whose structure cannot be examined in detail. Black boxes are defined, so the saying goes, by the relationship between their inputs and outputs. Software is really defined by the relationship between those APIs, the ones people aren’t paying as much attention to as they should. If you want to avoid vendor lock-in, deliberate or accidental, then you need to take APIs seriously.