Cuando buscas "serverless" en GCP, aparecen tres servicios de forma simultánea: App Engine, Cloud Run y Cloud Functions. Los tres comparten la característica de que nunca gestionas la infraestructura subyacente de forma directa, pero sus modelos de ejecución y los tipos de carga de trabajo para los que están optimizados son claramente distintos. Esta guía sintetiza los patrones extraídos de 53 preguntas reales del examen GCP-ACE y mapea cada servicio a los escenarios donde resulta la mejor opción.
---
Tres servicios detrás de la palabra "serverless"
| Servicio | Nivel de abstracción | Objetivo principal | Base de facturación | |----------|---------------------|-------------------|---------------------| | App Engine | Plataforma (PaaS) | Aplicaciones web completas | Horas de instancia | | Cloud Run | Serverless de contenedor | Microservicios HTTP | CPU, memoria, cantidad de solicitudes | | Cloud Functions | Serverless de función | Funciones efímeras orientadas a eventos | Cantidad de invocaciones + tiempo de ejecución |
Con App Engine simplemente subes tu código y una configuración de runtime, y Google se encarga del balanceador de carga, la terminación HTTPS y el autoescalado. Cloud Run acepta cualquier contenedor Docker tal cual, eliminando restricciones de lenguaje o framework. Cloud Functions conecta una única función a una fuente de eventos y representa la huella serverless más liviana. La distinción más importante entre los tres es la unidad que se despliega: una aplicación, una imagen de contenedor o una función.
Para ingenieros de plataforma que habitualmente trabajan con contenedores, Cloud Run resultará el más natural. Para ingenieros de backend que prefieren evitar incluso la idea de construir una imagen, Cloud Functions elimina esa capa. App Engine se ubica en el medio: el artefacto de despliegue es tu código fuente más un archivo , no una imagen de contenedor, aunque la abstracción es mayor que la de una VM tradicional.
---
App Engine Standard vs Flexible
App Engine ofrece dos entornos de ejecución distintos. Comprender con precisión en qué difieren es lo que distingue una respuesta correcta de una incorrecta en la mayoría de las preguntas del examen sobre App Engine.
| Atributo | Entorno Standard | Entorno Flexible | |----------|-----------------|------------------| | Runtimes | Python, Java, Go, Node.js, Ruby, PHP (versiones fijas) | Cualquier lenguaje (Dockerfile personalizado) | | Inicio de instancia | Segundos (a veces milisegundos) | Varios minutos | | Escala a cero | Sí — las instancias bajan a 0 cuando no hay tráfico | No — mínimo 1 instancia siempre activa | | Acceso directo a VPC | No — requiere Serverless VPC Access Connector | Sí | | Modelo de costos | Facturación por segundo, costo cero cuando está inactivo | Mínimo 1 instancia facturada continuamente | | Sistema de archivos | Solo lectura (el directorio /tmp local es escribible) | Lectura y escritura completa |
Las ventajas del entorno Standard son los arranques en frío rápidos y la capacidad de escalar a cero. Es rentable para aplicaciones con tráfico variable o impredecible, aunque las versiones de runtime fijas pueden ser una limitación si dependes de una librería que requiere un intérprete más reciente.
El entorno Flexible te permite traer una imagen Docker personalizada y conectarte directamente a una VPC, pero la instancia mínima siempre activa significa que pagas incluso cuando no hay tráfico. El heurístico para el examen es simple: si la pregunta menciona conectividad directa a VPC, la respuesta es Flexible; si menciona costo cero con tráfico cero, la respuesta es Standard.
Una restricción crítica que aparece en el examen: cada proyecto de GCP puede tener exactamente una aplicación de App Engine, y la región elegida en el primer despliegue es permanente. Cambiar la región requiere crear un proyecto completamente nuevo. Es un límite operativo definitivo, no una guía flexible.
---
Cloud Run: El serverless de contenedores por defecto
Cloud Run es la opción serverless más versátil en GCP. Acepta cualquier contenedor Docker que escuche en un puerto HTTP, lo que significa que puedes usar cualquier lenguaje, cualquier framework y cualquier pila de dependencias.
El mecanismo central de Cloud Run es el escalado basado en solicitudes. Cuando no llegan solicitudes, el servicio escala a cero instancias. Cuando el tráfico aumenta de forma repentina, Cloud Run se expande automáticamente hasta el máximo configurado — 1,000 por defecto.
| Configuración de Cloud Run | Valor predeterminado | Descripción | |---------------------------|---------------------|-------------| | Concurrencia | 80 | Solicitudes simultáneas máximas por instancia | | Instancias mínimas | 0 | Instancias siempre activas | | Instancias máximas | 1,000 | Límite de escalado horizontal | | Tiempo límite de solicitud | Hasta 3,600 segundos | Duración máxima de una solicitud individual | | Asignación de CPU | Solo durante el procesamiento | Usar --cpu-always-on para mantener CPU asignada |
Cloud Run opera en dos modos. Un Cloud Run Service recibe tráfico HTTP de forma continua y es la opción adecuada para APIs y aplicaciones web. Un Cloud Run Job no tiene un endpoint HTTP; se ejecuta hasta completar su trabajo y termina, lo que lo hace ideal para cargas de trabajo de procesamiento por lotes.
Para el procesamiento asíncrono, las suscripciones Push de Pub/Sub que invocan Cloud Run son una arquitectura estándar en GCP. El enfoque de autenticación recomendado por Google en este patrón es el uso de tokens OIDC. La autenticación mediante clave de API no es la respuesta correcta en el examen ni el enfoque recomendado en producción.
Para servicios intensivos en CPU, configura la concurrencia más baja (cerca de 1). Para servicios intensivos en I/O —aquellos que esperan consultas a bases de datos o llamadas a APIs externas— una mayor concurrencia significa que se necesitan menos instancias para mantener el mismo rendimiento, lo que reduce directamente el costo.
---
Cloud Functions y el modelo de disparadores de eventos
Cloud Functions despliega código a la granularidad de una función individual y la conecta directamente a una fuente de eventos. Si la unidad de Cloud Run es un contenedor, la unidad de Cloud Functions es una función. No gestionas el enrutamiento, no defines puertos y no piensas en el ciclo de vida de las solicitudes más allá del límite de la función.
| Tipo de disparador | Evento de ejemplo | Soporte Gen 1 | Soporte Gen 2 | |-------------------|-------------------|---------------|---------------| | HTTP | Solicitud HTTP entrante | Sí | Sí | | Cloud Storage | Carga de objeto (finalizar), eliminación, cambio de metadatos | Sí | Sí | | Cloud Pub/Sub | Mensaje publicado en un tema | Sí | Sí | | Firestore | Documento creado, actualizado o eliminado | Sí | Sí | | Eventarc (otros) | BigQuery, Cloud Audit Logs, más de 90 fuentes | No | Sí |
Las diferencias más importantes entre Gen 1 y Gen 2 son el límite de tiempo de ejecución y el modelo de concurrencia. Gen 2 se ejecuta internamente sobre Cloud Run, por eso hereda la configuración de concurrencia de Cloud Run y puede ejecutar funciones activadas por HTTP durante hasta 60 minutos.
| Atributo | Cloud Functions Gen 1 | Cloud Functions Gen 2 | |----------|-----------------------|-----------------------| | Tiempo máximo de ejecución | 9 minutos | 60 min (HTTP), 9 min (eventos) | | Infraestructura subyacente | Propia | Cloud Run | | Concurrencia | 1 solicitud por instancia (fija) | Configurable (igual que Cloud Run) | | Integración con Eventarc | No | Sí | | División de tráfico | No | Sí |
El caso de uso canónico de Cloud Functions es responder a eventos de Cloud Storage. Cuando se sube una imagen a un bucket, se dispara el evento y la función conectada se ejecuta automáticamente para redimensionar la imagen o extraer metadatos. Cuando no llegan eventos, el costo es cero. La facturación se basa en el número de invocaciones más el tiempo de ejecución redondeado al múltiplo de 100 milisegundos más cercano. El nivel gratuito incluye 2 millones de invocaciones y 360,000 GB-segundos por mes.
---
División de tráfico y patrones de despliegue sin tiempo de inactividad
La función Traffic Splitting de App Engine distribuye las solicitudes entrantes entre múltiples versiones desplegadas del mismo servicio con porcentajes configurables. Esto permite despliegues canary, pruebas A/B y cambios blue-green de forma nativa, sin necesidad de configurar un balanceador de carga externo.
| Método de división | Característica | Mejor escenario | |-------------------|---------------|------------------| | Basado en IP | El mismo cliente siempre se enruta a la misma versión | Cuando la consistencia de sesión es importante | | Basado en cookie | Una cookie HTTP fija al usuario a una versión (más estable que la IP) | Sesiones de usuario autenticado | | Aleatorio | Cada solicitud selecciona una versión de forma independiente | Pruebas de porcentaje puro |
Tanto la configuración de la división de tráfico como la realización de rollbacks se hacen con un único comando gcloud:
Despliegue canary (10% a la nueva versión): Rollback inmediato:
Cuando quieres desplegar una nueva versión sin desviar tráfico hacia ella, usa el flag . La versión se despliega e inicia, pero no recibe tráfico hasta que ajustes explícitamente la división. Este es el patrón de despliegue más seguro para servicios en producción con requisitos estrictos de disponibilidad.
Cloud Run gestiona las versiones a nivel de revisión y también admite la división de tráfico entre revisiones a través de las mismas herramientas de gcloud.
| Servicio | Unidad de versión | División de tráfico | Rollback inmediato | |----------|------------------|---------------------|--------------------| | App Engine | Versión | Sí (IP/cookie/aleatorio) | Sí | | Cloud Run | Revisión | Sí | Sí | | Cloud Functions Gen 1 | No admitido | No admitido | R