Microservicios

En ingeniería de software , una arquitectura de microservicios es un patrón arquitectónico que organiza una aplicación en una colección de servicios de grano fino y débilmente acoplados que se comunican mediante protocolos ligeros. Este patrón permite a los equipos desarrollar, implementar y escalar servicios de forma independiente, mejorando la modularidad, la escalabilidad y la adaptabilidad. Sin embargo, introduce una complejidad adicional, particularmente en la gestión de sistemas distribuidos y la comunicación entre servicios, lo que hace que la implementación inicial sea más desafiante en comparación con una arquitectura monolítica . ^{[ 1 ]}

No existe una definición única y universalmente aceptada de microservicios. Sin embargo, generalmente se caracterizan por su enfoque en la modularidad, donde cada servicio se diseña en torno a una capacidad de negocio específica. Estos servicios están débilmente acoplados, se pueden implementar de forma independiente y, a menudo, se desarrollan y escalan por separado, lo que permite una mayor flexibilidad y agilidad en la gestión de sistemas complejos. La arquitectura de microservicios está estrechamente relacionada con principios como el diseño orientado a dominios, la descentralización de datos y la gobernanza, y la flexibilidad para utilizar diferentes tecnologías para que cada servicio satisfaga mejor sus requisitos. ^{[ 2 ] [ 3 ] [ 4 ]}

Es común que las arquitecturas de microservicios se adopten para aplicaciones nativas de la nube , computación sin servidor y aplicaciones que utilizan la implementación de contenedores ligeros a través de la virtualización a nivel del sistema operativo . Según Fowler , debido a la gran cantidad de servicios (en comparación con las implementaciones de aplicaciones monolíticas), la entrega continua descentralizada y DevOps con monitoreo holístico de servicios son necesarios para desarrollar, mantener y operar dichas aplicaciones de manera efectiva. ^{[ 5 ]} Una consecuencia (y justificación) de seguir este enfoque es que los microservicios individuales se pueden escalar individualmente. En el enfoque monolítico, una aplicación que soporta tres funciones tendría que escalarse en su totalidad incluso si solo una de estas funciones tuviera una restricción de recursos. ^{[ 6 ]} Con los microservicios, solo el microservicio que soporta la función con restricciones de recursos necesita escalarse, lo que proporciona beneficios de optimización de recursos y costos. ^{[ 7 ]} A pesar de sus beneficios, la arquitectura de microservicios introduce desafíos como una mayor complejidad operativa, latencia de red y la necesidad de mecanismos robustos de monitoreo y tolerancia a fallas.

La arquitectura basada en celdas es un diseño de computación distribuida en el que los recursos computacionales se organizan en unidades autónomas llamadas celdas. Cada celda opera de forma independiente, manejando un subconjunto de solicitudes y manteniendo la escalabilidad, el aislamiento de fallos y la disponibilidad. ^{[ 2 ] [ 8 ] [ 9 ]}

Una celda generalmente consta de múltiples microservicios y funciona como una unidad autónoma. En algunas implementaciones, conjuntos completos de microservicios se replican en varias celdas, lo que permite redirigir las solicitudes a otra celda operativa si una falla. Este enfoque busca mejorar la resiliencia del sistema al limitar el impacto de fallas localizadas. ^{[ 2 ] [ 8 ] [ 9 ]}

Algunas implementaciones incorporan disyuntores dentro y entre celdas. Dentro de una celda, los disyuntores pueden utilizarse para mitigar fallos en cascada entre microservicios, mientras que los disyuntores entre celdas pueden aislar las celdas con fallos y redirigir el tráfico a las que permanecen operativas. ^{[ 2 ] [ 8 ] [ 9 ]}

La arquitectura basada en celdas se ha adoptado en ciertos sistemas distribuidos a gran escala donde el aislamiento de fallos y la redundancia son prioridades de diseño. Su implementación varía según los requisitos del sistema, las limitaciones de la infraestructura y los objetivos operativos específicos. ^{[ 2 ] [ 8 ] [ 9 ]}

En 1999, el desarrollador de software Peter Rodgers trabajaba en el proyecto de investigación Dexter en Hewlett Packard Labs , cuyo objetivo era lograr que el código fuera menos frágil y que los sistemas de software complejos y a gran escala fueran robustos ante los cambios. ^{[ 10 ]} En última instancia, esta línea de investigación condujo al desarrollo de la computación orientada a recursos (ROC), una abstracción de computación generalizada en la que REST es un subconjunto especial. En 2005, durante una presentación en la conferencia Web Services Edge, Rodgers defendió los " servicios REST " y afirmó que " los componentes de software son microservicios web... Los microservicios se componen utilizando pipelines tipo Unix (la web se encuentra con Unix = acoplamiento flexible real ). Los servicios pueden llamar a otros servicios (+múltiples entornos de ejecución de lenguaje). Los ensamblajes de servicios complejos se abstraen tras interfaces URI simples . Cualquier servicio, con cualquier nivel de granularidad, puede exponerse". Describió cómo una plataforma de microservicios bien diseñada "aplica los principios arquitectónicos subyacentes de los servicios web y REST junto con la programación y las canalizaciones tipo Unix para proporcionar una flexibilidad radical y una mayor simplicidad en las arquitecturas orientadas a servicios. ^{[ 11 ]}

También en 2005, Alistair Cockburn escribió sobre la arquitectura hexagonal , un patrón de diseño de software que se utiliza junto con los microservicios. Este patrón posibilita el diseño de microservicios, ya que aísla en capas la lógica de negocio de los servicios auxiliares necesarios para desplegar y ejecutar el microservicio de forma totalmente independiente.

Determinar el nivel adecuado de granularidad de (micro)servicios en una arquitectura de microservicios suele requerir una colaboración iterativa entre arquitectos y desarrolladores. Este proceso implica evaluar los requisitos del usuario, las responsabilidades del servicio y las características arquitectónicas, como los requisitos no funcionales. Neal Ford destaca el papel de los factores integradores y desintegradores en este contexto. Los factores integradores, como las transacciones compartidas o los procesos estrechamente acoplados, favorecen la combinación de servicios, mientras que los factores desintegradores, como la tolerancia a fallos o la escalabilidad independiente, fomentan la división de servicios para cumplir con los objetivos operativos y arquitectónicos. Además, las funciones de aptitud, propuestas por Neal Ford, pueden utilizarse para validar las decisiones arquitectónicas y la granularidad del servicio mediante la medición continua de las cualidades o comportamientos del sistema que son críticos para las partes interesadas, asegurando así la alineación con los objetivos arquitectónicos generales. ^{[ 12 ]}

En las arquitecturas de microservicios, la granularidad del servicio influye en las pruebas, el despliegue, el rendimiento y la fiabilidad. Los microservicios de grano muy fino suelen ser más fáciles de probar y desplegar de forma independiente, pero a menudo presentan un rendimiento inferior y una menor fiabilidad general debido al aumento de la comunicación entre servicios y a una coreografía de servicios más compleja. ^{[ 13 ]} Los servicios de grano grueso presentan características contrastantes. Generalmente proporcionan mayor robustez y fiabilidad al minimizar la sobrecarga de comunicación y la complejidad de la coordinación, pero son más difíciles de probar y desplegar porque las modificaciones afectan a un ámbito funcional más amplio. ^{[ 13 ]} El nivel adecuado de granularidad del servicio viene determinado por los impulsores del negocio. Las decisiones arquitectónicas suelen comenzar con la identificación de estos impulsores y, a continuación, alineando las características arquitectónicas, como el rendimiento, la escalabilidad, la fiabilidad o la flexibilidad de despliegue, para que les den soporte. ^{[ 13 ]}

Un contexto delimitado, un concepto fundamental en el diseño dirigido por el dominio (DDD), define un área específica dentro de la cual un modelo de dominio es consistente y válido, lo que garantiza claridad y separación de responsabilidades. ^{[ 12 ]} En la arquitectura de microservicios, un contexto delimitado suele corresponder a un microservicio, pero esta relación puede variar según el enfoque de diseño. Una relación uno a uno, donde cada contexto delimitado se implementa como un único microservicio, suele ser ideal, ya que mantiene límites claros, reduce el acoplamiento y permite el despliegue y escalado independientes. Sin embargo, otras asignaciones también pueden ser apropiadas: una relación uno a muchos puede surgir cuando un contexto delimitado se divide en múltiples microservicios para abordar diferentes necesidades de escalabilidad u otras necesidades operativas, mientras que una relación muchos a uno puede consolidar múltiples contextos delimitados en un único microservicio para simplificar o minimizar la sobrecarga operativa. La elección de la relación debe equilibrar los principios del DDD con los objetivos comerciales del sistema, las restricciones técnicas y los requisitos operativos. ^{[ 14 ]}

Las ventajas de descomponer una aplicación en diferentes servicios más pequeños son numerosas:

• Modularidad : Esto hace que la aplicación sea más fácil de entender, desarrollar y probar, y más resistente a la erosión de la arquitectura. ^{[ 15 ]} Este beneficio se suele argumentar en comparación con la complejidad de las arquitecturas monolíticas. ^{[ 16 ]}
• Escalabilidad : Dado que los microservicios se implementan y despliegan de forma independiente entre sí, es decir, se ejecutan dentro de procesos independientes, pueden ser monitoreados y escalados de forma independiente. ^{[ 17 ]}
• Integración de sistemas heterogéneos y heredados : los microservicios se consideran un medio viable para modernizar las aplicaciones de software monolíticas existentes. ^{[ 18 ] [ 19 ]} Existen informes de experiencia de varias empresas que han reemplazado con éxito partes de su software existente con microservicios o están en proceso de hacerlo. ^{[ 20 ]} El proceso de modernización del software de aplicaciones heredadas se realiza mediante un enfoque incremental. ^{[ 21 ]}
• Desarrollo distribuido: paraleliza el desarrollo al permitir que pequeños equipos autónomos desarrollen, implementen y escalen sus respectivos servicios de forma independiente. ^{[ 22 ]} También permite que la arquitectura de un servicio individual surja a través de la refactorización continua . ^{[ 23 ]} Las arquitecturas basadas en microservicios facilitan la integración continua , la entrega continua y la implementación continua. ^{[ 24 ]}

El enfoque de microservicios es objeto de críticas por una serie de problemas:

• Los servicios forman barreras de información. ^{[ 25 ]}
• Las llamadas entre servicios a través de una red tienen un costo mayor en términos de latencia de red y tiempo de procesamiento de mensajes que las llamadas dentro del proceso de un proceso de servicio monolítico . ^{[ 26 ]}
• Las pruebas y la implementación pueden ser complicadas. ^{[ 27 ]}
• Transferir responsabilidades entre servicios es más difícil. ^{[ 15 ]} Puede implicar la comunicación entre diferentes equipos, la reescritura de la funcionalidad en otro lenguaje o su adaptación a una infraestructura diferente. ^{[ 26 ]} Sin embargo, los microservicios se pueden implementar independientemente del resto de la aplicación, mientras que los equipos que trabajan en monolitos necesitan sincronizarse para implementarlos juntos. ^{[ 21 ]}
• Considerar el tamaño de los servicios como el principal mecanismo de estructuración puede llevar a un exceso de servicios, cuando la alternativa de la modularización interna podría resultar en un diseño más simple. Esto requiere comprender la arquitectura general de las aplicaciones y las interdependencias entre los componentes. ^{[ 28 ]}
• Las confirmaciones en dos fases se consideran un antipatrón en arquitecturas basadas en microservicios, lo que resulta en un acoplamiento más estrecho de todos los participantes en la transacción. Sin embargo, la falta de esta tecnología provoca prácticas engorrosas que deben ser implementadas por todos los participantes de la transacción para mantener la consistencia de los datos. ^{[ 29 ]}
• El desarrollo y el soporte de muchos servicios son más difíciles si se construyen con diferentes herramientas y tecnologías; esto es un problema especialmente si los ingenieros cambian de proyecto con frecuencia. ^{[ 30 ]}
• El protocolo que se suele usar con los microservicios (HTTP) fue diseñado para servicios de cara al público y, como tal, no es adecuado para microservicios internos que a menudo deben ser impecablemente fiables. ^{[ 31 ]}
• Aunque no es específica de los microservicios, la metodología de descomposición a menudo utiliza la descomposición funcional, que no maneja los cambios en los requisitos y, al mismo tiempo, agrega complejidad a los servicios. ^{[ 31 ]}
• El concepto mismo de microservicio es engañoso, ya que solo existen servicios. No hay una definición precisa de cuándo un servicio comienza o deja de ser un microservicio. ^{[ 31 ]}
• Agregación de datos. Para tener una visión completa de un sistema en funcionamiento, es necesario extraer conjuntos de datos de los repositorios de microservicios y agregarlos en un único esquema. Por ejemplo, para poder crear informes operativos que no serían posibles utilizando un único repositorio de microservicios.

• El "antipatrón de migración basado en datos", acuñado por Mark Richards, pone de relieve los desafíos que supone priorizar la migración de datos durante la transición de una arquitectura monolítica a una de microservicios. Para abordar este antipatrón, puede resultar útil un enfoque iterativo en el que primero se migra el código de la aplicación, mientras que los nuevos microservicios dependen temporalmente de la base de datos monolítica existente. Con el tiempo, a medida que se comprende mejor el sistema, los datos pueden desacoplarse y reestructurarse, lo que permite que cada microservicio opere con sus propias bases de datos. Esta estrategia puede simplificar el proceso de migración y reducir los errores de migración de datos. ^{[ 13 ]}
• El "antipatrón de tiempo de espera", acuñado por Mark Richards, describe los desafíos de establecer valores de tiempo de espera en sistemas distribuidos. Los tiempos de espera cortos pueden provocar que las solicitudes legítimas fallen prematuramente, lo que conlleva soluciones alternativas complejas, mientras que los tiempos de espera largos pueden resultar en respuestas de error lentas y una mala experiencia de usuario. El patrón de disyuntor puede abordar estos problemas mediante la monitorización del estado del servicio a través de mecanismos como latidos, "transacciones sintéticas" o monitorización del uso en tiempo real. Este enfoque permite una detección de fallos más rápida y mejora la experiencia general del usuario en arquitecturas distribuidas. ^{[ 13 ]}
• Generar informes sobre datos de microservicios presenta desafíos, ya que la recuperación de datos para un servicio de informes puede romper los contextos delimitados de los microservicios, reducir la puntualidad de los datos, o ambas cosas. Esto se aplica independientemente de si los datos se extraen directamente de las bases de datos, se recuperan a través de HTTP o se recopilan en lotes. Mark Richards se refiere a esto como el "antipatrón de informes de acceso directo". ^{[ 13 ]} Una posible alternativa a este enfoque es que las bases de datos envíen asincrónicamente los datos necesarios al servicio de informes en lugar de que este los extraiga. Si bien este método requiere un contrato separado entre los microservicios y el servicio de informes y puede ser complejo de implementar, ayuda a preservar los contextos delimitados al tiempo que mantiene un alto nivel de puntualidad de los datos. ^{[ 13 ]}

Los microservicios son susceptibles a las falacias de la computación distribuida : una serie de conceptos erróneos que pueden generar problemas importantes en el desarrollo y la implementación de software. ^{[ 12 ]}

Richards y Ford en Fundamentos de la arquitectura de software (2020) proponen que cada microservicio debe tener sus propias características arquitectónicas (también conocidas como requisitos no funcionales ), y que los arquitectos no deben definir características uniformes para todo el sistema distribuido . ^{[ 12 ]}

Para evitar tener que coordinar despliegues entre diferentes microservicios, Sam Newman sugiere mantener estables las interfaces de los microservicios y realizar cambios retrocompatibles a medida que evolucionan. En cuanto a las pruebas, Newman, en Building Microservices (2015), propone las pruebas de contrato impulsadas por el consumidor como una mejor alternativa a las pruebas tradicionales de extremo a extremo en el contexto de los microservicios. También sugiere el uso de agregación de registros y agregación de métricas, así como herramientas de rastreo distribuido para garantizar la observabilidad de los sistemas compuestos por microservicios. ^{[ 2 ]}

Los microservicios informáticos pueden implementarse en diferentes lenguajes de programación y utilizar distintas infraestructuras. Por lo tanto, las decisiones tecnológicas más importantes son la forma en que los microservicios se comunican entre sí (síncrona, asíncrona, integración de interfaz de usuario) y los protocolos utilizados para la comunicación (por ejemplo, HTTP RESTful, mensajería, GraphQL ). En un sistema tradicional, la mayoría de las decisiones tecnológicas, como el lenguaje de programación, afectan a todo el sistema. Por consiguiente, el enfoque para elegir tecnologías es bastante diferente. ^{[ 37 ]}

La Fundación Eclipse ha publicado una especificación para el desarrollo de microservicios, Eclipse MicroProfile. ^{[ 38 ] [ 39 ]}

• Número especial dedicado a los microservicios . IEEE Software . 35 (3). Mayo-junio de 2018.
• I. Nadareishvili et al., Arquitectura de microservicios: alineación de principios, prácticas y cultura , O'Reilly, 2016, ISBN 978-1-491-95979-4
• S. Newman, Creación de microservicios: diseño de sistemas de grano fino, O'Reilly, 2015 ISBN 978-1491950357
• Wijesuriya, Viraj Brian (29 de agosto de 2016) Arquitectura de microservicios, Apuntes de clase - Facultad de Informática de la Universidad de Colombo, Sri Lanka
• Christudas Binildas (27 de junio de 2019). Patrones arquitectónicos prácticos de microservicios: Microservicios Java basados ​​en eventos con Spring Boot y Spring Cloud. Apress. ISBN 978-1484245002.