Si estás construyendo y operando una arquitectura de microservicios a escala con Kubernetes, adoptar una malla de servicios para gestionar todos los aspectos transversales del funcionamiento de la arquitectura es una elección segura. Entre las diversas implementaciones de malla de servicios, Istio ha obtenido una adopción mayoritaria. Tiene un amplio conjunto de características, que incluyen descubrimiento de servicios, administración de tráfico, seguridad de servicio a servicio y de origen a servicio, observabilidad (incluyendo telemetría y rastreo distribuido), lanzamiento de nuevas versiones recurrentes y resiliencia. Su experiencia de usuario ha mejorado en las últimas versiones lanzadas, debido a su facilidad de instalación y arquitectura del panel de control. Istio ha bajado la vara en lo que se refiere a la implementación de microservicios a gran escala y con calidad operativa para muchos de nuestros clientes, pero también hay que admitir que la operación de instancias propias de Istio y Kubernetes requiere de una serie de conocimientos y recursos apropiados, lo que, lastimosamente, no es para cualquier persona.
Istio is becoming the de facto infrastructure to operationalize a microservices ecosystem. Its out-of-the-box implementation of cross-cutting concerns — such as service discovery, service-to-service and origin-to-service security, observability (including telemetry and distributed tracing), rolling releases and resiliency — has been bootstrapping our microservices implementations very quickly. It's the main implementation of the service mesh technique we've been using. We've been enjoying its monthly releases and its continuous improvements with seamless upgrades. We use Istio to bootstrap our projects, starting with observability (tracing and telemetry) and service-to-service security. We're closely watching its improvements to service-to-service authentication everywhere in and outside of the mesh. We'd also like to see Istio establish best practices for configuration files to strike a balance between giving autonomy to service developers and control to the service mesh operators.
When building and operating a microservices ecosystem, one of the early questions to answer is how to implement cross-cutting concerns such as service discovery, service-to-service and origin-to-service security, observability (including telemetry and distributed tracing), rolling releases and resiliency. Over the last couple of years, our default answer to this question has been using a service mesh technique. A service mesh offers the implementation of these cross-cutting capabilities as an infrastructure layer that is configured as code. The policy configurations can be consistently applied to the whole ecosystem of microservices; enforced on both in and out of mesh traffic (via the mesh proxy as a gateway) as well as on the traffic at each service (via the same mesh proxy as a sidecar container). While we're keeping a close eye on the progress of different open source service mesh projects such as Linkerd, we've successfully used Istio in production with a surprisingly easy-to-configure operating model.
