State of Industry - API Gateways
When my team originally moved from an in-house platform to a commercial off-the-shelf (COTS) API Gateway, we quickly found there are plenty of options on the market. Even now, coming up on two years later, we are still frequently asked about whether the right choice was made.
What is an API Gateway?
Fundamentally, an API Gateway is the front door (or single entry point) to an enterprise/product/application/…. Looking to the real world, this is a common trend - businesses, stores, and houses all have designated entry/exit points for the same overarching purposes: (1) validate the person entering should be here, (2) ensure the person is entering in the correct manner (no shoes allowed?), (3) keep track of who entered and when (i.e. Ring doorbell or front concierge).
Why Bother?
At a small organization, a public-facing monorepo Spring application should be sufficient but once more products/opportunities start emerging, most organizations will (formally or informally) head towards a service-oriented architecture [1]. At this inflection point, moving towards a single point of ingress may seem to create a bottleneck and add more overhead but this can be mitigated based on correct gateway choice and will reduce attack surface drastically in addition to preventing shadow IT [2].
Relevance of API Gateways with AI
Even with the proliferation of AI and concepts like MCP, APIs still remain relevant for the foreseeable future since they allow simple access and security controls on data access. API gateways make this simpler and cleaner which can even enable LLMs to have cleaner integrations (saving this discussion for another time).
What to look for?
In general, there are some standard out-the-box features which will distinguish an API Gateway from a generic webserver proxy. These features are going to be: (1) configurable request routing, (2) AuthN/AuthZ, (3) Rate limiting/throttling and circuit breaker, (4) monitoring/logging, (5) caching, (6) custom extensibility for request/response transforms.
Beyond those minimum requirements to call something an “API Gateway”, we get into the nice-to-haves which are going to matter more/less depending on the organization. These include at a bare level: (1) API versioning, (2) request schema validation, (3) developer portal, (4) built-in API stub tool, (5) integrated WAF and bot detection.
Aside from these objective defining features, additional concerns include resiliency model, scalability, and pricing.
The Playing Field
Broadly speaking, there are two major camps of API Gateways: cloud-native gateways and self-managed gateways. For the purposes of this discussion, we are only going to consider the major players which meet or exceed the above minimal requirements as of this article’s publication date.
Cloud-native Gateways
In the camp of cloud-native gateways for major public clouds, we have AWS (API Gateway), Azure (APIM - API Management), Google Cloud (API Gateway and Apigee), and Mulesoft (Mulesoft API Gateway) [3]. Typically, these gateways are only considered when you are already in the respective ecosystem to minimize gateway overhead - rarely would you consider using Azure APIM over AWS API Gateway when all of your services live in AWS. Accordingly, the major downside to these cloud-native gateways is vendor lock-in and limited support as most functionality will be custom written. Solutions exist such as AWS CLI and Localstack [4] as a workaround to enable local development of that functionality but in complex enterprise cases, you will likely require professional services to fill in the gaps on any missing functionality.
Self-managed Gateways
Major players in the self-managed API Gateway space are Kong, Tyk, Apache APISIX, and KrakenD. For the most part, self-managed gateways offer an open-source version, enterprise version with all the bells-and-whistles, and a vendor-managed cloud environment. Major advantages will be the platform independence (i.e. multicloud and hybrid are now possible) and typically a competitive offering of bells-and-whistles out the box as well as a better developer experience for any middleware requiring development. The biggest disadvantages to going self-managed over cloud-native will be managing another vendor and infrastructure (if not opting into using their cloud offering).
Not considered
I feel there’s value in explaining why several related concepts are not API Gateways and how they instead may compliment each other symbiotically. Below are application categories which do not meet the above API Gateway requirements but are often used in a similar context.
Service Mesh
Applications like Envoy, Istio, and Linkerd are service meshes. As far as service meshes are concerned, the moniker is that a service mesh is “east-to-west” and an API Gateway is “north-to-south” meaning service meshes connect services laterally while an API Gateway ties together with the “downstream” service from the client’s perspective. Because of this, a service mesh can actually enhance an API gateway by providing additional observability/controls between applications but is not a replacement to a proper API Gateway.
Load Balancers and Reverse Proxies
This bucket is where Nginx, Traefik, and HAProxy would fall. These applications are capable of routing HTTP calls and TLS termination but do not natively contain advanced API Gateway functionalities as discussed above (such as AuthZ). In some cases, these applications are perfect foundations to build an API Gateway as in the case of Kong, a self-managed API gateway built upon Nginx using Lua extensions [5], but natively are not a complete solution.
Summary
There's no best single API gateway option but there are optimal choices based on your organization’s needs based on the level of customization needed and organizational maturity. Whichever API Gateway you choose, keep in mind the future will be AI-first. We must assume the majority of API clients in the future will be LLMs and the API Gateway must be able to scale and functionally adapt accordingly.