Investigación: Comunicación entre Servicios en Cloud Run para Multi-Agent Systems

Comunicación entre Servicios en Cloud Run: Investigación Completa

Fecha: 2026-04-05 Objetivo: Determinar qué recomienda Google para comunicación entre servicios Cloud Run, especialmente en contexto de agentes AI multi-agent.

Respuestas Directas a las 5 Preguntas

1. ¿Recomienda Google shared filesystem (GCS FUSE / Filestore) para comunicación entre servicios?

NO. Google no recomienda shared filesystem para comunicación inter-servicio. Las docs de GCS FUSE y NFS volume mounts se enfocan exclusivamente en dar acceso a storage persistente a servicios individuales, nunca como mecanismo de comunicación entre servicios.

Evidencia concreta:

La doc de Cloud Storage FUSE dice explícitamente: “Cloud Storage FUSE does not provide concurrency control for multiple writes (file locking) to the same file. When multiple writes try to replace a file, the last write wins and all previous writes are lost.” Fuente: Cloud Run Cloud Storage volume mounts
GCS FUSE “is not a fully POSIX-compliant file system” y tiene “much higher latency than a local file system” Fuente: Cloud Storage FUSE overview
NFS mounts en Cloud Run “does not support NFS locking” Fuente: NFS volume mounts
En la arquitectura multi-agent de Google Cloud Architecture Center, no hay ninguna mención de shared filesystem para comunicación entre agentes Fuente: Multi-agent AI system

2. ¿Qué recomienda Google para pasar datos entre servicios Cloud Run?

Google recomienda tres patrones, en orden de preferencia según el caso:

a) HTTP/gRPC directo (síncrono)

Cloud Run services exponen endpoints HTTPS estables (*.run.app)
Soporta HTTP/2 y gRPC end-to-end
Autenticación via IAM + ID tokens (service-to-service auth)
Fuente: Cloud Run overview

b) Pub/Sub push (asíncrono)

Mensajes publicados a un topic se entregan automáticamente via HTTP POST al endpoint del servicio
Retry automático basado en HTTP status codes
Autenticación built-in con service accounts
Fuente: Pub/Sub push

c) Cloud Tasks / Eventarc / Workflows (orquestación)

Cloud Tasks para ejecución asíncrona confiable
Eventarc para triggering basado en eventos (Storage, Firestore, etc.)
Workflows para orquestar invocaciones entre servicios
Fuente: Cloud Run overview

3. ¿Cuáles son los tradeoffs de performance GCS FUSE vs HTTP message passing?

Aspecto	GCS FUSE	HTTP directo entre servicios
Latencia	”Much higher latency than a local file system” — operaciones de metadata son “expensive and slow”	Latencia de red intra-región (sub-ms a pocos ms)
Throughput	Degradado con archivos pequeños secuenciales; optimizado solo para archivos grandes con parallel downloads	Alto throughput con connection pooling
Concurrencia	Sin file locking; “last write wins”	Manejo nativo de concurrencia HTTP
Cold start	Agrega latencia al cold start (mount timeout 30s)	Sin impacto adicional
Consistencia	Eventual; writes simultáneos pueden causar `ESTALE` errors	Request-response atómico
Memoria	Consume memoria del container: 32MB stat cache + 64MB por archivo en escritura streaming	Mínimo overhead
Costo	Storage GCS + API calls (list, get, put)	Solo compute Cloud Run (ingress es gratis)

Dato clave de performance de GCS FUSE:

Flat buckets: 5,000 read requests/sec, 1,000 write requests/sec iniciales
Hierarchical namespace buckets: 40,000 read requests/sec, 8,000 write requests/sec
Streaming writes: ~64MB de memoria por archivo abierto
Fuente: Cloud Storage FUSE performance

4. Para multi-agent AI systems, ¿cuál es el patrón recomendado?

A2A Protocol sobre HTTP/HTTPS. Google tiene documentación oficial explícita:

“To facilitate communication between agents, use Agent2Agent (A2A) protocol with ADK, which is an open standard protocol that enables AI agents to communicate and collaborate across different platforms and frameworks, regardless of their underlying technologies.” — Multi-agent AI system, Cloud Architecture Center

La arquitectura oficial de Google para multi-agent systems tiene estos componentes:

A2A Protocol — comunicación entre agentes (JSON-RPC 2.0 sobre HTTPS o gRPC)
MCP — acceso de agentes a tools/servicios externos
Cloud Run — runtime serverless para cada agente
Vertex AI — modelos de AI (Gemini)
AlloyDB / Memorystore / Firestore — estado persistente (NO filesystem compartido)

El patrón de estado es explícito:

“Stateless agent applications with externalized state management enable horizontal scaling because any instance serves any request.” — Choose agentic AI architecture components

Para persistencia de estado entre agentes:

Short-term memory: Memorystore for Redis, Firestore, Cloud SQL
Long-term memory: Memory Bank, Firestore
Task state: AlloyDB + A2A TaskStore
NO shared filesystem

5. ¿Existen guías de Google Cloud que aborden específicamente agent-to-agent communication?

Sí, hay documentación oficial extensa:

Multi-agent AI system in Google Cloud — guía de arquitectura completa
- URL: https://docs.cloud.google.com/architecture/multiagent-ai-system
- Cubre: patrones secuencial, iterativo, human-in-the-loop
- Comunicación: A2A protocol, MCP, HTTP
Single-agent AI system using ADK and Cloud Run — deployment pattern
- URL: https://docs.cloud.google.com/architecture/single-agent-ai-system-adk-cloud-run
- Enfatiza: stateless design, external storage para estado
Choose your agentic AI architecture components — decision guide
- URL: https://docs.cloud.google.com/architecture/choose-agentic-ai-architecture-components
- Compara: Cloud Run vs Vertex AI Agent Engine vs GKE
Deploy A2A agents to Cloud Run — tutorial de deployment
- URL: https://docs.cloud.google.com/run/docs/deploy-a2a-agents
- Detalle: JSON-RPC 2.0, service accounts, IAM auth
A2A Protocol Specification v0.3 — spec completa del protocolo
- URL: https://a2a-protocol.org/latest/specification/
- Transport: JSON-RPC 2.0, gRPC, HTTP+JSON/REST
- Modos: blocking, non-blocking, streaming (SSE), push notifications
Getting Started with A2A: Purchasing Concierge Codelab
- URL: https://codelabs.developers.google.com/intro-a2a-purchasing-concierge
- Ejemplo práctico de multi-agent con A2A en Cloud Run

Detalle Técnico: A2A Protocol como Patrón de Comunicación

Transport Layer

JSON-RPC 2.0 sobre HTTP (default)
gRPC con Protocol Buffers (v0.3+)
HTTP+JSON/REST como alternativa
TLS 1.2+ obligatorio en producción

Modos de Ejecución

Blocking (default): operación espera hasta estado terminal
Non-blocking (return_immediately: true): retorna inmediatamente con task in-progress
Streaming (SendStreamingMessage): SSE para actualizaciones en tiempo real
Push notifications: webhooks para escenarios desconectados

Data Flow

Datos pasan via Message objects con Parts (texto, archivos, structured data)
NO hay shared storage en el protocolo A2A — todo es message passing
Artifacts representan outputs generados, compuestos de Parts
File exchange via URLs o referencias estructuradas, no filesystem compartido

Discovery

Cada agente publica un Agent Card en /.well-known/agent-card.json
Describe: nombre, capabilities, endpoint, security schemes

Seguridad

API keys, OAuth 2.0, OpenID Connect
En Cloud Run: IAM-based auth con --no-allow-unauthenticated

El Anti-Pattern: Shared Database/Filesystem para Comunicación

La industria completa de microservices considera el shared database/filesystem como anti-pattern para comunicación inter-servicio:

“Shared databases risk becoming performance bottlenecks that encourage close-coupling and create a single point of failure.”

Problemas específicos:

Coupling — servicios dependen de un schema/estructura compartida
Bottleneck — punto único de contención
No contracts — sin interfaz explícita entre servicios
Scaling — filesystem compartido no escala horizontalmente
Consistency — GCS FUSE no tiene file locking, “last write wins”

Alternativas correctas según best practices:

API/HTTP para comunicación síncrona
Message queues (Pub/Sub) para comunicación asíncrona
Event-driven para desacoplamiento
Database-per-service para persistencia propia

Cuándo SÍ Usar GCS FUSE / Filestore en Cloud Run

GCS FUSE y NFS sí tienen usos válidos, pero no para comunicación:

Uso válido	Ejemplo
Cargar modelos ML	Montar bucket con model weights en startup
Acceso a datasets	Leer datos de training/inference desde GCS
Archivos de configuración	Configs compartidas read-only
Output de batch jobs	Escribir resultados de procesamiento batch
Media processing	Leer/escribir archivos multimedia

Para el video de 7 agentes ADK en Cloud Run: GCS FUSE no es el patrón correcto para comunicación entre agentes. A2A protocol sobre HTTP es el patrón oficial de Google.

Resumen para el Video

El stack recomendado por Google para multi-agent AI en Cloud Run:

┌─────────────────────────────────────────────┐
│                  Frontend                     │
│           (Cloud Run service)                 │
└──────────────────┬──────────────────────────┘
                   │ HTTP/A2A
┌──────────────────▼──────────────────────────┐
│           Coordinator Agent                   │
│        (Cloud Run + ADK + A2A)               │
└──┬───────┬───────┬───────┬──────────────────┘
   │ A2A   │ A2A   │ A2A   │ A2A
┌──▼──┐ ┌──▼──┐ ┌──▼──┐ ┌──▼──┐
│Agent│ │Agent│ │Agent│ │Agent│  ← cada uno es
│  1  │ │  2  │ │  3  │ │  N  │    Cloud Run service
└──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘    independiente
   │       │       │       │
   │ MCP   │ MCP   │ MCP   │ MCP
┌──▼───────▼───────▼───────▼──────────────────┐
│        Tools / External Services              │
│   (APIs, DBs, Cloud Storage, etc.)           │
└─────────────────────────────────────────────┘

Estado: Memorystore/Firestore/AlloyDB (NO filesystem)
Comunicación: A2A Protocol (HTTP/JSON-RPC 2.0)