Why and how to manage microservices without API gateways

Microservices and API gateways: The basics

Microservices are a type of application architecture that divides application functionality into discrete services. Rather than having the application run as just one service, microservices enable a more modular and flexible approach, with each service handling a different type of task.

An API gateway is a tool that facilitates and streamlines communication by serving as an intermediary between the application services and clients. API gateways can also assist with important performance management and security processes, such as balancing requests between multiple service instances and blocking malicious requests.

How microservices and API gateways work together

An API gateway can simplify interactions between clients and the application. In an online shopping app that uses microservices, for example, one microservice might display an inventory of products while another allows customers to place items in a shopping cart, and a third lets them check out.

A client placing an item in a shopping cart doesn't have to connect directly to the shopping cart microservice. Instead, the client sends a request to the API gateway indicating that it wants to check out. The API gateway interprets the request and routes it to the microservice that can fulfill it.

Rather than requiring the microservices to directly interpret and route the request within the app, the API gateway acts as the go-between. It receives and forwards requests and then sends results back to the client to complete the exchange.

How API gateways help manage microservices

API gateways help organize and secure requests, which is beneficial from two key perspectives:

• Simplified application design and logic. Developers don't need to write logic into their apps that allow the microservices to receive and route requests. Implementing certain types of microservices may even be avoided altogether. For example, if client identities can be validated within an API gateway, there is no need to create a microservice devoted to that purpose within the app.
• Streamlined client experience. API gateways benefit clients by simplifying API requests, especially for applications that have multiple client-facing microservices. Instead of requiring clients to issue separate API requests to each service, an API gateway exposes a centralized, combined API. With this approach, clients can formulate a request and let the API gateway determine how it's fulfilled. Clients don't need an understanding of the internal application architecture.

API gateways can provide additional capabilities -- such as load balancing, observability and rate-limiting -- that help teams manage microservices apps effectively. These features can be implemented using tools other than API gateways, but the ability to address diverse needs through an API gateway makes it a versatile management option within a microservices architecture.

Downsides of API gateways

API gateways make it easier for microservices apps to interface with clients, but they also have the potential to decrease performance by increasing architectural and operational complexity. It's important to consider these possible API gateway drawbacks:

• Increased overhead. API gateways add another layer to an application hosting stack, increasing the amount of infrastructure resources required to run apps.
• Increased complexity. API gateways also add complexity to hosting stacks because they are another tool that must be configured and managed.
• Latency challenges. Having to pass requests through API gateways can increase latency, particularly if API gateways are poorly configured or lack sufficient resources to route requests efficiently.
• Risk of failure. API gateways function as centralized hubs for interactions between microservices and clients, and an API gateway failure could make apps unreachable.

Should you run microservices without an API gateway?

It's fair to say that the majority of microservices apps today should be accompanied by an API gateway. But whether the possible drawbacks of API gateways outweigh the benefits is a question that each application development team needs to address on a case-by-case basis.

For applications that consist of just a few microservices or that only need to handle a limited range of API requests, a gateway might be overkill. API gateways also might not work well for specialized types of application deployments like microservices running on edge IoT devices with limited CPU and memory resources. That said, API gateway overhead can vary widely depending on how the gateway functions and is deployed. Containerized API gateways can be quite lightweight, for instance.

An API gateway is not necessary if your application has no client-facing services, but that's rare for modern applications in today's API-first world.

Ways to run microservices apps without API gateways

In scenarios where an application might not have enough microservices to justify the overhead and complexity of an API gateway, two alternative approaches can provide some of the same performance management and security capabilities API gateways offer.

One approach is to run an app without an intermediary between clients and microservices. This requires ensuring that the app's microservices can accept, route and process API requests on their own and might entail implementing more logic within the microservices, including the development of additional microservices that would otherwise not be needed.

The other approach is to leverage tools that are not direct substitutes for API gateways but offer some of the same functionality, such as:

• Load balancer. Deploy a load balancer between clients and an app to help route traffic. Load balancers can't interpret and manage API requests, so they don't necessarily provide API management, but they can help balance traffic optimally across a distributed application.
• Network switch/ firewall. It might be possible to implement rate limiting through a network switch or firewall. But in that case, request rates typically need to be managed at the protocol level instead of throttling specific types of API requests.
• API proxy. API proxies can perform forwarding requests for individual APIs and shield backend services from direct client requests, but they are not a full-scale alternative to API gateways.
• Service mesh. A service mesh can manage API-based communications between microservices inside an application, but API gateways primarily manage external client requests, while service meshes handle internal traffic.

Chris Tozzi is a freelance writer, research adviser, and professor of IT and society who has previously worked as a journalist and Linux systems administrator.