Google Cloud Run

Modelo

Recurso	Uso
Service	Contenedor que atiende HTTP/gRPC/WebSockets con URL propia
Revision	Snapshot inmutable de imagen + configuración; cada deploy crea una
Job	Tareas que se ejecutan hasta terminar (batch, migraciones)
Worker pool	Cargas continuas sin endpoint (consumidores de colas)

El tráfico se reparte entre revisiones por porcentaje o etiqueta, lo que permite canary y rollback sin redeploy.

Configuración que más impacta

Parámetro	Efecto y recomendación
Concurrencia	Peticiones simultáneas por instancia (por defecto 80). Bájala si la app usa mucha CPU por petición
min-instances	Evita arranques en frío; tiene coste aunque no haya tráfico
max-instances	Protege dependencias (base de datos) de un escalado excesivo
Facturación por petición / por instancia	Con CPU solo durante peticiones, el trabajo en segundo plano se congela
Startup CPU boost	Más CPU durante el arranque; útil para la JVM
Startup y liveness probes	Evitan enviar tráfico a instancias que no están listas
Egress VPC	Direct VPC egress o conector para alcanzar recursos privados

Despliegue gradual

# Desplegar una revisión sin enviarle tráfico, con etiqueta para probarla
gcloud run deploy api-solicitudes \
  --image us-east1-docker.pkg.dev/krediya/apps/api-solicitudes:1.8.0 \
  --region us-east1 --no-traffic --tag candidata

# Probar en https://candidata---api-solicitudes-xxxx.a.run.app y luego mover el 5 %
gcloud run services update-traffic api-solicitudes \
  --region us-east1 --to-tags candidata=5

# Promover o volver atrás
gcloud run services update-traffic api-solicitudes --region us-east1 --to-latest

Seguridad

• Una cuenta de servicio dedicada por servicio con permisos mínimos; nunca la de Compute por defecto.
• Secretos desde Secret Manager montados como variables o volúmenes.
• --no-allow-unauthenticated para servicios internos; invocación con IAM (roles/run.invoker).
• Ingress internal o internal-and-cloud-load-balancing y Cloud Armor delante del balanceador para servicios públicos.

Antipatrones frecuentes

• Pools de conexiones grandes por instancia con max-instances alto: agotan las conexiones de Cloud SQL.
• Hacer trabajo después de responder con facturación por petición: la CPU se limita y el trabajo no termina.
• Guardar estado en el sistema de archivos local: está en memoria y se pierde.

Jobs para procesos batch

gcloud run jobs create conciliacion-diaria \
  --image us-east1-docker.pkg.dev/krediya/apps/conciliacion:2.4.0 \
  --region us-east1 --tasks 10 --parallelism 5 --max-retries 2 \
  --task-timeout 30m --service-account sa-conciliacion@krediya.iam.gserviceaccount.com

gcloud run jobs execute conciliacion-diaria --region us-east1

Cada tarea recibe CLOUD_RUN_TASK_INDEX y CLOUD_RUN_TASK_COUNT, lo que permite repartir el trabajo (por ejemplo, una partición de clientes por tarea). Se programan con Cloud Scheduler y se usan también para migraciones de base de datos antes de un despliegue.

Conectividad privada

Necesidad	Opción
Cloud SQL, Memorystore o VMs en una VPC	Direct VPC egress (sin conector) o Serverless VPC Access connector
IP de salida fija (listas blancas de socios)	Egress por la VPC con Cloud NAT y dirección reservada
Servicio solo accesible internamente	Ingress internal + invocación con IAM
Exposición pública con WAF y dominio propio	Balanceador de carga externo + Cloud Armor + backend serverless

La IP de salida fija es un requisito habitual al integrarse con burós de crédito, bancos o pasarelas que filtran por IP.

Observabilidad incluida

• Logs de stdout/stderr en Cloud Logging; si se escriben en JSON, los campos (severity, trace) se indexan.
• Métricas de peticiones, latencia, instancias, CPU y memoria por revisión.
• Trazas en Cloud Trace con la cabecera traceparent propagada; añade OpenTelemetry para spans de la aplicación.
• Para revisar el estado de servicios, revisiones y errores recientes de todo un proyecto desde la terminal, scripts que combinan gcloud run services list y gcloud logging read dan una vista rápida sin entrar en la consola.

Costes

Palanca	Efecto
Concurrencia más alta	Menos instancias para el mismo tráfico (si la app lo soporta)
Facturación por petición	Sin coste en reposo; adecuada para tráfico irregular
Facturación por instancia	Más barata con tráfico constante; permite trabajo en segundo plano
min-instances	Elimina arranques en frío a cambio de coste fijo
CPU y memoria ajustadas a lo medido	Evita sobredimensionar
Descuentos por compromiso de uso	Para cargas estables

Checklist de un servicio listo para producción

• Cuenta de servicio dedicada con permisos mínimos y secretos en Secret Manager.
• Startup y liveness probes; apagado ordenado al recibir SIGTERM.
• max-instances coherente con las conexiones de la base de datos.
• Despliegue con --no-traffic y promoción gradual.
• Alertas sobre errores 5xx, latencia y SLO; logs estructurados.
• Definición en código y región(es) acordes con los requisitos de residencia de datos.

Criterios de implementación

Define todo como código (Terraform/OpenTofu) con una cuenta de servicio, alertas y SLO por servicio. Instrumenta con OpenTelemetry hacia Cloud Trace. Elige GKE cuando necesites sidecars complejos, cargas con estado, GPU con control fino o portabilidad de un estándar de Kubernetes.