¿Qué son los microservicios?

Los microservicios, o arquitectura de microservicios, es un método arquitectónico nativo de la nube en el que una sola aplicación se compone de muchos componentes o servicios más pequeños acoplados de forma flexible e implementables de forma independiente.

Normalmente, los microservicios:

• tienen su propia tecnología, que incluye la base de datos y el modelo de gestión de datos.
  
• se comunican entre sí a través de una combinación de API de transferencia de estado representacional (REST), transmisión de eventos y agentes de mensajes.
  
• se organizan por capacidad empresarial, y la línea que separa los servicios suele denominarse contexto delimitado.

Aunque gran parte del debate sobre los microservicios ha girado en torno a definiciones y características arquitectónicas, su valor puede entenderse más comúnmente a través de beneficios empresariales y organizativos bastante sencillos:

• El código se puede actualizar más fácilmente: se pueden agregar nuevas características o funcionalidades sin tocar toda la aplicación.
  
• Los equipos pueden usar diferentes pilas y diferentes lenguajes de programación para diferentes componentes.
  
• Los componentes se pueden escalar de forma independiente entre sí, lo que reduce el desperdicio y el coste asociados con tener que escalar aplicaciones completas porque una sola característica podría enfrentar demasiada carga.

Los microservicios también pueden entenderse en contraste con dos arquitecturas de aplicaciones anteriores: la arquitectura monolítica y la arquitectura orientada a servicios (SOA).

La diferencia entre los microservicios y la arquitectura monolítica es que los microservicios componen una única aplicación a partir de muchos servicios más pequeños y poco acoplados, frente al enfoque monolítico de una aplicación grande y muy acoplada.

Las diferencias entre los microservicios y la SOA pueden ser un poco menos claras. Si bien se pueden establecer contrastes técnicos entre los microservicios y la SOA, especialmente en torno a la función del bus de servicios empresarial, es más fácil ver la diferencia como una cuestión de alcance. La SOA fue un esfuerzo de toda la empresa para estandarizar la forma en que todos los servicios web de una organización hablan y se integran entre sí, mientras que la arquitectura de microservicios es específica de las aplicaciones.

Es probable que los microservicios sean al menos tan populares entre los ejecutivos y los jefes de proyecto como entre los desarrolladores. Esta es una de las características más inusuales de los microservicios, ya que el entusiasmo por la arquitectura suele estar reservado para los equipos de desarrollo de software. La razón de esto es que los microservicios reflejan mejor la forma en que muchos líderes empresariales quieren estructurar y dirigir sus equipos y procesos de desarrollo.

Dicho de otra manera, los microservicios son un modelo arquitectónico que facilita mejor un modelo operativo deseado. En una encuesta de IBM realizada en 2021 a más de 1200 desarrolladores y ejecutivos de TI, el 87 % de los usuarios de microservicios aceptaron que la adopción de microservicios valga el gasto y el esfuerzo.

Estos son solo algunos de los beneficios empresariales de los microservicios:

Quizás la característica más importante de los microservicios es que, debido a que los servicios son más pequeños y se pueden implementar de manera independiente, ya no se requiere una ley del Congreso para cambiar una línea de código o agregar una nueva característica en la aplicación.

Los microservicios prometen a las organizaciones un antídoto contra las frustraciones viscerales asociadas a los pequeños cambios que llevan mucho tiempo. No se requiere un doctorado en informática para ver o comprender el valor de un enfoque que facilita mejor la velocidad y la agilidad.

Pero la velocidad no es el único valor de diseñar los servicios de esta manera. Un modelo organizativo emergente común es reunir equipos multifuncionales en torno a un problema, servicio o producto empresarial. El modelo de microservicios encaja perfectamente con esta tendencia. El modelo permite a una organización crear equipos pequeños e interfuncionales en torno a un servicio o una colección de servicios y hacer que funcionen de forma ágil.

El acoplamiento flexible de los microservicios también genera un grado de aislamiento de fallos y una mejor resiliencia en las aplicaciones. Además, el pequeño tamaño de los servicios, combinado con sus límites y patrones de comunicación claros, hace que sea más fácil para los nuevos miembros del equipo comprender la base del código y contribuir a ella rápidamente, un claro beneficio en términos de velocidad y moral de los empleados.

En los patrones tradicionales de arquitectura de n niveles, una aplicación suele compartir una pila común, con una gran base de datos relacional que soporta toda la aplicación. Este enfoque tiene varios inconvenientes obvios, el más importante de los cuales es que todos los componentes de una aplicación deben compartir una pila, un modelo de datos y una base de datos comunes, incluso si existe una herramienta clara y mejor para el trabajo de determinados elementos. Hace que la arquitectura sea mala y es frustrante para los desarrolladores, que siempre saben que existe una forma mejor y más eficiente de crear estos componentes.

Por el contrario, en un modelo de microservicios, los componentes se implementan de forma independiente y se comunican a través de una combinación de REST, transmisión de eventos y agentes de mensajes, por lo que es posible que la pila de cada servicio individual se optimice para ese servicio. La tecnología cambia constantemente, y una aplicación compuesta por múltiples servicios más pequeños es mucho más fácil y menos costosa de evolucionar con tecnología más deseable a medida que está disponible.

Con los microservicios, los servicios individuales pueden implementarse individualmente, pero también pueden escalarse individualmente. El beneficio resultante es obvio: hechos correctamente, los microservicios requieren menos infraestructura que las aplicaciones monolíticas porque permiten escalar con precisión sólo los componentes que lo requieren, en lugar de toda la aplicación en el caso de las aplicaciones monolíticas.

Los beneficios significativos de los microservicios vienen con desafíos significativos. Pasar de un monolito a un microservicio significa mucha más complejidad de gestión: muchos más servicios, creados por muchos más equipos, implementados en muchos más lugares. Los problemas en un servicio pueden causar, o ser causados por, problemas en otros servicios. Los datos de registro (utilizados para la monitorización y la resolución de problemas) son más voluminosos y pueden ser incoherentes entre los servicios. Las nuevas versiones pueden causar problemas de compatibilidad con una versión anterior. Las aplicaciones implican más conexiones de red, lo que significa más oportunidades para problemas de latencia y conectividad. Un enfoque de DevOps puede abordar muchos de estos problemas, pero la adopción de DevOps tiene sus propios desafíos.

Sin embargo, estos retos no están impidiendo que los no adoptantes adopten los microservicios, o que los adoptantes profundicen en sus compromisos con los microservicios. Los datos de la encuesta de IBM antes mencionados revelan que es probable o muy probable que el 56 % de los actuales no usuarios adopten microservicios en los dos años siguientes. En consecuencia, el 78 % de los usuarios actuales de microservicios probablemente aumentarán el tiempo, el dinero y el esfuerzo que han invertido en microservicios.

La arquitectura de microservicios se describe a menudo como optimizada para DevOps y una integración continua o entrega continua, y en el contexto de pequeños servicios que se pueden implementar con frecuencia, es fácil entender por qué.

Pero otra forma de ver la relación entre los microservicios y DevOps es que las arquitecturas de microservicio requieren que DevOps sea exitoso. Aunque las aplicaciones monolíticas tienen una serie de inconvenientes que se han analizado anteriormente en este artículo, cuentan con el beneficio de no ser un sistema distribuido complejo con múltiples partes móviles y pilas tecnológicas independientes. Por el contrario, dado el aumento masivo de la complejidad, las partes móviles y las dependencias que vienen con los microservicios, no sería prudente abordar los microservicios sin inversiones significativas en implementación, monitorización y automatización del ciclo de vida.

Rosalind Radcliffe profundiza en DevOps en el vídeo:

Aunque casi cualquier herramienta o lenguaje moderno puede utilizarse en una arquitectura de microservicios, hay varias herramientas básicas que se han convertido en esenciales y casi definitorias de los microservicios:

Uno de los elementos clave de un microservicio es que es pequeño. No hay una cantidad arbitraria de código que determine si algo es o no un microservicio, pero "micro" está ahí, en el nombre.

Cuando Docker avanzó en la era de los contenedores modernos en 2013, también introdujo el modelo de computación que se asociaría más estrechamente con los microservicios. Dado que los contenedores individuales no tienen la sobrecarga de su propio sistema operativo, son más pequeños y ligeros que las máquinas virtuales tradicionales y pueden subir y bajar más rápidamente, lo que los convierte en una combinación perfecta para los servicios más pequeños y ligeros encontrados en arquitecturas de microservicios.

Con la proliferación de servicios y contenedores, la organización y gestión de grandes grupos de contenedores se convirtió rápidamente en uno de los retos críticos. Kubernetes, una plataforma de orquestación de contenedores de código abierto, se ha convertido en una de las soluciones de orquestación más populares porque hace ese trabajo muy bien.

Los microservicios a menudo se comunican a través de la API, especialmente cuando se establece su estado por primera vez. Si bien es cierto que los clientes y los servicios pueden comunicarse entre sí directamente, las pasarelas API suelen ser una capa intermedia útil, sobre todo cuando el número de servicios de una aplicación crece con el tiempo. Una pasarela API actúa como proxy inverso para los clientes mediante el enrutamiento de solicitudes, la extracción de solicitudes en varios servicios y la prestación de seguridad y autenticación adicionales.

Existen varias tecnologías que se pueden utilizar para implementar pasarelas API. Entre estas tecnologías se encuentran las plataformas de gestión de API, pero si la arquitectura de microservicios se implementa mediante contenedores y Kubernetes, la pasarela suele implementarse mediante Ingress o, más recientemente, Istio.

Aunque una buena práctica podría ser diseñar servicios sin estado, el estado existe y los servicios deben ser conscientes de ello. Y aunque una llamada a la API suele ser una forma eficaz de establecer inicialmente el estado de un servicio específico, no es una forma eficaz de mantenerse al día. No es práctico mantener los servicios actualizados con una encuesta constante, con un enfoque del tipo "¿ya hemos llegado?".

En cambio, es necesario combinar las llamadas a la API que establecen el estado con la mensajería o la transmisión de eventos para que los servicios puedan transmitir los cambios de estado. De esta manera, otras partes interesadas pueden escuchar esos cambios y ajustarse en consecuencia. Es probable que este trabajo se adapte mejor a un corredor de mensajes de uso general, pero hay casos en los que una plataforma de transmisión de eventos, como Apache Kafka, podría ser una buena opción. Y, combinando los microservicios con la arquitectura basada en eventos, los desarrolladores pueden construir sistemas distribuidos, altamente escalables, tolerantes a fallos y extensibles que pueden consumir y procesar cantidades muy grandes de eventos o información en tiempo real.

Las arquitecturas sin servidor llevan algunos de los patrones básicos de nube y microservicios a su conclusión lógica. En su caso, la unidad de ejecución no es solo un pequeño servicio, sino una función, que a menudo puede ser solo unas pocas líneas de código. La línea que separa una función sin servidor de un microservicio es borrosa, pero se entiende comúnmente que las funciones son incluso más pequeñas que un microservicio.

Las arquitecturas sin servidor y las plataformas de funciones como servicio comparten afinidad con los microservicios, ya que ambas están interesadas en crear unidades de implementación más pequeñas y escalar con precisión según la demanda.

Los microservicios no son necesariamente exclusivamente relevantes para el cloud computing. Sin embargo, hay algunas razones importantes por las que suelen ir de la mano, razones que van más allá de que los microservicios sean un estilo arquitectónico popular para las nuevas aplicaciones y de que la nube sea un destino de alojamiento popular para estas.

Entre los principales beneficios de la arquitectura de microservicios se encuentran los beneficios de uso y coste asociados con la implementación y el escalado de componentes individualmente. Si bien estos beneficios aún estarían presentes hasta cierto punto con la infraestructura local, la combinación de componentes pequeños y escalables de forma independiente junto con una infraestructura de pago por uso bajo demanda es donde se pueden encontrar optimizaciones de costes reales.

En segundo lugar, y quizás más importante, otro beneficio principal de los microservicios es que cada componente individual puede adoptar la pila que mejor se adapte a su trabajo específico. La proliferación de pilas puede generar una gran complejidad y sobrecarga cuando la gestiona usted mismo, pero consumir la pila de soporte como servicios cloud puede minimizar drásticamente los desafíos de gestión. Dicho de otra manera, aunque no es imposible implementar su propia infraestructura de microservicios, no es recomendable, especialmente cuando se está empezando.

Dentro de las arquitecturas de microservicios, existen muchos patrones de diseño, comunicación e Integración comunes y útiles que ayudan a abordar algunos de los desafíos y oportunidades más comunes, entre ellos:

Este patrón inserta una capa entre la experiencia del usuario y los recursos a los que llama la experiencia. Por ejemplo, una aplicación utilizada en un escritorio tendrá límites de tamaño de pantalla, visualización y rendimiento diferentes a los de un dispositivo móvil. El patrón BFF permite a los desarrolladores crear y admitir un tipo de back-end por interfaz de usuario utilizando las mejores opciones para esa interfaz, en lugar de intentar admitir un back-end genérico que funcione con cualquier interfaz, pero que pueda afectar negativamente al rendimiento del front-end.

Una entidad es un objeto que se distingue por su identidad. Por ejemplo, en un sitio de comercio electrónico, un objeto de producto puede distinguirse por el nombre, el tipo y el precio del producto. Un agregado es una colección de entidades relacionadas que deben tratarse como una unidad. Así, para el sitio de comercio electrónico, un pedido sería una colección (agregado) de productos (entidades) encargados por un comprador. Estos patrones se utilizan para clasificar los datos de manera significativa.

Estos ayudan a que las aplicaciones y los servicios se encuentren. En una arquitectura de microservicios, las instancias de servicio cambian de forma dinámica debido al escalado, las actualizaciones, los fallos del servicio e incluso el fin del servicio. Estos patrones proporcionan mecanismos de descubrimiento para hacer frente a esta fugacidad. El equilibrio de carga puede usar patrones de detección de servicios mediante el uso de comprobaciones de estado y errores de servicio como desencadenadores para reequilibrar el tráfico.

Piense en los patrones de adaptadores del mismo modo en que piensa en los adaptadores de enchufe que utiliza cuando viaja a otro país. El propósito de los patrones adaptadores es ayudar a traducir relaciones entre clases u objetos que de otro modo serían incompatibles. Una aplicación que depende de API de terceros podría necesitar usar un patrón de adaptador para garantizar que la aplicación y las API puedan comunicarse.

Estos patrones ayudan a administrar la refactorización de una aplicación monolítica en aplicaciones de microservicios. El original nombre hace referencia a cómo una enredadera (microservicios) poco a poco y con el tiempo supera y estrangula a un árbol (una aplicación monolítica).

Aunque hay muchos patrones para hacer bien los microservicios, hay un número igualmente significativo de patrones que pueden meter rápidamente en problemas a cualquier equipo de desarrollo. Algunas de estas cosas (reformuladas como “cosas que no se deben hacer” con los microservicios) son las siguientes:

Dicho de manera más precisa, no empiece con microservicios. Los microservicios son una forma de administrar la complejidad una vez que las aplicaciones se han vuelto demasiado grandes y difíciles de gestionar para actualizarlas y mantenerlas fácilmente. Sólo cuando sienta que el sufrimiento y la complejidad del monolito empiezan a aparecer, merecerá la pena plantearse cómo podría refactorizar esa aplicación en servicios más pequeños. Hasta que no sienta ese sufrimiento, no habrá realmente un monolito que necesite refactorización.

Construir microservicios significa construir sistemas distribuidos, y los sistemas distribuidos son difíciles, y son especialmente difíciles si se toman decisiones que los hacen aún más difíciles. Intentar realizar microservicios sin una automatización adecuada de la implementación y la monitorización, o servicios cloud gestionados para respaldar su infraestructura heterogénea y ahora en expansión, es generar muchos problemas innecesarios. Ahórrese las molestias y podrá dedicar su tiempo a preocuparse por el estado.

Si se excede con el "micro" de los microservicios, puede encontrarse fácilmente con una sobrecarga y una complejidad que superen las ventajas generales de una arquitectura de microservicios. Es mejor inclinarse por servicios más grandes y separarlos sólo cuando empiecen a desarrollar características que los microservicios solucionan, es decir, cuando resulte difícil y lento implementar cambios, cuando un modelo de datos común resulte demasiado complejo o cuando las distintas partes del servicio tengan requisitos de carga/escala diferentes.

Los microservicios y la SOA se confunden a menudo entre sí, dado que en su nivel más básico, ambos están interesados en construir componentes individuales reutilizables que puedan ser consumidos por otras aplicaciones. La diferencia entre microservicios y SOA es que los proyectos de microservicios suelen implicar la refactorización de una aplicación para que sea más fácil de gestionar, mientras que la SOA se ocupa de cambiar la forma en que los servicios de TI funcionan en toda la empresa. Un proyecto de microservicios que se transforme en un proyecto SOA probablemente se doblará por su propio peso.

Netflix fue uno de los pioneros de la arquitectura de microservicios al crear y administrar una aplicación que representaba un tercio de todo el tráfico de Internet, una especie de tormenta perfecta que requirió que crearan una gran cantidad de código y servicios personalizados que son innecesarios para la aplicación promedio. Es mucho mejor empezar a un ritmo que pueda soportar, evitar la complejidad y utilizar tantas herramientas estándar como sea posible.

Si está preparado para obtener más información sobre cómo utilizar los microservicios o si necesita mejorar sus habilidades en microservicios, pruebe uno de estos tutoriales:

• Introducción a los microservicios
  
• Laboratorio rápido: cree microservicios de aplicaciones web altamente escalables con Node.js
  
• Dé sus primeros pasos con los microservicios de Java con Spring Boot y Cloudant
  
• Cree, ejecute e implemente microservicios de Spring en cinco minutos
  
• Microservicios, SOA y API: ¿Amigos o enemigos?