EasyTech: Service Mesh, comunicación entre servicios rápida y segura

octubre 18, 2019

Por Carlos Robles

De un tiempo a esta parte es probable que hayas oído hablar con frecuencia de ​Service Mesh ​ o de alguna de las herramientas que forman parte de su ecosistema, como pueden ser Istio​ o ​Linkerd.   

Sin duda, es una de las tecnologías que más fuerza ha cogido en 2019 y que más está creciendo debido, en gran medida, a la consolidación de las arquitecturas de microservicios y de los orquestadores de contenedores.  

A grandes rasgos lo que nos proporcionan estas ​mallas de servicios ​ es una forma de comunicar y operar nuestros servicios. Pero, si esto ya era algo para lo que teníamos soluciones, ¿por qué han crecido con tanta fuerza en los últimos años?  

Para entenderlo mejor vamos a recordar primero cuál ha sido la evolución de las arquitecturas orientadas a (micro) servicios y cuáles son los problemas que fueron apareciendo en esta evolución.  

Contexto 

En las arquitecturas orientadas a servicios de hace años era muy habitual contar con una pieza central denominada ESB (Enterprise Service Bus) donde de manera centralizada delegábamos aspectos tales como seguridad, monitorización, mediación o enrutado. En esta aproximación teníamos servicios muy ligeros que sólo implementaban la lógica de negocio y delegábamos muchas funcionalidades adicionales a las tuberías de comunicación.  

Aunque esta aproximación presentaba muchas ventajas para los equipos de desarrollo, el uso de este ESB como pieza central para intercomunicar y operar servicios presentaba múltiples inconvenientes que hicieron que fuera perdiendo popularidad.  

Unos años más tarde se popularizaron las actuales arquitecturas de microservicios impulsadas en gran medida con la llegada de Netflix y su stack de código abierto para Java.  En este escenario pasamos a tener una situación diametralmente opuesta a la anterior.  Los servicios ya no sólo son responsables de implementar la lógica de negocio, sino que también son responsables de otros aspectos tales como descubrimiento de otros servicios, seguridad, mediación, monitorización, orquestación, tolerancia a fallos, etc.  

Es decir, nuestros servicios pasan a ser muy pesados y complejos, ya que hemos dejado de delegar responsabilidades a las tuberías de comunicación.  

Y es en esta situación en la que comienza a cobrar sentido implantar un ​Service Mesh, ya que es una solución intermedia entre las dos aproximaciones anteriores. Por un lado, podemos volver a centrar nuestros servicios en resolver los problemas de negocio y, por otro, podemos delegar aspectos comunes a todos ellos en las tuberías de comunicación, pero haciéndolo de una forma descentralizada.  

Por tanto, un ​Service Mesh ​ es una capa de infraestructura dedicada que permite una comunicación entre servicios de manera segura, rápida y confiable. Se suele implementar como un conjunto de ​proxies​ desplegados junto a cada uno de nuestros servicios y que interceptan el tráfico de entrada y salida de las aplicaciones. Pasamos de tener una comunicación directa entre servicios a una comunicación realizada a través de estos ​sidecar proxies​.  

 

Esta arquitectura tan flexible nos permite implementar de forma sencilla y unificada múltiples funcionalidades como, por ejemplo:  

  • Autodescubrimiento de servicios y configuración.  
  • Implementación de trazas distribuidas para investigación de errores de aplicación.  
  • Métricas para dashboards operacionales. 
  • Inyección de fallos para técnicas de ​chaos engineering.  
  • Balanceo de carga de peticiones salientes.  
  • Reintentos, timeouts y mecanismos de ​circuit breaking. 
  • Telemetría y monitorización. 
  • Enrutado de tráfico.  
  • División de tráfico (despliegues en modo ​canary ​ o ​blue/green)  
  • Autenticación mutua automática entre servicios por TLS.  
  • Establecimiento de políticas de seguridad.  

 Algunas de estas funcionalidades podrían llegar a relacionarse con soluciones de ​Api Gateway ​ por lo que hay que tener claro su ámbito de utilización. Mientras que el ​Api Gateway ​ está orientado al denominado tráfico norte-sur (desde el cliente a nuestros servicios), ​Service Mesh ​está orientado al tráfico este-oeste (entre nuestros servicios internos).  

Si te ha parecido interesante el tema y quieres profundizar más y probarlo no dudes en revisar los siguientes proyectos:  

  

Utilizamos cookies propias y de terceros para ofrecerte una mejor experiencia y servicio, dentro de nuestra Web de acuerdo a tus hábitos de navegación. Si continúas navegando, consideramos que aceptas expresamente su utilización. Puedes obtener más información de cómo gestionar y configurar las cookies en nuestra Política de Cookies.