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:

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):

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:

Algunas de las topologías de redes son familiares:

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?

¿Y cuáles son los principales retos que hay que resolver para diseñar, construir y operar 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 la que hablaremos del papel que juegan las estructuras de malla (redes mesh) cómo Service Mesh, Event Mesh y Data Mesh en las nuevas arquitecturas de sistemas distribuidos como es la arquitectura de microservicios.

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.

Cuéntanos qué te parece.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.

Suscríbete

Estamos comprometidos.

Tecnología, personas e impacto positivo.