¿Qué es un API Gateway y por qué es esencial?

Introducción a las APIs

¿Qué es una API (Interfaz de Programación de Aplicaciones)? Una API es una forma estándar de intercambiar datos entre diferentes aplicaciones y sistemas. Muchos equipos de desarrollo adoptan el enfoque API-first, donde la iteración se centra en la API, desde el diseño, implementación, pruebas, seguridad, despliegue, solución de problemas y análisis de APIs, lo que constituye la gestión del ciclo de vida completo de las APIs (APIM).

Antes de la aparición de las APIs, no existía una forma estándar de intercambiar datos. Los programas de computadora se comunicaban entre sí utilizando una variedad de protocolos, como FTP, FTPS, SFTP, HTTPS, etc. La falta de estándares generaba altos costos de desarrollo y riesgos de seguridad ocultos en muchas dimensiones: control de permisos, gestión de datos, limitación de tasa, auditoría, etc. Esto es la "Torre de Babel" en el mundo de la computación. Para construir un producto suficientemente complejo, debemos resolver los problemas causados por sistemas desarrollados en diferentes lenguajes y con diferentes esquemas de almacenamiento de datos.

La aparición de las APIs ha resuelto con éxito el problema de la "Torre de Babel". Los desarrolladores solo necesitan enfocarse en las APIs expuestas por otros sistemas y no es necesario entender los detalles de implementación subyacentes.

La conexión y transmisión de datos entre dispositivos cliente y servidores para aplicaciones móviles, juegos en línea, transmisión de video en vivo, conferencias remotas y dispositivos IoT no pueden separarse de las APIs. Las APIs juegan un papel importante en sus comunicaciones.

¿Por qué usar un API Gateway?

El API Gateway es un componente esencial en la gestión del ciclo de vida completo de las APIs. Es responsable de la configuración, publicación, reversión de versiones, seguridad y balanceo de carga de las APIs en el entorno de producción. Además, el API Gateway es la entrada de todo el tráfico cliente, encargándose de enrutar las solicitudes de API del cliente al servicio upstream correcto para su procesamiento y luego devolver los datos al solicitante original, garantizando la seguridad, confiabilidad y baja latencia de todo el proceso.

Cuando no hay muchas APIs al principio, el API Gateway suele ser un componente virtual unido por el servidor web y los servicios upstream. Funcionalidades simples como enrutamiento, reenvío, proxy inverso y balanceo de carga son realizadas por Apache, NGINX y otros componentes; otras funcionalidades como autenticación y limitación de tasa dependen de los servicios upstream.

¿Por qué necesitas un API Gateway?

Sin embargo, a medida que aumenta el número de APIs, los desarrolladores "perezosos" encontraron un problema grave. En diferentes partes de los servicios upstream, las mismas funciones de autenticación, limitación de tasa, registro de logs y otras se codifican repetidamente. Esto no solo es un desperdicio de recursos, sino también una pesadilla en la gestión del código. Cuando una parte del código se modifica o actualiza, el código en otros lugares también debe actualizarse. ¿Cómo resolvemos este problema? Los desarrolladores inteligentes encontraron rápidamente una solución: abstraer (extraer) las funciones comunes y colocarlas en un solo componente. Extraemos el código que no está relacionado con la lógica de negocio de los servicios upstream y mejoramos componentes como Apache y NGINX. Esta es la evolución del API Gateway de primera generación.

La dirección de la evolución del API Gateway es integrar tantas funcionalidades no relacionadas con el negocio como sea posible. Para acelerar la iteración del producto, los desarrolladores front-end y back-end exigen cada vez más de los API Gateways, no solo limitándose a funcionalidades tradicionales como enrutamiento, reenvío, proxy inverso y balanceo de carga, sino también demandando funcionalidades de observabilidad como gRPC y GraphQL.

El papel de los API Gateways

Para hacer que el API Gateway sea más flexible y eficiente, los desarrolladores de API Gateways hicieron muchas innovaciones en la estructura subyacente, como:

• Plugins de funcionalidades. A medida que se integran más funcionalidades en el API Gateway, ¿cómo separamos cada funcionalidad para facilitar el desarrollo? Un mecanismo de plugins tipo Lego sería la solución perfecta. Los API Gateways principales utilizan plugins. En Apache APISIX, se llaman "plugins". En Envoy, se llaman "filtros". Los plugins liberan a los desarrolladores de los detalles de implementación, y se necesitan menos recursos de desarrollo para implementar nuevas funcionalidades.
• Separación del Plano de Datos y el Plano de Control. En la primera generación de API Gateway, el Plano de Datos y el Plano de Control se implementaban en el mismo proceso de computadora. Es más fácil para los usuarios desplegar y usar, pero crea riesgos de seguridad significativos. El Plano de Datos proporciona servicios directamente al exterior. Si los hackers acceden al Plano de Datos desde el exterior, podrían obtener permisos de control y datos del Plano de Control (como certificados SSL), causando potencialmente daños más devastadores. Por lo tanto, la mayoría de los API Gateways de código abierto ahora despliegan DP y CP por separado y utilizan bases de datos relacionales o etcd para la gestión y sincronización de configuraciones.

Tomando Apache APISIX como ejemplo, el siguiente diagrama de arquitectura ilustra las innovaciones mencionadas:

Desafíos del Cloud-Native

El cambio tecnológico más significativo en TI en la última década ha sido el cloud-native. Docker, nacido en 2013, abrió el telón del cloud-native. Desde entonces, los servidores físicos y las máquinas virtuales han sido reemplazados por contenedores, y las arquitecturas monolíticas han sido reemplazadas por microservicios. Sin embargo, el cloud-native no es una simple revolución tecnológica. La fuerza impulsora detrás de esto proviene del rápido desarrollo y la feroz competencia de los productos de Internet. Las tecnologías relacionadas con el cloud-native nacieron en el momento adecuado y rápidamente se popularizaron, reemplazando muchas arquitecturas y soluciones técnicas anteriores. Específicamente, los desafíos del API Gateway en el cloud-native provienen principalmente de dos aspectos:

De monolítico a microservicios

Después de que la arquitectura de microservicios ganara popularidad entre los desarrolladores, ha liberado enormes dividendos técnicos. Los microservicios pueden actualizarse y lanzarse a su propio ritmo sin preocuparse por el acoplamiento con otros servicios. Las iteraciones de productos son así ágiles, con decenas o incluso cientos de lanzamientos por día.

Sin embargo, el desarrollo de microservicios también trae algunos efectos secundarios, como:

• El número de APIs y microservicios ha crecido de decenas a miles o incluso decenas de miles.
• ¿Cómo localizamos rápidamente qué API causó el error?
• ¿Cómo garantizamos la seguridad de la API?
• ¿Cómo logramos la ruptura de servicio y la degradación de servicio?

El API Gateway no puede resolver por sí solo los problemas de seguridad, observabilidad y lanzamiento canario. Necesita cooperar con muchos otros proyectos de código abierto y servicios SaaS como Prometheus, Zipkin, Skywalking, Datadog, Okta, etc., para proporcionar mejores soluciones a las empresas.

Gestión dinámica y de clúster

El primer desafío proviene del ecosistema, mientras que el segundo proviene de la tecnología.

Dinámica

La popularidad de los contenedores y Kubernetes ha hecho que la dinámica sea una característica estándar de todos los componentes fundamentales del cloud-native. En el entorno de Kubernetes, los contenedores se crean y destruyen constantemente, y el escalado elástico se ha convertido en una necesidad en lugar de una opción.

Imagina un escenario: una empresa de comercio electrónico realiza una promoción, y millones de usuarios ingresan en una hora y se van después de que termina la promoción. En este escenario, las empresas con arquitectura tradicional deben comprar un lote de servidores físicos para manejar el tráfico de API en los momentos pico. En contraste, las empresas con arquitectura cloud-native pueden usar los recursos elásticos en la nube pública en cualquier momento. Pueden ajustar la escala de la red, la potencia de cómputo, las bases de datos y otros recursos automáticamente según el número de solicitudes de API.

También hay desafíos técnicos asociados con el escalado elástico de contenedores:

• Cambios frecuentes de direcciones IP y puertos en los servicios upstream.
• Actualizaciones frecuentes de listas de permitidos y denegados de IP.
• Detección y manejo de excepciones en la salud del servicio.
• Lanzamientos regulares de APIs.
• Oportunidad en el registro y descubrimiento de servicios.
• Renovación caliente y rotación automática de certificados SSL.

En el corazón de abordar estos desafíos técnicos está la dinámica.

Los API Gateways de primera generación representados por NGINX tienen capacidades dinámicas débiles. Debido a que NGINX está impulsado por archivos de configuración estáticos locales, cualquier cambio en la configuración requerirá recargar el servicio NGINX para que surta efecto, lo cual es inaceptable para las empresas en la era del cloud-native. Este es el primer punto de dolor técnico del API Gateway de primera generación.

Gestión de clúster

El segundo punto de dolor técnico es la gestión de clúster.

WPS, una empresa de software de oficina SaaS en China, que proporciona software como Microsoft Office 365. Tienen cientos de máquinas físicas ejecutando Apache APISIX, casi 10,000 CPUs principales procesando solicitudes de API de clientes, y procesan decenas de miles de millones de APIs diariamente.

En este entorno de API Gateway a gran escala, es imposible para los desarrolladores modificar la configuración de cada API Gateway uno por uno y luego recargarlos. En su lugar, desean una consola integrada para operar todo el clúster. Desafortunadamente, cuando nació la primera generación de API Gateways, no existía una escala de instancias tan grande, por lo que los desarrolladores de la primera generación de gateways no consideraron las necesidades de gestión de clúster.

API Gateway de próxima generación

Los desafíos y puntos de dolor mencionados anteriormente han dado lugar gradualmente a una nueva generación de API Gateways.

Características del API Gateway de próxima generación

A diferencia de la primera generación de API Gateways, la comunidad de código abierto es la fuerza principal que impulsa el desarrollo de la próxima generación de API Gateways en la era del cloud-native. Con el poder de la comunidad y numerosos contribuyentes de código abierto, estos API Gateways tienen la oportunidad de formar un ciclo de iteración y evolución positivo:

• Capaz de recopilar las necesidades y puntos de dolor de los desarrolladores y usuarios mucho más rápidamente.
• Intentar resolver estos problemas en proyectos de código abierto.
• Los proyectos de código abierto se vuelven más fáciles de usar, atrayendo a más desarrolladores.

En este proceso, el API Gateway de próxima generación supera el posicionamiento de balanceo de carga y proxy inverso de los gateways tradicionales y asume más responsabilidades, como la conexión de tráfico, programación, filtrado, análisis, conversión de protocolos, gobernanza e integración (ver más abajo).

El API Gateway soporta desarrollo secundario de menor costo

Al mismo tiempo, permitir que los desarrolladores realicen desarrollos personalizados a un costo menor también se ha convertido en el punto destacado del API Gateway de próxima generación. La integración es una de las funciones esenciales del API Gateway. Para el downstream, es la resolución y conversión de protocolos, incluyendo GraphQL, gRPC, Dubbo, etc.; para el upstream, integra Okta, Keycloak, Datadog y Prometheus para servicios de autenticación y observabilidad, así como los servicios internos de certificación, registro, auditoría y otros de la empresa.

El API Gateway no puede cubrir todos los componentes del proceso de integración. Por lo tanto, es inevitable que los desarrolladores realicen desarrollos personalizados a través de plugins para satisfacer sus propias necesidades de negocio.

Diferentes API Gateways proporcionan diferentes lenguajes de programación y métodos de desarrollo para desarrollos personalizados. Por ejemplo, tanto Apache APISIX como Kong pueden usar Lua para escribir plugins nativos, mientras que Envoy usa C++ para escribir plugins nativos. Al mismo tiempo, Apache APISIX también puede usar Go, Python, Node.js, Java y Wasm para desarrollar plugins. Casi todos los desarrolladores usan uno de estos lenguajes de programación principales.

El código abierto y el desarrollo personalizado fácil son las características más importantes del API Gateway de próxima generación. Proporcionan más opciones para los desarrolladores. Mientras tanto, los desarrolladores pueden usar con confianza el API Gateway en un entorno multi-nube o híbrido, sin preocuparse por ser bloqueados por los proveedores de servicios en la nube.

Ejemplo: API Gateway para el tráfico del Black Friday

A continuación, explicaremos lo que hace un API Gateway con un ejemplo concreto.

En el Black Friday, las empresas de comercio electrónico tendrán muchas promociones, y el volumen de solicitudes de API durante este período es decenas de veces mayor que lo habitual. Primero, veamos cómo sería la arquitectura técnica si no hubiera un API Gateway:

Como se puede ver en la imagen anterior, las funciones de autenticación y registro de logs están duplicadas en los servicios de Pedidos y Pagos. Un servicio de comercio electrónico generalmente consta de miles de servicios diferentes. En este momento, gran parte del código y los procedimientos se repetirán.

La siguiente figura es el diagrama de arquitectura después de agregar el API Gateway:

Como se puede ver arriba, hemos integrado los servicios comunes en la capa del API Gateway. Como resultado, los servicios back-end solo necesitan enfocarse en su propio negocio, proporcionando más posibilidades para el escalado elástico.

Cuando comienza la promoción, millones de solicitudes de API de los clientes llegan al API Gateway, y el servicio back-end necesita realizar un escalado elástico rápido. Para proteger los negocios críticos de verse afectados por el tráfico repentino, necesitamos identificar los rastreadores maliciosos en el API Gateway e implementar la limitación de tasa, la degradación de servicio y la ruptura de circuito.

También podemos desactivar temporalmente algunos servicios, como la evaluación de productos, consultas de envíos, etc. Sin embargo, los negocios centrales como la información de inventario, la compra y el pago no deben fallar. Por lo tanto, necesitamos gestionar el servicio de contenedores a través de K8s y generar más copias del servicio para mantener su funcionamiento adecuado. En este momento, el API Gateway necesita enrutar la solicitud de API del cliente a la nueva réplica del servicio y eliminar automáticamente el servicio defectuoso, como se muestra en la siguiente figura:

Resumen

En resumen, el API Gateway no es un middleware nuevo. Sin embargo, ha ganado cada vez más importancia a medida que las arquitecturas técnicas evolucionan y los productos iteran a un ritmo cada vez más rápido. La aparición del API Gateway de próxima generación en el cloud-native resuelve los puntos de dolor de los usuarios empresariales en términos de gestión de clúster, dinámica, ecosistema, observabilidad y seguridad.

El API Gateway puede manejar no solo el tráfico de API, sino también el tráfico de Kubernetes Ingress y service mesh, acortando aún más la curva de aprendizaje de los desarrolladores y ayudando a las empresas a gestionar el tráfico de manera integrada.

Contáctenos para obtener más información sobre Apache APISIX, API7 Enterprise Edition y los productos API7 Cloud.