API gateway vs. load balancer

What is an API gateway?

An API gateway is a service deployed in front of an API or set of microservices, which passes requests from clients and responses or data returned by APIs.

An API gateway decouples the client interface from the backend. This ensures clients can communicate with applications consistently even as internal implementations change. When a client makes a request, the API Gateway splits it into multiple requests, routes them to the appropriate service, routes responses back to the client, and keeps track of everything.

API gateways have multiple benefits for microservices applications, including improved security, better request performance, centralized monitoring and control.

APIs allow individual applications to communicate with each other and exchange data. API gateways provide a focal point and standard interface for these communications. It receives API calls, which are requests from internal and external sources, gathers multiple related requests and packages them together, and routes them to the appropriate API. Finally, it receives and forwards the responses to requesting users or devices.

API gateways are a key component of modern microservices architecture. In a microservices application, numerous services within the application communicate with each other via APIs, and might also serve external clients and users. In this context, the role of API gateway is to provide a single point of communication for a group of microservices, with the ability to enforce policies and determine availability and behavior across all microservices.

Related content: Read our guide to API gateway and microservices.

Load balancers need to handle incoming requests from users for services and information. A load balancer sits between the servers handling user requests and the public Internet. 

Once a load balancer receives a request, it finds an available online server and routes the request to this server. It can dynamically add servers in response to traffic spikes and drop servers when demand is low.

You can find various load balancers, including physical appliances, software instances, or a combination of the two. 

Hardware-based load balancing

In the past, vendors loaded proprietary software onto dedicated hardware and offered them as stand-alone appliances. These appliances were usually sold in pairs to provide failover when one goes down. As a result, a growing network requires purchasing additional or bigger appliances.

These legacy load balancing solutions cannot keep up with the changes in dynamic capacity and do not meet the automation needs of modern networks. Because this technology cannot keep up with changing requirements, it might delay application rollouts and cause overspending and overprovisioning.

Software-based load balancing

Software load balancing runs on white box servers or virtual machines (VMs), typically as part of an application delivery controller (ADC). An ADC provides additional features, such as caching, traffic shaping, and compression. 

Virtual load balancing is highly popular in cloud environments, offering a high level of flexibility. For example, it enables you to automatically scale down or up to match decreased network activity or traffic spikes.

Both API gateways and load balancers manage network traffic, but they use different methods to support networks.

Implementation

• Load balancers are usually deployed as dedicated physical devices or software running on a set of virtual servers.
• API gateways are usually implemented as a service—organizations often deploy an API gateway as a container or VM instance.

Traffic Management Approach

• Application load balancers command how traffic flows. A load balancer redirects traffic across multiple servers. This ability helps large networks handle high traffic volumes and minimizes performance issues associated with running an application on one server.
• API gateways manage network traffic by processing API requests from clients to determine the necessary services and destination applications to handle API calls. Clients are the software making API calls. APIs are important for integrating disparate application components and enabling them to communicate. An API gateway also manages the protocols and translations between software components.

Capabilities

• Load balancers use algorithms to direct inbound network traffic to the appropriate servers: 
  • Round-robin algorithms distribute traffic evenly across servers. 
  • Least-connection algorithms direct traffic to the least burdened server (i.e., with the fewest connections)—they ensure high availability when the servers in a given environment have varying capabilities.
  • IP hash algorithms direct traffic to servers according to the origin of the requests. They are best suited for environments with servers distributed across multiple geographic regions—these route network traffic to the nearest server to minimize application latency.
• API gateways act as translators and organizers connecting separate software components. Among their key capabilities are:
  • API security including authentication and authorization.
  • Rate-limiting for APIs to prevent abuse or over-utilization.
  • API monitoring and logging to assist with observability.
  • API transformation to enable services to communicate with each other even if they use different protocols or technology stacks.

Related content: Read our guide to API gateway security 

Use Cases

• Load balancers are best suited to geographically distributed deployments that prioritize resilience and redundancy. A load balancer can redirect traffic to other instances on another server when a server fails. Enterprises usually run multiple application instances in parallel, sometimes on multiple physical servers. This approach provides redundancy to maintain high availability and ensure applications can handle all traffic. 
• API gateways are best suited for designing and deploying microservices-based applications. Enterprises often build modern applications as separate services, not a monolithic architecture. These independent services use APIs to communicate, with an API gateway ensuring that all services function and collaborate properly in a unified deployment.

An organization’s approach to managing network traffic doesn’t need to use only API gateways or load balancers. Both services can function together, although they do not require each other to work. For instance, the API gateway connects between microservices. The load balancer redirects multiple instances of a microservice component (to scale the deployment).

In microservices architectures, client applications typically need functionality from multiple microservices. If the clients consume services directly, they must handle many calls. Applications become unmanageable when they evolve because they have clients coupled to microservice endpoints. Each change impacts the clients. 

An API gateway provides an intermediary that simplifies communication between microservices. Without an API gateway, applications may face several problems: 

• Client coupling—with a client app coupled to internal microservices, it must know the application’s structure. Every update to an internal microservice makes it harder to maintain the application, introducing a breaking change unless the client apps are also updated. 
• Too much traffic—with each client app making direct calls to each service, the result can be too much client-server traffic, increasing latency. 
• Security—without an API gateway, organizations must expose all microservices to the outside world, increasing the attack surface. Gateways keep internal microservices hidden because client apps don’t have to access them directly.
• Cross-cutting—publicly exposed microservices must handle SSL and authorization. The intermediate tier (API gateway) simplifies microservices by handling these concerns.

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.