¿Qué son las mallas/mesh en las arquitecturas de microservicios?

Desde siempre estamos familiarizados con el concepto de estructuras organizativas en todos los ámbitos de nuestra vida (colegio, mundo laboral). Si pensamos en el modelado de las estructuras organizativas, nos viene a la mente una empresa con departamentos, que se organizan en unidades de personas en estructura piramidal, tribus, squads… canales de comunicación que se articulan entre las diferentes unidades, etc.

En cierto modo, no nos debería sorprender que las estructuras organizativas aparezcan con bastante frecuencia en las arquitecturas de desarrollo software. De hecho, en la arquitectura software de cualquier aplicación encontramos una estructura similar en la que se ofrecen servicios y se establecen canales de comunicación para poder consumir y prestar los servicios. La manera de organizar, estructurar y gestionar los servicios entre los diferentes componentes marca la diferencia de cómo una aplicación va a ser resiliente, escalable y observable para poder cumplir con los objetivos del negocio que tenga marcados.

Una arquitectura de software proporciona un diseño estructural, es decir, la formulación de diferentes estructuras:

• El diseño estructural organiza los componentes del sistema, proporcionándoles los medios para comunicarse mientras trabajan juntos.
• La estructura también sirve para definir grupos de componentes para que puedan funcionar de forma independiente.
• Por lo tanto, las estructuras deben ayudar a conseguir atributos de calidad más que funcionales, mientras que los componentes implementan la funcionalidad especificada por los equipos que desarrollan el sistema.

La arquitectura software la podemos dividir de forma dicotómica en arquitecturas locales, donde todos los componentes de un sistema ejecutan en un solo nodo de computación, y otras, donde ejecutan en varios nodos. Estas últimas se denominan sistemas distribuidos que tienen unas peculiaridades muy determinantes, puesto que se tiene una red de comunicación por medio, con lo que ello implica: latencia, fallos de red…

En arquitecturas basadas en cloud o en on-premise los componentes forman redes de dos o más componentes interconectados para compartir recursos y servicios.

En las modernas arquitecturas de microservicios, dentro de su diseño estructura,l juegan un papel relevante diferentes mallas (Mesh):

• Service Mesh: estructura que habilita principalmente la resiliencia y observabilidad de las interacciones síncronas entre servicios mediante invocación de API 's internas de aplicación. No se entra en las API 's exportadas a través de API Gateways.
• Event Mesh: estructura que habilita la interacción asíncrona de microservicios, aplicaciones y clouds a través de eventos.
• Data Mesh: otra estructura que permite una mayor calidad, eficiencia y estandarización, entre otros beneficios, para el acceso de datos analíticos de aplicaciones

En las redes que comunican los componentes se encuentran diferentes estructuras organizativas que se denominan topologías. La topología de red la determina la configuración de las conexiones entre nodos y componentes. Los objetivos que se persiguen en el diseño de una topología:

• Máxima resiliencia, redundancia.
• Enrutamiento del tráfico, accesibilidad.
• Rendimiento óptimo y el tiempo de respuesta mínimo (latencia).

Algunas de las topologías de redes son familiares:

• Topología de interconexión completa: todos los nodos comunicados con los otros. Esta topología es costosa y difícil de gestionar por el número de interconexiones entre nodos dependiendo del número de estos.
• Topología jerárquica: topología de red en la que los nodos están dispuestos en forma de árbol.
• Topología en bus: habilita que todos los nodos reciben las peticiones que se realizan, un nodo pide y todos los restantes pueden responder. Un ejemplo es un nodo Ethernet o el Enterprise Service Bus (ESB).
• Topología en estrella: los nodos están conectados directamente a un nodo central y todas las peticiones pasan a través de este.
• Topología en malla: cada uno de los nodos de la red están interconectados entre sí, totalmente o parcialmente.

Cada una de estas topologías proporcionan diferentes ventajas e inconvenientes para la resiliencia y latencia. Por lo tanto, cada una de ellas marcará de manera diferente la calidad del sistema distribuido que soporte.

Red en malla

En una topología de red en malla, cada uno de los nodos de la red están interconectados entre sí. Cada nodo no solo se comunica con otros, sino que también enruta otros nodos. De hecho, una verdadera topología de malla es aquella en la que cada nodo está conectado a todos los demás nodos de la red.

Es muy resiliente, ya que hay muchas conexiones redundantes, llevando los mensajes de un nodo a otro por diferentes caminos. Si está completamente conectada, no puede existir absolutamente ninguna interrupción en las comunicaciones y hace que el tiempo de uptime de la red aumente. Cada nodo tiene sus propias conexiones con todos los demás nodos.

La topología en malla ofrece una redundancia y fiabilidad mayor que otras topologías.

Se encuentra en las últimas arquitecturas evolutivas de referencia a la hora de desarrollar aplicaciones Cloud Native, como en los proyectos de modernización de aplicaciones legacies. Estas mallas están formadas por interacciones de componentes de aplicación síncronas y/o asíncronas.

Sistemas distribuidos

Un sistema distribuido es una red de componentes intercomunicados entre sí (si falla un componente puede dejar inutilizado todo el sistema y la aplicación). Estos componentes cooperan para realizar alguna tarea mediante el intercambio de mensajes a través de sistemas de comunicación. Además, un componente puede referirse genéricamente a otro componente dentro de una aplicación, a otra aplicación, a un microservicio…

¿Cuáles son las razones por las que existen los sistemas distribuidos?

• Algunas aplicaciones son inherentemente distribuidas. Por ejemplo, la web es un sistema distribuido. Accedes a ella con un navegador, que se ejecuta en tu teléfono, tableta, ordenador…. Junto con otros miles de millones de dispositivos en todo el mundo, forma un sistema distribuido.
• Determinadas aplicaciones requieren una alta disponibilidad y necesitan ser resistentes a los fallos de un solo componente. Aplicaciones de misión crítica, de negocio, necesitan uptime de 24x7x365.
• Otras aplicaciones tienen que hacer frente a cargas de trabajo que son demasiado grandes para caber en un solo nodo, por muy potente que sea. Por ejemplo, Google para satisfacer sus búsquedas.
• Algunas aplicaciones tienen requisitos de rendimiento que serían físicamente imposibles de alcanzar con solamente un nodo. Netflix puede transmitir sin problemas películas a tu televisor con altas resoluciones porque tiene un centro de datos cerca de ti.

¿Y cuáles son los principales retos que hay que resolver para diseñar, construir y operar sistemas distribuidos?

• Comunicación: el primer reto proviene del hecho de que los nodos tienen que comunicarse entre sí a través de la red. Por ejemplo, cuando el navegador quiere cargar una página web, resuelve la dirección del servidor a partir de la URL y le envía una petición HTTP. A su vez, el servidor devuelve al cliente una respuesta con el contenido de la página.
• Coordinación: otro de los grandes retos de la construcción de sistemas distribuidos es la coordinación de los componentes en un todo coherente en presencia de fallos. Un fallo es un componente que deja de funcionar, y un sistema es tolerante a los fallos cuando puede seguir funcionando a pesar de uno o más fallos.
• Escalabilidad: el rendimiento de un sistema distribuido representa la eficiencia con la que maneja la carga, y generalmente se mide con el rendimiento y el tiempo de respuesta. El rendimiento es el número de operaciones procesadas por segundo, y el tiempo de respuesta es el tiempo total entre la solicitud de un cliente y su respuesta.
• Resiliencia: un sistema distribuido es resistente cuando puede seguir haciendo su trabajo, incluso cuando se producen fallos. Y a gran escala, cualquier fallo que pueda ocurrir acabará ocurriendo. Cada componente de un sistema tiene una probabilidad de fallar (nodos, enlaces, etc.). Por muy pequeña que sea esa probabilidad, cuantos más componentes haya y más operaciones realice el sistema, mayor es la probabilidad de fallos. Y lo que es peor, como los fallos no suelen ser independientes, el fallo de un componente puede aumentar la probabilidad de que otro falle.
• Operaciones: los sistemas distribuidos necesitan ser probados, desplegados y mantenidos. Antes, un equipo desarrollaba una aplicación y otro se encargaba de operarla. El auge de los microservicios y las DevOps ha cambiado esto. El mismo equipo que diseña un sistema es también responsable de su funcionamiento en vivo. Esto es algo bueno, ya que no hay mejor manera de descubrir dónde falla un sistema que experimentarlo estando de guardia. Es deseable que la arquitectura de estos sistemas distribuidos nos den servicios para gestionar, monitorizar y observar el ciclo de vida de los componentes software y sus relaciones en las aplicaciones que se montan en estas arquitecturas de sistemas distribuidos.

Estilos de arquitectura de aplicaciones

Entre las muchas definiciones que se pueden encontrar de la arquitectura de un sistema software, un factor común puede ser que la arquitectura de software es una descripción de un sistema de software en términos de sus principales componentes, sus relaciones y la información que pasa entre ellos. En esencia, la arquitectura es un plan para construir sistemas que cumplan con requisitos definidos y, por extensión, sistemas que posean las características necesarias para cumplir con estos requisitos ahora y en el futuro.

Un propósito fundamental de la arquitectura de software es ayudar a gestionar la complejidad de los sistemas de software y las modificaciones que inevitablemente sufren los sistemas en respuesta a los cambios externos en los entornos empresariales, organizativos y técnicos.

Los estilos de arquitectura pueden clasificarse en dos tipos principales: monolítica (una solo componente de despliegue de todo el código) y distribuida (múltiples componentes de despliegue conectadas a través de servicios en red). Las arquitecturas distribuidas comparten un conjunto común de retos y problemas que no se encuentran en los estilos de arquitectura monolítica, lo que hace que este esquema de clasificación sea una buena separación entre los distintos estilos de arquitectura. Una posible clasificación:

Monolítica

Arquitectura por capas

Conocida como estilo de arquitectura en n niveles, es uno de los estilos de arquitectura más frecuentes. Es el estándar de facto para la mayoría de las aplicaciones, principalmente por su simplicidad, familiaridad y bajo coste.

También es una forma muy natural de desarrollar aplicaciones debido a la ley de Conway, que establece que las organizaciones que diseñan sistemas están limitadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones.

En la mayoría de las organizaciones hay desarrolladores de interfaces de usuario, desarrolladores de backend, desarrolladores de reglas y expertos en bases de datos. Estas capas organizativas encajan perfectamente en los niveles de una arquitectura por capas tradicional, lo que la convierte en una opción natural para muchas aplicaciones empresariales.

Arquitectura de tubería

Se divide la funcionalidad en componentes discretos, donde cada componente recibe como entrada la salida de un componente previo.

Este estilo de arquitectura es el principio subyacente a los lenguajes de shell de comandos de Unix, las pipes. Los lenguajes de programación funcionales tienen paralelismos entre las construcciones del lenguaje y los elementos de esta arquitectura. Muchas herramientas que utilizan el modelo de programación MapReduce en Big Data siguen esta topología básica.

Arquitectura del micronúcleo

El estilo de arquitectura del micronúcleo (también conocido como arquitectura plug-in). Este estilo es relativamente sencillo.

Consta de dos componentes de arquitectura: un componente central y componentes complementarios. La lógica de la aplicación se divide entre los componentes plug-in independientes y el componente básico del núcleo.

Distribuida

Arquitectura basada en servicios

Su topología básica sigue una estructura distribuida de macro capas que consiste en una interfaz de usuario desplegada por separado, servicios remotos de grano grueso desplegados por separado y una base de datos monolítica. Los servicios dentro de este estilo de arquitectura son típicamente "porciones de una aplicación" (usualmente llamados servicios de dominio) que son independientes y se despliegan por separado.

Arquitectura basada en eventos

Estilo de arquitectura asíncrona distribuida utilizado para producir aplicaciones altamente escalables y de alto rendimiento. También es muy adaptable y puede emplearse tanto para aplicaciones pequeñas como para las grandes y complejas.

La arquitectura dirigida por eventos (EDA) está formada por componentes de procesamiento de eventos desacoplados que reciben y procesan eventos de forma asíncrona. Puede usarse como un estilo de arquitectura independiente o integrado en otros estilos de arquitectura (como una arquitectura de microservicios basada en eventos).

Arquitectura Space-Based

La mayoría de las aplicaciones empresariales basadas en la web siguen el mismo flujo general de solicitudes: una solicitud de un navegador llega al servidor web, luego a un servidor de aplicaciones y, por último, al servidor de base de datos. Aunque este patrón funciona muy bien para un pequeño conjunto de usuarios, los cuellos de botella empiezan a aparecer a medida que aumenta la carga de usuarios, primero en la capa del servidor web, luego en la del servidor de aplicaciones y, por último, en la del servidor de base de datos. La respuesta habitual a los cuellos de botella basados en el aumento de la carga de usuarios es reducir la escala de los servidores web. Esto es relativamente fácil y barato, y a veces funciona para resolver los problemas de cuello de botella. Sin embargo, en la mayoría de los casos de alta carga de usuarios, el escalado de la capa del servidor web solamente desplaza el cuello de botella hacia el servidor de aplicaciones.

El escalado de los servidores de aplicaciones puede ser más complejo y costoso que el de los servidores web y, por lo general, únicamente traslada el cuello de botella al servidor de la base de datos, que es aún más difícil y costoso de escalar. Incluso si se puede escalar la base de datos, lo que finalmente se obtiene es una topología en forma de triángulo, siendo la parte más ancha del triángulo los servidores web (más fáciles de escalar) y la parte más pequeña la base de datos (más difícil de escalar).

El estilo de arquitectura basado en el espacio está diseñado específicamente para abordar problemas que implican alta escalabilidad, elasticidad y problemas de alta concurrencia. También es un estilo de arquitectura útil para aplicaciones que tienen volúmenes de usuarios concurrentes variables e impredecibles. Resolver el problema de la escalabilidad extrema y variable desde el punto de vista arquitectónico es a menudo un enfoque mejor que intentar escalar una base de datos o adaptar las tecnologías de caché a una arquitectura no escalable

Arquitectura orientada al servicio

SOA puede definirse como un estilo arquitectónico que promueve el concepto de servicio empresarial alineado con el negocio como unidad fundamental para diseñar, construir y componer soluciones empresariales. Más concretamente, SOA se ocupa de la construcción independiente de servicios alineados con el negocio que puedan combinarse en procesos y soluciones empresariales significativas y de alto nivel dentro del contexto de la empresa.

Cualquiera puede crear un servicio; ese no es el reto de SOA. El verdadero valor de SOA surge cuando los servicios reutilizables se combinan para generar procesos empresariales ágiles y flexibles. Parte de la arquitectura de SOA se encarga de producir el entorno necesario para crear y utilizar servicios componibles en toda la empresa. La arquitectura permite que diferentes organizaciones implementen de forma independiente servicios que satisfagan sus necesidades inmediatas, pero que también puedan ser combinadas en procesos de negocio y soluciones empresariales de mayor nivel.

En SOA se diseña principalmente en torno a la reutilización y, por tanto, se incurre en una enorme cantidad de acoplamiento entre componentes con las consecuencias que esto tiene.

Arquitectura de microservicios

Este estilo de arquitectura está basado en el diseño de aplicaciones de microservicios. En esencia es un refinamiento de SOA y en este prima que los microservicios, que ofrecen un conjunto de servicios (endpoints), tengan una cohesión lo más alta posible con el dominio que implementan y que el acoplamiento de todo tipo, estático, temporal (ejecución), deployment y entre dominios, sea el mínimo posible.

Comment end

Este artículo forma parte de una serie de posts en los que hablamos sobre:

• El papel que juegan las estructuras de malla (redes mesh) en las arquitecturas de microservicios.
• O cómo nos ayudan las mallas de servicio (services mesh).

En este primer post hemos descrito diferentes estructuras, topologías y arquitecturas que forman los sistemas y aplicaciones de empresas desde hace algunos años y actualmente. ¿Qué te ha parecido introducción a las redes de malla? ¿Echas en falta algo o tienes alguna pregunta? ¡Déjanos un comentario! Y si te interesa el tema, no te pierdas los siguientes post de esta serie en los que hablaremos de Arquitectura de Microservicios, Service Mesh, Event Mesh y Data Mesh.