Arquitectura GCP — Módulo 3: cómputo, Cloud Run como filosofía

Las tres preguntas del cómputo para agentes — ¿cuánto dura?, ¿cuánto pesa el entorno?, ¿el trabajo llega como tráfico o como lotes? — y la convicción de fondo (el agente es trabajo que despierta cómputo) viajan intactas desde AWS. Lo que cambia en GCP es la forma del menú: donde AWS reparte la respuesta entre cinco servicios, GCP concentra la suya en uno con dos caras.

Necesidad	En AWS	En GCP
Función por evento, corta	Lambda	Cloud Run functions (sobre el motor de Run)
Contenedor efímero por tarea	Tarea Fargate	Cloud Run jobs
Servicio continuo con tráfico	Servicio ECS + Fargate	Cloud Run services
Kubernetes (por organización)	EKS	GKE
Lotes masivos	AWS Batch	Batch
Orquestación con esperas	Step Functions	Workflows (módulo 11)

La tesis del módulo

Cloud Run es la apuesta de GCP hecha servicio: contenedores estándar con scale-to-zero por defecto, en dos modos que mapean exactamente a los dos patrones del agente — services para lo que atiende tráfico, jobs para lo que nace, trabaja y muere. La decisión de cómputo que en AWS era un árbol, en GCP es casi siempre una pregunta: ¿esto atiende peticiones o ejecuta tareas? Todo lo demás — escalar a cero, facturar por uso, el entorno como contenedor — viene puesto.

Las dos caras de Cloud Run

• Services: reciben peticiones HTTP (o eventos empujados), escalan por concurrencia — incluido a cero: sin tráfico, cero instancias, cero costo. El agente conversacional del catálogo vive aquí, y el scale-to-zero difumina la frontera que en AWS separaba “servicio siempre vivo” de “cómputo efímero”: un service sin tráfico es efímero en la práctica. La letra chica: el arranque en frío existe, y para latencia estricta con humanos esperando se configura un mínimo de instancias calientes — que ya no es cero costo. La física no cambió; cambió el default.
• Jobs: la cara que AWS llamaría tarea Fargate — un contenedor que corre hasta terminar (hasta 7 días por tarea, si hace falta), sin puerto HTTP, disparado a demanda o por Cloud Scheduler. El agente reactivo largo (investigar y redactar la cotización) y el lote nocturno viven aquí. Con reintentos y paralelismo (N ejecuciones del mismo job sobre una lista de trabajo) incluidos.
• Functions: las Cloud Run functions son funciones-como-servicio montadas sobre el mismo motor — conveniencia de función (solo código, sin Dockerfile) con la mecánica de Run debajo. Sin el muro de los 15 minutos de Lambda con el que peleamos en AWS: los límites de duración son los de Run (hasta 60 minutos por petición). La elección function-vs-contenedor queda en empaque y control del entorno, no en duración.

     ¿DÓNDE CORRE EL AGENTE EN GCP?

START ──► ┌──────────────────────┐
          │ ¿atiende peticiones  │
          │ o ejecuta tareas?    │
          └─────┬──────────┬─────┘
   peticiones   │          │   tareas
                ▼          ▼
        ┌────────────┐  ┌────────────┐
        │ Cloud Run  │  │ Cloud Run  │
        │ service    │  │ job        │
        │ (escala a  │  │ (nace,     │
        │ cero solo) │  │ trabaja,   │
        └────────────┘  │ muere)     │
                        └────────────┘
   GKE: solo por razón organizacional
   Batch: lotes masivos con colas propias

Lo que no cambió (y conviene decir rápido)

• GKE es EKS con otra insignia: se elige por razones organizacionales (equipo Kubernetes, portabilidad exigida), nunca por prestigio. Si dudas, Cloud Run llega igual de lejos con una fracción de la operación — el argumento completo está en el módulo de AWS y no envejece al cruzar.
• La espera se diseña fuera del cómputo: colas, scheduler y Workflows esperan gratis; un contenedor vivo mirando el reloj es el mismo anti-patrón en cualquier nube.
• Estado externo, cómputo desechable: el principio rector del módulo 6, idéntico.
• La identidad viaja con el cómputo: cada service y cada job corre con su service account del módulo 2 adjunta — el equivalente exacto del execution role.

Ojo — el scale-to-zero no es gratis semánticamente: que el service escale a cero invita a usarlo para todo, incluidas tareas que no atienden a nadie. Resiste: una tarea disfrazada de service (disparada con un HTTP interno “para que corra”) pierde los reintentos, el paralelismo y la semántica de terminación de los jobs, y gana timeouts de petición que no pidió. La pregunta del diagrama — ¿peticiones o tareas? — se responde por la naturaleza del trabajo, no por comodidad de despliegue.

Errores comunes

• Tareas disfrazadas de services. El lote nocturno invocado por HTTP “porque ya teníamos el service” — pierde reintentos y semántica de job, gana timeouts ajenos. Jobs para tareas, services para tráfico.
• Pelear contra el frío en vez de configurarlo. Si hay humanos esperando y el arranque duele, instancias mínimas calientes — es un dial, no un defecto. Para agentes autónomos, el frío es irrelevante y el dial se queda en cero.
• GKE por prestigio. El mismo error, la misma respuesta: razón organizacional o Cloud Run.
• Traducir Lambda→function por reflejo. Sin el muro de 15 minutos, la función GCP compite con el contenedor solo en empaque. Muchos “Lambdas” de AWS son, en GCP, el mismo contenedor del resto de la plataforma — un artefacto menos que mantener.
• Ignorar el paralelismo de los jobs. Procesar 10.000 llamadas repartidas en N ejecuciones paralelas del mismo job es capacidad incluida; redescubrirla con orquestación artesanal es trabajo regalado.

La frase para llevarse

“En GCP la decisión de cómputo es una pregunta: ¿peticiones o tareas? Services que escalan a cero para lo primero, jobs que nacen y mueren para lo segundo, y el mismo mantra de siempre: la espera fuera del cómputo, el estado fuera del contenedor, la identidad adjunta.”

Qué viene

Módulo 4: redes. La topología no cambia — privado por defecto, egress como lista corta — pero GCP trae dos diferencias con consecuencias: la VPC es global (una red que cruza regiones, donde en AWS tenías una por región), y el acceso privado a los servicios de Google tiene sus propias piezas (Private Google Access, Private Service Connect). Más la versión GCP del guardrail anti-exfiltración.

Material relacionado

• Módulo 2: identidad y service accounts
• Módulo 4: redes en GCP
• Curso de AWS — Módulo 3: cómputo para agentes
• Glosario de Arquitectura GCP para Agentes de IA