¿Qué son los microservicios?

Los microservicios, o arquitectura de microservicios, son un enfoque arquitectónico nativo de la nube en el que una sola aplicación se conforma de muchos componentes o servicios más pequeños poco acoplados y que se pueden desplegar de forma independiente.

Por lo general, 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 microservicios y SOA pueden ser un poco menos claras. Si bien se pueden establecer contrastes técnicos entre los microservicios y la SOA, especialmente en torno al rol del bus de servicios empresariales, es más fácil considerar la diferencia como una 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 se comunican e integran entre sí, mientras que la arquitectura de microservicios es específica de la aplicación.

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 de 2021 a más de 1200 desarrolladores y ejecutivos de TI, el 87 % de los usuarios de microservicios coincidieron en que la adopción de microservicios vale la pena 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 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 y multifuncionales en torno a un servicio o una colección de servicios y hacer que operen de manera ágil.

El acoplamiento flexible de los microservicios también crea un grado de aislamiento de fallas y una mejor resiliencia en las aplicaciones. Y el pequeño tamaño de los servicios, combinado con sus límites y patrones de comunicación claros, facilita que los nuevos miembros del equipo comprendan el código base y contribuyan a él 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 normalmente comparte una pila común, con una base de datos relacional grande 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 despliegan de forma independiente y se comunican a través de alguna combinación de REST, transmisión de eventos y agentes de mensajes, por lo que es posible optimizar la pila de cada servicio individual 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 se pueden desplegar individualmente, pero también se pueden escalar individualmente. El beneficio resultante es obvio: cuando se realizan correctamente, los microservicios requieren menos infraestructura que las aplicaciones monolíticas porque permiten un escalado preciso solo de los componentes que lo requieren, en lugar de toda la aplicación en el caso de las aplicaciones monolíticas.

Los importantes beneficios de los microservicios conllevan importantes desafíos. Pasar de monolito a microservicios significa mucha más complejidad de gestión: muchos más servicios, creados por muchos más equipos, desplegados 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 el monitoreo y la resolución de problemas) son más voluminosos y pueden ser inconsistentes 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 desafíos 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 mencionada revelan que es probable o muy probable que el 56% de los no usuarios actuales adopten microservicios dentro de los próximos dos años. 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 desplegar 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 microservicios requieren que DevOps tenga éxito. Si bien las aplicaciones monolíticas tienen una serie de inconvenientes que se analizaron anteriormente en este artículo, tienen 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 piezas móviles y las dependencias que conllevan los microservicios, no sería prudente abordar los microservicios sin inversiones significativas en despliegue, supervisión y automatización del ciclo de vida.

Rosalind Radcliffe ofrece una inmersión más profunda en DevOps en el video:

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 existe una cantidad arbitraria de código que determine si algo es o no es un microservicio, pero “micro” está ahí mismo 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 desafíos 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 puertas de enlace de API suelen ser una capa intermedia útil, sobre todo cuando el número de servicios de una aplicación crece con el tiempo. Una puerta de enlace de 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 múltiples tecnologías que se pueden utilizar para implementar puertas de enlace de 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 puerta de enlace suele implementarse mediante Ingress o, más recientemente, Istio.

Si bien las mejores prácticas podrían 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. Un enfoque de encuestas constantes para mantener actualizados los servicios, del tipo “¿ya llegamos?”, simplemente no es práctico.

En su lugar, es necesario acoplar las llamadas a la API de establecimiento de estado con mensajería o transmisión de eventos para que los servicios puedan transmitir cambios en el estado. De esta manera, otras partes interesadas pueden escuchar esos cambios y ajustarlos en consecuencia. Es probable que este trabajo sea más adecuado para un agente de mensajes de propósito 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 al combinar microservicios con arquitectura basada en eventos, los desarrolladores pueden crear sistemas distribuidos, altamente escalables, tolerantes a fallas y extensibles que pueden consumir y procesar grandes cantidades 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 el caso de sin servidor, 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.

En lo que las arquitecturas sin servidor y las plataformas de funciones como servicio comparten afinidad con los microservicios es que ambas están interesadas en crear unidades de despliegue más pequeñas y escalar con precisión en función de la demanda.

Los microservicios no son necesariamente relevantes para la computación en la nube. Sin embargo, hay algunas razones importantes por las que con tanta frecuencia van juntas: razones que van más allá de que los microservicios sean un estilo arquitectónico popular para nuevas aplicaciones y que la nube sea un destino de alojamiento popular para nuevas aplicaciones.

Entre los principales beneficios de la arquitectura de microservicios se encuentran los beneficios de uso y costo asociados con el despliegue y escalado de componentes individualmente. Si bien estos beneficios seguirían estando presentes hasta cierto punto con la infraestructura on premises, la combinación de pequeños componentes escalables de forma independiente junto con una infraestructura de pago por uso bajo demanda es donde se pueden encontrar optimizaciones de costos reales.

En segundo lugar, y quizás lo 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 el uso de la pila de soporte como servicios en la nube puede minimizar drásticamente los desafíos de gestión. Dicho de otra manera, si bien no es imposible implementar su propia infraestructura de microservicios, no es recomendable, especialmente cuando recién comienza.

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, que  incluyen:

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

Una entidad es un objeto que se distingue por su identidad. Por ejemplo, en un sitio de comercio electrónico, un objeto de producto podría 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. Entonces, para el sitio de comercio electrónico, un pedido sería una colección (agregado) de productos (entidades) pedidos 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 entre sí. En una arquitectura de microservicios, las instancias de servicio cambian dinámicamente debido al escalado, las actualizaciones, las fallas del servicio e incluso la terminación del servicio. Estos patrones proporcionan mecanismos de descubrimiento para hacer frente a esta transitoriedad. 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 con mayor precisión, no empiece con microservicios. Los microservicios son una forma de gestionar la complejidad una vez que las aplicaciones se han vuelto demasiado grandes y difíciles de manejar para actualizarlas y mantenerlas fácilmente. Solo cuando siente que el dolor y la complejidad del monolito comienzan a colarse, vale la pena considerar cómo podría refactorizar esa aplicación en servicios más pequeños. Hasta que no sientes ese dolor, ni siquiera tienes un monolito que necesite refactorización.

Crear microservicios significa crear sistemas distribuidos, y los sistemas distribuidos son difíciles, y son especialmente difíciles si toma decisiones que lo hacen aún más difícil. Intentar hacer microservicios sin una automatización adecuada de despliegue y monitoreo, o servicios en la nube para respaldar su infraestructura heterogénea y en expansión, es generar muchos problemas innecesarios. Ahórrese la molestia para que pueda 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 solo cuando empiecen a desarrollar características que los microservicios solucionan, es decir, cuando resulte difícil y lento desplegar 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 aprender más 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
  
• Primeros pasos con los microservicios de Java usando Spring Boot y Cloudant
  
• Cree, ejecute y despliegue microservicios de Spring en cinco minutos
  
• Microservicios, SOA y API: ¿amigos o enemigos?