entrepreneur-696966_640

Veo en este gran artículo toda una descripción de las características que debe tener un API Gateway y el rol que desempeña en una arquitectura basada en APIs y en Microservicios.

Repasando estas características, y si nos atenemos a los aspectos más técnicos, la verdad es que no veo gran diferencia con lo que podríamos definir como el concepto clásico de un ESB.

Mediación en las invocaciones a los servicios desde el cliente

A poco que tengamos la funcionalidad de la solución que tenemos entre manos, como la típica de una tienda online, tendremos varios servicios que van a proporcionar una parte de la lógica de negocio que necesitamos para responder al consumidor. Estos servicios pueden ser unos cuantos (manejables hasta cierto punto) pero en sistemas completos pueden llegar a ser decenas de ellos, y esto se nos puede escapar de las manos.

Evidentemente implementar un servicio compuesto desde el cliente, una app móvil por poner un ejemplo, tendría varios inconvenientes. Además de la complejidad de hacer esto en un dispositivo con relativamente menos capacidad de proceso, seguramente tendríamos que hacer varias invocaciones a servicios con lo que puede significar esto para el tiempo de espera y el gasto del plan de datos móvil.

En definitiva, parece claro que necesitamos que este API Gateway haga de mediador y sea capaz de orquestar las llamadas a los servicios de grano finos proporcionando un servicio de alto nivel para el consumidor. Si recordamos, este es uno de los cometidos de los ESB.

Integrarse con diferentes tecnologías y protocolos

Los servicios que tenemos que orquestar pueden estar hechos con diferentes tecnologías y con diferentes protocolos de transporte. Sería una locura que el cliente tenga que lidiar con toda esta heterogeneidad para poder invocar a la lógica de negocio. Parece lógico también que esta complejidad se delega a un middlware que ofrezca algunas facilidades para hacer esto… una vez más aquí entra el API Gateway… pero también nos encontramos con un típico cometido del ESB.

¿Dónde están los servicios?

Esta es una de las características de SOA, y con los servicios más independientes (o autónomos) que nunca cobra más importancia que tengamos la libertad de distribuir los servicios y moverlos por diferentes servidores según las necesidades de disponibilidad, escalabilidad o simplemente economía que nos vayamos encontrando. ¿Cómo encuentro los servicios entonces? y también ¿Cómo los descubro? y el descubrimiento se puede hacer incluso en tiempo de ejecución.
¿Cómo se logra esto? pues con una herramienta que sea capaz de registrar los servicios (más o menos dinámicamente) y que luego sea capaz de encontrarlos… otro cometido para el API Gateway y también, una vez más, una característica fundamental clásica de un ESB.

Así pues, me hacía a mi mismo la pregunta de que al final, ¿en qué se diferencia el concepto de API Gateway del de ESB?

Una diferencia de concepto

Sin embargo, creo que hay una diferencia de opinión, que quizás no es tan técnica. Es más bien una diferencia de orientación, de cómo se entiende esta pieza del engranaje. Por decirlo, grosso modo, según mi visión un ESB está orientado a servicios por así decirlo. Pero no me refiero ahora a SOA, que eso es obvio. Me refiero a que lo que prima en un ESB es cómo implementar los mecanismos de seguridad de la especificación que corresponda, de cómo crear un servicio compuesto que se integre con otros servicios, de como transformar el protocolo de transporte de un servicio en otros muchos protocolos… en definitiva, podríamos decir que está orientado a hacer la “vida más fácil” a los propios servicios.

Sin embargo, con el API Gateway es distinto. También por supuesto vale para integrar, transformar protocolos, etc, etc. sin embargo, la solución orientada a los APIS tiene una diferencia fundamental, está orientada a hacerle la vida más fácil a los desarrolladores que van a usar este API.

Anuncios