The Future of API Management

With the adoption of API-first within a large number of companies the number of APIs that are published is growing exponentially. At the same time the API ecosystem is expanding into new territories and standards like GraphQL and AsyncAPI gain a lot of popularity lately. API Management vendors struggle to provide support for newer technologies in a timely manner. Because of this a lot of teams resort to specialized, highly dedicated API runtimes / gateways to get the job done. At the same time many companies would like to modernize their infrastructure components without sacrificing their legacy systems. These trends inevitably set an end to the “one size fits all” type of API Management solutions.

The logical consequence: Split the management of APIs from their execution. While the management system need to guarantee visibility, governance and adherence to security policies based on an per API basis, the runtimes need to focus on what they excel at: the speedy execution of client requests. This is what we at APIIDA call “True API Management”.

API Management – Done Right

Instead of proxying all requests through a new common API gateway, APIIDA’s solution is based on one compute science’s basic principles: Divide and Conquer. Instead of putting all of the functionality in one component or platform, we split things up into a management plane and the data plane built by existing API gateways and runtimes.

The management component focuses on the APIs itself. How can consumers and developers access them as easy as possible? Which APIs are published at all and which are available to the broader public and which are limited to certain partners? These and other API Management related questions are universal. They don’t have any obvious relationship with the runtime that will finally execute it other then that the runtime needs to enforce the constraints defined in the management solution. The runtimes on the other hand, need to get all of the low-level operations right. Bandwidth and memory management are crucial to be able to operate at the maximum throughput for an indefinite timespan. They don’t care about the discoverability of the developer documentation or what plan a user needs to subscribe to and in order to access the API. So why mix up these two components?

If one looks at the current API Management solutions one can cluster them into two groups: The ones that focused on the runtime and added management capabilities later on to be able to call themselves Full Lifecycle API solutions and those that started out as an API catalog of some sorts and then added runtime capabilities to be able to compete with the others. In the first case the systems offer a very wide variety of functionality, however the developer portals are often an afterthought or pressure the customers into a paid subscription. The latter have great developer flows but are lacking the stability and efficiency of the specialized runtimes. APIIDA’s API Management solution hits the sweet spot and delegates functionality to other systems.

Best of all? API platforms with a great runtime but a horrible management experience (i.e. AWS’s API Gateway) can be enhanced with a convenient management solution and a great developer experience without sacrificing any of the great runtime performance and integration within the AWS ecosystem.