API gateway microservices

APIs enable applications to seamlessly communicate with each other. An API gateway is a type of middleware for mediating requests between the clients consuming APIs and upstream application services

API gateways act as a single entry point, standardizing control over interactions between the organization’s data, services, and apps and external users.

Additionally, API gateways can perform other key functions to manage and support API usage, including rate limiting, analytics, and authentication.

Several factors are reshaping how users evaluate API Gateways:

• How well does it scale to handle a larger volume of API traffic?
• How well does it perform at a larger scale? 
• How well does it consistently deliver low-latency response times? 
• Does it natively work in public cloud or any Kubernetes environments?
• Does it leverage the latest innovations in proxy technologies (e.g. Envoy Proxy)? 
• Does it leverage the latest open source innovations around proxy technologies (e.g. WebAssembly or GraphQL)?

As each of these issues become more impactful to how an API Gateway can enable your microservice applications, the more companies are beginning to choose Solo.io Gloo Gateway. Based on Envoy Proxy, Gloo Gateway enables greater scalability and latency than legacy API Gateways based on NGINX, HAProxy or Java-wrappers on proxy technology. In addition, Gloo Gateway is both public cloud native and Kubernetes native, so integrating with DevOps environments is seamless. And Gloo Gateway enables users to easily add new innovations such as Web Assembly or GraphQL to their API Gateway environment to handle next-generation application needs.

A microservices architecture offers great benefits but also poses unique challenges that API gateways help address.

1. API gateways vs. direct client-to-microservice communication

A microservices architecture usually requires client apps to consume the functionality from different microservices. However, direct consumption requires the client to handle multiple calls to microservice endpoints, which can become difficult as an application evolves, introducing new microservices or updating existing ones. 

An application that utilizes a great number of microservices forces client apps to handle too many endpoints. Additionally, when a client app is coupled to internal endpoints, any future change to these microservices can significantly impact the client apps. An API gateway helps solve these issues.

An intermediate indirection tier, or gateway, provides a convenient communication mediator for microservice-based apps, eliminating the need for clients to handle each call. Otherwise, clients must make direct requests to microservices. 

Here are the most common issues that arise from direct client-to-microservice communication:

• Coupling—client apps that do not have an API gateway pattern to mediate communication are coupled to internal microservices. When coupled, client applications must know how many parts of the application are split into microservices. When you evolve and refactor internal microservices, you impact maintenance. Because of the direct reference to these internal microservices from client apps, changes to the microservices causes breaking changes to client apps. It means you need to update client apps frequently, making it difficult to improve the solution.
• Too many round trips—one screen or page in a client app can require multiple calls to several services. This approach might result in several network round trips between a client and a server, adding latency. When aggregation is handled at an intermediate level, it can improve the user experience and performance of client apps.
• Security issues—an architecture that does not utilize an API gateway causes all microservices to be exposed externally, creating a larger attack surface. However, hiding internal microservices not directly used by a client app creates a smaller attack surface that strengthens the security of your application.
• Cross-cutting concerns—a publicly published microservice needs to handle various security concerns, such as SSL and authorization. However, many of these concerns can be addressed in a single intermediate tier to simplify internal microservices.

Related content: Read our guide to API gateway security 

2. Abstraction for Microservice Language and Protocol Independence

Developers can build each microservice in their application with a different technology stack and communication protocol. For instance, a developer can build some services in Java, implementing them as RESTful APIs, and write other services in Python and implement them using the gRPC protocol. While this provides flexibility, the use of different languages means that the clients accessing the APIs must support both communication protocols.

API gateways can convert between different protocols, so clients can call any service over the same protocol. API gateways conceal the service implementation from client applications. If the interface definition stays the same, the developer can use any technology stack to change the service logic without the client’s knowledge.

With an API gateway, services can be rewritten or redesigned with a different technology stack, and redeployed, without any impact on consumer services. For the client, the interface remains the same, even as the underlying technology and communication protocol have changed.

3. Scalable, Distributed Service Management and Discovery

The cloud is elastic, allowing services to scale horizontally according to changing demand. This is beneficial for application resilience, but it requires load balancing, easy service discovery, and recovery features such as timeouts and retries.

API gateways can load balance among replicas of a given service to improve resource utilization and end user performance. Unlike traditional proxies, which use simple algorithms like round robin, an API gateway has application awareness, so it can leverage more advanced algorithms such as weighted connection, least-connection, and other options based on querying a service registry. 

In essence an API gateway can achieve sophisticated traffic routing between services. It can also support features such as retries on services, redirecting requests to healthy service instances, and graceful error handling.

Related content: Read our guide to API gateway vs. load balancer 

The main problem with using API gateways for microservices is that it requires an admin to manage another software configuration on the server. While this configuration process often takes less time than using a developer to produce the code for each microservice, it is only effective if the configuration behaves correctly. Otherwise, it could end up wasting more time.

Another problem with using a microservices API gateway is that it adds a potential point of failure. For instance, configuration errors can result in hard-to-detect application bugs. The server hosting the API gateway runs might crash, or the bug might prevent the application from communicating with the server. An API gateway becomes a single point of failure, which can reduce the system’s overall reliability.

However, in most microservices scenarios, the benefits of an API gateway overweigh the downsides. API gateways are becoming an inseparable part of most large-scale microservices deployments.