TUP_4C_LCIV_TEO_U1_Microservicios.pdf

LABORATORIO DE COMPUTACIÓN IV Unidad Temática N°1: Microservicios Material de Estudio 2° Año – 4° Cuatrimestre Índice ¿Qué son los microservicios? 2 Autónomos.....................

LABORATORIO DE COMPUTACIÓN IV Unidad Temática N°1: Microservicios Material de Estudio 2° Año – 4° Cuatrimestre Índice ¿Qué son los microservicios? 2 Autónomos................................................................................................................ 3 Especializados.......................................................................................................... 4 Monolitos vs Microservicios 5 Escalabilidad............................................................................................................. 6 Ventajas y desventajas de la arquitectura de microservicios 7 Ventajas.................................................................................................................... 8 Desventajas............................................................................................................... 8 Tolerancia a fallos y gestión de errores. 9 Tolerancia a fallos:.................................................................................................... 9 Gestión de errores:.................................................................................................. 10 Resiliencia............................................................................................................... 10 Patrones y Buenas Prácticas en microservicios 11 Circuit Breaker......................................................................................................... 12 API Gateway........................................................................................................... 13 Laboratorio de Computación IV Material de Estudio – U1 Pág. 1 ¿Qué son los microservicios? Los microservicios son una arquitectura de diseño de software que ha ganado una gran popularidad en la última década debido a su capacidad para abordar los desafíos asociados con sistemas monolíticos y el creciente enfoque en la entrega rápida y eficiente de aplicaciones. Esta arquitectura ofrece una manera moderna y escalable de desarrollar, desplegar y mantener aplicaciones complejas, brindando una mayor flexibilidad y eficiencia para las organizaciones y equipos de desarrollo. En el contexto de la arquitectura de microservicios, una aplicación completa se divide en un conjunto de servicios más pequeños e independientes que se conocen como "microservicios". Cada uno de estos microservicios representa una funcionalidad específica y bien definida dentro de la aplicación general, lo que permite un enfoque modular y un desacoplamiento entre las distintas partes del sistema. Cada microservicio es responsable de una tarea o una función del negocio y opera de manera independiente, lo que facilita su desarrollo, implementación, escalabilidad y mantenimiento. La principal premisa detrás de los microservicios es la división del sistema en componentes más manejables y especializados, en lugar de tener un gran monolito donde todas las funcionalidades están fuertemente acopladas. Esto permite que cada microservicio se desarrolle y se despliegue de manera independiente, sin afectar a los demás. De hecho, diferentes equipos de desarrollo pueden trabajar en microservicios separados al mismo tiempo, lo que fomenta la colaboración y aumenta la velocidad de desarrollo. La comunicación entre los microservicios se realiza generalmente a través de interfaces bien definidas, como API (Interfaces de Programación de Aplicaciones) RESTful o gRPC. Estas interfaces permiten que los microservicios se comuniquen entre sí de manera eficiente y estandarizada. Al tener una interfaz clara y definida para cada microservicio, se facilita la comprensión de cómo interactúan los diferentes componentes y se mejora la mantenibilidad y escalabilidad del sistema. Además, los microservicios permiten que los equipos utilicen diferentes tecnologías y lenguajes de programación para desarrollar cada servicio según las necesidades específicas. Esto proporciona una gran flexibilidad y evita que un equipo quede limitado a una única tecnología para toda la aplicación. La arquitectura de microservicios también facilita la escalabilidad horizontal, lo que significa que se pueden agregar más instancias de un microservicio específico para manejar un mayor número de solicitudes o cargas de trabajo, sin afectar el rendimiento global del sistema. Esto se debe a Laboratorio de Computación IV Material de Estudio – U1 Pág. 2 que cada microservicio es autónomo y puede escalar por separado, lo que permite una mayor eficiencia en el uso de recursos. Sin embargo, a pesar de sus numerosos beneficios, los microservicios también presentan desafíos significativos, especialmente en términos de gestión y monitoreo de múltiples servicios, así como en el manejo de la complejidad de las interacciones entre ellos. La orquestación, el monitoreo, la seguridad y la consistencia de datos son aspectos críticos que deben considerarse cuidadosamente al adoptar esta arquitectura. Entonces… ¿Qué son los microservicios..? Es un enfoque arquitectónico y organizativo para el desarrollo de software en el que el sistema está compuesto por pequeños servicios autónomos y especializados que se comunican a través de APIs bien definidas, eventos/mensajes. Organizativamente, los propietarios de estos servicios son equipos pequeños independientes. Autónomos Cada servicio componente en una arquitectura de microservicios se puede desarrollar, implementar, operar y escalar sin afectar el funcionamiento de otros servicios. Los servicios no necesitan compartir ninguno de sus códigos o implementaciones con otros servicios. Cualquier comunicación entre componentes individuales ocurre a través de API, eventos o mensajes. Algunas características clave que hacen que los microservicios sean autónomos incluyen: Despliegue independiente: Cada microservicio puede ser implementado y actualizado por separado sin afectar a los otros servicios. Esto permite una mayor agilidad en el despliegue de nuevas funcionalidades o correcciones de errores, ya que no es necesario detener o recompilar todo el sistema para realizar un cambio en un microservicio específico. Lógica de negocio específica: Cada microservicio está diseñado para abordar una tarea o función específica del negocio. Esto significa que cada servicio se enfoca en una sola responsabilidad, lo que facilita el mantenimiento y la comprensión del código. Comunicación a través de interfaces: Los microservicios se comunican entre sí a través de interfaces claramente definidas, como API RESTful o gRPC. Esto proporciona un acoplamiento mínimo y evita que los servicios se entrelacen en exceso. Laboratorio de Computación IV Material de Estudio – U1 Pág. 3  Escalabilidad independiente: Los microservicios pueden escalar de manera independiente según su demanda específica. Si un servicio experimenta una carga alta, se pueden agregar más instancias de ese servicio sin afectar la escalabilidad de otros. Tecnología y plataforma independiente: Cada microservicio puede estar desarrollado en diferentes tecnologías o lenguajes de programación, lo que brinda a los equipos de desarrollo la libertad de utilizar las herramientas más adecuadas para cada servicio. Aislamiento de fallos: La autonomía de los microservicios permite que un fallo en uno de ellos no afecte directamente a los demás. Esto ayuda a mantener la estabilidad general del sistema y a aislar y resolver problemas de manera más efectiva. Especializados Cada servicio está diseñado para un conjunto de capacidades y se enfoca en resolver un problema específico. Si los desarrolladores aportan más código a un servicio a lo largo del tiempo y el servicio se vuelve más complejo, se puede dividir en servicios más pequeños. La especialización de un microservicio tiene varias implicaciones importantes: Enfoque en una sola responsabilidad: Cada microservicio tiene una funcionalidad limitada y claramente definida, lo que facilita el entendimiento de su propósito y el mantenimiento del código asociado. Esto mejora la legibilidad y facilita la resolución de problemas y actualizaciones. Desarrollo y despliegue ágil: Al ser específico en su propósito, el desarrollo de un microservicio se puede llevar a cabo de manera más rápida y eficiente. Además, su despliegue e implementación son independientes, lo que agiliza el proceso de lanzamiento y actualización. Acoplamiento reducido: Al tener funcionalidades especializadas y bien definidas, los microservicios minimizan las dependencias entre sí. Esto permite una mayor flexibilidad y facilidad para modificar o mejorar un servicio sin afectar a otros. Escalabilidad dirigida: Los microservicios especializados permiten escalar solo aquellos componentes que enfrentan una mayor carga de trabajo, sin tener que escalar todo el sistema. Esto brinda una mejor utilización de recursos y una mayor eficiencia. Mejor adaptación a la evolución del negocio: Al tener una especialización clara, los microservicios son más adaptables a los cambios en los requerimientos o en el enfoque del negocio. Pueden ser modificados o reemplazados sin afectar al resto del sistema. Laboratorio de Computación IV Material de Estudio – U1 Pág. 4 Monolitos vs Microservicios Con las arquitecturas monolíticas, todos los procesos están estrechamente asociados y se ejecutan como un solo servicio. Esto significa que, si un proceso de una aplicación experimenta un pico de demanda, se debe escalar toda la arquitectura. Agregar o mejorar las características de una aplicación monolítica se vuelve más complejo a medida que crece la base de código. Esta complejidad limita la experimentación y dificulta la implementación de nuevas ideas. Las arquitecturas monolíticas aumentan el riesgo de la disponibilidad de la aplicación porque muchos procesos dependientes y estrechamente vinculados aumentan el impacto del error de un proceso. Con una arquitectura de microservicios, una aplicación se crea con componentes independientes que ejecutan cada proceso de la aplicación como un servicio. Estos servicios se comunican a través de una interfaz bien definida mediante API ligeras. Los servicios se crean para las capacidades empresariales y cada servicio desempeña una sola función. Debido a que se ejecutan de forma independiente, cada servicio se puede actualizar, implementar y escalar para satisfacer la demanda de funciones específicas de una aplicación. Imagen1: Elaboración Propia. Laboratorio de Computación IV Material de Estudio – U1 Pág. 5 Escalabilidad La escalabilidad (palabra que no existe en el diccionario de la RAE, pero que tomamos prestada del Inglés como un anglicismo), en el contexto de las arquitecturas de software y sistemas, se refiere a la capacidad de un sistema para adaptarse y manejar eficientemente un aumento en la demanda de recursos o cargas de trabajo sin perder rendimiento o funcionalidad. Es decir, un sistema escalable es capaz de crecer y adaptarse de manera flexible y eficiente para satisfacer las necesidades cambiantes y crecientes de los usuarios o aplicaciones. La escalabilidad es un aspecto crucial para garantizar que una aplicación o sistema pueda manejar el crecimiento y la expansión sin degradar su rendimiento o causar interrupciones en el servicio. La capacidad de escalar es esencial en un mundo digital en constante evolución, donde la demanda de servicios y aplicaciones puede variar significativamente a lo largo del tiempo. Existen dos tipos principales de escalabilidad en el contexto de sistemas de software: Escalabilidad Vertical (Escalado hacia arriba): Este enfoque consiste en aumentar los recursos (como CPU, memoria RAM o almacenamiento) en un solo servidor o máquina para mejorar su rendimiento y capacidad. Por ejemplo, se puede mejorar un servidor agregando más memoria o cambiando a un procesador más potente. Sin embargo, el escalado vertical tiene un límite práctico, y alcanzar ese límite puede volverse costoso o incluso técnicamente inviable. Imagen2: Elaboración Propia. Laboratorio de Computación IV Material de Estudio – U1 Pág. 6  Escalabilidad Horizontal (Escalado hacia afuera): En este enfoque, se aumenta la capacidad del sistema agregando más instancias o servidores idénticos para distribuir la carga de trabajo. En lugar de mejorar un solo servidor, se agregan más servidores que trabajan de manera conjunta para manejar la demanda creciente. El escalado horizontal es más flexible y puede brindar una mayor escalabilidad, ya que permite agregar recursos adicionales a medida que crece la demanda. Imagen3: Elaboración Propia. En el contexto de las arquitecturas monolíticas y las de microservicios, los microservicios tienen la capacidad de crecer horizontalmente y de manera dirigida u orgánica a la demanda, es decir, pueden crecer de acuerdo a la necesidad puntual de cada microservicio y acompañando a la demanda; un microservicio puede crecer en horas pico de consumo y disminuir en momentos donde no requieren tantos recursos. Ventajas y desventajas de la arquitectura de microservicios Las arquitecturas de microservicios ofrecen una serie de ventajas y desventajas que deben considerarse cuidadosamente al adoptar este enfoque en el desarrollo de software. A continuación, se presentan algunas de las principales ventajas y desventajas de las arquitecturas de microservicios: Laboratorio de Computación IV Material de Estudio – U1 Pág. 7 Ventajas Desarrollo ágil y rápido despliegue: Los microservicios permiten el desarrollo y despliegue independiente de cada componente, lo que acelera el proceso de desarrollo y mejora la agilidad del equipo. Escalabilidad y flexibilidad: La escalabilidad horizontal de los microservicios permite agregar o quitar instancias de servicios específicos según la demanda, lo que brinda una mayor flexibilidad y eficiencia en el uso de recursos. Mantenibilidad simplificada: Al tener servicios más pequeños y especializados, el mantenimiento y las actualizaciones se pueden realizar de manera más enfocada y sin afectar a otros componentes del sistema. Independencia tecnológica: Cada microservicio puede estar desarrollado utilizando diferentes tecnologías, lo que brinda a los equipos la libertad de elegir las herramientas más adecuadas para cada tarea. Mayor facilidad para equipos distribuidos: Los equipos pueden trabajar en microservicios separados, lo que permite la colaboración entre equipos distribuidos geográficamente. Resistencia a fallos: Los microservicios pueden ser diseñados para aislar fallos y evitar que afecten a todo el sistema. Desventajas Complejidad en la gestión y coordinación: Con múltiples servicios independientes, la gestión y la coordinación entre ellos puede volverse compleja, especialmente en sistemas grandes. Overhead de comunicación: La comunicación entre microservicios a través de redes puede generar un overhead adicional, especialmente si no se gestiona adecuadamente. Posible degradación del rendimiento: Una mala planificación de la comunicación entre microservicios puede llevar a una degradación del rendimiento general del sistema. Mayor esfuerzo de pruebas y monitoreo: Las pruebas y el monitoreo de múltiples microservicios pueden requerir un mayor esfuerzo debido a la naturaleza distribuida del sistema. Consistencia de datos: Mantener la consistencia de datos a través de múltiples microservicios puede ser un desafío, especialmente en operaciones transaccionales. Requerimientos de infraestructura adicionales: El despliegue de múltiples microservicios puede requerir infraestructura adicional para manejar la complejidad. Laboratorio de Computación IV Material de Estudio – U1 Pág. 8 Tolerancia a fallos y gestión de errores. La tolerancia a fallos y la gestión de errores son aspectos críticos en el diseño y desarrollo de sistemas, especialmente en entornos distribuidos como las arquitecturas de microservicios. Estos conceptos se refieren a cómo un sistema maneja situaciones inesperadas o problemas en su funcionamiento para asegurar la continuidad del servicio y la recuperación ante fallos. A continuación, explicaré cada uno de estos aspectos: Tolerancia a fallos: La tolerancia a fallos es la capacidad de un sistema para continuar funcionando de manera adecuada y proporcionar una funcionalidad degradada o una recuperación automatizada en caso de que uno o varios de sus componentes (como microservicios) experimenten fallos o errores. En una arquitectura de microservicios, la tolerancia a fallos implica diseñar los microservicios y su interacción de tal manera que el fallo en uno de ellos no afecte negativamente a todo el sistema. Algunas prácticas comunes para lograr la tolerancia a fallos son: Redundancia y replicación: Mantener copias redundantes de los microservicios y sus datos en diferentes nodos o servidores, de modo que si uno falla, otros puedan tomar su lugar. Circuit Breaker (Interruptor de circuito): Implementar el patrón de circuit breaker para detectar errores en los microservicios y evitar solicitudes adicionales hasta que el servicio se recupere. Respuestas degradadas: En lugar de fallar por completo, los microservicios pueden proporcionar respuestas degradadas, lo que significa que ofrecen una funcionalidad limitada o reducida en caso de problemas. Gestión de colas y reintentos: Si un microservicio no responde temporalmente, se puede implementar una gestión de colas y reintentos para volver a intentar la solicitud en un momento posterior. Manejo adecuado de excepciones: Los microservicios deben capturar y manejar adecuadamente las excepciones para evitar que los errores se propaguen sin control. Laboratorio de Computación IV Material de Estudio – U1 Pág. 9 Gestión de errores: La gestión de errores se refiere a la forma en que el sistema maneja los errores y las situaciones excepcionales cuando ocurren. En una arquitectura de microservicios, es fundamental implementar una gestión de errores robusta para proporcionar información significativa sobre los fallos y facilitar la resolución de problemas. Algunas prácticas para la gestión de errores incluyen: Registro y monitoreo de errores: Registrar y monitorear los errores en los microservicios para identificar patrones y tendencias de fallos y facilitar su resolución. Respuestas con códigos de estado adecuados: Devolver códigos de estado HTTP o códigos de error significativos para que los clientes puedan entender la naturaleza del problema y responder en consecuencia. Notificación y alertas: Configurar sistemas de notificación y alertas para que el equipo de desarrollo sea informado inmediatamente cuando ocurra un error crítico. Reintentos y recuperación: Implementar mecanismos de reintentos y recuperación para intentar nuevamente la operación o proporcionar alternativas en caso de errores temporales. Respuestas amigables para el usuario: Proporcionar mensajes de error claros y comprensibles para los usuarios finales, evitando mensajes técnicos o poco informativos. Resiliencia La resiliencia, en el contexto de los sistemas informáticos y las arquitecturas de software, se refiere a la capacidad de un sistema para resistir, recuperarse y adaptarse de manera efectiva ante situaciones inesperadas, fallos, errores o condiciones adversas. Un sistema resiliente es capaz de mantener su funcionalidad básica y su rendimiento incluso cuando se enfrenta a situaciones estresantes o desafiantes. La resiliencia es una propiedad esencial en sistemas distribuidos y en arquitecturas de microservicios, donde múltiples componentes o servicios trabajan juntos para brindar una funcionalidad completa. Estos sistemas están expuestos a una variedad de posibles fallos, como errores en los microservicios, problemas de red, sobrecargas, pérdidas de datos y otros eventos inesperados. La resiliencia busca garantizar que el sistema pueda recuperarse de estos fallos y siga funcionando sin afectar negativamente a la experiencia del usuario. Laboratorio de Computación IV Material de Estudio – U1 Pág. 10 Patrones y Buenas Prácticas en microservicios Los Patrones y Buenas Prácticas en microservicios son un conjunto de directrices, principios y estrategias que guían el diseño, desarrollo y despliegue efectivo de sistemas basados en microservicios. Estas pautas están diseñadas para abordar los desafíos específicos que surgen al trabajar con arquitecturas de microservicios y ayudan a los equipos de desarrollo a construir sistemas más robustos, escalables y fáciles de mantener. En el contexto de los microservicios, los patrones y buenas prácticas abordan varios aspectos clave, como la comunicación entre microservicios, la gestión de datos, la tolerancia a fallos, la seguridad, el despliegue y la escalabilidad. Estos patrones y prácticas se han desarrollado y refinado a lo largo del tiempo a medida que la adopción de las arquitecturas de microservicios ha ido aumentando, y son fundamentales para el éxito y el rendimiento óptimo de los sistemas distribuidos. Una de las principales preocupaciones en el diseño de microservicios es la comunicación efectiva entre ellos. Los patrones de Agregación y API Gateway ofrecen soluciones para manejar múltiples llamadas a microservicios y presentar una interfaz unificada al cliente. Por otro lado, los patrones de Circuit Breaker y Resiliencia ayudan a mitigar los efectos de fallos o errores en los microservicios, garantizando la disponibilidad y evitando el colapso del sistema. En términos de despliegue y escalabilidad, los patrones de Blue-Green Deployment y Canary Deployment permiten implementar actualizaciones y cambios en microservicios de forma controlada y sin interrupciones en el servicio. Además, la gestión de la configuración y la escalabilidad horizontal son aspectos clave abordados por prácticas como el uso de orquestadores de contenedores y servicios de registro y descubrimiento. La seguridad también es un factor crítico en los sistemas distribuidos. Los patrones de Autenticación y Autorización proporcionan métodos para proteger los microservicios y controlar el acceso a recursos sensibles. Además, se aplican buenas prácticas para la gestión de tokens y cifrado de datos para proteger la confidencialidad y la integridad de la información transmitida entre microservicios. Es importante mencionar que los patrones y buenas prácticas en microservicios no son soluciones rígidas o universales; más bien, son guías que se adaptan a las necesidades específicas de cada sistema y aplicación. La elección y aplicación de patrones depende de diversos factores, como la complejidad del sistema, las necesidades de negocio y las habilidades del equipo de desarrollo. Laboratorio de Computación IV Material de Estudio – U1 Pág. 11 Circuit Breaker El patrón de Circuit Breaker (Interruptor de circuito) es un patrón de diseño utilizado en arquitecturas de software para mejorar la resiliencia y la tolerancia a fallos en sistemas distribuidos, como los basados en microservicios. Su objetivo es proteger un sistema de colapsos en cadena causados por fallos en uno o varios servicios, evitando que el fallo se propague a otras partes del sistema. El patrón de Circuit Breaker se inspira en los interruptores de circuito utilizados en sistemas eléctricos, que se abren para cortar el flujo de electricidad en caso de una sobrecarga o un cortocircuito, evitando daños mayores al sistema. De manera similar, en el contexto de software, el Circuit Breaker actúa como un mecanismo de protección entre los componentes del sistema. El funcionamiento del patrón de Circuit Breaker se puede dividir en tres estados: Estado Cerrado (Closed): En este estado, el Circuit Breaker permite que las solicitudes fluyan normalmente entre los componentes del sistema. Si la operación es exitosa, el Circuit Breaker mantiene el estado cerrado y las solicitudes continúan su curso. Sin embargo, si una solicitud falla o no responde, el Circuit Breaker cuenta ese fallo. Estado Abierto (Open): Cuando el número de fallos alcanza un umbral predefinido, el Circuit Breaker cambia a estado abierto. En este estado, el Circuit Breaker bloquea las solicitudes entrantes y evita que lleguen a los componentes subyacentes que han experimentado fallos. En lugar de enviar solicitudes, el Circuit Breaker puede devolver respuestas predefinidas o enviar respuestas de error rápidas para las solicitudes. Estado Semifuncional (Half-Open): Después de un período de tiempo predefinido en estado abierto, el Circuit Breaker cambia al estado semi funcional. En este estado, se permite que una sola solicitud fluya hacia los componentes subyacentes para evaluar si la recuperación ha tenido éxito. Si la solicitud tiene éxito, el Circuit Breaker vuelve al estado cerrado y reanuda el flujo normal de solicitudes. Si la solicitud falla nuevamente, el Circuit Breaker vuelve al estado abierto y se repite el proceso. Laboratorio de Computación IV Material de Estudio – U1 Pág. 12 API Gateway API Gateway es un patrón de diseño y un componente clave en arquitecturas de microservicios y sistemas distribuidos. Es una puerta de enlace (gateway) que actúa como punto de entrada único para las solicitudes de los clientes hacia los microservicios subyacentes. En otras palabras, el API Gateway proporciona una interfaz unificada y simplificada para que los clientes interactúen con el sistema en su conjunto, en lugar de comunicarse directamente con cada uno de los microservicios individualmente. Imagen4: Elaboración Propia. Las principales funciones y características del API Gateway son las siguientes: Unificación de servicios: El API Gateway permite combinar múltiples microservicios y sus diferentes puntos de acceso en una única API pública. Los clientes pueden realizar todas sus solicitudes a través del API Gateway sin necesidad de conocer la estructura interna del sistema o interactuar con cada microservicio de manera individual. Composición de solicitudes: El API Gateway puede agrupar varias solicitudes de los clientes y realizar llamadas a diferentes microservicios para cumplir con la solicitud del cliente. Esto evita que el cliente realice múltiples llamadas a diferentes microservicios y permite que el API Gateway optimice la comunicación interna para mejorar el rendimiento. Enrutamiento y redirección: El API Gateway puede realizar el enrutamiento de las solicitudes entrantes hacia el microservicio adecuado según la lógica de negocio o los parámetros proporcionados por el cliente. También puede redirigir las solicitudes a diferentes versiones de los microservicios para permitir implementaciones de múltiples versiones. Seguridad y autenticación: El API Gateway actúa como un punto de control de acceso y puede gestionar la autenticación y autorización de los clientes antes de redirigir las solicitudes a los microservicios correspondientes. Esto centraliza la gestión de la seguridad y protege los microservicios de accesos no autorizados. Cache de datos: El API Gateway puede implementar una capa de caché para almacenar respuestas a solicitudes comunes y reducir la carga en los microservicios. Esto mejora la eficiencia y el rendimiento del sistema al reducir la cantidad de llamadas a los microservicios. Laboratorio de Computación IV Material de Estudio – U1 Pág. 13  Monitoreo y análisis: El API Gateway puede realizar el seguimiento y monitoreo de las solicitudes entrantes y salientes, lo que proporciona información valiosa para analizar el rendimiento del sistema, identificar posibles cuellos de botella y detectar problemas de manera temprana. El API Gateway no solo beneficia a los clientes que interactúan con el sistema, sino también a los desarrolladores y equipos de operaciones. Proporciona una capa de abstracción que facilita la gestión, el mantenimiento y la evolución de la arquitectura de microservicios. Además, el API Gateway puede ser implementado como un servicio independiente o incorporado en un servicio de orquestación más amplio. Es importante tener en cuenta que el diseño y la implementación del API Gateway deben considerar los requisitos específicos del sistema y la escalabilidad necesaria para gestionar la carga de solicitudes entrantes. Un diseño cuidadoso y una correcta elección de herramientas y tecnologías son fundamentales para garantizar un funcionamiento eficiente y confiable del API Gateway en el contexto de una arquitectura de microservicios. Atribución-No Comercial-Sin Derivadas Se permite descargar esta obra y compartirla, siempre y cuando no sea modificado y/o alterado su contenido, ni se comercialice. Universidad Tecnológica Nacional Facultad Regional Córdoba (S/D). Material para la Tecnicatura Universitaria en Programación, modalidad virtual, Córdoba, Argentina. Laboratorio de Computación IV Material de Estudio – U1 Pág. 14