¿Qué es un API Gateway?

Un API Gateway es la pieza encargada de unificar la publicación de APIs para que sean consumidas por otras aplicaciones o por los desarrolladores. Implementa en un producto de software lo que genéricamente han denominado “API Management” en un artículo de Paradigma Digital:
Según el autor del artículo anterior, un API Gateway suele estar formado por:

• Intercambiador de APIs: Componente cuya principal función es la de habilitar la conexión entre los servicios y los clientes.
• Gestor de APIs: Permite la configuración y publicación de APIs en el componente API Gateway.
• Dashboard de APIs: Recopila toda la información necesaria para los clientes sobre las APIs publicadas.

Funcionalidades de un API Gateway

• Enrutamiento: envía las peticiones a diferentes destinos dependiendo del contexto o del contenido del mensaje.
• Transformación: componentes destinados a transformar los datos, o de su enmascaramiento.
• Monitorización del tráfico de entrada y salida.
• Políticas de seguridad que añaden autenticación, autorización y cifrado a las APIs.
• Políticas de uso: habilitan la creación de políticas de consumo, rendimiento, fallos, etc.. para asegurar los SLAs

Sin profundizar en los beneficios que nos aportan las APIs, vamos a hablar de dos herramientas para definir y gestionar APIs de forma sencilla y eficaz.

Kong

Kong nació en 2011 como un API Gateway privado de la empresa Kong Inc. (originalmente Mashup) apoyado en el servidor HTTP Nginx con un enfoque claro: ofrecer alto rendimiento. Más tarde en 2015 se convierte en un proyecto open-source.
Hoy en día su uso está extendido de forma global en más de 5000 organizaciones.
Disponemos de dos modalidades de Kong:

• Community Edition: La versión CE viene bastante bien equipada, con soporte de plugins open-source, balanceo de carga y service discovery entre otros, pero no incluye un panel de administración, por lo que configuraremos Kong vía REST o bien apoyándonos en algunos de los dashboard open-source que existen como Konga o Kong Dashboard.
• La versión Enterprise Edition nos ofrece muchas más funcionalidades de serie como el dashboard de administración, plugins de seguridad, métricas y soporte 24x7 entre otros.

Podemos consultar más en detalle la lista completa con todas las diferencias entre CE y EE.
Kong puede ser instalado de diversas formas tanto en infraestructura propia como en la nube. Disponemos desde paquetería nativa de Debian, Red Hat, y OS X, hasta contenedor de Docker y CloudFormation para AWS entre otros.

Arquitectura de Kong

El equipo de Kong propone la siguiente arquitectura de referencia:

• Kong Server: Es la pieza que hace de proxy de todas las peticiones. Consta de una capa pública por la cual le llegan las peticiones para acceder a las APIs que expone y otra privada para la administración y configuración de las mismas. Además nos permite habilitar, deshabilitar y configurar los plugins instalados.
• Kong Datastore: Es una base de datos externa que sirve como almacenamiento de todas las configuraciones de Kong y sus plugins o APIs. Los datastore soportados por defecto son Cassandra y PostgreSQL.

Importante: Kong utiliza su propia caché para operar, sin embargo en determinados casos, algunos plugins como el rate-limiting requieren de componentes adicionales como Redis.

Plugins

Kong dispone de un ecosistema de plugins bastante grande, existiendo plugins open-source y enterprise. En algunos casos puede tratarse del mismo plugin pero con las prestaciones limitadas en su distribución open-source.
Podemos encontrar diversos plugins como Autenticación LDAP, CORS, Dynamic SSL, AWS Lambda, Syslog y muchos más.
Si no encontramos lo que necesitamos siempre podemos crear nuestro propio plugin. Al estar basado en Nginx, Kong viene equipado con el paquete OpenResty y nos permite crear plugins utilizando Lua.

Si no encontramos la funcionalidad que necesitamos, podemos crear nuestro propio plugin para Kong en el lenguaje Lua.

Escalado

Kong escala horizontalmente con gran facilidad. Simplemente hay que levantar nuevos nodos y conectarlos a la base de datos. Debemos tener en cuenta que la base de datos es el punto único de fallo, de modo que si queremos una alta disponibilidad tiene que estar replicada.

Tyk

Tyk es un API Gateway open-source que nació en 2014 antes incluso del API Gateway como servicio de AWS. Tyk está desarrollado en Golang y utiliza el servidor HTTP del propio lenguaje.

Si queremos utilizar Tyk disponemos de varios sabores: Cloud, Hybrid (GW en infraestructura propia) y On-Premises.
Cabe destacar que en la versión cloud podemos tener un API Gateway con un tráfico de 50.000 peticiones diarias de forma gratuita, mientras que la modalidad on-premises nos permite tener una instancia corriendo de manera gratuita.
Existen varias formas de instalar Tyk: paquetería estándar de Ubuntu y RHEL, tarball o contenedor de Docker.

Arquitectura de Tyk

Tyk está compuesto por 3 piezas:

• Gateway: El proxy por el que pasa todo el tráfico de nuestras aplicaciones.
• Dashboard: La interfaz desde la cual podemos administrar Tyk, visualizar las métricas y organizar las API.
• Pump: Es el encargado de persistir los datos de las métricas y exportarlas a MongoDB (instalación de serie), ElasticSearch, InfluxDB entre otros.

Plugins

Tyk dispone de extensiones que nos permiten integrarlo con diferentes mecanismos de autenticación como LDAP, OAuth, etc.. Además nos ofrece la posibilidad de establecer cuotas de tráfico, versionado, importación desde Swagger o API Blueprint e incluso integración con sistemas de service discovery como Consul o etcd, así como el balanceo entre diferentes clústeres o data centers.
Si tenemos un requisito que no cumplen los plugins que vienen de serie podemos crearlos nosotros usando Lua, Python o gRPC.

Escalado

Escalar Tyk es tan sencillo como levantar una instancia más de Tyk Gateway y conectarla a la misma base de datos para mantener la consistencia. Si queremos alta disponibilidad podemos usar MongoDB configurado con replica set.

Batería de pruebas
Hemos sometido a Kong y Tyk a una carga de 100 usuarios concurrentes durante 60 segundos, y también aumentando el número de instancias del backend para ver cómo afecta al rendimiento. Las pruebas se han realizado con Siege.
El Hardware utilizado para todas las pruebas ha sido:

• CPU: i7-6820HQ @ 2.70GHz
• RAM: 16GiB
• HDD: SSD 512GB

Para correr tanto Tyk Como Kong hemos usado la distribución basada en Docker y sus correspondientes bases de datos.
Con autenticación básica desactivada estos han sido los resultados:

En el caso de Tyk hemos utilizado tokens ya que el rendimiento usando autenticación básica ha sido extremadamente pobre, alrededor de 85 peticiones por segundo. Es posible que sea un bug en la versión que hemos utilizado en nuestras pruebas.

Conclusiones

Como hemos podido comprobar, tanto Kong como Tyk vienen con bastantes funcionalidades de serie, en muchos casos más que suficientes para entornos pequeños de entre uno y diez microservicios sin demasiada concurrencia.

Ahora bien, si queremos un número de microservicios significativamente mayor o simplemente tener alta disponibilidad con tolerancia a fallos necesitamos escalar el número de gateways. En el caso de Kong es tan simple como levantar un nodo nuevo y conectarlo a la base de datos. Con Tyk podemos hacer lo mismo aunque previo paso por caja. Este podría ser un factor determinante a la hora de elegir qué API Gateway usar.

Es de agradecer que Tyk open-source lleve de serie el panel de control, las métricas y logs integrados. Sin embargo con Kong debemos recurrir a las alternativas open-source si queremos disponer de un panel de control de forma gratuita. Lo mismo ocurre con las métricas y logs: hay que usar plugins que requieren de configuraciones adicionales.

Escalar en el caso de Kong es tan simple como levantar un nodo nuevo y conectarlo a la base de datos.

Otra cosa a favor de Tyk es la Tyk Cloud, un servicio que nos ahorra gestionar la capa de infraestructura, y que nos podría venir bien si somos un pequeño negocio o Startup.
En cuanto a rendimiento, en nuestras pruebas el King ha sido Kong. Ha conseguido batir a Tyk en todas las pruebas, tanto con autenticación desactivada como activada, llegando a obtener el doble de peticiones procesadas en el segundo de los casos.

Definitivamente estamos ante dos herramientas muy buenas, repletas de funcionalidades, cada una con sus virtudes y flaquezas. Sin duda, usar un API Gateway es el aliado perfecto para una arquitectura de microservicios y contenedores.

Te animamos a participar enviando tus comentarios a BBVA-Labs@bbva.com y, si eres de BBVA, aportando tus propuestas de publicación.

Actualizado

Hemos recibido valioso feedback del equipo de Tyk. Nos han informado de que el la versión CE sin dashboard (headless) es posible escalar el gateway sin disponer de un plan de pago al igual que Kong. En la web oficial hacen referencia en este apartado.

También nos han comentado que en el modo headless el rendimiento es superior ya que las métricas y los logs estan deshabilitados.

Hemos realizado una una batería de pruebas con los logs y métricas deshabilitados. Estos han sido los resultados: