En una aplicación basada en microservicios, estos no funcionan de manera aislada. No tenemos un microservicio o dos, tenemos una red de servicios, es decir, un sistema. Un sistema formado por elementos que tienen que coordinarse entre sí, de la manera más desacoplada posible, para producir un resultado o ejecutar una función de negocio. A este sistema o “nube” de servicios, se le llama “service mesh” o red de servicios.

Además, para funcionar, un microservicio necesita ciertos servicios de infraestructura como puede ser el descubrimiento de los otros servicios, el balanceo de carga, monitorización, logs…, y por supuesto, seguridad.

istio.png

Istio es una iniciativa open source impulsada por Google, IBM y Lyft que proporciona estos servicios de infraestructura para microservicios sin “contaminar” el código de negocio. Es decir, tu código únicamente se ocupa de la funcionalidad mientras que el resto de servicios técnicos, como la seguridad y el enrutado de las llamadas a los otros servicios lo hace Istio. Existen otros frameworks para la implementación de microservicios, el más conocido es el de Netflix. Sin embargo, Istio, a diferencia de este es  independiente del lenguaje que se utiliza para implementar el microservicio.

En concreto, Istio se ocupa de:

  • Gestión de tráfico entre microservicios y desde estos con el resto “del mundo”. 
  • Observación de las dependencias entre servicios y de los flujos de llamadas entre ellos
  • Aplicación de políticas en las interacciones entre los servicios
  • Identidad y seguridad, verificando la identidad de llamante y validando si un microservicio puede llamar a otro.

Istio es un proyecto muy nuevo, ahora mismo va por la versión 0.7, aunque madura rápidamente y Google insiste que ya se puede utilizar en producción. Sin embargo, la documentación y referencias son bastante escasas todavía. A modo de introducción y para picarte un poco la curiosidad voy a citar algunas de las características más relevantes extraídas de su documentación y de otros artículos.

Componentes de Istio

Captura de pantalla 2018-04-08 a las 8.14.37.png

  • Envoy
    Es un proxy desarrollado en C++, con un gran rendimiento, que intercepta todas las llamadas entrantes y salientes del microservicio. Envoy proporciona service discovery, TLS, HTTP/2 y gRPC proxies, circuit breakers, health checks, enrutados variables en base a porcentajes, inyección de errores para el concepto de kaos monkey y recolección de métricas.
    En un entorno de Kubernetes, el componente de Envoy se despliega en el mismo pod que el microservicio. Envoy constituye para el microservicio la puerta con el resto de microservicios ya que no hay comunicación directa entre estos, todo la comunicación se hace a través del Envoy que tiene cada microservicio desplegado a su lado.
  • Mixer
    Es un componente independiente de la plataforma que se ocupa de garantizar las políticas de control y uso en el service mesh y de recolectar métricas. Envoy extrae por ejemplo los atributos de la request y los envía a Mixer para su evaluación
  • Pilot
    Proporciona el servicio de descubrimiento para los sidecars, capacidades de gestión de tráfico para el enrutado inteligente como test A/B, canary deployments, etc y el control de la resiliencia, es decir control de timeouts, reintentos, corto circuitos, etc.
    Convierte las reglas de enjutado de alto nivel especificadas en el fichero de despliegue en configuraciones específicas de Enfoy y las propaga a los sidecars en tiempo de ejecución.
    Abastrae los mecanismos específicos de la plataforma en cuanto al mecanismo de descubrimiento de servicios y proporciona un formato estándar para consumir esta información por cualquier sidecar.
  • Istio Auth
    Proporciona autenticación entre servicios y con el usuario final usando mutual TLS, incorporando la gestión de las identidades y credenciales.

Planos

A nivel conceptual, Istio se divide en dos partes o planes, el de datos y el de control:

Data plane

Está compuesto por una serie de proxies inteligentes implementados con Envoy. Cada microservicio tiene su proxy desplegado al lado, a modo de sidecar. Es este sidecar el encargado de proveer todos los servicios de infraestructura para el microservicio.

Captura de pantalla 2018-04-07 a las 19.14.16.png

Control plane

Es el encargado de monitorizar todos las instancias de los sidecars, aplicando políticas de control, recolección de métricas y monitorizaciónCaptura de pantalla 2018-04-07 a las 19.13.45.png

 

Características de Istio

Comunicaciones entre servicios

  • Se introduce el concepto de versión de los servicios (v1, v2) o (staging, prod), pudiendo tener varias versiones del mismo servicio en el mismo entorno.
  • Los clientes no tienen conocimiento de las diferentes versiones del servicio. Pueden continuar accediendo a través del hostname/IP. El sidecar/proxy Envoy intercepta y redirige todas las peticiones/respuestas del cliente y del servicio
    • Istio no proporciona DNS. Se tiene que apoyar en lo que de Kubernetes
  • Todas las comunicaciones entrantes y salientes al microservicio pasan por Envoy

Discovery and Load Balancing

  • Registro de Servicios: Istio asume que hay un registro ya configurado, lo tendría que proporcionar Kubernetes.
  • Discovery: consume información del registro de servicios y proporciona un interfaz agnóstico para el descubrimiento. 
  • Además del load balancing también hace periodic health checks (cuanto están mal tienen que devolver un error 503)

Handling Failures

  • Permite gestionar los “problemas” o fallos que puede surgir en la ejecución. Las características que vienen de caja (se pueden configurar dinámicamente a través las reglas de tráfico):
    • Timeouts
    • Reintentos limitados con indicación de timeouts y fluctuación de tiempo entre reintentas
    • Límite en el número de conexiones concurrentes
    • Health checks periódicos (active) en cada miembro del pool de load balance
    • Circuit Breakers de grano fino (passive health checks) – aplicados a cada instancia del pool de balanceo
  • Los health checks de combinan con los que hace Kubernetes
  • Se puede hacer configuración de grano fino, sobrescribiendo la configuración general, con las HTTP headers (the headers are “x-envoy-upstream-rq-timeout-ms” and “x-envoy-max-retries”)

Fault Injection

  • Para probar la capacidad de recuperación ante fallos. Nos permite introducir a propósito fallos en el sistema.
  • Tipos de fallos que se pueden introducir:
    • Delays
      • Imitan un incremento de latencia o un sobrecarga en las llamadas a los servicios
    • Aborts
      • Son crash que imitan a fallos en los servicios. Normalmente se manifiestan en la forma de HTTP error codes o TCP connection failures

Configuración de reglas

  • Proporciona un Domain-specific language (DSL) que controla como las llamadas a las APIs y de nivel-4 de red fluyen a través de varios servicios en el despliegue de aplicaciones.
  • Permite al operador configurar circuit breakers, timeouts, reinvents, canary rollouts, A/B testing, staged rollouts basado en la división de un % del tráfico, etc.

En la imagen siguiente se puede ver un fichero de configuración de Istio donde se está diciendo que para un servicio llamado “reviews” el 25% del tráfico se envíe a la versión 2 mientras que el 75% restante se envíe a la versión 1 del servicio.

istio rules.png