Malla de servicios - Service mesh

Una malla de servicios consiste en una capa de infraestructura específica dentro de una aplicación de software que gestiona la comunicación entre servicios. Puede encargarse del enrutamiento del tráfico, la seguridad, la determinación del estado interno y las funciones de recuperación y, al mismo tiempo, de abstraer estas complejidades de cada uno de los servicios.

Las aplicaciones modernas se basan en servicios que se comunican entre sí. Recuerda la última vez que visitaste una tienda en línea. Seguramente usaste la barra de búsqueda del sitio para acceder a los productos. Esa búsqueda representa un servicio. Es posible que también hayas visto recomendaciones de productos relacionados o hayas agregado un objeto a tu carrito de compras en línea. Estos también son servicios. Por tanto, el servicio que se conecta con la base de datos del inventario debe hacerlo también con la página web del producto y esta, a su vez, con el carrito de compra en línea del usuario. Además, la tienda puede ofrecer un servicio que recomiende productos a los usuarios a través de la aplicación. Este 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.

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? Es entonces cuando entra en juego una malla de servicios, ya que gestiona la comunicación entre ellos y optimiza el funcionamiento de todas las partes juntas.

Una malla de servicios puede considerarse un patrón de arquitectura de microservicios. El término "microservicios" hace referencia al estilo de la arquitectura de las aplicaciones en el que un conjunto de servicios independientes se comunican a través de interfaces de programación de aplicaciones (API) ligeras. Una arquitectura de microservicios es un enfoque diseñado en la nube para desarrollar sistemas de software de una manera que permita que cada función central dentro de la aplicación exista de manera independiente. A diferencia del desarrollo de aplicaciones en otras arquitecturas, un equipo reducido se encarga de diseñar microservicios independientes, con la flexibilidad de elegir sus propias herramientas y lenguajes de programación. En otras palabras, los microservicios se crean de forma independiente y se comunican entre sí. Además, si se produce un error en uno de ellos, esto no provoca una interrupción de toda la aplicación.

Los microservicios se basan en la comunicación entre los servicios. A medida que se amplía su arquitectura, su gestión se torna más compleja. Si una aplicación contiene decenas o cientos de servicios que interactúan entre sí, surgen problemas relacionados con los errores en la red, la supervisión y el seguimiento, el equilibrio de las cargas de tráfico y la seguridad de la comunicación entre los distintos microservicios. No es muy conveniente abordar todos estos problemas con un código personalizado; sin embargo, la malla de servicios ofrece una solución uniforme que permite hacer frente a estos desafíos sin tener que modificar el código de cada uno de los servicios.

Una malla de servicios gestiona la comunicación entre servicios con un plano de datos y otro de control. 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 la distingue 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 cuales son un concepto común: si accedes a esta página web desde una computadora de trabajo, es muy probable que hayas utilizado un proxy. A continuación, te explicamos en qué consiste:

1. Cuando se envía la solicitud para esta página, la recibe el proxy web de tu 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 desde el proxy hacia ti.

En una malla de servicios, cada instancia de servicio se asocia a un proxy de sidecar que se ejecuta junto a cada servicio e intercepta todo el tráfico de red entrante y saliente. Este proxy se encuentra junto a los microservicios, y envía las solicitudes hacia y desde otros proxies. Además, se encarga de otras tareas, como el enrutamiento del tráfico, el equilibrio de carga, la aplicación de políticas de seguridad y la recopilación de datos de telemetría. En lugar de comunicarse directamente entre sí, los servicios envían solicitudes a través de sus sidecars, los cuales se encargan de la comunicación entre cada servicio. Todo ello constituye el plano de datos.

El plano de control gestiona la configuración y la distribución de políticas en el plano de datos. Además, se ocupa de distribuir las reglas de enrutamiento del tráfico, gestionar los certificados de seguridad entre servicios, configurar los distintos elementos para aplicar las políticas y recopilar los datos de telemetría.

Sin una malla de servicios, se debe codificar cada microservicio para que incluya las normas que regirán la comunicación entre los servicios. De este modo, es más difícil detectar los errores que se produzcan allí, ya que la lógica que guía la comunicación entre servicios permanece oculta en cada uno de ellos.

Más información sobre los microservicios

Istio es una plataforma de malla de servicios con tecnología de open source que controla el intercambio de datos entre los microservicios. Asimismo, regula el flujo de tráfico, aplica políticas y supervisa las comunicaciones en un entorno de microservicios. Incluye API que le permiten integrarse a cualquier plataforma de registro, telemetría o sistema de políticas. Puede ejecutarse en diversos entornos locales, virtualizados, en contenedores y en la nube.

La arquitectura de Istio se divide en el plano de datos y el plano de control. Además, utiliza proxies de alto rendimiento como Envoy que se implementan como sidecars y facilitan el tráfico para todos los servicios dentro de la malla de servicios. En el plano de datos, los desarrolladores pueden incorporar el soporte de esta plataforma a un servicio mediante la implementación de un proxy de sidecar dentro del entorno.

La malla de servicios de Istio dispone de un nuevo modo denominado "Ambient" para que no sea necesario utilizar proxies de sidecar y, en su lugar, se empleen proxies de nodos y puertas de enlace intermedias denominadas "Waypoints". Estos últimos se ejecutan en un entorno externo a los pods de aplicaciones y se gestionan sin depender de ellas.

Obtenga más información sobre Istio en Red Hat Developer

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 prácticamente imposible encontrar la causa de los problemas en una arquitectura de microservicios compleja.

El uso de una malla de servicios ofrece diversas ventajas:

• Mejor seguridad. Esta plataforma utiliza la seguridad de la capa de transporte mutua (mTLS) para que la comunicación entre servicios sea cifrada y segura, y los datos confidenciales de los usuarios estén protegidos. Esto agrega otra capa de seguridad sin que sea necesario incorporar manualmente un cifrado adicional a cada servicio. Una malla de servicios puede mejorar el control de acceso basado en funciones (RBAC) y las políticas para proteger las API, así como automatizar la gestión de certificados y la rotación de claves.
• Implementación de políticas. Este tipo de plataforma ofrece una configuración concentrada de las políticas de servicios, como cuotas, limitación de acceso, autenticación y autorización. Además, permite controlar las interacciones de los servicios mediante políticas de acceso, que se aplican a nivel de proxy, lo cual favorece la uniformidad entre los distintos servicios.
• Gestión del tráfico. Con la malla de servicios, tus aplicaciones pueden gestionar el tráfico hacia los distintos servicios en función de las condiciones de carga, las versiones y las normas específicas del usuario. Por ejemplo, si deseas lanzar una versión nueva de tu servicio de inventario, puedes utilizar una implementación de tipo canary (que es más limitada) para enviar únicamente el 5 % del tráfico al servicio en cuestión. Si funciona, puedes aumentar el tráfico.
• Verificación y determinación del estado interno. La interacción de los microservicios en tiempo real puede plantear algunas dificultades a la hora de observar su funcionamiento; sin embargo, con una malla de servicios es posible implementar herramientas de determinación del estado interno integradas (como el seguimiento distribuido y la recopilación de indicadores). Los sidecars de una malla de servicios recopilan indicadores (recuento de solicitudes, latencia, tasas de error) y los envían al plano de control o a las herramientas de supervisión.
• Tolerancia a errores y mayor capacidad de recuperación. En caso de que se produzcan errores en los microservicios, una malla de servicios puede resolverlos con la automatización de reintentos y respuestas alternativas. Si un servicio no funciona o deja de responder, la plataforma volverá a intentarlo conforme a una serie de normas definidas previamente y podrá redirigir el tráfico a otros servicios. Esto significa que la aplicación puede gestionar el error de manera adecuada cuando un servicio deja de estar disponible y garantizar así que los usuarios sigan disfrutando de una buena experiencia. La malla de servicios también recopila datos sobre el tiempo que transcurre antes de que un reintento tenga éxito. Estos datos pueden utilizarse para establecer normas relativas al tiempo de espera óptimo y evitar que el sistema se sobrecargue con reintentos innecesarios.

Con una malla de servicios, los desarrolladores y los equipos de operaciones cuentan con mejores herramientas para gestionar la migración de las aplicaciones monolíticas a las de la nube, que son conjuntos de aplicaciones de microservicio pequeñas, independientes y de bajo acoplamiento. 

Las empresas pueden enfrentarse a diversos desafíos al implementar una malla de servicios, entre ellos:

• Complejidad e integración con los sistemas actuales. Una malla de servicios puede resultar difícil de configurar, gestionar e integrar a los sistemas actuales. En este sentido, las empresas pueden enfrentarse a diversos desafíos si operan en un entorno amplio y distribuido entre sistemas locales y multicloud, o bien si nunca antes utilizaron una malla de servicios en su entorno.
• Necesidad de recursos y costos operativos. Las mallas de servicios pueden aumentar los costos operativos derivados de la gestión de aplicaciones, ya que cada instancia de servicio tiene ahora un proxy de sidecar, lo cual implica un mayor uso de la CPU y la memoria. La gestión y la resolución de problemas, sobre todo en implementaciones que se realizan en toda la empresa, pueden resultar complejas y, en consecuencia, puede ser mucho más complicado mantener el rendimiento y la capacidad de ajuste.
• Falta de personal capacitado. Los equipos deben recibir capacitación para poder comprender las funciones, la configuración y las prácticas recomendadas de la malla de servicios. La corrección de los errores puede ser una tarea difícil, sobre todo cuando los problemas aparecen como consecuencia de normas de enrutamiento complejas o configuraciones erróneas de mTLS. En muchas empresas, los equipos no poseen los conocimientos necesarios sobre la tecnología de malla de servicios, lo cual puede plantear serios problemas a la hora de ponerse en marcha y utilizarlas de manera eficaz.

Una puerta de enlace de API es una herramienta de gestión de API que se encuentra entre tú y un conjunto de servicios de backend. En este caso, el cliente es la aplicación en el dispositivo de un usuario, y los servicios de backend son los que están en los servidores de una empresa. Una puerta de enlace de API permite separar la interfaz del cliente de su implementación de backend. Cuando un cliente realiza una solicitud, la puerta de enlace de API la divide en varias solicitudes, las distribuye a los lugares correctos, genera una respuesta y realiza un seguimiento de todo el proceso.

Una malla de servicios protege la comunicación de los servicios internos y permite el tráfico externo a través de la puerta de enlace de API. Si se utiliza en conjunto este último, es posible garantizar la aplicación uniforme de las políticas en todos los servicios internos. 

Obtén más información sobre Red Hat 3scale API Management

Red Hat te ayuda a diseñar una arquitectura de servicios completa, ya que ofrece productos integrados de gestión de las API, de malla de servicios y de plataforma de infraestructura.Red Hat® OpenShift® Service Mesh te permite conectar, gestionar y controlar las aplicaciones basadas en microservicios de manera uniforme. No solo te permite obtener información sobre el comportamiento de los microservicios conectados a la red que forman parte de la malla de servicios, sino también controlarlos.

OpenShift Service Mesh se basa en el proyecto open source Istio y ofrece funciones adicionales, ya que incluye otros proyectos similares, como Kiali (la consola para Istio) y Jaeger (el sistema de rastreo de entornos distribuidos), que respaldan la colaboración con los principales miembros de la comunidad de Istio. OpenShift Service Mesh permite que los desarrolladores aumenten la productividad al integrar las políticas en materia de comunicación sin necesidad de cambiar el código de las aplicaciones ni integrar las bibliotecas específicas de los lenguajes.

El servicio Red Hat OpenShift Service Mesh viene preinstalado, probado y optimizado para Red Hat OpenShift y es compatible con algunas de las funciones específicas de esta plataforma, como los operadores y los canales de integración y distribución continuas (CI/CD). Además, cuenta con el soporte empresarial de Red Hat y se realizan actualizaciones y se aplican parches con regularidad para garantizar la seguridad y la estabilidad. Este servicio funciona en varios clústeres de Red Hat OpenShift y ofrece uniformidad en entornos de nube híbrida o multicloud.