API Gateway vs Load Balancer vs Reverse Proxy
Tags: reverseproxy, microservices, distributedsystems, apigateway
Published: 2024-04-04 06:10:01

---
title: API Gateway vs Load Balancer vs Reverse Proxy
published: true
date: 2024-04-03 07:02:13 UTC
tags: reverseproxy,microservices,distributedsystems,apigateway
canonical_url: https://medium.com/all-you-need-is-clean-code/api-gateway-vs-load-balancer-vs-reverse-proxy-82f34e10e324
---

#### Infraestructuras de Gestión y Distribución de Tráfico

#### Conoce las diferencias entre las distintas infraestructuras de gestión y distribución de tráfico

[**Este post se publicó originalmente en el blog Secture&Code**](https://secture.com/blog/api-gateway-load-balancer-reverse-proxy/)

### Escalado de aplicaciones web

Con el paso del tiempo, las aplicaciones basadas en la web y los servicios que ofrecen han ido incrementado tanto en escala como en complejidad. Aunque era lo habitual años atrás, la idea de mantener un proyecto grande funcionando con un solo servidor es algo cada vez menos realista.

Para manejar mayores volúmenes de tráfico tenemos dos formas diferentes de escalado: el escalado vertical y el escalado horizontal.

#### **Escalado vertical**

Básicamente consiste en mejorar el hardware sobre el que corre nuestro proyecto, añadiendo más memoria, más CPU, más disco duro, más tarjetas de red… Antiguamente era la forma más barata de escalar y a día de hoy es una opción poco realista, ya que a medida que la demanda del servicio web aumenta, puede llegar un punto en el que el escalado vertical ya no sea suficiente para satisfacer las necesidades de rendimiento y disponibilidad del proyecto.

#### **Escalado horizontal**

Consiste en agregar más servidores o instancias de manera distribuida para manejar la carga. Esto permite una mayor flexibilidad y capacidad para adaptarse a cambios en la demanda, así como una mayor tolerancia a fallos, ya que los servidores individuales pueden fallar sin degradar significativamente la disponibilidad del servicio.

### Infraestructuras de Gestión y Distribución de Tráfico

Es aquí, en las estrategias de escalado horizontal, donde juegan un papel importante las infraestructuras de gestión y distribución de tráfico, ya que gracias a ellas podemos controlar el flujo de datos y distribuir la carga de manera eficiente entre múltiples servidores o instancias, garantizando así un rendimiento óptimo y una alta disponibilidad del servicio.

Vamos a ver tres de las más conocidas: _Reverse Proxy_ (Proxy inverso), _API Gateway_ (Puerta de acceso) y _Load Balancer_ (balanceador de carga).

Si no te has visto en la necesidad de utilizarlas, es posible que tengas dudas sobre qué hace cada una de ellas o en qué se diferencian, así que vamos a ver las características y usos de cada una de ellas.

### Reverse Proxy

![](https://cdn-images-1.medium.com/max/1024/1*SL0APGCkDd8-0rsxVfZtXQ.png)
_La función principal del reverse proxy es enmascarar la dirección real de un servidor_

Empezamos por el más simple de los tres, el _reverse proxy_ o proxy inverso.

El _reverse proxy_ básicamente es un servidor que actúa como intermediario entre los clientes y el o los servidores de destino. En lugar de establecerse una comunicación directa en cliente y servidor, el cliente conecta con el _reverse proxy_ y este se encarga de pasar la petición al servidor y devolver la respuesta correspondiente a los clientes.

#### **Con qué propósito usamos un _reverse proxy?_**

- **Seguridad.** Actúa como una barrera entre los clientes y los servidores de destino, ocultando la estructura interna de la red y proporcionando una capa adicional de seguridad contra ataques maliciosos.
- **Cacheo de contenido estático.** Almacena en caché el contenido estático como imágenes, archivos CSS y JavaScript para reducir la carga en los servidores de origen y mejorar los tiempos de carga de la página.
- **Terminación SSL/TLS.** Gestiona las conexiones SSL/TLS de los clientes y las termina en el proxy antes de reenviar las solicitudes a los servidores de destino, lo que simplifica la gestión de certificados SSL/TLS y mejora el rendimiento de los servidores. De esta forma la conexión HTTPS es únicamente entre el cliente y el proxy. Esto es especialmente útil cuando el _reverse proxy_ enmascara más de un servidor.
- **Balanceo de carga.** Sí, así es, el _reverse proxy_ se puede usar como balanceador de carga, ya que distribuye el tráfico entrante entre varios servidores de destino para mejorar la escalabilidad y la disponibilidad del servicio.

La función de proxy inverso la realizan la mayoría de servidores web comerciales, como [NGINX](https://www.nginx.com/), [Apache](https://httpd.apache.org/) y [Microsoft IIS](https://learn.microsoft.com/es-es/iis/get-started/introduction-to-iis/iis-web-server-overview), y también software específico como [HAProxy](https://www.haproxy.org/).

### Load Balancer

![](https://cdn-images-1.medium.com/max/1024/1*uogqnCQnaeIzPwzqyew6KQ.png)
_Un balanceador de carga reparte el tráfico entre distintas instancias o servidores de un mismo servicio_

Un balanceador de carga (o _Load Balancer_ en inglés) es un dispositivo o software que distribuye el tráfico de red entrante entre múltiples servidores, con el objetivo de mejorar el rendimiento, la disponibilidad y la fiabilidad de una aplicación o servicio web.

Al igual que en el caso del _reverse proxy_, actúa como un intermediario entre el cliente y (en este caso) los servidores, ya que no es solo uno sino varios los servidores que oculta el _load balancer._ Al ser varios servidores, se paralelizan las peticiones y se puede manejar un flujo de peticiones mucho mayor

#### **Con qué propósito usamos un balanceador de carga_?_**

- **Distribución de carga.** Distribuye el tráfico de red entre varios servidores para evitar la sobrecarga de uno solo y garantizar un uso equitativo de los recursos disponibles.
- **Mejora del rendimiento.** Al distribuir la carga de trabajo entre múltiples servidores, un balanceador de carga puede mejorar el tiempo de respuesta y el rendimiento general de una aplicación o servicio.
- **Alta disponibilidad.** Si un servidor falla, el balanceador de carga puede redirigir automáticamente el tráfico a servidores alternativos que estén funcionando correctamente, lo que garantiza la disponibilidad continua del servicio.
- **Escalabilidad.** Facilita la adición o eliminación dinámica de servidores según las necesidades de carga, lo que permite escalar horizontalmente la infraestructura de manera flexible.

#### **Cómo reparte la carga un balanceador?**

Dependiendo de su implementación, puede utilizar algoritmos de balanceo de carga simples, como round-robin (cada solicitud se envía a los servidores en secuencia) o algoritmos más avanzados que consideran la carga actual de los servidores, la latencia, entre otros factores.

Los algoritmos de distribución de carga más habituales incluyen:

- **Round Robin.** Este algoritmo distribuye las solicitudes de manera uniforme entre los servidores en secuencia. Cada solicitud se envía al siguiente servidor en la lista, y cuando se alcanza el último servidor, se vuelve al principio.
- **_Least Connections_ (Menos Conexiones).** Este algoritmo dirige las nuevas solicitudes al servidor con la menor cantidad de conexiones activas en ese momento. Es útil para distribuir la carga de manera más equitativa, considerando la carga real de cada servidor.
- **_Least Response Time_ (Menor Tiempo de Respuesta).** Similar al algoritmo de Menos Conexiones, este enfoque dirige las solicitudes al servidor que tiene el menor tiempo de respuesta en ese momento. Ayuda a maximizar la capacidad de respuesta y el rendimiento general del sistema.
- **_IP Hashing_ (Hashing de IP).** Este algoritmo utiliza la dirección IP del cliente para determinar a qué servidor enviar la solicitud. De esta manera, todas las solicitudes de un cliente particular se envían siempre al mismo servidor, lo que puede ser útil para mantener la sesión de un usuario en un servidor específico.
- **_Weighted Round Robin_ (Round Robin Ponderado).** Este algoritmo asigna un peso a cada servidor en función de su capacidad de procesamiento, y luego distribuye las solicitudes en función de esos pesos. Los servidores con mayor capacidad recibirán una mayor proporción de solicitudes.
- **_Random_** **(Aleatorio).** Este algoritmo elige aleatoriamente un servidor para manejar cada solicitud entrante. Aunque simple, puede no ser la opción más eficiente en términos de distribución de carga equitativa.

#### Cómo manejamos las sesiones con un balanceador de carga?

Si el servicio que estamos enmascarando con nuestro balanceador requiere de una sesión, corremos el peligro de que en las siguientes peticiones un mismo cliente sea redirigido a otro servidor que no tenga su sesión guardada, y esto puede producir cierto malestar en el usuario al estar constantemente pidiéndole iniciar sesión de nuevo.

Para ello, los balanceadores de carga cuentan con una característica conocida como **_sticky bit_** , que permite que las solicitudes de un cliente se dirijan siempre al mismo servidor durante la duración de una sesión específica, es decir, garantiza la persistencia de sesión al asociar un cliente con un servidor particular.

Cuando se habilita el _sticky bit_, el balanceador de carga utiliza una técnica, como el _hashing_ de la dirección IP del cliente o la inserción de una _cookie_ en el navegador del cliente, para identificar y asociar al cliente con un servidor específico. Como resultado, todas las solicitudes posteriores de ese cliente durante la misma sesión se redirigen al mismo servidor, lo que asegura una experiencia coherente para el usuario y permite que las sesiones persistan correctamente a través de múltiples solicitudes.

Podemos encontrar implementaciones de balanceadores de carga en las principales plataformas _cloud_, como [_AWS Elastic Load Balancer (ELB)_](https://aws.amazon.com/es/elasticloadbalancing/)_,_ [_Microsoft Azure Load Balancer_](https://azure.microsoft.com/es-es/products/load-balancer/) y [_Cloud Load Balancing_](https://cloud.google.com/load-balancing?hl=es) de Google.

### API Gateway

![](https://cdn-images-1.medium.com/max/1024/1*Cup6l2mVRlAUNqMZE9a18g.png)
_Un API Gateway sirve como punto de entrada único a una serie de servicios distribuidos e independientes_

Por último, un _API Gateway_ es un componente de software que actúa como punto de entrada único (_single entry point_) para una variedad de servicios y APIs dentro de una arquitectura de microservicios o de servicios distribuidos. Funciona como una capa intermedia entre clientes y múltiples servicios, proporcionando una interfaz unificada y facilitando la gestión, seguridad, supervisión y orquestación de las solicitudes y respuestas entre ellos.

#### Cómo funciona un API Gateway?

El funcionamiento de un API Gateway ya es algo más complejo que los casos anteriores. De base podemos entender sus similitudes con el balanceador de carga, pero con un matiz muy importante: tras un _API Gateway_ hay distintos servicio y que además pueden funcionar con diferentes protocolos. De hecho, un _API Gateway_ puede estar encubriendo un servicio que usa internamente un balanceador de carga para repartir la carga del servicio entre distintas instancias o servidores (hablamos por supuesto de magnitudes de tráfico enormes).

Veamos los pasos básicos de su funcionamiento:

1. **Recepción de solicitudes.** El _API Gateway_ recibe las solicitudes de los clientes y las enruta a los servicios correspondientes basándose en reglas de enrutamiento configuradas.
2. **Traducción de protocolos.** Puede traducir los protocolos de comunicación, por ejemplo, convirtiendo solicitudes HTTP en llamadas a servicios internos usando protocolos como _gRPC_ o _Thrift_.
3. **Autenticación y autorización.** Gestiona la autenticación y la autorización de los clientes, verificando las credenciales y aplicando políticas de acceso antes de enviar las solicitudes a los servicios subyacentes.
4. **Agregación de datos.** Puede combinar múltiples llamadas a servicios internos para formar una única respuesta para el cliente, reduciendo así la latencia y el tráfico de red.
5. **Monitorización y análisis.** Recopila métricas y registros de las solicitudes y respuestas para facilitar la supervisión, el análisis de rendimiento y la solución de problemas.

#### Con qué propósito usamos un balanceador de carga?

- **Unificación de interfaces.** Proporciona una única interfaz para los clientes, simplificando su interacción con un conjunto diverso de servicios internos.
- **Gestión de versiones.** Permite la introducción y el control de versiones de APIs, lo que facilita la evolución de los servicios subyacentes sin afectar a los clientes.
- **Seguridad centralizada.** Implementa políticas de seguridad centralizadas, como autenticación, autorización y cifrado, para todos los servicios internos.
- **Orquestación y transformación.** Permite la orquestación de solicitudes a través de múltiples servicios internos y la transformación de datos según sea necesario.
- **Escalabilidad y disponibilidad.** Puede distribuir la carga de manera equitativa entre múltiples instancias de servicios internos, mejorando así la escalabilidad y la disponibilidad del sistema.

#### Problemas comunes

Una infraestructura tan compleja no está exenta de problemas, veamos cuales son los más comunes:

1. **Cuellos de botella de rendimiento.** Un _API Gateway_ puede convertirse en un cuello de botella si no se dimensiona adecuadamente para manejar la carga de solicitudes entrantes.
2. **Complejidad de configuración.** Configurar y mantener reglas de enrutamiento, políticas de seguridad y transformaciones de datos puede volverse complejo a medida que aumenta la cantidad de servicios y funcionalidades implementadas.
3. **Puntos únicos de fallo.** Si un _API Gateway_ es el único punto de entrada para todos los servicios, un fallo en él puede afectar la disponibilidad de todo el sistema.
4. **Sobrecarga de red** : El enrutamiento de todas las solicitudes a través del _API Gateway_ puede introducir una sobrecarga adicional en la red, especialmente en entornos distribuidos a gran escala.

De nuevo, podemos encontrar implementaciones de _API Gateway_ en los principales proveedores de _cloud_ como [_AWS API Gateway_](https://aws.amazon.com/es/api-gateway/)_,_ [_Azure API Management_](https://azure.microsoft.com/es-es/products/api-management) o [_Google Cloud API Gateway (Apigee)_](https://cloud.google.com/apigee?hl=es)_,_ así como soluciones Open Source como [_Kong_](https://konghq.com/products/kong-gateway)_._

### Conclusiones

Como hemos podido ver, aunque similares en su propósito, estas tres infraestructuras de gestión y distribución de tráfico tienen usos muy distintos y trabajan de formas muy diferentes.

Es importante saber elegir en cada caso cuál necesitamos, ya que elegir mal puede derivar en añadir un extra de complejidad a nuestro proyecto, además de salirnos caro el error (económicamente hablando).

Recordad, empezad siempre por lo mínimo necesario, siempre habrá tiempo de escalar más alto!

* * *