En 02-07 se escribió una decisión y se dejó pendiente. DA-001: el catálogo web de AlpinaShop debe pasar a Cloud Run. Se justificó con una tabla, se firmó, y se guardó en el README de alpinashop-catalogo. Desde entonces el curso ha vuelto a ella una docena de veces —en el balanceador de 03-02, en los secretos de 03-06, en Pub/Sub push de 04-04, en Cloud Functions de 06-03, en el agente de operaciones de 06-04— siempre con la misma coletilla: "en 07-02".

Esta es 07-02. Aquí se cumple.

No es un capricho de coherencia narrativa: es que hasta ahora no estaban las condiciones. Mover el catálogo de producción a otra plataforma sin un pipeline que construya imágenes reproducibles, sin observabilidad para saber si ha ido bien, sin infraestructura como código para revertir y sin un balanceador delante que absorba el cambio, es una temeridad. Con las cuatro cosas hechas —módulos 3 y 6— el movimiento es una tarde de trabajo con red de seguridad.

Al terminar la lección, el catálogo de AlpinaShop servirá desde Cloud Run, detrás de la misma IP, el mismo dominio, el mismo certificado, la misma CDN y el mismo WAF que tenía; habrá pasado por un despliegue canario al 10 %; el MIG alpinashop-web-mig estará apagado; y la factura de cómputo del catálogo habrá bajado de unos 50 € al mes a menos de 10. Y sabrás por qué la concurrencia es el parámetro que más gente configura mal.

1. Qué es Cloud Run y por qué importa el contrato del contenedor
2. Servicios y trabajos (jobs): el criterio para elegir
3. Desplegar el catálogo: gcloud run deploy bandera a bandera
4. El mismo servicio en Terraform
5. Revisiones y reparto de tráfico: canario, etiquetas y reversión
6. Concurrencia: el concepto que más se malinterpreta
7. Escalado: cero, mínimo, máximo y el modelo de facturación de CPU
8. Conectar Cloud Run con el resto de la plataforma
9. Identidad y seguridad del servicio
10. Detrás del balanceador global: el NEG sin servidor
11. La migración desde el MIG, paso a paso y sin corte
12. Coste: el modelo y el cálculo comparado
13. Límites y cuándo Cloud Run no encaja
14. La tabla madura: Cloud Run vs Functions vs GKE vs Compute Engine
15. Apagar alpinashop-web-mig y lo que eso simplifica

Cloud Run ejecuta contenedores sin servidor. Le das una imagen, te da una URL HTTPS, y escala de cero a muchas instancias según el tráfico, cobrando por lo que uses.

Dicho así suena a App Engine con otro nombre, y no lo es. La diferencia está en la unidad de despliegue:

Que la unidad sea un contenedor estándar es lo que hace a Cloud Run distinto y lo que resolvió el punto más delicado de DA-001: la portabilidad. La misma imagen que corre hoy en alpinashop-cluster correrá mañana en Cloud Run sin tocar una línea. Y si algún día hiciera falta salir, esa imagen corre en cualquier sitio donde haya un runtime de contenedores.

Cloud Run no ejecuta cualquier imagen de cualquier manera: exige cumplir un contrato, y es deliberadamente corto.

Esas seis líneas son todo. No hay que aprender ningún formato de despliegue nuevo, y esa es la razón por la que Cloud Run se ha convertido en la opción por defecto para aplicaciones web en Google Cloud.

Dos errores frecuentes contra el contrato, dichos ya:

El primero produce el error más común de los principiantes en Cloud Run: "The user-provided container failed to start and listen on the port defined provided by the PORT environment variable". Cuando lo veas, ya sabes qué mirar.

Tres conceptos que hay que fijar desde ya:

• Servicio: la entidad estable, con nombre y URL. alpinashop-web.
• Revisión: una versión inmutable del servicio (imagen + configuración). alpinashop-web-00042-abc. No se modifica nunca: cada cambio crea una revisión nueva.
• Instancia: un contenedor en ejecución de una revisión. Nacen y mueren solas.

La inmutabilidad de las revisiones es lo que hace posible el reparto de tráfico y la reversión instantánea del apartado 5.

Cloud Run tiene dos formas de ejecutar un contenedor, y elegir mal es una fuente clásica de arquitecturas raras.

La regla de decisión, en una frase:

Si algo responde a alguien, es un servicio. Si algo hace una cosa y termina, es un trabajo.

Aplicado a AlpinaShop:

El antipatrón clásico —y se ve mucho— es montar el informe nocturno como un servicio con un endpoint /ejecutar-informe que llama Cloud Scheduler. Funciona, pero: tienes un endpoint HTTP que hay que proteger, la ejecución está limitada por el tiempo máximo de petición, no hay reintentos integrados, y si tarda de más el proceso se corta a mitad. Un trabajo elimina los cuatro problemas.

Un trabajo real de AlpinaShop, el informe nocturno de 04-06:

Y su ejecución desde Cloud Scheduler, sin exponer ningún HTTP propio:

Nótese --time-zone="Europe/Madrid": sin ella, el 30 3 * * * es UTC y el informe se ejecutará a las 5:30 en verano. Es un error que se descubre en marzo o en octubre y desconcierta durante horas.

La imagen del catálogo ya está en Artifact Registry desde 06-01, construida por Cloud Build y etiquetada con $COMMIT_SHA. Solo falta desplegarla. Este es el comando completo de AlpinaShop, y a continuación cada bandera explicada.

Las dos últimas son las que convierten un despliegue en un despliegue seguro, y merecen su propio apartado.

AlpinaShop gestiona su infraestructura con Terraform desde 06-07, así que el comando anterior es para experimentar: lo que va a main es HCL.

Cuatro observaciones importantes sobre este HCL:

1. Usa google_cloud_run_v2_service, no google_cloud_run_service. El recurso v1 sigue existiendo por compatibilidad y su sintaxis (basada en anotaciones de Knative) es mucho peor. Todo lo nuevo va en v2.
2. cpu_idle = true es el equivalente a --cpu-throttling: la CPU solo se factura durante las peticiones. false significa CPU siempre activa, y es hasta cuatro veces más caro.
3. startup_cpu_boost = true da CPU adicional durante el arranque. Reduce el arranque en frío entre un 20 % y un 50 % en aplicaciones con inicialización pesada (JVM, frameworks grandes), y solo se paga ese medio segundo.
4. ingress = "INGRESS_TRAFFIC_INTERNAL_LOAD_BALANCER" es la pieza de seguridad: nadie puede llegar al servicio por su URL *.run.app. Solo entra tráfico desde el balanceador global.

Y hay una tensión que conviene resolver explícitamente, porque es la pregunta que todo el mundo se hace al llegar aquí: si el despliegue lo hace el pipeline, ¿qué gestiona Terraform?

Es exactamente la regla de 06-07: Terraform gestiona la forma, no el contenido. En la práctica se resuelve con lifecycle { ignore_changes = [template[0].containers[0].image, traffic] } en el recurso, para que Terraform no intente devolver la imagen a la versión de su fichero cada vez que corre.

Aquí está una de las mejores capacidades de Cloud Run, y es prácticamente gratis.

Al desplegar con --no-traffic --tag=candidata, Cloud Run crea la revisión y le asigna una URL propia:

Esa URL apunta solo a esa revisión, con cero tráfico de producción. Sirve para:

• Probar la versión nueva contra la base de datos real, sin que ningún cliente la vea.
• Pasar las pruebas de humo automáticas del pipeline.
• Enseñársela a alguien antes de publicarla.

Si la prueba pasa, se le da un porcentaje pequeño de tráfico real:

A partir de ese momento, una de cada diez peticiones va a la revisión nueva. Se observa durante veinte o treinta minutos en el panel de 06-04 —tasa de error, latencia p95, errores en Error Reporting— y se decide.

Progresión completa recomendada:

Y esta es la parte que cambia cómo se duerme por las noches. Si la revisión nueva falla:

Tarda segundos y no reconstruye ni redespliega nada, porque la revisión anterior sigue existiendo íntegra. Compárese con el MIG: había que crear una plantilla de instancia nueva, lanzar una actualización progresiva y esperar a que las VM se sustituyeran una a una — entre cinco y quince minutos, con el sitio degradado mientras tanto.

Consejo operativo: ten el comando de reversión escrito en el runbook (07-06) con el número de revisión rellenado como variable. A las tres de la madrugada nadie recuerda la sintaxis de --to-revisions.

1. El canario no protege contra cambios de esquema de base de datos. Si la revisión nueva hace ALTER TABLE, el 90 % que sigue en la vieja también ve la tabla cambiada. Las migraciones de esquema deben ser compatibles hacia atrás (añadir columnas, nunca renombrarlas en el mismo despliegue), y ejecutarse como un trabajo aparte.
2. Con poco tráfico, el 10 % no significa nada estadísticamente. Si AlpinaShop recibe 30 peticiones por minuto fuera de campaña, el 10 % son 3 peticiones. Un canario que no ve errores durante 20 minutos con 60 peticiones no ha demostrado gran cosa. En volúmenes bajos conviene subir el porcentaje y alargar el tiempo, o hacer el canario en horas de más tráfico.

Si te llevas un solo apartado de esta lección, que sea este.

Concurrencia es el número máximo de peticiones que Cloud Run envía simultáneamente a una misma instancia antes de arrancar otra.

El valor por defecto es 80. Y aquí está la fuente de todos los malentendidos: mucha gente llega a Cloud Run desde Cloud Functions o desde AWS Lambda, donde el modelo es una petición por instancia, y asume que Cloud Run funciona igual. No.

La clave está en la penúltima fila. Una petición típica del catálogo de AlpinaShop pasa así sus 200 ms:

El 85 % del tiempo la CPU no hace nada: espera a la base de datos. Con --concurrency=1, pagas una vCPU entera para que esté ociosa 170 ms de cada 200. Con --concurrency=80, esa misma vCPU atiende a otras peticiones durante esa espera.

La concurrencia correcta no se adivina, se mide. El procedimiento:

Paso 1 — Averiguar el modelo de concurrencia de tu aplicación. Es lo primero y casi nadie lo comprueba:

El error más caro de todos: poner --concurrency=80 en un servidor que solo procesa una petición a la vez. Cloud Run le manda 80, el servidor las encola, y las peticiones 2 a 80 esperan su turno. La latencia se dispara y parece un problema de la plataforma. Es un problema de configuración del servidor de aplicaciones.

Para el catálogo de AlpinaShop, que es Flask, el Dockerfile termina así:

--timeout 0 desactiva el temporizador de Gunicorn porque el tiempo de espera lo gobierna Cloud Run con --timeout=60s. Tener dos temporizadores compitiendo produce cortes inexplicables.

Paso 2 — Prueba de carga con distintos valores. Se despliegan revisiones con etiqueta y se mide cada una:

Y con una herramienta de carga (hey, k6, vegeta) contra cada URL etiquetada. Resultados reales del catálogo, con 50 peticiones por segundo sostenidas durante 5 minutos:

Lectura de la tabla, que es donde está el aprendizaje:

• De 1 a 80, la latencia p50 apenas sube (190 → 210 ms) y el coste se divide por doce. Regalo evidente.
• De 80 a 160 la latencia se dispara: se han superado los 80 hilos reales de Gunicorn y las peticiones se encolan. El techo no lo pone Cloud Run, lo pone tu aplicación.
• El p95 se degrada antes que el p50. Por eso se mide el p95: es donde se ve el sufrimiento antes de que sea evidente.

Paso 3 — Ajustar CPU y memoria a la concurrencia elegida. Son parámetros acoplados:

• Con concurrencia 80, la instancia necesita memoria para 80 peticiones simultáneas. Si cada una consume 4 MiB de estructuras, son 320 MiB solo de peticiones, más el runtime.
• Si la aplicación es intensiva en CPU, la concurrencia alta hace que las peticiones compitan por la misma vCPU. Ahí se sube CPU o se baja concurrencia.

La señal de que la memoria se queda corta es inconfundible en los logs:

Cuando eso ocurre, la instancia muere y las peticiones en curso se pierden. Es de los pocos fallos de Cloud Run que se manifiestan como errores 5xx sin traza de la aplicación.

Sin tráfico, Cloud Run apaga todas las instancias y no cobra nada. Es la propiedad que hace que un entorno de desarrollo cueste céntimos.

El precio de esa propiedad es el arranque en frío (cold start): la primera petición tras un periodo de inactividad tiene que esperar a que se cree una instancia, se descargue la imagen y arranque la aplicación.

Números orientativos de arranque en frío completo: un binario de Go en una imagen distroless de 15 MB arranca en unos 300 ms; una aplicación Python con muchas dependencias, en 1-3 s; una JVM con Spring Boot sin ajustar, entre 8 y 20 s. La diferencia la marca la imagen y el runtime, no Cloud Run.

Mantiene N instancias siempre vivas. La instancia inactiva se factura a una tarifa reducida —del orden de la décima parte de la activa—, así que una instancia mínima es barata: unos pocos euros al mes.

Criterio para AlpinaShop:

Advertencia importante: --min-instances reduce mucho los arranques en frío, pero no los elimina. Si el tráfico sube de golpe, hay que crear instancias nuevas y esas arrancan en frío igualmente. Y hay un detalle contraintuitivo: con CPU limitada a las peticiones (cpu_idle=true), las instancias mínimas tienen la CPU congelada entre peticiones, así que si tu aplicación hace algo periódico en segundo plano, no se ejecutará.

Esto es protección, y hay que ponerlo siempre. Dos motivos:

1. Coste. Un bucle infinito en el código, un rastreador agresivo o un ataque pueden lanzar cientos de instancias. Sin techo, la factura del día es un incidente.
2. Dependencias aguas abajo. Cloud SQL tiene un límite de conexiones. Si cada instancia abre 5 conexiones y arrancan 200 instancias, son 1000 conexiones contra una base de datos que admite 100: Cloud Run escala perfectamente y tumba la base de datos.

La fórmula para elegirlo:

Para AlpinaShop: Cloud SQL admite ~100 conexiones útiles, el pool por instancia es de 3 → 33 instancias. El pico esperado en campaña son 20 req/s, con concurrencia 80 → menos de 1 instancia, con margen ×5 para picos bruscos → 5. Se elige 30: cómodo para el tráfico, por debajo del límite de la base de datos.

Cuando se alcanza el máximo, Cloud Run no rechaza: encola las peticiones y las va sirviendo, y solo devuelve 429 si la cola se satura. Es un comportamiento amable, pero conviene tener una alerta:

Para el catálogo, --cpu-throttling es lo correcto: entre peticiones no hay nada que hacer. La trampa clásica es lanzar un hilo en segundo plano para "enviar métricas cada 30 segundos" y descubrir que no se ejecuta nunca. Con CPU congelada, ese hilo se para.

Un servicio aislado no vale nada. Estas son las cinco conexiones de AlpinaShop.

Cloud Run monta un socket Unix en /cloudsql/<nombre-de-conexión> que habla con la instancia por un canal cifrado, sin IP pública y sin abrir firewall. La cadena de conexión de la aplicación:

Las cuatro opciones del pool no son decorativas:

• pool_size=3: recuérdese la fórmula de --max-instances. Un pool de 20 por instancia es la receta para agotar la base de datos.
• max_overflow=0: impide que el pool abra conexiones adicionales bajo carga, que es justo cuando no te lo puedes permitir.
• pool_pre_ping=True: imprescindible en Cloud Run. Una instancia con la CPU congelada durante minutos vuelve con conexiones muertas; sin pre-ping, la primera petición tras la pausa falla.
• pool_recycle=1800: recicla conexiones cada media hora antes de que las corte el servidor.

La alternativa moderna es conectar por IP privada a través de la VPC (siguiente punto), que evita el conector y da menos latencia. Es lo que AlpinaShop hará cuando la red esté ordenada en 07-03.

La aplicación lee os.environ["DB_PASSWORD"] y no sabe que viene de Secret Manager. Alternativa, montarlo como fichero:

Diferencia práctica que conviene conocer: una variable de entorno se lee una vez al arrancar la instancia; un fichero montado se puede releer. Si rotas un secreto, las instancias vivas con variable de entorno siguen usando el valor viejo hasta que se reemplacen. Con :latest y ficheros, la rotación se propaga sola.

Y la contrapartida: usar :latest significa que una rotación mal hecha rompe el servicio sin que nadie despliegue nada. Para secretos críticos, fijar la versión (:7) y actualizarla en un despliegue controlado es más seguro.

Por defecto, el tráfico saliente de Cloud Run va a internet. Para llegar a recursos con IP privada —una réplica de Cloud SQL, Memorystore, o el ERP de Sabadell al otro lado del túnel de 07-03— hay que conectar el servicio a la VPC:

Esto es VPC directa (Direct VPC egress), que sustituye al antiguo conector de acceso a VPC sin servidor (Serverless VPC Access connector):

Si encuentras documentación que habla de conectores, es anterior. VPC directa es lo que hay que usar hoy.

El valor de --vpc-egress decide qué sale por la VPC:

En 04-04 se dijo que el modelo push encaja con Cloud Run. Así se conecta, sin abrir el servicio a nadie:

Lo esencial es --push-auth-service-account: Pub/Sub firma cada entrega con un token OIDC de esa cuenta. El servicio, que está en --no-allow-unauthenticated, solo acepta la petición si esa cuenta tiene roles/run.invoker:

Ningún secreto compartido, ninguna cabecera mágica, ninguna comprobación en el código. La plataforma valida el token antes de que la petición llegue a tu contenedor.

Eventarc entrega a Cloud Run eventos de más de un centenar de servicios de Google Cloud, con el formato estándar CloudEvents:

La relación con lo ya visto: Cloud Functions 2ª generación (06-03) está construida sobre Cloud Run y Eventarc. La función procesar-imagen-producto es, por debajo, un servicio de Cloud Run con un disparador de Eventarc. Saberlo explica por qué comparten límites, opciones de escalado y modelo de facturación.

Cuatro decisiones, todas coherentes con el módulo 3.

1. Cuenta de servicio propia y mínima. sa-catalogo-web tiene exactamente lo que necesita y nada más:

Si no se especifica --service-account, Cloud Run usa la cuenta de servicio por defecto de Compute Engine, que históricamente tiene el rol Editor sobre todo el proyecto. Desplegar así es dar a tu aplicación web permiso para borrar la base de datos. Es el fallo de seguridad más común de todo Cloud Run.

2. --no-allow-unauthenticated. El servicio exige un token de identidad válido de alguien con roles/run.invoker. Quién puede invocarlo:

3. Control de entrada (ingress). Es distinto de la autenticación y complementario:

Con internal-and-cloud-load-balancing, la URL *.run.app deja de responder desde fuera. Todo el tráfico de clientes tiene que pasar por Cloud Armor y la CDN, sin excepción. Esto es lo que impide el atajo de "voy a probar directamente contra run.app", que es el agujero por el que se salta el WAF.

4. IAP para servicios internos. El panel de administración interno se publica con el mismo patrón de 03-04: balanceador + IAP + Cloud Run privado. Los empleados entran con su cuenta de Google, sin VPN y sin usuarios propios.

En 03-02 se montó el balanceador global de AlpinaShop y se dejó dicho que el día que el catálogo fuera a Cloud Run bastaría con cambiar el backend. Ese día ha llegado.

Un NEG sin servidor (serverless network endpoint group) es un backend que apunta a un servicio de Cloud Run, App Engine o Cloud Functions en lugar de a un grupo de instancias.

Todo lo azul del diagrama —IP, certificado, WAF, mapa de URL, CDN— no se toca. Solo cambia lo verde.

Creación del NEG:

Y su incorporación al servicio de backend existente:

Cuatro particularidades del NEG sin servidor que hay que conocer, porque son distintas de todo lo visto en 03-02:

1. No hay comprobaciones de estado. El servicio de backend con NEG sin servidor no usa hc-catalogo. La salud la gestiona Cloud Run. Al principio desconcierta; es correcto.
2. No hay modo de balanceo ni capacidad. No existen max-rate-per-instance ni capacity-scaler: Cloud Run escala solo.
3. El NEG es regional, aunque el balanceador sea global. Para servir desde varias regiones se crean varios NEG, uno por región, y se añaden al mismo servicio de backend — que es exactamente cómo se hace la alta disponibilidad multirregión de 07-06.
4. La CDN sigue funcionando igual. Las cabeceras Cache-Control que emite Cloud Run gobiernan la caché exactamente como lo hacían las del MIG (03-03).

Este es el procedimiento real que ejecutó Marta. Está escrito para poder seguirlo, y su virtud es que en ningún momento hay un punto sin retorno.

Y una lista de comprobación previa que evita el 90 % de los sustos:

• [ ] La aplicación escucha en $PORT y en 0.0.0.0.
• [ ] No escribe nada importante en disco local.
• [ ] No guarda sesiones en memoria (las de AlpinaShop están en Firestore desde 02-06).
• [ ] Los logs van a stdout/stderr en JSON estructurado (06-06).
• [ ] Gunicorn está configurado con hilos suficientes para la concurrencia elegida.
• [ ] El pool de conexiones es pequeño y tiene pool_pre_ping.
• [ ] No hay hilos de fondo que dependan de CPU entre peticiones.

El servicio existe, funciona contra la base de datos real y ningún cliente lo ve. Aquí se hacen las pruebas de humo y se compara la latencia con la del MIG.

Se crea el NEG y se añade al servicio de backend bs-catalogo-web, que ahora tiene dos backends: el MIG y Cloud Run. El balanceador reparte entre ellos según capacidad.

Para controlar el reparto con precisión, AlpinaShop usa la técnica del capacity-scaler sobre el backend del MIG:

Se va reduciendo la capacidad del MIG, lo que empuja tráfico hacia Cloud Run:

En cada escalón se miran las mismas cuatro cosas en el panel de 06-04, y se comparan por backend:

La métrica de conexiones a Cloud SQL es la que más sorpresas da, y es el motivo por el que el trasvase se hace en horas y no en minutos.

Durante 24-72 horas el MIG sigue existiendo con capacity-scaler=0.0: no recibe tráfico pero está encendido. La reversión es un solo comando:

Y en segundos vuelve todo al MIG. Pagar dos días de VM apagada de tráfico es el precio de dormir tranquilo, y es un precio ridículo.

Solo cuando han pasado los tres días y se ha atravesado al menos un pico de tráfico:

El paso 2 es importante: reducir a cero antes de borrar. Un MIG de tamaño cero no cuesta cómputo, conserva su plantilla, y volver a levantarlo es un resize. El borrado definitivo se hace desde Terraform, porque si se hace a mano el siguiente plan intentará recrearlo.

Cloud Run cobra tres cosas, y solo mientras hay instancias vivas:

Y hay un nivel gratuito mensual generoso —del orden de 180.000 vCPU-s, 360.000 GiB-s y 2 millones de peticiones— que hace que muchos proyectos pequeños cuesten literalmente cero.

Los precios cambian y varían por región. Consulta siempre la página de precios oficial y la calculadora. Lo que sigue son órdenes de magnitud para razonar, no un presupuesto.

Escenario: 1,5 millones de peticiones al mes, latencia media 200 ms, 1 vCPU, 512 MiB, concurrencia 80, min-instances=1, CPU limitada a la petición.

Tiempo de instancia activa. Con concurrencia 80, las peticiones se solapan. Una estimación conservadora del tiempo con al menos una petición en vuelo, a partir de la distribución horaria real, da unas 28 horas al mes de actividad ≈ 100.000 vCPU-s.

Comparación con lo que se venía pagando, usando las cifras de 02-07:

Ahorro: unos 47 €/mes, un 63 % del coste de la tienda. Y esa es la parte pequeña. Las 2-4 horas mensuales de Marta valen más que los 47 €, y el tiempo de reversión pasa de 10 minutos a 5 segundos.

Pero hay que decir la verdad completa, porque este curso no vende:

• Si el tráfico fuera constante y alto las 24 horas, el MIG con descuento por uso comprometido sería más barato. Cloud Run gana con tráfico irregular, que es el caso de AlpinaShop, no todos los casos.
• En campaña de otoño la factura de Cloud Run sube, porque se paga el uso. Es lo correcto —se paga cuando se vende— pero significa que la factura ya no es plana. Se planifica en 07-05.
• El balanceador global sigue costando lo mismo y ahora representa el 74 % de la factura del catálogo. Es lo que pasa cuando se optimiza bien: el mayor coste se desplaza a otra parte.

Los límites que hay que conocer antes de decidir (verifícalos en la documentación, cambian a mejor con el tiempo):

Y los escenarios donde Cloud Run no es la respuesta:

En 02-07 se hizo esta comparación con la información de entonces. Ahora, con seis módulos más de recorrido, se puede hacer con criterio de verdad.

Las cuatro preguntas que resuelven casi todas las decisiones, en este orden:

1. ¿Es un contenedor HTTP sin estado con tráfico irregular? → Cloud Run. Es el caso mayoritario.
2. ¿Es una reacción a un evento único, de código breve? → Cloud Functions (que por debajo es Cloud Run).
3. ¿Hay muchos servicios que se llaman entre sí, con estado, DaemonSets u operadores? → GKE.
4. ¿Necesitas el sistema operativo, disco local, licencias atadas o protocolos no HTTP? → Compute Engine.

Y la observación que cierra el continuo de abstracción de 02-07: la respuesta correcta para AlpinaShop resultó ser el escalón que no se había probado. Se pasó por VM, por App Engine y por Kubernetes antes de llegar a la opción que encajaba. Eso no fue tiempo perdido: fue cómo se adquirió el criterio para decidir.

La lista de cosas que dejan de existir al retirar el MIG es más larga de lo que parece, y es el argumento más fuerte a favor del movimiento:

Diez elementos menos que mantener, entender, documentar y explicar a quien venga después. Para una empresa con una persona de infraestructura, esa reducción vale más que el ahorro económico.

Lo que sí hay que seguir haciendo, para que nadie se confunda:

• Actualizar la imagen base del Dockerfile y reconstruir. Cloud Run parchea el sandbox, no tu contenedor.
• Vigilar las vulnerabilidades de la imagen en Artifact Registry (07-04).
• Gestionar migraciones de esquema de la base de datos.
• Todo lo relacionado con la aplicación en sí.

La arquitectura de cómputo de AlpinaShop queda, por fin, así:

No queda ni una máquina virtual en la ruta de servicio de la tienda. Y alpinashop-cluster queda sin cargas de producción: se conserva como entorno de pruebas de contenedores y para lo que pueda venir, con una nota en DA-004 para revisar si merece la pena mantenerlo.

• Escuchar en un puerto fijo o en 127.0.0.1. Es el error número uno. Lee $PORT y escucha en 0.0.0.0.
• Desplegar sin --service-account. Heredas la cuenta por defecto de Compute Engine, que suele tener Editor sobre el proyecto. Tu web tendría permiso para borrar la base de datos.
• Poner --concurrency=80 con un servidor de un solo hilo. Las peticiones se encolan dentro del contenedor y la latencia se dispara. Configura Gunicorn, Uvicorn o lo que uses antes de tocar la concurrencia.
• No poner --max-instances. Un bucle infinito o un rastreador te crea cientos de instancias, y además tumba Cloud SQL por agotamiento de conexiones.
• Pool de conexiones grande. pool_size=20 × 30 instancias = 600 conexiones contra una base de datos que aguanta 100. Pool pequeño, max_overflow=0 y pool_pre_ping=True.
• Guardar algo en el sistema de ficheros y esperar encontrarlo. El disco es efímero y vive en memoria: escribir un fichero de 300 MiB consume 300 MiB de tu límite de memoria.
• Lanzar hilos en segundo plano con CPU limitada a la petición. No se ejecutan. O usas CPU siempre activa, o mueves ese trabajo a un job o a Cloud Scheduler.
• Usar la URL *.run.app como URL pública del producto. Cambia si recreas el servicio, se salta Cloud Armor y la CDN, y no es tu dominio. Balanceador siempre.
• Confundir autenticación con ingress. --no-allow-unauthenticated dice quién puede invocar; ingress dice por dónde puede llegar. Hacen falta los dos.
• Desplegar con latest. Pierdes la trazabilidad de qué versión corre y la reversión deja de ser fiable. Etiqueta con $COMMIT_SHA.
• Creer que el canario protege de todo. No protege de cambios de esquema de base de datos ni sirve de nada con tráfico bajo.
• Olvidar --timeout 0 en Gunicorn. Dos temporizadores compitiendo producen cortes que parecen aleatorios.
• Consejo: mide la concurrencia con una prueba de carga real antes de fijarla. Es el parámetro con mayor impacto conjunto en coste y latencia.
• Consejo: usa --tag en cada despliegue, aunque no hagas canario. Tener una URL por revisión es útil para depurar y no cuesta nada.
• Consejo: activa startup_cpu_boost. Es gratis en la práctica y reduce el arranque en frío de forma apreciable en runtimes pesados.
• Consejo: la imagen pequeña es la mejor optimización de arranque en frío. Una imagen distroless o alpine bien hecha arranca mucho antes que una ubuntu con medio sistema dentro.

AlpinaShop va a desplegar en Cloud Run un servicio nuevo: alpinashop-buscador, una API de búsqueda del catálogo.

Datos medidos en el entorno de desarrollo:

• Escrito en Python con FastAPI + Uvicorn (asíncrono, un solo proceso).
• Cada petición: 15 ms de CPU (tokenizar y puntuar) + 120 ms esperando a Elasticsearch.
• Consumo de memoria: 180 MiB en reposo + ~2 MiB por petición en vuelo.
• Tráfico: 5 peticiones/segundo de media, 40 peticiones/segundo en campaña.
• Elasticsearch admite 200 conexiones concurrentes en total y lo comparte con otros dos servicios.
• Nadie tolera más de 800 ms de latencia p95.

Determina --concurrency, --cpu, --memory, --min-instances y --max-instances, justificando cada valor con los datos. Indica además qué cambiarías en el arranque de la aplicación.

Escribe los pasos de Cloud Build (cloudbuild.yaml) que implementan el despliegue canario del catálogo con estas reglas:

1. Construir la imagen etiquetada con $COMMIT_SHA.
2. Desplegar sin tráfico, con la etiqueta candidata.
3. Ejecutar una prueba de humo contra la URL de la etiqueta; si falla, abortar.
4. Dar el 10 % del tráfico.
5. Esperar 10 minutos y comprobar automáticamente que la tasa de error 5xx de la revisión nueva está por debajo del 1 %; si no, revertir a 0 % y fallar la compilación.
6. Solo entonces, esperar la aprobación manual de Marta para pasar al 100 %.

Indica también qué permisos necesita la cuenta de servicio del pipeline y por qué el paso 5 es el que más gente omite.

Tres horas después de mover el 70 % del tráfico a Cloud Run, Marta observa esto:

• La latencia p50 del backend de Cloud Run es de 210 ms; la del MIG, 195 ms. Aceptable.
• La latencia p99 de Cloud Run es de 4,2 segundos; la del MIG, 380 ms.
• En Cloud Logging aparecen unos 40 errores por hora: sqlalchemy.exc.OperationalError: server closed the connection unexpectedly.
• El número de instancias oscila entre 1 y 9 constantemente, con subidas y bajadas cada pocos minutos.
• cloudsql.googleapis.com/database/postgresql/num_backends ha pasado de 12 a 34.
• Error Reporting muestra 6 casos de Memory limit of 512 MiB exceeded.

Diagnostica cada síntoma, indica la causa raíz probable de cada uno, y escribe el plan de corrección ordenado por prioridad. Decide además si hay que revertir al MIG o se puede corregir en caliente.

Solución 1 — Elegir concurrencia, CPU, memoria e instancias

Punto de partida: el perfil de la petición. 15 ms de CPU frente a 120 ms de espera. La CPU trabaja el 11 % del tiempo. Es un servicio dominado por la E/S, exactamente el caso donde la concurrencia alta es rentable.

--concurrency. Tres restricciones a la vez, y hay que respetar la más estricta:

1. Por CPU: con 15 ms de CPU cada 135 ms totales, una vCPU podría sostener teóricamente unas 9 peticiones simultáneas antes de saturarse. Este es el límite duro.
2. Por Elasticsearch: 200 conexiones compartidas entre tres servicios, digamos 60 para el buscador. Si cada petición abre una conexión, concurrencia × instancias ≤ 60.
3. Por latencia: el presupuesto p95 es de 800 ms, y la petición base son 135 ms. Hay margen para algo de cola, pero no mucho.

Con 1 vCPU, poner concurrencia por encima de 9-10 hace que las peticiones esperen CPU. Se elige --concurrency=10. Y si se sube a --cpu=2, se podría ir a 20; con el tráfico de este servicio no compensa.

--cpu=1. Suficiente para la concurrencia elegida. Subir a 2 vCPU solo tiene sentido si se sube también la concurrencia, y el tráfico no lo justifica.

--memory=512Mi. Cálculo: 180 MiB de base + 10 peticiones × 2 MiB = 200 MiB, más el runtime de Python y margen. 512 MiB deja holgura de más del doble. Poner 256 MiB sería jugar con fuego, porque quedarse sin memoria mata la instancia, no ralentiza.

--max-instances. El pico son 40 req/s. Con 135 ms por petición y concurrencia 10, cada instancia sostiene unas 74 req/s en teoría; en la práctica, con margen, digamos 40-50. Bastarían 1-2 instancias. Pero el límite real lo pone Elasticsearch: 60 conexiones / 10 por instancia = 6 instancias. Se elige --max-instances=6, que cubre el pico con margen amplio y protege el backend compartido, que es el recurso escaso.

--min-instances=1. Un buscador es de cara al cliente y un arranque en frío de 1-2 s en la primera búsqueda de la mañana es visible y molesto. Una instancia mínima cuesta unos pocos euros al mes. En alpinashop-dev, 0.

Qué cambiar en el arranque. FastAPI con Uvicorn en un solo proceso es asíncrono, así que puede con varias peticiones simultáneas —pero solo si el código es realmente asíncrono. La comprobación crítica:

Este es exactamente el error del apartado 6 con otra cara: un async def que llama a una biblioteca síncrona no es concurrente, y la concurrencia 10 configurada en Cloud Run no sirve de nada.

Además: crear el cliente HTTP una vez al arrancar y reutilizarlo (no en cada petición, como en el ejemplo simplificado), y arrancar con uvicorn main:app --host 0.0.0.0 --port $PORT --workers 1 — un solo worker, porque el paralelismo lo da el bucle de eventos y Cloud Run añade instancias.

Solución 2 — Diseñar el despliegue seguro en el pipeline

El paso 6, la aprobación manual, no es un paso del cloudbuild.yaml: se configura en el disparador de Cloud Build con --require-approval, tal como se montó en 06-01 para producción. Cuando la compilación llega al final, queda a la espera de que Marta apruebe, y el paso al 100 % se hace en un disparador separado o manualmente con --to-latest.

Permisos de la cuenta de servicio del pipeline (sa-deploy-prod):

Nótese que no tiene roles/editor ni permisos sobre Cloud SQL o Secret Manager: despliega, no administra.

Por qué el paso 5 es el que casi todo el mundo omite. Porque es el único que requiere pensar. Los pasos 1-4 son mecánicos y salen en cualquier tutorial; el 5 exige decidir qué métrica, qué umbral, cuánto tiempo y qué hacer si no hay datos suficientes. Sin él, el canario es teatro: se despliega al 10 %, nadie mira, y a los diez minutos alguien pulsa "aprobar" porque no ha saltado ninguna alarma — que es distinto de que todo esté bien.

La comprobación de muestra mínima (TOTAL -lt 100) es la sutileza que separa un canario real de uno decorativo: con pocas peticiones, la ausencia de errores no demuestra nada, y fallar la compilación obliga a mirarlo en lugar de aprobar a ciegas.

Solución 3 — Diagnosticar una migración que va mal

Diagnóstico síntoma a síntoma.

(1) p50 correcto pero p99 de 4,2 s. El p50 sano descarta un problema general de rendimiento: la mayoría de peticiones van bien. Un p99 veinte veces peor con un p50 normal es la firma inconfundible del arranque en frío. El servicio se desplegó con --min-instances=0, o el tráfico es lo bastante irregular como para crear instancias constantemente. La confirmación está en el síntoma (4).

(2) server closed the connection unexpectedly, ~40/hora. Conexiones del pool que llevaban tiempo inactivas y que Cloud SQL, o la propia congelación de CPU de la instancia, ha dado por muertas. Es el caso exacto de pool_pre_ping: sin él, la primera consulta tras un periodo de inactividad usa una conexión zombi y falla. La causa raíz es falta de pool_pre_ping=True y de pool_recycle en la configuración de SQLAlchemy, agravada por la congelación de CPU entre peticiones que Cloud Run aplica y el MIG no aplicaba.

(3) Instancias oscilando entre 1 y 9 cada pocos minutos. Es la causa de (1), y a su vez tiene su propia causa. Con concurrencia 80 y el tráfico de AlpinaShop, una sola instancia debería bastar de sobra. Que suba a 9 significa que las instancias mueren y se recrean: eso lo explica el síntoma (6). Es un ciclo vicioso —muere por memoria, arranca en frío, atiende, vuelve a morir— que además genera parte de (2), porque cada muerte se lleva por delante las conexiones del pool.

(4) Conexiones a Cloud SQL de 12 a 34. Coherente con 9 instancias × pool de 3-4. No es un problema por sí mismo —34 está lejos del límite— pero confirma la aritmética y avisa: si el máximo de instancias estuviera mal puesto, aquí es donde se vería el desastre. Es un síntoma para vigilar, no para corregir.

(5) Seis casos de Memory limit exceeded. Esta es la causa raíz principal. 512 MiB no bastan para la concurrencia configurada. Las hipótesis, por probabilidad: la concurrencia es 80 y cada petición del catálogo consume más memoria de lo estimado (renderiza plantillas, carga imágenes en memoria); o hay una caché en proceso que crece sin límite; o la aplicación escribe ficheros temporales, que en Cloud Run cuentan como memoria.

Cadena causal completa:

¿Revertir o corregir en caliente?

No hay que revertir. El razonamiento: el 30 % del tráfico sigue en el MIG, el p50 es correcto, los errores son 40 a la hora sobre miles de peticiones (~0,5 %) y todas las causas son de configuración, no de código. Revertir costaría el resto del día y no aportaría información nueva. Ahora bien, sí hay que dejar de subir tráfico hasta que esté corregido, y tener el comando de reversión preparado por si algo empeora.

Si en lugar de esto los errores fueran del 10 %, o hubiera pérdida de pedidos, o el p50 estuviera degradado, la decisión sería la contraria: revertir primero, diagnosticar después. En un incidente, primero se para el daño.

Plan de corrección por prioridad:

El paso 6 es el que no hay que saltarse. Subir la memoria es la acción correcta ahora, porque para el sangrado. Pero si hay una fuga de memoria real —una caché que crece sin límite, por ejemplo— con 1 GiB simplemente tardará el doble en morir, y el problema reaparecerá en campaña con el peor momento posible. La diferencia entre resolver un incidente y aplazarlo es exactamente ese último paso, y es el que se cancela cuando todo vuelve a estar verde.

DA-001 está cumplida. El catálogo de AlpinaShop corre en Cloud Run, detrás de la misma IP, el mismo dominio, el mismo certificado, la misma CDN y el mismo WAF; el MIG está apagado; y no queda una sola máquina virtual en la ruta de servicio de la tienda.

Sabes qué es Cloud Run —contenedores sin servidor— y por qué la unidad de despliegue lo cambia todo: el contrato son seis reglas (escuchar en $PORT y en 0.0.0.0, hablar HTTP, arrancar rápido, no guardar estado, no hacer nada entre peticiones, ser un contenedor Linux sin privilegios) y cumplirlas hace que la misma imagen corra en Cloud Run, en Kubernetes o en tu portátil. Distingues servicio, revisión e instancia, y sabes que las revisiones son inmutables — que es lo que hace posible todo lo demás.

Tienes el criterio entre servicios y trabajos: si responde a alguien, servicio; si hace algo y termina, trabajo. Con el antipatrón identificado: el informe nocturno como endpoint HTTP disparado por Scheduler, que hereda cuatro problemas que un job no tiene.

Has desplegado el catálogo con gcloud run deploy bandera a bandera, sabiendo qué hace cada una y por qué tiene ese valor, y lo has escrito en Terraform con google_cloud_run_v2_service, con cpu_idle, startup_cpu_boost e ingress restringido al balanceador, y con la frontera clara de qué gestiona Terraform (la forma) y qué gestiona el pipeline (la imagen y el tráfico).

Dominas las revisiones y el reparto de tráfico: la etiqueta que da una URL propia para probar sin arriesgar, la progresión 0 → 10 → 50 → 100 con lo que se observa en cada escalón, y la reversión instantánea que tarda segundos porque la revisión anterior nunca dejó de existir. Con las dos advertencias honestas: el canario no protege de cambios de esquema, y con tráfico bajo el 10 % no demuestra nada.

Entiendes la concurrencia mejor que la mayoría: qué es, por qué el modelo de una petición por instancia es doce veces más caro para una carga dominada por E/S, cómo se mide con una prueba de carga real, y —lo más importante— que el techo no lo pone Cloud Run sino tu servidor de aplicaciones. Un --concurrency=80 sobre un Gunicorn de un worker síncrono, o un async def que llama a una biblioteca bloqueante, convierten la concurrencia en una cola invisible.

Sabes gobernar el escalado: el escalado a cero y su precio en arranques en frío, --min-instances que los mitiga pero no los elimina, --max-instances como cortafuegos de coste y de conexiones a la base de datos con su fórmula, y la elección entre CPU durante la petición y CPU siempre activa, con la trampa de los hilos en segundo plano que no se ejecutan.

Has conectado el servicio con toda la plataforma: Cloud SQL por conector con un pool pequeño y pool_pre_ping, Secret Manager montado como variable o como fichero con la diferencia práctica en la rotación, VPC directa —que sustituye al viejo conector— con sus dos modos de egress, Pub/Sub push con OIDC sin un solo secreto compartido, y Eventarc, con la revelación de que Cloud Functions 2ª generación es Cloud Run por debajo.

Has asegurado el servicio con las cuatro decisiones: cuenta de servicio propia y mínima —evitando el fallo más común, heredar la cuenta por defecto con Editor—, --no-allow-unauthenticated, ingress restringido al balanceador para que nadie pueda saltarse el WAF por la URL run.app, e IAP para lo interno.

Has hecho la migración sin corte: preparación con lista de comprobación, despliegue sin tráfico, NEG sin servidor añadido al balanceador existente, trasvase progresivo con capacity-scaler vigilando cuatro métricas, tres días de convivencia con reversión de un comando, y retirada en dos pasos con resize 0 antes del borrado desde Terraform. Y conoces las cuatro particularidades del NEG sin servidor: sin comprobaciones de estado, sin capacidad, regional aunque el balanceador sea global, y con la CDN funcionando igual.

Tienes el coste desmenuzado: vCPU-segundo, GiB-segundo y peticiones, con nivel gratuito, y el cálculo comparado que baja el cómputo del catálogo de unos 50 € a unos 7 € al mes — con la honestidad de señalar que con tráfico constante alto el MIG con compromiso ganaría, que en campaña la factura sube porque se paga el uso, y que ahora el balanceador es el 74 % de lo que cuesta la tienda. Conoces los límites y los siete escenarios donde Cloud Run no encaja. Y te llevas la tabla madura con las cuatro preguntas que resuelven casi cualquier decisión de cómputo.

Por último, has visto lo que desaparece al apagar el MIG: diez elementos —plantilla, script de arranque, parcheo, agente, autoescalado, actualizaciones progresivas, claves SSH, discos, instantáneas, reserva de campaña— que ya no hay que mantener, entender ni explicar. Para un equipo de una persona, eso vale más que el ahorro.

Y sin embargo, dos apartados de esta lección han dejado un cabo suelto que apunta al mismo sitio. La conexión a Cloud SQL sería mejor por IP privada a través de la VPC. Salir hacia la pasarela de pago con IP fija exige pasar por el Cloud NAT. Y el ERP de Sabadell, que DA-004 dejó al otro lado de un túnel que todavía no existe, necesita que Cloud Run pueda alcanzarlo por la red privada.

Los tres son el mismo problema: la red de AlpinaShop se quedó en lo básico en el módulo 3 y ya no basta. Una sola VPC en un solo proyecto, tres proyectos que se ignoran entre sí, ninguna conectividad con la tienda física y ningún perímetro que impida que los datos de alpinashop-datos salgan por la puerta. La siguiente lección lo resuelve: VPC compartida, emparejamiento, Private Service Connect, Cloud VPN HA hacia Sabadell y controles de servicio de VPC.