API Management in General
API Management evolved from the service-oriented architectures of the ’90s. Some of the API Management players active today still date back to this era. Mostly built on the core principles of the WS-Security specification, Broadcom’s Layer7 API Gateway, for example, is rooted in this development. Instead of integrating the relatively complex logic of WS-* specifications within each and every web service, the early Gateways took over this task in a centralized approach and acted as a proxy between the consumers and the upstream services.
With the rise of Web 2.0 and the shift to REST-based web services, additional protocols were added, but the basic functionality stayed almost the same. When containerized platforms and orchestrators like K8s disrupted the IT landscape, the focus shifted from North / South Traffic – that is, traffic going in and coming out of the organization- to East/West Traffic – that is, traffic running within the organization. New architectures like microservices and new ways of thinking like Zero Trust created a new wave of API Management platforms integrating “classic” API 1.0 Gateways with Service Meshes. The API 2.0 platforms were born. One of the front runners is Kong. By providing a free and open-source base package, Kong also brought down the prices for professional API Management significantly.
In the last few years, a new trend emerged in the scene. Driven by design principles like Event Sourcing and the rise of IoT asynchronous, event-driven APIs (or streaming APIs) have gained popularity. At the same time, new protocols like gRPC or GraphQL brought new challenges to “classic” synchronous Request/Response based APIs. Different API Platforms now support a different set of protocols. As the lifetime of protocols tends to shorten, this turned into a continuous struggle for the API Platforms to either keep up or specialize.
New challengers tried to copy Kong’s promise of a free API Management Platform and created many free and open-source Gateways. This led to a highly heterogeneous landscape. Together with the rise of APIs from a necessity to a strategic focus point, this leads to a shift in perception and tasks which eventually enforces a new way to think about API Management: Separating the APIs from their runtimes and acting on them as independent entities.
This disruption is similar to how K8s, Terraform, and others changed the cloud-native world in a sense, that it is now possible and strategically important to set up your operations in a way that embraces change, allows you to easily switch or expand the used services and to use the right tool for the job.
APIIDA shares this view on the API landscape with other high-profile API companies like Postman or RapidAPI. But while these think of APIs from a standpoint of collaboration and design, APIIDA is currently the only company thinking this from the other end, one of the operations.