The Case Against Full Life-Cycle API Management

Why you should decouple API runtimes and management

The importance of APIs for business has risen tremendously in the last few years. Besides the usual citations like “Every company is a software company” or “if software eats the world, API eats software”, several studies have been conducted, that clearly shows that companies that deeply care about their APIs or even apply an API-first strategy have big advancements in the market place.

APIs (both inbound and outbound) have become a so essential and important building block of corporate IT landscapes that they absolutely need to be managed as well.

Until now, that usually meant putting an API management platform in front of it, using the management tools of this platform, and calling it a day. However, this does not reflect the importance of API management. Moreover, what you manage with this approach is not your APIs, but the generated API proxies running on that (and only that) management platform.

We believe that there is a better way to manage APIs and that there is a way to drastically improve your return on API. You shouldn’t be limited to one platform, and you shouldn’t have to recreate all of the settings when you switch to another platform resulting in a huge cost of change. The policies, guidelines, and specs of your APIs should be managed on their own, independent of the runtime that is used. They are the core of your API strategy, they are what makes or breaks your landscape. The runtime, however, should focus on what it does best: Serving and checking as many requests as possible in the shortest amount of time possible. Fully transparent for all management tasks.

In this article, we will look at the core elements of APIs and API management, which elements should be centralized and which should not, and how APIIDA’s products naturally fit into this and help you achieve excellence in the space of API management.

The Core Tasks of API Management

API Security

APIs expose data and services to the outside world. As such they actively need to be protected. You have to control which applications access your APIs, which users perform the requests and if they are allowed to do so. Some APIs even return different sets of data depending on the role and authorizations of the user executing the request. All of these sub tasks form the task of API security. But instead of managing security at the API level and replicating it again and again, API management moves this cross cutting concern to a higher level. This allows the APIs themselves to focus on their business targets and getting rid of a lot of code directed at those cross cutting concerns.

API Discovery

In order to use an API developers and business process designers need to know that the API even exists in the first place. As well as the description of the API the developers also need access to its documentation. This task of finding APIs and accessing their documentation is usually referred to as API discovery. A good developer experience boosts adoption and retention of API products. For the API itself, discovery is of no relevance. Because of this API discovery can be pushed up to a higher level as well. This higher level can also ensure, that certain best practices are applied like high quality descriptions or clear use case descriptions to fully leverage the API’s business value.

API Provisioning

If you decide to manage your APIs, you usually do so by deploying an API management platform. These platforms create a proxy of your APIs which is called by the consumers instead of the real API. The proxy performs all the necessary steps to protect your APIs or to transform data from one format to another. It then forwards the call to the real API and returns its results back to the consumer. These proxies need to be provisioned. Some management platforms require the user to define the proxy’s security policies within a management user interface, others allow their definition as code in declarative files. While the proxies themselves are bound to the runtime they are executed in (the so called API gateway), their definition is not. This definition along with corporate wide policies on how APIs should be protected form the core of API provisioning. While the act of provisioning a proxy to an API gateway is tightly coupled to the platform used, the process around it, APIOps, is not. Thus the process, the specs and policies can be managed at a higher level.

Full Life-Cycle API Management

Definition

Full Life-Cycle API Management platforms span the whole life-cycle of an API. Starting with its design, following on with implementation, testing, securing, managing access to it and even monetization. The whole process is repeated during the life time of an API. Usually this ever continuing cycle is depicted using a moebius band.

The basic promise of a full life-cycle management product is that you only need this one system to run your API program. The better the single steps are integrated with each other, the more synergies can be leveraged. The goals: reduction of the total cost of ownership and improvements to the performance of the API program.

The Case Against Full Life-Cycle API Management

If full life-cycle management is such a great tool, then why are there even non full life-cycle platforms in the market? Full life-cycle platforms are usually built around one central element: the API gateway. This means that all other tools of the suite need the API gateway to work. As there is no widely adopted management interface standard for API gateways this results in a closed solution, that is only capable of managing the APIs located on this one API gateway. This misaligns with the reality in many organizations that have multiple API management solutions deployed. And this is by far more common than one might think. Every company running a multi-cloud strategy or a hybrid cloud / on-premises architecture has potentially multiple API management platforms at work.

So if the API landscape of a company is heterogeneous and highly complex, how can a closed system can deal with it. The answer is easy: It can’t. If you split up the above moebius band you basically get three different jobs, that have to completed in order to maximize your return on APIs.

Design Your API Contract and Create Its Specification

Designing APIs is a topic of interest of its own. Multiple books have been written just on this very topic. The tooling support in the market is great as well. Tools like Postman, Insomnia or Stoplight are very capable and the result of the design process – the API specification – is standardized. The Open API Specification (formerly also known as Swagger) is well defined and widely supported by all mainstream API management platforms. APIIDA is a sponsoring member of the Open API initiative as well, as we strongly believe this vendor-agnostic specification will carry the API industry in the coming years.

If processes, tools and interoperable formats are available, why should a company settle on a less capable solution for API design just because it is integrated into a bigger platform?

Manage Your API in Regards to the Tasks We Identified Above (Security, Discovery, Provisioning)

As discussed above the tasks of Security, Discovery and Provisioning can be moved to a higher level and be looked at isolated from the API gateway that will execute the request. Moving these considerations up one level allows companies to really plan, execute and control their API strategies, without being limited by the capabilities of their full life-cycle API management platform.

Also, having an API management (and thus a discovery) that spans all API platforms in the company allows developers – both external and internal ones – to build solutions on top of everything the company has to offer and not only on some subset of services and data made available by one single business unit. If you are interested in why a unified developer experience will enable and boost API adoption in scale, check out our blog post on the matter.

The input to this stage is the specifications derived in the design step. The output are the API proxies, that are transported into the API gateways for execution. Both artifacts are well defined, so that there is no reason why the full potential of API management could only be leveraged in a full life-cycle system.

Execute the API Proxy and Check Each and Every Request

Once the proxies are in place the task is to execute consumer’s requests and perform the checks defined in the proxies as fast as possible. There are a lot of API gateways in the market and many of them boast their speed of execution as their primary selling point. And this is basically what you want from your gateway. Speed, Robustness and Security. However, none of these characteristics require a tight coupling with other tools in the tool chain. So, full life-cycle management systems have no advantage in this discipline compared to specialized “only gateway” solutions.

The APIIDA Solution

At APIIDA we focus on API management. We don’t want to create another Postman clone. We don’t want to come up with new, creative ways of designing APIs in a collaborative way. This is the reason we joined the Open API initiative to make sure that these tools have a standardized, highly versatile output, that builds a perfect base for all the lifetime stages of an API that follow. By building on these specifications (no matter if imported manually, in a pipeline flow or automatically discovered from one of the connected systems) APIIDA enables the modern API economy. In a true “focus on one thing and make it perfect” approach, we won’t intercept with the lot of API gateways that there are in the market. These systems have been battle-hardened for years in the most challenging conditions and have stood the test of time and countless attacks. What we provide is a new way of managing your APIs. One that focuses on your APIs and allows you to bring your API strategy in line with your corporate strategy. One that levels the playing field of different API gateways and provides your developers with a consistent developer experience, that is crucial for high quality APIs and stellar API adoption.