Header Ads Widget

Ticker

6/recent/ticker-posts

¿Service Mesh es solo SOA de nuevo?

 

Los microservicios han ido en aumento en el espacio de las API durante varios años y ofrecen a los desarrolladores muchas ventajas. Estos servicios hacen solo una cosa, por lo que generalmente son fáciles de administrar y tienen un alcance pequeño. ¡De ahí el nombre!

Pero una de las mayores ventajas de los microservicios también contribuye a una de sus mayores desventajas; La gestión de un gran número de estos servicios puede resultar complicada y llevar mucho tiempo a escala. Ahí es donde entra la malla de servicios .

Cuando profundicemos en la malla de servicios a continuación, veremos que tiene mucho en común con SOA. Como señala Jeff Foster en una publicación de blog sobre el tema, "SOA tenía ideas similares en los años 90, pero la tecnología a su alrededor era torpe ... parecía involucrar una gran cantidad de XML, ¡nunca un buen comienzo!"

¿Service mesh es simplemente otra iteración de las ideas detrás de SOA, o representa algo más que eso? Vamos a averiguar.

Diferencias entre Service Mesh (MSA) y SOA
Las mallas de servicio están más asociadas con la gestión de microservicios, con el objetivo de permitir una mejor gestión de muchos microservicios diferentes que componen una aplicación o servicio.

El uso de una malla de servicios implica dividir cómo interactúan los servicios, con un plano de datos para administrar las comunicaciones entre microservicios y un plano de control que se usa para administrarlos (o más bien el sidecar asociado con ellos) y evaluar su desempeño.

A primera vista, esa configuración parece tener mucho en común con la arquitectura orientada a servicios (SOA) y el Enterprise Service Bus que a menudo se asocia con ellos para la comunicación entre funciones.

Antes de profundizar en la comparación del uso de una malla de servicios con SOA, echemos un vistazo a algunos de los principios de cada tipo de arquitectura:

Arquitectura orientada a servicios (SOA)

  • Arquitectura de "compartir tanto como sea posible"
  • Importancia de la reutilización de la funcionalidad empresarial
  • Gobernanza y estándares comunes
  • Enterprise Service Bus (ESB) para la comunicación
  • Múltiples protocolos de mensajes
  • Plataforma común para todos los servicios implementados
  • Multi-hilo con más gastos generales para manejar E / S
  • Máxima reutilización del servicio de aplicaciones
  • Es más probable que utilicen bases de datos relacionales tradicionales
  • No preferido en un modelo DevOps
Arquitectura de microservicios (MSA)

  • Arquitectura de "compartir lo menos posible"
  • Importancia otorgada al concepto de contexto acotado
  • Gobernanza relajada, con más enfoque en las personas
  • Colaboración eficiente y libertad en la elección de plataformas y tecnologías.
  • Sistema de mensajería simple y menos elaborado
  • Protocolos ligeros como HTTP / REST y AMQP
  • De un solo subproceso generalmente con el uso de funciones de bucle de eventos para el manejo de E / S sin bloqueo
  • Los contenedores funcionan muy bien en MSA y se consideran perfectos para un modelo DevOps
  • Más centrado en el desacoplamiento
  • Utiliza bases de datos modernas y no relacionales
Estos tipos de arquitectura tienen algunas similitudes, como el hecho de que la reutilización es tan importante para los microservicios como para SOA. Sin embargo, también podemos ver algunas diferencias significativas entre los principios de estos dos enfoques anteriores. Siendo ese el caso, es probable que su aplicación también sea diferente.

Aplicaciones de Service Mesh (MSA) frente a SOA
Al observar lo anterior, puede comenzar a tener una idea del tipo de entornos en los que cada enfoque podría ser adecuado.

Por ejemplo, MSA podría usarse en casos en los que los desarrolladores quieran retener un mayor grado de control en comparación con el historial de SOA de proporcionar un marco para aplicaciones más grandes y procesos comerciales complicados.

Una publicación de blog de BMC sobre el tema sugiere que “a medida que el negocio crece, las organizaciones pueden requerir capacidades como la transformación de solicitudes complejas y la integración de sistemas heterogéneos. En tales situaciones, las organizaciones a menudo recurren al patrón SOA para reemplazar a MSA ".

En otras palabras, SOA tiene (o tuvo) un cierto peso en el desarrollo empresarial. El uso de la malla de servicios enfrenta una batalla cuesta arriba para cambiar esa mentalidad, incluso si servicios como Istio, Linkerd y Consul están facilitando su implementación.

Y esa implementación es una que está siendo ayudada por desarrolladores que adoptan la mentalidad ágil, con el deseo de enfocarse en construir servicios y agregar valor al negocio en lugar de conectar servicios.

Los grandes nombres como Netflix que adoptan la malla de servicios tampoco hacen daño...

De las cenizas de SOA, ¿surge Service Mesh?
Es clave tener en cuenta que, aunque hemos combinado los dos en este artículo, una malla de servicios no necesariamente tiene que ser parte de la arquitectura de microservicios. En su lugar, puede pensar en utilizar una malla de servicios como un enfoque para tratar algunos de los problemas presentados por MSA.

En SOA, el uso de Enterprise Service Bus es esencial. Pero, como dice el blog de IBM , “en muchas otras organizaciones, el ESB llegó a ser visto como el cuello de botella. Hacer cambios o mejoras en una integración podría desestabilizar a otros que utilizan esa misma integración ".

A pesar de las buenas intenciones, eso significa que SOA que usa un ESB tiene un único punto de falla. Eso no es cierto en el caso de MSA, en el que los microservicios operan de forma independiente. Ese es un punto clave aquí porque demuestra hasta qué punto una malla de servicios eleva algunos de los conceptos de SOA.

El uso de una malla de servicio ofrece una visibilidad mejorada, lo que facilita la detección y el diagnóstico de problemas. Además, pueden desviar las solicitudes de los servicios fallidos sin que todo se caiga.

Ciertamente, existen similitudes entre SOA y el uso de una malla de servicios. Sin embargo, sería un flaco favor sugerir que el último es algo menos que una v2 mucho más capaz del primero. De hecho, en la mayoría de los casos, la malla de servicio se encuentra muy por encima de SOA.


Publicar un comentario

0 Comentarios