APIs are the latest vendor-locked networking threat

0

In my business surveys, the number of people concerned about vendor foreclosures has hovered around 90% for the past 30 years. When you ask companies how they avoid it, they say “standard interfaces” or “open source”. Even today, the percentage that includes “API management” in their list of lock avoidance measures is in the statistical noise level, but APIs are perhaps the fastest growing locking problem. fast today, and they will surely become a major problem in the future.

API stands for “application programming interface,” but the term is widely used in software today to describe the interfaces between all software components used in an application, cloud, or even a network. APIs allow parts of software to communicate with each other and they are essential in any situation where software components rather than hardware devices are connected. What creates a challenge in locking APIs today is the fact that networking is moving more towards software, which means it is shifting to a model where APIs are just as important as these. standard interfaces, and companies are not keeping up with this significant change.

Inside a network device, you can expect to find four layers of software. Down there is Conductors that provide a general way to link things like Ethernet interface chips to the rest of the software. Above this, there is a Network Operating System (NOS) which provides general hosting capacity, and above it, “middleware” which manages the specific network functionality needed. In addition to all of this, there are network dependent applications, including management and service features such as 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 network or even wireless, and everyone understands that you can’t plug an input into the wrong outputs any more than you can plug an Ethernet cable into a USB port. What makes APIs different is that there is no physical connector to stop you from trying. An API represents a specification for exchanging messages. Every aspect of the message format, data structure, request / response synchronization, etc., is defined in the API specifications, and they all must match or the software using the API will not communicate properly. In other words, incompatible APIs break software, including software inside devices and network management centers.

Vendors know this, and many (especially in the networking space) authorize their APIs. This means that a company can only use APIs on the basis of the license terms. It may not be possible to attach software from another vendor to a licensed API, even if you develop the adapter software to do so, without violating the license terms. If you create software on a licensed API and subsequently modify 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 fix the problem.

Even when providers don’t specifically use APIs to lock you down, APIs can create an accidental lockout. Remember those four software layers? It is likely that each layer uses NOS APIs. Most NOS will use driver APIs, and middleware will likely use both NOS APIs and APIs from other middleware packages. All of this creates a network of interconnections, doesn’t it? Now suppose your NOS provider changes their API. Your primary middleware vendor supports and supports the change, but one or more other middleware vendors do not. If you install the new NOS, you break any middleware that doesn’t support API switching. If you don’t, you will lose the new NOS features and all new features from the single middleware provider that supports the new NOS API.

Even open source software has an API problem. Most open source licenses don’t prohibit customization, they only require that the source code be available. A vendor of an NOS or open source middleware, or network management software tool, could customize certain APIs, publish the source code, and be compliant with the open source license terms. But other software, still waiting for standard APIs for the software, would no longer work with it.

I have seen this problem with Linux, which has a number of distributions that include Linux and various middleware components. You may have an application that you want to run on Linux that uses Python, for example. Distribution “A” may include one version of Python, and distribution “B” may include another. If you are purchasing an application / tool that uses Python and the Python APIs change between versions, there may be no way to write software that can be portable to several distributions.

You connect the hardware with physical interfaces. You connect software with APIs. If networking, both at the level of network operations and within disaggregated devices, separates software from hardware and creates functionality by combining software packages, then you need to pay as much attention to APIs as you do to interfaces. physical, maybe even more.

How? ‘Or’ What?

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

The second step is to get the software version history when API changes are made. What you are looking for is the timeline of how changes creep into multiple software packages. If the provider of package A supports new APIs very quickly, and the provider of a competing package A is slow, you can expect issues to arise if an API change is made and you select it. provider who responds slowly. You may not be able to update your software without breaking an API connection until all providers that use the API are on the same page.

The last step is to contract 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 in a contractual clause.

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

Join Network World communities on Facebook and LinkedIn to comment on matters of concern to you.

Copyright © 2021 IDG Communications, Inc.


Source link

Share.

About Author

Comments are closed.