Serverless Application Development with Cloud Run and Cloud Functions

Resumen

El serverless computing elimina de la conversación de arquitectura una variable que históricamente condiciona todas las decisiones: la administración de servidores. En un modelo serverless, la plataforma ejecuta el código, gestiona la capacidad, aplica los parches, distribuye el tráfico y escala según la demanda, y el equipo de aplicación se ocupa del código, de la configuración y de la experiencia del usuario. El coste se reconoce por el tiempo de cómputo realmente ejecutado, de modo que un servicio sin tráfico produce una factura casi nula en lugar de pagar una máquina encendida esperando peticiones.

En Google Cloud ese modelo se materializa en tres plataformas con contratos operativos distintos. Cloud Run despliega contenedores como servicios HTTP con escalado automático —incluido el escalado a cero—, balanceo gestionado y un modelo de concurrencia que permite que una sola instancia atienda varias peticiones a la vez. Cloud Functions ejecuta funciones acopladas a eventos —una cola, un objeto de almacenamiento, una petición HTTP, un planificador— y es la opción natural para reaccionar a lo que ocurre en el sistema. App Engine es la plataforma como servicio con despliegue por versión y enrutado por versión, concebida para aplicaciones web que necesitan entornos de pruebas y producción conviviendo bajo un mismo dominio.

Este tema cubre los beneficios del serverless computing, el valor de negocio de cada plataforma y el criterio de elección entre ellas. El punto que un Digital Leader debe poder sostener es que serverless no es "más fácil" ni "más barato" por definición: es un intercambio. Se gana velocidad de entrega, se elimina la operación de servidores y se alinea el coste con el uso; se aceptan límites de ejecución, un modelo de entorno más estrecho, cierta latencia de arranque y una dependencia de la plataforma. Elegir bien consiste en conocer ese intercambio y aplicarlo a la carga concreta.

Objetivos de Aprendizaje

Al terminar este contenido, serás capaz de:

Definir serverless computing y enumerar sus beneficios de negocio principales.
Señalar las restricciones del modelo serverless (límites de ejecución, arranque en frío, control del entorno) y cómo se gestionan.
Describir el valor de negocio de Cloud Run como plataforma de servicios basados en contenedores.
Explicar qué ofrece Cloud Functions para lógica dirigida a eventos y cuál es su contrato de ejecución.
Describir el papel de App Engine como PaaS con despliegue por versión y enrutado controlado.
Diferenciar las tres plataformas por modelo de despliegue, disparador, escalado y perfil de coste.
Elegir entre Cloud Run, Cloud Functions y App Engine para un caso de uso dado y justificar la elección con restricciones.
Identificar las decisiones de operación y de coste que acompañan a un servicio serverless (concurrencia, instancias mínimas, etiquetado, seguridad del endpoint).
Reconocer cuándo una carga no es candidata a serverless y qué alternativa corresponde.
Explicar cómo el serverless se integra con el resto de un programa de modernización de infraestructura y aplicaciones.

Contenido Principal

Subtema 1: Qué es serverless computing y qué beneficios aporta

Serverless computing es el modelo de ejecución en el que la plataforma gestiona la capacidad de cómputo —provisionamiento, escalado, parcheo, disponibilidad— y el cliente entrega código o una imagen ya empaquetada, pagando por el tiempo realmente ejecutado. El nombre es engañoso en un sentido literal: hay servidores; lo que desaparece es la administración de servidores por parte del cliente. En la práctica, el límite de responsabilidad se mueve: el equipo deja de dimensionar máquinas, de actualizar el sistema operativo y de gestionar clústeres, y pasa a ser responsable del código, de la configuración, de la seguridad del punto de acceso y del coste por invocación.

Los beneficios de negocio que la certificación espera poder nombrar y justificar son cinco. Velocidad de entrega: publicar un servicio o una función es una operación de minutos, y el equipo puede iterar sin esperar a que la infraestructura esté disponible. Coste alineado al uso: sin tráfico no hay cómputo cobrado, y la parte fija del entorno de desarrollo desaparece; para servicios con demanda irregular el ahorro es estructural, no cosmético. Escalado automático: la capacidad sigue al tráfico en ambos sentidos, incluido el escalado a cero cuando la plataforma lo soporta, sin configurar grupos ni políticas. Menos operación de plataforma: no hay ventanas de parcheo ni clústeres que actualizar, y el tiempo del equipo se concentra en producto. Integración nativa con el resto de servicios: identidad, colas, almacenamiento y observabilidad se conectan por configuración, lo que acorta la construcción de flujos completos.

Las restricciones son la otra mitad del modelo, y conviene conocerlas con la misma precisión. Límites de ejecución: las funciones tienen un tiempo máximo de ejecución, y las cargas de larga duración deben partirse o moverse a un servicio permanente. Arranque en frío: la primera petición tras un periodo sin tráfico paga el tiempo de inicialización del runtime; se mitiga con instancias mínimas cuando la latencia lo exige. Entorno acotado: no hay acceso libre al sistema de ficheros ni capacidad de mantener estado local entre invocaciones; el estado se externaliza. Coste por invocación: con tráfico masivo y duraciones medias largas, el modelo puede superar el de un servicio permanente dimensionado. Dependencia de plataforma: los disparadores, la autenticación y el escalado usan primitivas del proveedor, y la portabilidad exige disciplina en el empaquetado y en la definición del entorno.

Aspecto	Serverless	Servidor gestionado con VM o clúster
Administración de servidores	La realiza el proveedor	Parcialmente el cliente
Modelo de coste	Por tiempo o invocación ejecutada	Por capacidad reservada, con encendido continuo
Escalado	Automático, incluido a cero en algunos servicios	Configurado por el cliente con políticas
Límites de ejecución	Presentes en el modelo de funciones	No aplican
Estado local entre invocaciones	No soportado	Soportado con configuración
Adecuado para tráfico irregular	Sí, es su mejor caso	No, paga capacidad ociosa

Las señales de que una carga no conviene al modelo serverless son tan útiles como las que sí lo abonan, y conviene poder enumerarlas en una revisión de arquitectura:

Operaciones que superan con holgura el tiempo de ejecución admitido, o que no se pueden dividir en pasos cortos.
Servicios que mantienen estado local —sesiones, caché en memoria, conexiones largas— entre peticiones.
Cargas con volumen constante durante todo el día y duración media alta, donde el coste por invocación supera al de capacidad reservada.
Aplicaciones que requieren control del sistema operativo, procesos en segundo plano o dispositivos locales.
Servicios cuya latencia de respuesta no admite el tiempo de arranque ni se puede mitigar con instancias mínimas.

El coste también conviene mirarlo con la unidad de negocio en la mano, no solo con la factura total. El modelo serverless permite calcular coste por petición, por evento o por usuario activo con una precisión que las VMs no ofrecen, porque el cómputo se reconoce por ejecución. Esa granularidad es el argumento económico más sólido ante un comité: se puede comparar el coste de un pedido procesado con serverless contra el mismo pedido en un servicio permanente dimensionado para el pico, y la comparación incluye los meses de baja actividad en los que la VM sigue encendida. La condición para que el cálculo sea honesto es tener el volumen medido —no estimado— y la duración media real de la operación.

Subtema 2: Cloud Run: servicios HTTP a partir de contenedores

Cloud Run es la plataforma serverless de Google Cloud para desplegar contenedores como servicios HTTP. El cliente construye una imagen de contenedor —con el lenguaje, el runtime y las dependencias que quiera— y la publica; la plataforma se encarga de exponer un punto de acceso HTTPS, de enrutar las peticiones, de escalar el número de instancias según la carga y de eliminar las que sobran, hasta llegar a cero en los periodos sin tráfico. La elección de contenedores como formato de despliegue es el argumento de negocio central: no hay que adaptar la aplicación a un runtime concreto, y la misma imagen que pasa las pruebas es la que corre en producción.

Un concepto operativo distingue a Cloud Run de un servidor tradicional: la concurrencia. Una instancia puede atender varias peticiones simultáneas, de modo que el escalado no se produce por cada petición sino cuando la carga supera el umbral configurado. Ese comportamiento tiene dos consecuencias prácticas. La primera es el coste: una aplicación que procesa peticiones en milisegundos puede servir muchas por instancia y el número de instancias crece menos rápido de lo que la intuición de "una máquina por usuario" sugeriría. La segunda es el rendimiento: si una petición bloquea la instancia —por una llamada síncrona larga a otro servicio—, bloquea también a las demás que comparten esa instancia, de ahí que el diseño de los timeouts sea parte del trabajo de configuración.

Cloud Run ofrece además recursos que lo acercan a un servicio permanente sin abandonar el modelo serverless: instancias mínimas configurables para evitar el arranque en frío, ejecución de trabajos por lotes sin endpoint permanente, ejecución dirigida por eventos, dominios personalizados, autenticación integrada con Identity-Aware Proxy y con tokens de identidad, revisiones con promoción controlada y despliegue por porcentaje de tráfico para pruebas progresivas. Para el negocio, esa lista significa que la plataforma cubre operaciones de release que antes exigían herramientas propias: canary, rollback, pruebas por versión y separación de entornos.

La operación de despliegue merece una atención específica porque es donde el serverless se vuelve comparable con una arquitectura tradicional. Cada despliegue crea una revisión nueva; el tráfico se asigna a revisiones con un porcentaje; y el rollback consiste en redirigir el cien por cien a la revisión anterior, sin reconstruir nada. Ese mecanismo convierte el release en una operación reversible, que es la condición para que un equipo despliegue con frecuencia sin negociar ventanas. El trabajo de negocio que acompaña es definir el criterio de promoción —qué métrica mejora o empeora antes de subir el porcentaje—, porque sin criterio, la prueba progresiva se convierte en un ritual sin decisión.

El control de acceso forma parte del despliegue inicial y no de una fase posterior. Un servicio puede quedar abierto a Internet o restringido a identidades concretas, y la elección depende del contrato con el usuario: un endpoint para terceros requiere autenticación, cuota y límite de tasa; un endpoint interno debe exigir identidad de servicio y, cuando el backend está on-premises, conectividad privada en lugar de exposición pública. La plataforma ofrece los mecanismos —identidad, proxy de identidad, permisos de invocación, redes—, pero la decisión de quién puede invocar es una decisión de negocio y de riesgo que debe quedar documentada en el mismo ticket que crea el servicio.

La lista de comprobación previa a un servicio en producción es corta y se puede ejecutar como parte del despliegue:

Autenticación y autorización definidas, sin acceso anónimo salvo decisión explícita y documentada.
Límites de instancias y de concurrencia acordes con el presupuesto y con el objetivo de respuesta.
Tiempo de espera de la aplicación menor que el tiempo asignado a la plataforma, para que el fallo se gestione donde corresponde.
Etiquetas de proyecto, entorno y propietario que permitan atribuir el coste y localizar al dueño de la carga.
Logs y métricas de nivel servicio activados, con alerta sobre tasa de error y latencia, no solo sobre saturación.

La disciplina con la que se aplique esa lista determina si el servicio serverless se puede operar como una plataforma de negocio o si se convierte en un catálogo de endpoints que nadie entiende; la velocidad del modelo hace que las malas decisiones también se propaguen rápido.

El valor de negocio de Cloud Run se concentra en cuatro frases: publicar contenedores existentes sin reescritura, escalar automáticamente según peticiones, pagar solo por el tiempo servido y eliminar la operación de servidores. Su límite es igualmente claro: es una plataforma para servicios web y trabajos con contrato HTTP o por eventos; no es un reemplazo de una máquina virtual con estado, ni una base de datos, ni un entorno de larga duración sin restricciones.

Ejemplo Práctico

Desplegar un servicio en Cloud Run es una operación que un equipo puede completar sin ticket de infraestructura, siempre que el proyecto tenga habilitada la API correspondiente:

gcloud services enable run.googleapis.com cloudbuild.googleapis.com
gcloud run deploy pedidos-api \
  --image gcr.io/PROJECT_ID/pedidos-api:stable \
  --region us-central1 \
  --allow-unauthenticated \
  --max-instances 10 \
  --concurrency 80

La bandera --allow-unauthenticated abre el servicio a Internet; en un entorno con usuarios reales debe acompañarse de la autenticación y de las restricciones de red que el caso exija, porque un endpoint público sin control es el hallazgo de seguridad más frecuente en servicios recién desplegados. --max-instances limita el crecimiento y, por tanto, el coste máximo del mes; --concurrency define cuántas peticiones atiende cada instancia y condiciona tanto el rendimiento como el número final de instancias facturadas.

Para comprobar el estado y la dirección del servicio una vez publicado:

gcloud run services list --region=us-central1 \
  --format="table(metadata.name, status.url, status.latestReadyRevisionName, status.traffic)"

La tabla permite verificar dos cosas que interesan al negocio: la URL pública real del servicio y la revisión que sirve el tráfico, que es el punto de control para un rollback. Cuando en la columna de tráfico aparece repartido entre varias revisiones, se está ejecutando una prueba progresiva: la plataforma está sirviendo la versión nueva solo a una fracción del tráfico, operación que en una arquitectura de VMs exigiría un balanceador configurado a mano.

Temas relacionados: Cómputo, contenedores y serverless, Cloud modernization y estrategias de migración, Hybrid y multicloud con Anthos.

Subtema 3: Cloud Functions: lógica acoplada a eventos

Cloud Functions es la plataforma de funciones de Google Cloud: unidades pequeñas de código que se ejecutan en respuesta a un evento o a una petición, sin gestionar servidores ni estados de proceso. Su segunda generación se construye sobre Cloud Run y comparte su modelo de contenedores y escalado, por lo que también se presentan como Cloud Run functions; la consecuencia operativa es que una función puede llamar a un servicio de Cloud Run y viceversa dentro de la misma arquitectura, sin que el límite entre ambos sea un problema de plataforma.

El disparador es el concepto central. Una función puede activarse por una petición HTTP, por un mensaje en Pub/Sub, por la creación o modificación de un objeto en Cloud Storage, por un registro de auditoría o por un evento de otro servicio de Google Cloud o de un partner, y esa lista crece con el catálogo. El patrón de negocio que esto habilita es la reacción desacoplada: cuando un archivo llega a un bucket se lanza su procesamiento; cuando se publica un evento de pedido se actualiza el inventario; cuando se registra un error de autenticación se envía una alerta. En cada caso, la lógica de reacción se separa del sistema que produce el evento, y ambos pueden evolucionar por separado.

Las restricciones del modelo son las de una función y se expresan en su contrato de ejecución: tiempo máximo de ejecución, memoria asignada, entorno de ejecución gestionado y ausencia de estado local persistente. Una función no es el lugar correcto para una carga de horas, para un servidor de cola que mantiene conexiones abiertas o para una aplicación con sesión propia; sí lo es para trabajo corto, reanudable y desacoplado. Cuando la lógica crece más allá de lo que una función puede sostener con claridad, se traslada a un servicio de Cloud Run y se deja la función como reacción al evento, no como contenedor de toda la aplicación.

El valor de negocio de Cloud Functions es la reducción del tiempo entre un evento y su procesamiento, la eliminación de la infraestructura de colas y de workers dedicados que muchos equipos construyen a mano, y el coste ligado a la actividad real. Su riesgo de negocio es el exceso de confianza: una cadena larga de funciones encadenadas produce un flujo difícil de observar y de presupuestar, y la disciplina correcta es mantener funciones cortas, con nombres que describan la acción y con métricas de duración y de error por función.

Los patrones de integración que estas funciones hacen posibles son una parte del valor que conviene conocer para los escenarios de examen. El buffer entre sistemas: un productor publica un evento y el consumidor lo procesa a su ritmo, de modo que un pico no arrastra al sistema que no lo puede absorber. El fan-out: un único evento dispara varias funciones independientes —actualizar inventario, generar factura, enviar notificación— sin que el productor conozca a los consumidores. La orquestación de flujos: varias funciones coordinadas por eventos avanzan un proceso de negocio sin un motor de workflows propio. En los tres, la plataforma absorbe la mecánica de entrega, reintento y escalado, y el equipo se queda con la lógica de negocio y con las decisiones de idempotencia —qué hacer si el mismo evento llega dos veces—, que son las que determinan si el flujo es correcto en condiciones reales.

Subtema 4: App Engine: PaaS con despliegue por versión

App Engine es la plataforma como servicio de Google Cloud para aplicaciones web y móviles. El cliente define una aplicación y sus versiones, y la plataforma se encarga del runtime, del balanceo, del escalado y de la exposición bajo un dominio. Su rasgo distintivo es el modelo de despliegue por versión: cada versión de la aplicación recibe su propio entorno y su propia dirección, y el tráfico se puede repartir entre versiones, enviar una versión a un conjunto de usuarios o redirigir por completo en un rollback. Ese modelo resuelve una necesidad de negocio concreta: tener pruebas y producción conviviendo bajo el mismo proyecto y el mismo dominio, con control explícito de la promoción.

App Engine se opera en dos entornos. El entorno estándar ejecuta aplicaciones en runtimes gestionados con arranque rápido y escalado hasta cero, y es el más cercano al modelo serverless puro; el entorno flexible despliega contenedores sobre máquinas virtuales con más control del entorno y capacidad de ejecución más larga, y es el más cercano a una plataforma de contenedores con gestión delegada. La diferencia de negocio entre ambos es la misma que entre un servicio serverless y una carga con requisitos de entorno: si la aplicación necesita un runtime soportado y escala bien, el estándar reduce coste y operación; si necesita librerías, procesos propios o tiempos de ejecución largos, el flexible paga más y a cambio entrega compatibilidad.

El valor de negocio de App Engine para una organización existente es la continuidad: aplicaciones que ya se despliegan con app.yaml y versiones conservan su modelo operativo y su curva de aprendizaje, y la modernización puede avanzar por capas sin reescribir el despliegue. Para proyectos nuevos con un servicio HTTP bien definido, la recomendación habitual del ecosistema es evaluar primero Cloud Run, por su formato de contenedor y su modelo de coste, y reservar App Engine para cargas que se benefician del enrutado por versión o que ya viven en su modelo. Esa recomendación no obedece a que App Engine sea una plataforma descartada, sino a que Cloud Run cubre el caso general con menos piezas.

Para una aplicación que ya vive en App Engine, la modernización ordenada no empieza por cambiar de plataforma, sino por entender qué usa de su contrato: si depende del enrutado por versión, del acceso a servicios internos o del entorno flexible con binarios propios, la migración a Cloud Run exige un análisis de compatibilidad y una ventana de cambio; si la aplicación es esencialmente un servicio HTTP que no usa esas capacidades, la migración se convierte en un empaquetado y en una reconfiguración del despliegue. El error frecuente es programar la migración de plataforma como un objetivo en sí mismo, sin una restricción de negocio que la justifique, y consumir el presupuesto de modernización en mover un servicio que funcionaba.

Ejemplo Práctico

El despliegue de una aplicación en App Engine se define con un descriptor de configuración y se publica con una operación única, manteniendo el modelo de versiones que la plataforma gestiona:

gcloud app deploy app.yaml --project=PROJECT_ID --quiet
gcloud app versions list --format="table(id, traffic_split, servingStatus)"
gcloud app services set-traffic S_NAME --splits=VERSION_A=0.9,VERSION_B=0.1

El primer comando crea una nueva versión de la aplicación; la segunda tabla permite ver qué versiones están sirviendo tráfico y con qué reparto; y el tercero ejecuta un reparto deliberado entre versiones, que es la operación que en otras plataformas exigiría configuración adicional de balanceo. La lectura de negocio es que una prueba con el diez por ciento del tráfico deja de ser una improvisación técnica y pasa a ser una operación reversible con métricas comparables entre versiones.

Subtema 5: Cuándo elegir Cloud Run, Cloud Functions o App Engine

La elección se resuelve con tres preguntas. ¿Cuál es la forma de la carga? Un servicio con endpoint HTTP y algo de lógica va a Cloud Run; una reacción acoplada a un evento va a Cloud Functions; una aplicación web con despliegue por versiones puede ir a App Engine. ¿Qué necesita el entorno? Si la aplicación requiere librerías, procesos o binarios concretos, el contenedor de Cloud Run o el entorno flexible de App Engine son compatibles; los runtimes gestionados imponen su catálogo. ¿Cómo se comporta el tráfico? Un servicio con picos marcados y fondo cercano a cero gana con el escalado a cero; un servicio con carga constante y latencia exigente puede necesitar instancias mínimas; una función invocada millones de veces al día con duración media alta conviene modelarla antes de decidir, porque el coste por invocación puede superar al de un servicio permanente.

La respuesta que el examen espera no es una plantilla, sino una justificación con restricciones. Un backend de catálogo que recibe tráfico diario irregular y se puede contenedorizar: Cloud Run. Un proceso que transforma objetos subidos a un almacenamiento: Cloud Functions con disparador de almacenamiento. Una aplicación de portal con dos versiones conviviendo y enrutado por porcentaje de usuarios: App Engine. Un motor de cálculo de horas: ninguna de las tres, sino un servicio de larga duración o un trabajo por lotes fuera del modelo de funciones. Cada una de esas cuatro respuestas se apoya en una restricción verificable, y esa es la forma de razonar que la certificación evalúa.

La tabla de decisión rápida que se puede aplicar en una revisión de arquitectura se reduce a estas reglas:

Evento que dispara una acción corta y desacoplada → Cloud Functions.
API o backend HTTP con lógica de servicio y tráfico variable → Cloud Run.
Trabajo por lotes sin endpoint permanente → Cloud Run como trabajo, no como servicio.
Aplicación web con despliegue por versiones o instalada en App Engine → App Engine.
Carga con estado, larga duración o requisito de entorno completo → fuera del serverless: Compute Engine o GKE.
Volumen masivo y duración media alta → modelar el coste antes de elegir; a menudo corresponde un servicio permanente.

El último punto de la tabla es el que más se discute en los comités, y la forma de cerrarlo es siempre la misma: cálculo con tráfico medido de ambas opciones y revisión tras el primer mes de operación. El serverless no gana por ser serverless; gana cuando su modelo de coste y su contrato operativo encajan con la carga real.

Ejemplo Práctico

La publicación de una función acoplada a eventos, en su segunda generación sobre Cloud Run, es una operación de una línea que oculta decisiones de arquitectura importantes —el disparador, el punto de entrada y la región—, y conviene revisarlas antes de publicar:

gcloud functions deploy procesar-pago \
  --gen2 \
  --runtime python312 \
  --trigger-topic pagos \
  --entry-point procesar_pago \
  --region us-central1 \
  --memory 512MB \
  --timeout 120s

--trigger-topic define el evento: la función se ejecuta con cada mensaje publicado en el tema de Pub/Sub indicado, de modo que el productor del evento y el consumidor quedan desacoplados. --timeout fija el tiempo máximo de ejecución, y debe fijarse a partir de la duración medida del proceso, no por intuición: demasiado corto interrumpe trabajos válidos; demasiado largo oculta un cuello de botella y prolonga el coste de un fallo. El mensaje de Pub/Sub se reintenta hasta que la función lo procesa o se agotan los reintentos, y esa garantía de entrega es la que permite eliminar el procesamiento manual de archivos huérfanos.

Una vez desplegadas las piezas, la revisión operativa conjunta —funciones, servicios y el coste asociado— se hace desde la lista de servicios y la consola de facturación:

gcloud run services list --region=us-central1 \
  --format="table(metadata.name, status.url, status.latestReadyRevisionName)"
gcloud functions list --gen2 --region=us-central1 \
  --format="table(name, status, runtime, trigger)"

La columna de disparador de las funciones permite confirmar que cada una escucha el evento que se esperaba, y no un HTTP expuesto por error; la columna de estado muestra cuáles están activas frente a las desactivadas que siguen generando configuración. Para un Digital Leader, la lectura de negocio es que ambas listas, cruzadas con la etiqueta de proyecto y con la facturación por servicio, permiten sostener la conversación de coste por transacción: el volumen de eventos y de peticiones sale de aquí, y el gasto de Cloud Billing aporta el numerador.

Conceptos Clave

Concepto	Descripción	Cuándo usarlo
Serverless computing	Modelo sin administración de servidores, con pago por ejecución	Cuando la prioridad es velocidad y coste alineado al uso
Cloud Run	Servicios HTTP desplegados a partir de contenedores	Servicios web y backends con tráfico irregular o creciente
Cloud Functions	Funciones acopladas a eventos o peticiones HTTP	Reacción a eventos, lógica corta y desacoplada
Cloud Run functions	Denominación actual de las funciones de segunda generación	Cuando se necesita el modelo de funciones con el soporte de Cloud Run
App Engine	PaaS con despliegue por versión y enrutado controlado	Aplicaciones web existentes y cargas que se benefician de versiones
Concurrencia	Peticiones atiende una instancia antes de escalar	Para ajustar coste y rendimiento de un servicio en Cloud Run
Arranque en frío	Latencia de la primera petición tras escalar desde cero	Al dimensionar instancias mínimas para latencia exigente
Escalado a cero	Eliminación de instancias cuando no hay tráfico	Servicios de actividad esporádica
Disparador	Evento que provoca la ejecución de una función	Al definir la reacción a un cambio en otro sistema
Límite de ejecución	Tiempo máximo que puede correr una función	Para descartar cargas de larga duración del modelo de funciones
Revisión (Cloud Run)	Versión inmutable de un servicio tras un despliegue	Para promoción controlada y rollback
Entorno flexible (App Engine)	Contenedores sobre VMs gestionadas con más control	Cuando la aplicación necesita un entorno completo
Instancia mínima	Réplicas que permanecen activas sin tráfico	Para eliminar el arranque en frío en latencia exigente

Comparaciones

Dimensión	Cloud Run	Cloud Functions	App Engine
Forma de despliegue	Imagen de contenedor	Código de función o contenedor (segunda generación)	Aplicación con `app.yaml` y versiones
Disparador habitual	Petición HTTP o trabajo por eventos	Evento o petición HTTP	Petición HTTP a una versión
Escalado	Por peticiones, hasta cero	Por invocaciones, hasta cero	Por versión y métrica, según entorno
Límites de ejecución	Según configuración del servicio	Tiempo máximo por función	Según entorno y configuración
Coste dominante	Instancia-servicio con concurrencia	Por tiempo de ejecución de la función	Según entorno: escalado o capacidad
Operación de servidores	Ninguna	Ninguna	Ninguna
Mejor caso	Backend HTTP con lógica de servicio	Reacción desacoplada a eventos	Web con despliegue por versiones
Promoción de versiones	Revisiones con reparto de tráfico	Versiones por despliegue	Versiones con enrutado propio
Trabajo por lotes	Sí, como tipo de ejecución	Sí, por eventos reiterados	No es su modelo principal

Dimensión	Candidato a serverless	Candidato a servicio permanente
Perfil de tráfico	Irregular, con valles largos o picos bruscos	Constante durante el día
Duración de la operación	Milisegundos a pocos minutos	Horas o ejecución continua
Estado local	Ninguno, estado externalizado	Sesiones o caché en memoria
Sensibilidad a latencia de arranque	Baja o mitigable con instancias mínimas	Alta
Volumen y duración media	Moderados	Masivos y con duración media alta

Errores Comunes

Error: Tratar el serverless como la respuesta por defecto a cualquier carga y descartarlo solo cuando ya falla. → Solución: Evaluar restricciones antes de elegir —duración, estado, latencia, volumen— y comparar con la alternativa de servicio permanente modelando el coste con el tráfico real; el serverless es la mejor opción en cargas irregulares y cortas, no en todas.
Error: Emplear Cloud Functions para procesos de larga duración o como servidor de cola permanente. → Solución: Reservar las funciones para lógica corta acoplada a eventos y mover la parte larga a un servicio de Cloud Run o a un trabajo por lotes; la duración medida debe fijar el límite de ejecución, no al revés.
Error: Desplegar servicios con acceso no autenticado por defecto porque --allow-unauthenticated es lo más rápido. → Solución: Definir la autenticación y las restricciones de red como parte del despliegue inicial —identidad, token, proxy de identidad, control por origen— y revisar la exposición pública en cada servicio antes de llevarlo a producción.
Error: Optimizar el arranque en frío de un servicio sin haber medido su impacto real. → Solución: Medir la latencia de las primeras peticiones y la fracción de tráfico afectada; si el impacto es marginal, el coste de mantener instancias mínimas no compensa, y la inversión debe ir a la duración de la operación, que sí afecta a cada petición.
Error: Mantener App Engine para servicios nuevos solo por costumbre del equipo, sin revisar si el despliegue por versión es un requisito real. → Solución: Evaluar Cloud Run para cargas nuevas con formato de contenedor y reservar App Engine para las aplicaciones que se benefician del enrutado por versión o que ya operan con ese modelo; la continuidad es un valor, pero no debe convertirse en una decisión sin revisión.

Puntos para el Examen

🎯 Punto clave 1: Serverless elimina la administración de servidores y alinea el coste con la ejecución, a cambio de límites de ejecución, entorno acotado y posible latencia de arranque. Los beneficios que se evalúan son velocidad de entrega, coste por uso, escalado automático y menos operación; las restricciones son parte de la respuesta, no un matiz opcional.

🎯 Punto clave 2: Cloud Run despliega contenedores como servicios HTTP, con escalado por peticiones, concurrencia por instancia y escalado a cero. Es la opción general para backends y servicios web; su valor de negocio es publicar la misma imagen que pasa las pruebas y eliminar la operación de servidores.

🎯 Punto clave 3: Cloud Functions ejecuta lógica dirigida a eventos —HTTP, Pub/Sub, almacenamiento, auditoría— y es la herramienta de reacción desacoplada. La segunda generación se basa en Cloud Run y a veces se presenta como Cloud Run functions; la pregunta de escenario que la pide suele describir un cambio en un sistema y una acción inmediata posterior.

🎯 Punto clave 4: App Engine es el PaaS con despliegue por versión y enrutado controlado, con entorno estándar y flexible. Conviene para aplicaciones web existentes y para cargas que se benefician de versiones conviviendo; para servicios nuevos, la alternativa habitual a evaluar es Cloud Run.

🎯 Punto clave 5: La elección entre las tres plataformas se justifica con restricciones verificables: forma de la carga (evento o HTTP), duración, estado, perfil de tráfico y necesidad de versiones. Un escenario que pide "reaccionar a un archivo subido" apunta a Cloud Functions; "servir una API con tráfico irregular" apunta a Cloud Run; "mantener dos versiones con reparto de tráfico" apunta a App Engine.

Recursos Externos

Documentación de Cloud Run — Desarrollo, despliegue y operación de servicios basados en contenedores con escalado automático.
Configuración de servicios en Cloud Run — Concurrencia, instancias, revisión de despliegues y opciones de exposición del servicio.
Documentación de Cloud Functions — Funciones, disparadores, límites de ejecución y despliegue de la segunda generación.
Conceptos de Cloud Functions — Modelo de eventos, recursos y ciclo de vida de una función.
Documentación de App Engine — Aplicaciones, versiones, entornos estándar y flexible, y despliegue con app.yaml.

Autoevaluación Rápida

Pregunta: Un equipo afirma que con serverless "ya no hay que preocuparse de la infraestructura". ¿Qué corrección y qué beneficio sí son válidos? Respuesta: La corrección es que serverless elimina la administración de servidores —no hay que dimensionar, parchear ni actualizar clústeres— pero no la responsabilidad sobre el código, la configuración, la seguridad del endpoint ni el coste por invocación. El beneficio válido es la velocidad de entrega y el coste alineado al uso: la plataforma gestiona la capacidad y el equipo se concentra en producto, aceptando los límites del modelo.
Pregunta: Una función procesa un mensaje de Pub/Sub con duración media de tres minutos y picos de tráfico masivos. ¿Qué se debe revisar antes de dejarla en Cloud Functions? Respuesta: Dos cosas: el límite de ejecución, que debe cubrir el peor caso medido, y el modelo de coste, porque una función con duración media alta y volumen elevado puede costar más que un servicio permanente que procese la misma cola. Si la duración crece o el volumen se dispara, corresponde mover el procesamiento a un servicio de Cloud Run o a un trabajo por lotes, dejando la función como reacción de encolado.
Pregunta: ¿Cuál es la diferencia operativa de la concurrencia en Cloud Run frente a una réplica de un grupo de instancias? Respuesta: En Cloud Run, una instancia atiende varias peticiones simultáneas según el umbral configurado, de modo que el escalado responde a la saturación de esas instancias y no a la cuenta de peticiones; en un grupo de instancias, la réplica suele atender una conexión o un conjunto menor y el escalado se configura por métrica de la instancia. La consecuencia de negocio es el coste: con concurrencia bien ajustada se necesitan menos instancias para el mismo tráfico, pero una petición lenta puede afectar a las demás que comparten la instancia.
Pregunta: ¿Qué escenario corresponde a App Engine y por qué no se recomienda automáticamente para un backend nuevo? Respuesta: Corresponde a una aplicación web que necesita convivencia de versiones, enrutado por porcentaje de tráfico y rollback por versión, o a una aplicación existente que ya opera con su modelo de despliegue. No se recomienda automáticamente para un backend nuevo porque Cloud Run cubre el caso general de servicio HTTP con formato de contenedor y escalado a cero, con menos piezas y mayor portabilidad del artefacto; la elección debe apoyarse en si el despliegue por versión es un requisito real del negocio.
Pregunta: ¿Cómo se argumenta, ante un comité, activar instancias mínimas en un servicio de Cloud Run que hoy escala a cero? Respuesta: Con evidencia de latencia y de negocio: si las métricas muestran que la primera petición de cada periodo sin tráfico paga un arranque en frío que supera el objetivo de tiempo de respuesta acordado con el negocio, mantener una instancia mínima elimina esa penalización a cambio de un coste fijo de instancia en los periodos sin tráfico. La decisión se toma comparando el coste de la instancia mínima contra el valor de la experiencia atendida, y se documenta para revisarla cuando cambie el volumen o el objetivo de latencia.