Sobre la historia de la arquitectura de software

Antes de iniciar las explicaciones sobre la infraestructura de Service Mesh, vamos a entender un poco sobre lo que creamos antes, como arquitectos y desarrolladores de software. Creo que es esencial saber por qué Service Mesh puede ser útil para usted.

Hablaremos un poco sobre la historia de la arquitectura de software. Prometo que será rápido, pero valdrá la pena.

Vamos a analizar la imagen siguiente.

Existen modelos de arquitecturas diferentes en esta línea del tiempo, incluyendo el estándar MVC, que está presente en nuestra arquitectura hoy.

SOA y EDA fueron popularizados en el 2000 y 2003, respectivamente; cuando las cosas comenzaron a ser distribuidas. Comenzamos en aquel momento a dividir las cosas en pequeños pedazos de software, por varias razones.

Y, finalmente, Microservices y Serverless, en el 2013 y 2015, respectivamente, cuando diferentes enfoques sobre desarrollo de software estaban llegando.

La ley de Conway e Inverse Conway Maniobra surgieron en la escena para explicar cómo trabajar con arquitectura de software en términos de negocios y equipos.

Existe un comportamiento típico, si vemos esta línea del tiempo, estamos intentando dividir nuestras partes de software en partes cada vez menores, al máximo posible.

Pero ¿por qué esto es importante o relacionado a la infraestructura de Service Mesh?

Microservicios son sistemas distribuidos, y cuando hablamos de sistemas distribuidos hablamos en tener que tratar con problemas de red.

Y es exactamente en esto que Service Mesh Infrastructure puede ayudarnos. Abstrayendo problemas de red de los desarrolladores.

Service Mesh

En pocas palabras.

Service Mesh puede ser definido como una infraestructura dedicada para tratar con un alto volumen de tráfico basado en el IPC (comunicación entre procesos). En una arquitectura de microservicios generalmente es llamada Tráfico Este-Oeste.

En pocas palabras, Service Mesh puede ser considerado como una “capa” para abstraer la red para comunicaciones de servicios.

Estas abstracciones resuelven la mayor parte de los manipuladores de red, como balance de carga, disyuntores, nuevas tentativas, tiempo límite y enrutamiento inteligente, que pueden activar técnicas avanzadas de implantación, como Canary Releases, Dark Launches, entre otras. 

Enseguida, podemos asumir estas responsabilidades en nuestro código de aplicación. Además de esto, podemos retirar estas funciones de los desarrolladores, y esto es muy importante porque los desarrolladores deben codificar para los negocios, no para los requisitos de infraestructura.

Otra característica importante de Service Mesh es la Telemetría, algunas implementaciones se integran fácilmente a Jaeger y a Prometheus.

Bibliotecas famosas en el ecosistema Java relacionadas a manipulaciones de red como Netflix Ribbon, Hystrix y Eureka pueden ser sustituidas por las implementaciones del Service Mesh como ISTIO.

Service Mesh & Arquitectura de Microservicios 

En general, en la arquitectura de microservicios, la comunicación servicio-a-servicio es muy compleja, involucrando diferentes estándares de comunicación, como REST y gRPC sobre HTTP o AMQP, para comunicaciones asíncronas y durables.

Como podemos ver, los microservicios son sistemas distribuidos, y por esto Service Mesh Infrastructure se encaja muy bien.

Ejemplo práctico

Veamos una arquitectura de microservicios simple y muy estándar:

Arquitectura de Microservicios estándar

Hay algunas cosas importantes a ser observadas aquí.

Tráfico Norte & Sur

El tráfico Norte-Sur generalmente ocurre entre redes diferentes, vea la imagen Red A y Red B. Este tipo de tráfico viene de afuera de nuestra infraestructura, de nuestros clientes, y este tráfico no es confiable porque la red externa está fuera de nuestro control.

Necesitamos de una seguridad pesada aquí, este es nuestro Gateway para proteger nuestras aplicaciones.

Normalmente, tenemos una plataforma de API para gestionar nuestras APIs externas, donde las técnicas y procesos de gestión de API pueden ayudarnos en esta tarea.

Tráfico Este & Oeste

Por otro lado, el tráfico Este-Oeste ocurre en general en la misma red, como vimos, normalmente es llamado comunicación servicio-a-servicio o IPC.

Es en este lugar que vive Service Mesh.

gRPC es una estructura muy interesante si usted está buscando aplicaciones de alto rendimiento o comunicaciones servicio-a-servicio.

Conclusiones

Service Mesh es una cosa interesante que usted está intentando jugar con la arquitectura de microservicios, pero recomiendo que usted entienda un poco más antes de adicionar Service Mesh a su pila de arquitectura.

No existe una bala de plata cuando usted piensa en Arquitectura de Software, pero nosotros, como Arquitectos de Software, Desarrolladores y otros, debemos entender y proponer la solución correcta, considerando el contexto de cada empresa.

Vea el texto original aquí.