Gestionar microservicios en producción exige visibilidad, seguridad y control centralizado. Anthos, la plataforma de Google Cloud, reúne estas capacidades en un solo lugar y permite operar aplicaciones distribuidas con confianza. A continuación se recorre paso a paso un despliegue real que muestra cómo crear un proyecto, activar el Service Mesh, definir niveles de servicio y aplicar encriptación MTLS desde un repositorio de código.
¿Cómo se despliega un proyecto con Anthos desde cero?
El punto de partida es crear un nuevo proyecto en Google Cloud y activar el API de Anthos [0:18]. Una vez habilitado, Google pone a disposición un sample preconfigurado: basta con hacer clic, seleccionar las variables de entorno y esperar a que la plataforma se aprovisione automáticamente [0:33].
Cuando el despliegue termina, se puede observar un clúster de Google Kubernetes Engine (GKE) con todos los componentes de Anthos activos [0:44]. Este clúster incluye:
- Nodos y cargas de trabajo organizados por namespace.
- Una aplicación de ejemplo llamada Online Boutique, construida con microservicios.
- Servicios de ingress gestionados por Istio Ingress Gateway con endpoints expuestos externamente [1:07].
Esta arquitectura refleja un escenario real donde múltiples equipos pueden desplegar y operar servicios de forma independiente dentro del mismo clúster.
¿Qué información ofrece Anthos Service Mesh sobre los microservicios?
Anthos Service Mesh (ASM) se encarga de todas las comunicaciones entre servicios [1:22]. Su panel de topología muestra de forma visual cada servicio desplegado y la latencia que existe entre ellos. Esa información se reporta al componente Pilot de Istio, se almacena y se presenta en un dashboard en tiempo real [1:41].
¿Cómo se define un SLO para un servicio crítico?
Un SLO (Service Level Objective) establece el rendimiento mínimo aceptable. En el ejemplo se configura el servicio del carrito de compras con una latencia máxima de cinco milisegundos para el 90 % de las solicitudes en un día [2:04]. Aunque el objetivo sea muy exigente y no se cumpla de inmediato, lo importante es la visibilidad sobre los cuellos de botella que se generan dentro de la aplicación [2:22].
¿Cómo se verifica si la comunicación está encriptada?
ASM indica visualmente si los servicios están encriptando sus comunicaciones o no. Citadel, un componente de Istio integrado en Anthos, firma los certificados SSL necesarios para cifrar el tráfico dentro del clúster [1:55].
¿Cómo se aplica encriptación MTLS con Anthos Config Management?
Para forzar la encriptación entre servicios se utiliza Anthos Config Management (ACM) [2:42]. ACM funciona como un repositorio Git donde se almacenan las políticas de configuración. Cualquier cambio en esas políticas se propaga automáticamente al clúster.
El proceso práctico, ejecutado desde Cloud Shell, consiste en dos ediciones de archivos [2:52]:
- En el archivo de mesh policy se elimina el modo permisivo, que permitía tráfico sin cifrar.
- En el archivo de destination rules se establece el certificado mutuo (MTLS), exigiendo autenticación por ambas partes.
Tras hacer commit y push al repositorio, los cambios se propagan al clúster [3:18]. Los candados en el panel de ASM cambian a verde, confirmando que la comunicación entre servicios ya está encriptada [3:26].
Este flujo separa responsabilidades de forma clara: el equipo de seguridad administra el repositorio Git con las políticas, mientras el equipo de desarrollo se concentra en desplegar los servicios que necesita [3:36].
La combinación de GKE, Anthos, ASM y ACM entrega un ecosistema completo para operar microservicios con observabilidad, gobernanza y seguridad integradas. Si ya experimentaste con alguno de estos componentes, comparte tu experiencia y cuéntanos qué retos encontraste en el camino.
