Ya que aún persisten los costos y la complejidad operativa de las mallas de servicios (service meshes) basados en sidecars, nos entusiasma ver otra opción surgir para service mesh sin sidecar: Istio ambient mode. El ambient mode introduce una arquitectura en capas que separa las responsabilidades entre dos componentes clave: el proxy L4 por nodo (ztunnel) y el proxy L7 por espacio de nombres (Waypoint proxy). ztunnel garantiza que el tráfico L3 y L4 se transporte de manera eficiente y segura. Este hace funcionar el plano de datos ambient, obteniendo certificados para todas las identidades de nodo y, a su vez, gestiona la redirección del tráfico hacia y desde las cargas de trabajo habilitadas para ambient. El proxy Waypoint, un componente opcional del modo ambient, habilita características más avanzadas de Istio como gestión de tráfico, seguridad y observabilidad. Hemos tenido buenas experiencias con este modo en clústeres de pequeña escala y esperamos obtener más información y mejores prácticas a medida que crece su adopción.
Malla de servicios suele implementarse como un proxy inverso, también conocido como sidecar, desplegado a la par de cada instancia de servicio. Aunque estos procesos de sidecar suelen ser ligeros, el coste general y la complejidad a la hora de adoptar una malla de servicios se incrementa con cada nueva instancia de servicio que requiere un sidecar adicional. Sin embargo, con los avances en eBPF, estamos observando un nuevo enfoque de malla de servicios sin sidecar donde las funcionalidades de la malla son transferidas de forma segura al núcleo del SO, habilitando a los servicios que se ejecutan en el mismo nodo a comunicarse de forma transparente a través de sockets, sin necesidad de proxies adicionales. Puedes probar esto con Cilium service mesh y simplificar el despliegue pasando de un proxy por servicio a un proxy por nodo. Estamos intrigados por las capacidades de eBPF y por eso nos parece importante evaluar está evolución de la malla de servicios.
