How to manage your API in an extended information system

API Management solutions have been evolving since the beginning. They are now a core component to modernize any Information System and numerous new business applications use it. But new technologies coupled with new usage challenges of API consumption models are on the rise. Let’s see how to take into account new patterns.

Multiplication of API consumption usage

The goal of an API is to be consumed by customers or developers. Initially, most of the APIs in Information systems were dedicated to developers. It represents the biggest chunk of traffic and it allows us to accelerate the modernization of internal applications. But some APIs are exposed to customers to leverage the business and to monetize data. So consumers can be internal or external and constraints are different from use cases. However, customer experience is very important each time.

API Management aims to virtualize APIs, manage their lifecycle and consumers. These APIs are based on the existing system. But they are heterogeneous and require many technical capabilities to the API Management solution. In this context, it’s a real challenge to expose them with a good level of security and performance.

Then consumers just have to search what they want in the catalog thanks to some tags and clear API documentation. It also offers capabilities to try them and provide an example code in different languages.

But a new kind of API consumption is emerging with Microservices API. The microservice approach is to create one feature per information system capability (login, get customer info etc.). The microservice capability should be exposed to an API which means a huge number of APIs. They are consumed globally by other microservices and potentially many teams spread in many projects. Consumers are mainly internal developers.

Traditional API Gateways couldn’t manage Microservices APIs because they require them to be closest to the microservice. So one gateway per micro-service. That’s a lot of gateways! It’s the reason why the concept of micro gateway exists: Light resources costs and Light capabilities. For example, secure interconnections with authentication or rate-limiting, traffic management with fault injection or ingress/egress capabilities.

To resume, an API Gateway covers North-South traffic with only one entry point. It’s a hub architecture. Although micro gateway covers East-West traffic with only relevant features to manage interactions. It’s a distributed architecture.

Multiplication of gateways for an extend Information System

Initially, API Gateway was deployed on servers on-premise to expose internal services. Sizing was static and a strong architecture was needed to support the hub usage.

But a lot of IT strategy is now based on Cloud. And API Gateway has to adapt their location with these new usages, so in Cloud, too. In fact, the Cloud approach is very different compared to the on-premise solution because of its openness. It is very easy to subscribe to one solution and to deploy it globally. And it is also easier to switch to another solution. Each department can deploy different solutions. As a consequence, an explosion of APIs in API Catalog.

On another aspect, Microservices API is associated with container technology. Developers are able to deploy their API in any container infrastructure without caring for server infrastructure. It’s very important because IT has more choice to deploy your API in the best environment and location for use cases.

All of this explains the apparition of multiple gateways inside the Information System. But consumers have to juggle with these platforms to find their APIs. Another problem, APIs could be developed many times because developers were not aware of their previous existence.

The answer to this challenge is the API federation

So, the best solution is to keep what is working and to federate all of these API with a global control plane adoption. Consumers aren’t interested by the way you choose to execute APIs, they will be interested in how to easily find them in one catalog. They will be interested in having the same subscription and follow all of their API consumption at the same location. And business providers will be interested in having a consolidated view of their API health and consumption. So they must provide a Unified Catalog for all kinds of APIs – a telemetry feature to API usage. That way both customers and developers can view all APIs consumed, regardless of their location.