Azure API Management: Lo bueno, lo bonito y lo no tan bonito

Azure API Management: Lo bueno, lo bonito y lo no tan bonito


Si estás construyendo APIs, ya sea REST, OData o GraphQL, es muy probable que implementes estas APIs dentro de algún servicio de nube como Azure App Service, Azure Functions o incluso tal vez en los clásicos servidores de aplicaciones/web como IIS si eres del mundo .NET o WildFly, GlassFish y Tomcat si eres del mundo Java.

Esta forma de trabajar es abordable cuando tienes uno o pocos equipos, con un número de APIs modesto; no hay un número exacto para esto, pero se podría considerar un número modesto entre 1 a 30 APIs. Después de esto, comenzarás a tener sensaciones de pérdida de control de lineamientos, mucha diversidad en cuestiones transversales como el manejo de la autenticación, manejo de versiones, manejo de valores sensibles, así como complejidad para poder hacer seguimiento y monitoreo.

Para poder recuperar o tener el control existe un conocido patrón relacionado con el mundo de microservicios que se conoce como API Gateway (nació con microservicios, pero se puede implementar junto con otro tipo de arquitecturas). Este patrón consiste en poner una capa delantera de infraestructura antes de poder llegar a tu capa de infraestructura de backend (por ejemplo, Kubernetes y microservicios). Esta capa adicional se agrega para lograr las siguientes capacidades:

  • Proxy: ocultamiento de backend, ruteo, reenvío y balanceo.
  • Autenticación y autorización: con diferentes proveedores y protocolos, OAuth2, tokens y keys.
  • Capacidad de caché: principalmente caché de respuestas.
  • Logging, monitoreo y observabilidad centralizado.
  • Rate limit: para evitar automatizaciones y ataques de saturación desde un mismo punto.

Entonces, Azure API Management es un servicio de Azure que implementa el patrón de API Gateway, pero que además agrega capacidades de gobernanza y administración como las siguientes:

  • Versionado: para la evolución de las APIs en operaciones y cambios de contrato.
  • Validación de esquemas y transformaciones de headers, body y parámetros.
  • Monetización: productos, cuotas y suscripciones.
  • Capacidades al desarrollador: portal para desarrollo, documentación OpenAPI, WSDL, esquemas públicos, entre otros.

Entonces, dados estos beneficios, ¿Azure API Management debe ser el camino para todo equipo que construye APIs? La respuesta corta es que depende de tu propio escenario, pero debes tener en cuenta las siguientes consideraciones:

  • El tamaño de la organización. Un equipo pequeño con productos de pocas APIs se puede percibir como un exceso, por el alto costo y porque las capacidades de gobernanza no se percibirán como un beneficio. Por otro lado, una organización grande, con múltiples productos y equipos, con múltiples iniciativas creando y modificando APIs en cada iteración, para este escenario es un componente que toma mucha relevancia.
  • Qué nivel de gobernanza deseas lograr. API Management es gobernanza de ejecución e implementación para todas aquellas APIs que deseas exponer por Azure. Pero este puede que no sea tu caso, ya que puedes tener APIs en otro proveedor de nube, On-Premise o incluso APIs en otras plataformas. ¿Cómo gobiernas estas APIs en un catálogo coherente? Incluso puede que no quieras usar API Management para exponer APIs en Azure; seguirás con tus App Services, Functions o Container Apps, pero deseas un catálogo de APIs que te permita gobernar todas estas APIs. Para estos escenarios, API Center es una mejor opción que API Management.
  • El precio siempre es un factor importante. Los niveles que permiten la mayor capacidad de gobernanza, como Premium, tienen un coste por arriba de $1500 USD mensuales. Existen otros planes tipo consumo y estándar, pero tienen limitantes para integrarse en redes virtuales y capacidades multirregión.
  • La complejidad técnica. Implementar API Management con requisitos de seguridad y disponibilidad regional no es una tarea trivial. Incluso se debe combinar con otros componentes como Azure Front Door o Application Gateway para poder obtener capacidades WAF, disponibilidad global y anti-DDoS, lo cual incrementará el costo de implementación.

Por otro lado, API Management no es la única opción para implementar el patrón API Gateway. Si eres del mundo .NET, puedes implementar un gateway con base en la librería YARP. Si no eres del mundo .NET, podrías usar Envoy. Cabe mencionar que este tipo de implementaciones propias te permitirán lograr las capacidades técnicas, pero no las capacidades de gobernanza que te da API Management.

Si ya decidiste implementar API Management en tus soluciones y te encuentras en la aventura de diseñar tu posible implementación, te dejo una propuesta que podría calzar con tu escenario:

Implementación API Management en Azure

Este diagrama se puede explicar en alto nivel de la siguiente manera:

  • Para recibir las peticiones desde aplicaciones web o móviles, se encuentra una capa WAF implementada con Azure Front Door; esto permite seguridad web, protección anti-bots y anti-DDoS.
  • Front Door debe tener configurado un grupo de origen con dos backends, uno por cada gateway regional de API Management. Cada gateway está en su propia red virtual, protegida con reglas de grupo de seguridad.
  • Las APIs expuestas al exterior en API Management apuntan a Container Apps dentro de un Container App Environment en su propia VNET y también regional para lograr disponibilidad regional.
  • Estas APIs “públicas” consumen servicios o APIs internas que solo pueden ser accedidas dentro del Environment.
  • En API Center se puede catalogar las APIs expuestas por API Management y también las APIs internas.
  • En la propuesta elegí Container App porque lo considero un servicio versátil y preparado para aplicaciones basadas en contenedores, sin tener que lidiar con la complejidad de un clúster de Kubernetes, pero en un caso específico también se pueden poner como backend clústeres de AKS regionales.
Conclusiones
  • Azure API Management es una excelente opción para implementar API Gateway y lograr gobernanza de APIs, pero debes tener en cuenta si realmente lo necesitas y toda la complejidad que esto implicará.
  • Si tienes un equipo pequeño y un inventario modesto de APIs, evalúa opciones intermedias para gobernar tus APIs; escala de forma progresiva conforme creces en cantidad y complejidad.

Sígueme en Linkedin para estar al tanto de mis publicaciones y novedades

Referencias