Malla de servicios - Service mesh

Una malla de servicios o service mesh, como el proyecto open source Istio, se utiliza para controlar el intercambio de datos entre las distintas partes de una aplicación. A diferencia de otros sistemas que también administran esta comunicación, la malla de servicios es una capa visible y específica de la infraestructura integrada a la aplicación, la cual puede registrar si las distintas partes interactúan bien o no, a fin de facilitar la optimización de las comunicaciones y evitar el tiempo de inactividad a medida que crece una aplicación.

Las partes de la aplicación se denominan "servicio" y dependen unas de otras para brindar a los usuarios lo que desean. Si alguien utiliza la aplicación de una tienda en línea para comprar un producto, debe saber si el artículo está disponible. Por lo tanto, el servicio que se conecta con la base de datos del inventario de la empresa se debe comunicar con la página web del producto, que a su vez debe comunicarse con el carrito de compras en línea del usuario. Si la tienda quiere ofrecer más beneficios, podría diseñar un servicio que recomiende productos a los usuarios dentro de la aplicación. Este nuevo servicio se comunicará con una base de datos de etiquetas de los productos para ofrecer recomendaciones y, además, debe comunicarse con la misma base de datos del inventario que necesitaba la página del producto; es decir, se trata de una gran cantidad de partes independientes y reutilizables.

Las aplicaciones modernas suelen dividirse de este modo: como una red de servicios en la cual cada uno de ellos desempeña una función comercial específica. Para ello, estos servicios deberían intercambiar datos permanentemente. ¿Pero qué sucede si algunos servicios, como la base de datos del inventario de la tienda minorista, sufren una sobrecarga de solicitudes? Entonces entra en juego la malla de servicios, que dirige las solicitudes de un servicio a otro para optimizar el funcionamiento en conjunto de las partes.

La malla de servicios no agrega funciones nuevas al entorno de tiempo de ejecución de la aplicación; las aplicaciones siempre necesitan normas que especifiquen cómo se transfieren las solicitudes del punto A al B, independientemente de su arquitectura. Lo que distingue a la malla de servicios es que las normas que rigen la comunicación entre los servicios no se encuentran dentro de cada uno de ellos, sino que se extraen y se colocan en una capa de infraestructura.

Para ello, la malla de servicios se integra a la aplicación como un conjunto de proxies de red. Los proxies son un concepto común en el ámbito de la TI empresarial: si accede a esta página web desde una computadora de trabajo, es muy probable que haya utilizado un proxy.

1. Cuando se envía la solicitud para esta página, primero la recibe el proxy web de su empresa.
2. Una vez que la solicitud pasa la medida de seguridad del proxy, se envía al servidor que aloja esta página.
3. Luego, la página regresa al proxy y se vuelve a verificar en función de las medidas de seguridad.
4. Finalmente, se envía del proxy a usted.

En una malla de servicios, las solicitudes se envían entre los microservicios por medio de proxies en su propia capa de infraestructura. Por eso, los proxies individuales que forman una malla de servicios a veces se denominan "sidecars", ya que se ejecutan junto a cada uno de los servicios, y no dentro de ellos. En conjunto, estos proxies sidecar, que están separados de cada servicio, forman una red.

Los proxies sidecar se encuentran junto a los microservicios y envían las solicitudes a otros proxies. Juntos, los sidecars forman una red.

Sin una malla de servicios, se debe codificar cada microservicio para que incluya las normas que regirán la comunicación entre los servicios, lo cual distrae a los desarrolladores de los objetivos empresariales. También significa que los errores de comunicación son más difíciles de diagnosticar porque las normas de comunicación entre los servicios están ocultas dentro de cada uno de ellos.

Cada servicio nuevo que se incorpora a una aplicación, o cada instancia nueva de un servicio actual que se ejecuta en un contenedor, agrega complejidad al entorno de comunicación y genera nuevas posibilidades de error. Sin una malla de servicios, es casi imposible encontrar la fuente de los problemas en una arquitectura compleja de microservicios.

Esto se debe a que la malla de servicios también captura todos los aspectos de la comunicación entre los servicios como índices de rendimiento. Con el tiempo, los datos que muestra la malla de servicios se pueden aplicar a las normas que rigen la comunicación entre los servicios, lo cual se traduce en solicitudes más eficientes y confiables.

Por ejemplo, si se produce un error en cierto servicio, la malla puede recopilar datos sobre el tiempo que transcurrió antes de que funcionara el reintento. A medida que se incorporan datos sobre los intervalos de error de un servicio, se pueden escribir normas para determinar el tiempo de espera óptimo antes de volver a intentar usarlo, lo cual garantiza que el sistema no se sobrecargue con reintentos innecesarios.

Si desea diseñar microservicios, es probable que prevea ciertas necesidades, como la capacidad de extenderlos rápidamente y la incorporación de funciones nuevas para satisfacer las necesidades empresariales. Es posible que la arquitectura de microservicios sea muy diferente al año de su lanzamiento. Al principio, las bibliotecas de los microservicios podrán lidiar con la comunicación entre los servicios con una interrupción mínima de las operaciones. Sin embargo, si decidimos aumentar la capacidad y las funciones de los microservicios para sacar el máximo provecho de ellos, podrían producirse más interrupciones. Esto puede generar problemas con el tiempo, ya que los servicios se sobrecargan con las solicitudes, y los desarrolladores pasan cada vez más tiempo codificando las normas que rigen las solicitudes para cada servicio.

Ventajas de la malla de servicios:

• Los desarrolladores pueden centrarse en aportar valor empresarial, en vez de dedicarse a conectar los servicios.
• El seguimiento distribuido de las solicitudes con Jaeger forma una capa de infraestructura visible junto a los servicios, así que resulta más sencillo reconocer y detectar los problemas.
• Las aplicaciones son más resistentes al tiempo de inactividad, dado que la malla puede redirigir las solicitudes para que no se conecten con los servicios en los que se produjo un error.
• Los indicadores de rendimiento sugieren formas de optimizar la comunicación en el entorno de ejecución.

Comience a hacer planes para el futuro y pruebe la malla de servicios en la plataforma Red Hat® OpenShift® Service Mesh, la cual le permite conectar, gestionar y supervisar las aplicaciones de microservicios de manera uniforme, con información y control sobre el comportamiento de aquellos que se encuentran conectados a su malla. OpenShift Service Mesh se encuentra disponible para Red Hat OpenShift sin costo.

Este elemento forma parte de Red Hat Ansible Automation Platform y ofrece un marco sencillo y confiable para ajustar la automatización. La malla incluye una capa de comunicación flexible y multidireccional, lo cual mejora la capacidad de una empresa para funcionar a gran escala. No es tan sensible a la latencia ni a los problemas de conexión, y además cuenta con funciones para el intercambio directo de tráfico, lo cual aumenta la confiabilidad y le permite realizar más tareas que con cualquier otra plataforma de automatización del mercado. Además, puede confiar en Red Hat Ansible Automation Platform para ampliar los límites de su entorno informático empresarial, ya que ofrece funciones de seguridad, como el cifrado y la autenticación de TLS, y controles de acceso adicionales.