Cloud Run o GKE: las cuatro preguntas que lo deciden

"Necesitamos Kubernetes porque vamos a escalar" es la frase más cara de la arquitectura cloud. Cloud Run escala a miles de instancias y baja a cero, así que la escala no es el eje. El eje es qué necesita tu carga que un contenedor con alcance de petición no puede darle.

Cuatro preguntas lo deciden, y puedes responder las cuatro esta tarde.

1. ¿Necesitas algo funcionando cuando no llega ninguna petición?

Consumidores en segundo plano, conexiones de larga vida, elección de líder, cachés en memoria que deben mantenerse calientes, crons que no pueden solaparse. Cloud Run ya tiene respuestas para algunas —jobs para lotes, un mínimo de instancias para el calor y CPU asignada durante toda la vida de la instancia y no solo durante las peticiones— pero cada respuesta cuesta un poco de la simplicidad que buscabas.

Si la respuesta honesta es "sí, bastante", estás describiendo un deployment, no un servicio, y GKE encaja mejor.

2. ¿Tu unidad de despliegue es un contenedor o un pod de varios?

Los sidecars son el factor decisivo silencioso. Proxies de service mesh, agentes de logs, refrescadores de credenciales, un proxy de Cloud SQL. Cloud Run admite varios contenedores por servicio, lo que cubre los casos comunes. Pero si tu equipo de plataforma ha construido una plantilla de pod opinada con cuatro sidecars y un conjunto de admission webhooks que la imponen, ya has construido una plataforma sobre Kubernetes, y pasar a Cloud Run significa reconstruirla.

3. ¿Necesitas primitivas de nivel clúster?

StatefulSets con volúmenes persistentes, DaemonSets, operadores propios, CRDs, afinidad de nodo para software con licencia, GPU con requisitos concretos de driver. Son funciones genuinas de Kubernetes sin equivalente en Cloud Run. Si las usas, la decisión está tomada.

Sé honesto sobre si las usas o solo las tienes. Un clúster cuyo único StatefulSet es un Redis que podrías sustituir por Memorystore no es un requisito de StatefulSet.

4. ¿Cuál es el presupuesto operativo de tu equipo?

Cloud Run no tiene nodos, ni actualizaciones, ni ajuste de autoescalador, ni CNI, ni controlador de ingress que parchear. GKE Autopilot quita parte de eso pero no el concepto de clúster, ni los manifiestos, ni la curva de aprendizaje de Kubernetes. Para un equipo de cinco personas que publica servicios web y APIs, Cloud Run suele ser una cuarta parte de la superficie operativa para el mismo resultado — y la pregunta de Autopilot frente a Standard solo pasa a ser relevante cuando ya has decidido que necesitas un clúster.

La comparación de coste, bien hecha

Cloud Run factura por segundo-petición de CPU y memoria asignadas, con escalado a cero generoso. GKE factura los nodos de forma continua.

• Tráfico a picos con noches tranquilas: gana Cloud Run con claridad, a menudo por mucho, porque tus entornos de staging no cuestan nada de madrugada.
• Tráfico alto y estable 24/7: gana GKE con descuentos por uso comprometido y nodos Spot, y la diferencia crece con el volumen.
• Muchos servicios pequeños: gana Cloud Run, porque en GKE cada servicio necesita al menos la capacidad solicitada de un pod, y la pérdida por empaquetado se acumula.

Los descuentos por uso comprometido de Cloud Run estrechan la diferencia en carga estable, así que cotiza ambos con cifras reales de tráfico en lugar de suponer.

Lo que solemos recomendar

Empieza en Cloud Run. Servicios web, APIs, webhooks, trabajos programados y consumidores de eventos encajan todos, y puedes pasarte a GKE después porque el artefacto es la misma imagen de contenedor. Esa portabilidad es el argumento real: el coste de migrar de Cloud Run a GKE son manifiestos y un pipeline, no una reescritura.

Mueve una carga a GKE cuando se lo gane — cuando necesite las primitivas de la pregunta tres, o cuando el análisis de coste en régimen estable lo diga con números reales.

Ten los dos, a propósito. La forma habitual que desplegamos es Cloud Run para la capa que sirve peticiones y las herramientas internas, y GKE para la plataforma con estado y de fondo. Una VPC, una frontera de service mesh si la necesitas, y la salida directa a VPC de Cloud Run para que los servicios lleguen a bases de datos privadas sin conector.

El error a evitar es la suposición por defecto en cualquiera de los dos sentidos: adoptar Kubernetes porque es lo que usan las empresas serias, o rechazarlo cuando visiblemente estás peleándote con el modelo de Cloud Run. Ambos salen caros, y el segundo es más raro pero más doloroso. Tomamos esta decisión pronto en casi todos los proyectos cloud porque todo lo demás se deriva de ella.

Qué hacer esta semana

Lista tus servicios y responde la pregunta uno para cada uno: ¿necesita estar ejecutándose cuando no llega ninguna petición? Aquellos donde la respuesta es no son candidatos a Cloud Run hoy mismo, y suelen ser la mayoría.