Login

This time, it is different: API gateways

Back to homepage

Click here for an overview of all news articles

API gateways are not new – the first examples burst into the general IT scene back in the 2004-2006 timeframe. Most of the early products were developed by start-ups that were then acquired by IT giants, but some products came out of corporate R&D.
Over the past fifteen years, not only the capabilities but also the role of the API gateway have changed, just as the overall business, technical and regulatory environment are changing.

Deployment patterns
The early deployment pattern of API gateways was to deploy them in the DMZ to expose APIs to the general Internet or as a front-end before a server farm. This setup was quite monolithic and did not work well with the concept of microservices and functional clusters. The old deployment pattern is still used today, but additional patterns, where the API gateways are closely associated with a functional cluster often deployed in a cloud environment, are also becoming more and more common.

Authentication and authorization
One of the keys capabilities of the early API gateways was to provide authentication and authorization functionality. In most cases, a service account that was identified with a login and password or a certificate was authorized to access certain URLs. The authorization was usually limited to coarse-grained constructs with advanced fine-grained authorization, sometimes provided by integration with XACML-based authorization servers.
Today, the authentication is often based on federations, and claims-based authorization is getting more and more popular. Provisioning of identities leverages implicit just-in-time provisioning or SCIM calls, and most gateways do support LDAP-based centralized user stores. XACML is sometimes leveraged for authorization, but the standard is still waiting for the mass market breakthrough.

API Utilization and accounting

The original API gateways basically supported logging, but this functionality has been substantially expanded over the years. That change is driven by the ambition to directly monetize the API access on a per-call basis as well as by the switch to microservices, which enables rapid scale-up and scale-down of capacity. The API gateway can provide an overview of API usage as well as level of service, which is really helpful as an information source for service level agreement compliancy check and capacity planning.

API lifecycle and developer enablement
Today, the combination of API lifecycle, developer enablement and the associated workflow management is one of the core functions of an API gateway and is often one of the major business drivers for the deployment. These functions were very rudimentary on the early API gateways, so adding this capability could justify an upgrade program.

Conclusions
API gateway is a key component in a modern IT infrastructure not only to providing protection but also to providing an interface for API discovery and developer enablement. The product category has come a long way since the inception, and the functional role of the API gateway today is quite different from what was originally envisioned. The system architects need to take these changes into account and optimize the architecture to deliver the full business value.

Martin Sandren is a lead consultant at Nixu Corporation