Written by NGINX
API gateways are the bedrock of API infrastructure. API gateways secure and mediate traffic between backend applications that expose their APIs and the consumers of the APIs. For example, API gateways can manage the API traffic generated by calls from a mobile application like Uber to a backend application like Google Maps. API gateway functionality includes authenticating API calls, routing requests to appropriate backends, applying rate limits to prevent overloading your systems, mitigating DDoS attacks, offloading SSL/TLS traffic to improve performance, and handling errors and exceptions.
To generate new sources of revenue, enterprises are developing external APIs that third‑party developers can use to build applications. They are also exposing APIs to simplify business processes. And to support these new digital business models, enterprises need a comprehensive API management solution that helps them define, publish, secure, and analyze APIs, as well as quickly onboard third‑party developers who consume the APIs. In response, many vendors have emerged to offer a one‑stop solution for full API lifecycle management, with an API gateway integrated into the feature‑heavy solution. Such gateways, often referred to as “enterprise” or “edge” API gateways, manage and protect the “north‑south” traffic between the applications that expose APIs and the consumers of those APIs.
But applications evolve. Apps that use a microservices architecture generate a significant amount of API traffic among the microservices, referred to as “east‑west” traffic. API management vendors have responded, but the resulting architectures are overly complex.
This blog explores why.
The Rise of Microservices
Microservices are an approach to software architecture adopted by many distributed applications developed by companies such as Netflix and Uber, wherein an application is made up of distinct, smaller “services” that are autonomous and perform a single function or process. Compared to traditional monolithic apps, microservices apps are:
- More resilient – Failure of one service does not bring down the app as a whole
- Easier to scale – To alleviate bottlenecks, you spin up more instances of the relevant microservices
- More agile – Smaller apps lend themselves better to continuous integration/continuous delivery (CI/CD) software development processes
Since microservices by definition perform a single function, they don’t need the full infrastructure support provided by a server or virtual machine. Most microservices architectures use container‑based infrastructure, which is flexible, portable, and lightweight.
Microgateways Have Emerged to Handle Traffic Among Microservices
To work effectively together, the microservices that make up an application must of course communicate. The usual mechanism is for each microservice to call the APIs exposed by its peer microservices. The volume of this east‑west traffic among the component microservices is often substantially higher than the volume of north‑south traffic between the application and its external clients. Many API management vendors have introduced a new kind of gateway, the microgateway, dedicated to handling east‑west traffic.
As defined in a recent report from Gartner:
Microgateways are lightweight, distributed API proxies that enforce policies at, or near, service endpoints. For an API gateway to be considered a microgateway, it must be suitable for deployment as an inner gateway paired with a microservice instance. Thus, it must:
- Be containerized or container‑ready
- Have no limit on number of instances
- Incur no (or very low) license fees for additional instances
- Provide low latency
- Have a small footprint
- Be amenable to centralized and automatic administration
The primary reason that legacy API management vendors have introduced microgateways as a new type of gateway is that their first‑generation solutions were designed before the emergence of microservices and containers. As products of their time, these solutions share characteristics of the monolithic applications they were designed to work with: all processing functionality is included in a single binary, and configuration information is typically stored in a database (either bundled into the binary or from a separate database vendor).
These solutions usually have a large footprint, because the vendors have included a large number of features to maximize the solution’s appeal to customers with a wide range of use cases. The API gateway (data plane) is tightly coupled with the API management software (control plane), with the result that a failure in the control plane also halts API traffic processing.
Using a database to store configuration that controls how traffic is processed (for example, rate limits) adds latency because the API gateway must access the database every time it receives an API call. As with the control plane, if the database is unavailable, the API gateway can’t function.
Optimized to handle north‑south traffic at the edge of the data center, the API gateway in a first‑generation solution is inefficient for the large volume of east‑west traffic in distributed microservices environments: it has a large footprint, can’t be containerized, and the constant communication with the database and control plane adds latency. Bolting on a microgateway is the only way to manage significant east‑west network traffic, where low latency is critical.
The upside of using a first‑generation solution that includes a microgateway is that you can maintain your relationship with the API management vendor you previously chose for north‑south traffic, and use its solution to handle east‑west traffic as well. The downside is that the microgateway is actually a separate tool – yet another moving part that brings its own additional cost, complexity, scalability, and reliability issues.
What if you could eliminate the need for two different types of API gateways? Now you can, visit NGINX for further details.