La gran mayoría de las aplicaciones modernas, exponen recursos a internet con la intención de que otras aplicaciones o usuarios puedan accederlos, sin embargo, mantener una línea clara entre los recursos públicos y privados es una tarea complicada, pero, sobre todo, es clave para la seguridad, por lo que mantener una certeza clave de que recursos son expuestos a internet es fundamental.
Problemática
Uno de los problemas más olvidados al momento de construir Microservicios es, la forma de exponer estos servicios a los clientes, pues a pesar de que una arquitectura de Microservicios es muy buena en el Backend, puede tener varios inconvenientes para los clientes o consumidores de estos servicios, pues cada Microservicios proporciona una pequeña cantidad de servicios, lo que requiere que una aplicación requiere de varios Microservicios para brindar una funcionalidad completa al usuario, lo que hace que cada aplicación requiere conocer la ubicación de cada Microservicio y los servicios que expone cada uno, lo cual genera una experiencia muy mala para los clientes.
Otro de los problemas que se presenta con frecuencia es la seguridad, pues no podemos exponer todos nuestros servicios a internet, por lo que debemos de controla la forma en que los clientes los consumen y la forma en lo que hacen, por lo que dar un acceso directo a un Microservicio implica dar acceso a todos sus recursos o nos obliga a implementar la seguridad en cada método de cada Microservicio lo cual es una tarea titánica.
Comunicación directa a los Microservicios
Finalmente, cada cliente requiere de una experiencia diferente, por lo tanto, habrá clientes que requieran los datos en formatos diferentes o con políticas de acceso diferentes, por lo que exponer los Microservicios tal cual están desarrollados puede ser un problema para algunos clientes, por lo que es indispensable proporcionar una capa que les permite tener una mejor experiencia.
En la imagen anterior se puede apreciar más claro el problema que mencionaba antes, donde cada aplicación tiene que conocer la ubicación física de cada Microservicio, además, si el servicio se expone sin más, puede tener graves problemas de seguridad, pues estamos exponiendo todos los recursos del Microservicio a internet, y aun cuando estos recursos tenga seguridad, siempre corremos el riego de que alguien logre acceder, entonces, si hay recursos que no son necesario exponer, ¿para qué exponerlos?, lo mejor será mantenerlos privado.
Solución
Para solucionar estos problemas, podemos utilizar un API Gateway, el cual, y como su nombre lo dice, es una compuerta para nuestra API, desde la cual podemos exponer nuestros Microservicios personalizando la experiencia para cada cliente, de esta forma, podemos indicar que servicios exponer, el formato de los datos retornados, e incluso, controlar el acceso, además, nos permite proporcionar un único punto de acceso para toda el API, lo que podemos aprovechar para agregar la seguridad que sea necesaria.
En pocas palabras, el API Gateway es la cara que damos a los clientes, y es la forma en que los clientes externos se comunicarán con nosotros por lo que es común que el API Gateway ofrezca servicios simples y de alto nivel que oculten la complejidad de nuestra arquitectura.
Implementando un API Gateway
Este enfoque es especialmente útil cuando los clientes son aplicaciones de terceros, los cuales no necesitan saber los detalles de cómo están compuestos nuestros servicios, como están divididos y los Endpoints internos de nuestros Microservicios.
En la imagen anterior podemos ver cómo los clientes solo se comunican con el API Gateway y no necesitan preocuparse por si existen múltiples instancias o si tenemos un balanceador, o incluso, el API está compuesta de múltiples Microservicios, porque al final, el cliente solo accede a todos los servicios por una URL base.
Conclusiones
Ocultar la complejidad de nuestra API a nuestros clientes es super importante, porque reducimos la complejidad para utilizarla, logrando con esto, tener una mejor experiencia en su utilización, pero al mismo tiempo, nos permite controlar la forma y los servicios que exponer al público, creando una barrera clara entre los servicios públicos y privado, obteniendo con esto, claras ventajas de seguridad para el API.
Por otra parte, el usuario solo conocerá un solo punto de acceso, lo que nos permitirá aplicar políticas más fácilmente, como monitoreo de solicitudes, seguridad, auditoría, medir SLA’s, etc.
Acerca de este libro
Todo lo que acabas de ver en este artículo es solo una pequeña parte del libro Introducción a la arquitectura de software, el libro más completo en español sobre arquitectura de software, donde cubrimos los temas más importantes para convertirte en un arquitecto de software profesional.
¿Quieres convertirte en arquitecto de software pero no sabes cuál es el camino adecuando? o simplemente no sabes que guía estudiar para convertirte en arquitecto de software, te invito a que veas mi libro:
