Hasta ahora, la migración de AlpinaShop ha seguido el camino más conservador: mover lo que había a máquinas virtuales. Funciona, pero Marta sigue manteniendo sistemas operativos, escribiendo startup scripts, versionando plantillas de instancia y vigilando parches de seguridad. Es trabajo que no distingue a AlpinaShop de ninguna otra tienda: nadie compra más mochilas porque su servidor esté bien parcheado.

App Engine fue el primer servicio de Google Cloud, lanzado en 2008, y sigue siendo una de las formas más rápidas de poner una aplicación web en producción: subes el código, Google se encarga de todo lo demás —servidores, escalado, balanceo, certificados TLS, despliegues— y pagas por el uso. En esta lección desplegarás el catálogo Flask de AlpinaShop en App Engine, aprenderás a controlar su escalado y su coste, dividirás tráfico entre versiones para hacer un despliegue canary, conectarás con Cloud SQL y Cloud Storage, y terminarás con una valoración honesta de por qué hoy muchos equipos eligen Cloud Run en su lugar.

1. Qué es un PaaS y qué desaparece de tu trabajo
2. Entorno estándar y entorno flexible
3. Anatomía de app.yaml
4. Desplegar el catálogo de AlpinaShop
5. Versiones, división de tráfico y despliegue canary
6. Tipos de escalado y su efecto en el coste
7. Servicios y enrutamiento con dispatch.yaml
8. Acceso a Cloud SQL y Cloud Storage desde App Engine
9. Variables de entorno y configuración
10. Logs y errores
11. Tareas en segundo plano: Cloud Tasks y cron.yaml
12. Limitaciones reales y por qué hoy muchos equipos eligen Cloud Run

Plataforma como servicio significa que el proveedor gestiona todo lo que hay por debajo de tu código. Comparado con lo que hicimos en 02-01:

Toda la lección 02-01 —plantillas, grupos gestionados, health checks, autoescalado, actualizaciones progresivas— se reduce en App Engine a un fichero de configuración y gcloud app deploy. Y sale gratis HTTPS con dominio propio, algo que en Compute Engine exigirá un balanceador de carga y un certificado gestionado (03-02 y 03-07).

Lo que pagas por ello: menos control y más acoplamiento. No eliges el sistema operativo, no instalas paquetes arbitrarios en el estándar, y el app.yaml es un formato propio de Google que no funciona en ninguna otra parte.

Un detalle organizativo que sorprende: una aplicación de App Engine por proyecto, y su región se elige al crear la aplicación y no se puede cambiar. Si te equivocas, hay que crear un proyecto nuevo. Para AlpinaShop, europe-west1, coherente con todo lo demás.

App Engine tiene dos entornos que se comportan de forma muy distinta bajo el mismo nombre:

Cuándo cada uno. El estándar es la elección natural para aplicaciones web en un lenguaje soportado: arranca rápido, escala a cero y es barato. El flexible tiene sentido si necesitas una dependencia del sistema que el sandbox no permite, un binario propio o un lenguaje no soportado.

Y aquí la valoración honesta que anticipa el apartado 12: si estás pensando en App Engine flexible, casi siempre Cloud Run es mejor opción hoy —también ejecuta tu contenedor, pero escala a cero, se factura por petición y no está atado al formato de App Engine.

AlpinaShop usa el entorno estándar con Python 3.12: el catálogo es Flask puro con dependencias que se instalan con pip, sin nada exótico.

app.yaml es el fichero que describe la aplicación entera. Vamos a construir el de AlpinaShop comentando cada bloque.

Tres ideas de este fichero que conviene retener:

• Los handlers de tipo estático son gratis en tiempo de CPU. Google sirve esos ficheros desde su propia infraestructura, sin arrancar ni ocupar una instancia. Servir CSS, JS e imágenes por ahí en lugar de con Flask reduce el coste y la latencia de forma notable.
• secure: always debería estar en todos los handlers. Redirige HTTP a HTTPS automáticamente.
• max_concurrent_requests es la palanca más importante del coste. Si tu aplicación pasa la mayor parte del tiempo esperando a la base de datos, puede atender muchas peticiones simultáneas por instancia; subir este valor reduce el número de instancias necesarias. Si la aplicación consume CPU, subirlo empeora la latencia.

Junto al app.yaml van los ficheros habituales de un proyecto Python:

El .gcloudignore no es un detalle menor: sin él, subirías el directorio .git y el entorno virtual entero, con despliegues lentos y el riesgo real de publicar un fichero .env con credenciales.

La aplicación, con las piezas que ya conocemos de las lecciones anteriores:

Fíjate en pool_size=2. Es un cambio deliberado respecto a la lección anterior: App Engine puede crear decenas de instancias en un pico, y cada una abriría su propio pool. Con pool_size=5 y 20 instancias serían 100 conexiones solo del catálogo. En entornos que escalan de forma agresiva, los pools deben ser pequeños.

Observa también GAE_VERSION: App Engine inyecta variables de entorno con información del entorno de ejecución (GAE_SERVICE, GAE_VERSION, GAE_INSTANCE, GOOGLE_CLOUD_PROJECT). Mostrar la versión en la página es un truco muy práctico para verificar despliegues y divisiones de tráfico.

Despliegue:

Al desplegar, App Engine construye el paquete, instala las dependencias de requirements.txt, crea una versión nueva y —salvo que digas lo contrario— le envía el 100 % del tráfico. La URL por defecto es https://<projectId>.<region>.r.appspot.com, con certificado TLS válido desde el primer segundo y sin haber configurado nada.

Usa siempre --version con un nombre significativo. Sin él, App Engine genera un identificador con marca temporal, difícil de leer en la lista de versiones y en los comandos de reparto de tráfico.

Cada despliegue crea una versión inmutable que permanece disponible. Esto habilita algo muy potente: repartir el tráfico entre versiones.

La URL con el prefijo <version>-dot-<servicio>-dot-<proyecto> es un detalle muy útil: cualquier versión desplegada es accesible directamente, lo que permite validar en el entorno real antes de dirigirle usuarios.

Sobre el criterio de reparto, hay dos modos y la diferencia importa:

Para un canary de una interfaz de usuario, cookie es casi siempre lo correcto: con random, un cliente podría ver una página en la versión antigua y la siguiente en la nueva, con resultados desconcertantes.

Y una advertencia de coste: las versiones antiguas con instancias mínimas configuradas siguen facturando aunque no reciban tráfico. Limpia periódicamente:

App Engine estándar ofrece tres modos de escalado, y elegir mal es la principal fuente de facturas inesperadas.

El problema del arranque en frío. Con min_instances: 0 no pagas nada cuando no hay tráfico, pero la primera petición después de un periodo de inactividad tiene que esperar a que arranque una instancia: cargar el intérprete, importar las dependencias, abrir el pool de conexiones. En Python con Flask suelen ser 1–3 segundos; si el código importa bibliotecas pesadas, más.

La solución es reservar instancias calientes:

Y aquí está el compromiso, con números orientativos:

Cifras orientativas para razonar sobre el orden de magnitud. Consulta la calculadora oficial de Google Cloud.

Decisión de AlpinaShop, coherente con su realidad: en alpinashop-dev, min_instances: 0 —a Dani no le importa esperar dos segundos y el entorno pasa la noche sin tráfico. En producción, min_instances: 1 y max_instances: 10, porque un cliente que ve la tienda tardar tres segundos en cargar es un cliente que se va. Durante la campaña de otoño se sube el mínimo a 3 y el máximo a 20.

Consejos adicionales para reducir arranques en frío: importa las bibliotecas pesadas de forma perezosa, no ejecutes trabajo costoso en el arranque del módulo, y mantén requirements.txt sin dependencias que no uses.

Una aplicación de App Engine puede tener varios servicios (antes llamados módulos), cada uno con su propio app.yaml, su escalado y sus versiones. Es la forma de separar componentes con perfiles distintos.

Para AlpinaShop:

Cada servicio tiene su URL propia (https://api-dot-alpinashop-prod.ew.r.appspot.com). Para servirlos todos bajo un mismo dominio con rutas distintas, se usa dispatch.yaml:

Ventajas de separar servicios: cada uno escala según su propia carga (el panel de administración no necesita 10 instancias porque haya un pico en la tienda), se despliegan de forma independiente, y un fallo en el panel no tumba el catálogo. Es una separación de dominios de fallo, la misma idea que aplicamos en 01-05 a las zonas.

Ten en cuenta que las reglas de dispatch.yaml se evalúan en orden y solo se admiten un número limitado; para enrutamiento complejo se usa un balanceador de carga (03-02).

Aquí se ve el valor de haber usado bibliotecas cliente en las lecciones anteriores: el código no cambia.

Cada aplicación de App Engine tiene una cuenta de servicio por defecto, <projectId>@appspot.gserviceaccount.com. Basta con darle los permisos adecuados:

Con eso, el mismo storage.Client() y el mismo conector de Cloud SQL de las lecciones 02-02 y 02-03 funcionan sin tocar una línea, porque las Application Default Credentials resuelven ahora a la cuenta de servicio de App Engine.

Una particularidad del entorno estándar: el sistema de ficheros es de solo lectura salvo /tmp, que además vive en memoria y cuenta contra la memoria de la instancia. Nunca guardes ahí nada que deba persistir ni ficheros grandes. Las imágenes que suben los usuarios van directas a Cloud Storage, exactamente como programamos en 02-02 con upload_from_file sobre el flujo.

Las variables no sensibles van en app.yaml, bajo env_variables. Las sensibles, no: app.yaml acaba en el repositorio de Git y sus valores son visibles para cualquiera que pueda ver la configuración de la versión.

El patrón correcto es leer los secretos en el arranque desde Secret Manager:

Para distinguir entornos, lo habitual es tener un app.yaml por entorno (app-dev.yaml, app-prod.yaml) y desplegar el que toque:

El detalle completo de Secret Manager, la rotación de secretos y el cifrado con Cloud KMS está en la lección 03-06.

App Engine envía automáticamente a Cloud Logging las peticiones y todo lo que la aplicación escriba en la salida estándar. No hay que configurar nada.

Para que los logs sean realmente útiles, escríbelos estructurados en JSON: Cloud Logging los indexa por campos y podrás filtrar por sku o por severidad en lugar de buscar cadenas.

Los errores no capturados llegan automáticamente a Error Reporting, que los agrupa por traza de pila, cuenta ocurrencias y puede avisar cuando aparece un error nuevo. Es de lo más rentable que ofrece la plataforma sin configuración.

El tratamiento en profundidad de Cloud Logging, las métricas y las trazas está en 06-06 y 06-04.

Una petición HTTP no debe hacer trabajo largo: el usuario espera, y en escalado automático hay un límite de 10 minutos. Cuando AlpinaShop confirma un pedido, hay que enviar un correo, actualizar el stock y avisar al almacén; nada de eso debe bloquear la respuesta al cliente.

Cloud Tasks es una cola gestionada: encolas una tarea, que consiste en una petición HTTP diferida a tu propia aplicación, y el servicio la entrega con reintentos y control de ritmo.

Dos puntos críticos aquí: la comprobación de la cabecera X-AppEngine-TaskName como control de acceso, y la idempotencia. Cloud Tasks garantiza entrega al menos una vez, no exactamente una vez: si tu manejador tarda y hay un reintento, podrías enviar dos correos o descontar el stock dos veces. Registra qué pedidos ya has procesado y comprueba antes de actuar.

Cron. Para tareas programadas, cron.yaml invoca una URL de tu aplicación según un horario:

Los endpoints invocados por cron reciben la cabecera X-Appengine-Cron: true, que se comprueba igual que la de Tasks. Protege esas rutas también con un handler login: admin en app.yaml.

El servicio equivalente fuera de App Engine es Cloud Scheduler, que puede invocar HTTP, Pub/Sub o Cloud Functions y funciona con cualquier servicio de cómputo. Es la opción a usar si tu aplicación no vive en App Engine.

App Engine sigue siendo un buen producto y hay aplicaciones que llevan más de una década funcionando en él sin sobresaltos. Pero conviene ser sincero sobre sus límites en 2026:

• Acoplamiento al formato de Google. app.yaml, dispatch.yaml y cron.yaml no existen fuera de App Engine. Migrar a otro proveedor —o incluso a otro servicio de Google— implica rehacer la configuración.
• Runtimes limitados y con calendario propio. Solo los lenguajes y versiones que Google soporta; cuando una versión de Python queda obsoleta, hay que migrar en el plazo que marque Google.
• Sandbox restrictivo en el entorno estándar. Nada de binarios propios, dependencias del sistema o escritura en disco.
• El entorno flexible ha quedado desplazado. Arranca en minutos, no escala a cero y cuesta más que las alternativas basadas en contenedores.
• Región inmutable y una aplicación por proyecto. Rígido para arquitecturas que evolucionan.
• La inversión no se acumula. El tiempo dedicado a dominar app.yaml no sirve en ningún otro sitio; el tiempo dedicado a dominar contenedores sirve en todas partes.

Cloud Run (lección 07-02) ocupa hoy ese espacio: ejecuta tu contenedor, escala a cero, se factura por uso, ofrece división de tráfico entre revisiones igual que App Engine, HTTPS automático, y lo que despliegas es una imagen de contenedor estándar que también funcionaría en GKE, en tu portátil o en otra nube.

Cuándo sigue teniendo sentido App Engine: ya lo usas y funciona; quieres el camino más corto desde código Python a una URL con HTTPS; no tienes contenedores ni ganas de aprenderlos ahora mismo; o necesitas específicamente dispatch.yaml y el cron integrado.

Cuándo elegir Cloud Run: proyecto nuevo, ya trabajas con contenedores, quieres portabilidad, o necesitas control sobre el entorno de ejecución.

Para AlpinaShop, la decisión que documentaremos en 02-07 es empezar por Compute Engine (lift-and-shift, ya hecho) y evolucionar hacia contenedores. App Engine se queda como una opción conocida y descartada de forma razonada, que es la mejor manera de descartar algo.

• Crear la aplicación en la región equivocada. Es irreversible: exige proyecto nuevo. Verifica antes de gcloud app create.
• Desplegar sin .gcloudignore. Despliegues lentos y riesgo de subir .env o .git.
• Olvidar --no-promote al probar. Enviarás el 100 % del tráfico a una versión sin validar.
• Usar --split-by=random para un canary de interfaz. El usuario ve versiones distintas en peticiones consecutivas.
• Dejar versiones antiguas con min_instances > 0. Facturan sin recibir tráfico.
• Poner min_instances: 0 en producción sin medir. El arranque en frío se lo come la conversión.
• Pools de conexiones grandes. Multiplicados por muchas instancias, agotan max_connections de Cloud SQL.
• Guardar ficheros en el sistema local. Solo /tmp, en memoria y efímero.
• Secretos en env_variables de app.yaml. Acaban en Git. Usa Secret Manager.
• Manejadores de Cloud Tasks no idempotentes. La entrega es al menos una vez.
• Servir estáticos desde Flask. Usa handlers static_dir: son más rápidos y no consumen instancias.
• Consejo: pon secure: always en todos los handlers.
• Consejo: usa --version con nombres legibles.
• Consejo: muestra GAE_VERSION en la aplicación para verificar de un vistazo qué versión sirve cada petición.
• Consejo: define max_instances siempre. Es tu freno de emergencia ante un pico anómalo o un ataque.

1. Crea la aplicación de App Engine en europe-west1 sobre alpinashop-dev.
2. Escribe una aplicación Flask mínima que muestre "AlpinaShop" y la versión (GAE_VERSION), con una ruta /salud.
3. Escribe un app.yaml con runtime python312, clase F1, escalado automático de 0 a 4 instancias y un handler estático para /estatico.
4. Despliega como versión v1 y comprueba la URL.
5. Explica qué cambiarías en app.yaml para producción y justifica el coste asociado.

1. Modifica la aplicación para mostrar los precios con IVA y despliégala como v2 sin enviarle tráfico.
2. Comprueba v2 en su URL específica.
3. Envía el 20 % del tráfico a v2 con reparto por cookie.
4. Comprueba el reparto haciendo varias peticiones y observando la versión mostrada.
5. Simula un fallo y ejecuta un rollback completo a v1. Después limpia las versiones sin tráfico.

1. Crea un segundo servicio api con su propio app.yaml y escalado propio, que exponga /api/pedidos.
2. Escribe un dispatch.yaml que envíe /api/* al servicio api y el resto al default.
3. Añade un cron.yaml con una tarea diaria a las 3:00 (hora de Madrid) que llame a /tareas/exportar-pedidos en el servicio api.
4. Protege el endpoint de cron comprobando la cabecera correspondiente.
5. Explica por qué el manejador de una tarea debe ser idempotente y cómo lo garantizarías para el envío del correo de confirmación de un pedido.

Solución 1

Para producción cambiaría instance_class: F2 (más memoria para el pool de conexiones y las bibliotecas cliente), min_instances: 1 para eliminar el arranque en frío del primer cliente, y max_instances: 10 para absorber los picos de otoño. El coste añadido es el de mantener una instancia F2 encendida las 24 horas, del orden de 30–40 € al mes: una cifra pequeña frente al valor de que la portada de la tienda cargue siempre en menos de un segundo. Conviene verificar el importe en la calculadora oficial antes de comprometerse.

Solución 2

Con --split-by=cookie, si mantienes la cookie entre peticiones verás siempre la misma versión: es el comportamiento deseado para no desconcertar al usuario. Sin cookie —como en el bucle de curl anterior, donde cada llamada es una sesión nueva— el reparto se comporta como aleatorio, y en torno a 2 de cada 10 respuestas mostrarán v2.

Solución 3

5. El manejador debe ser idempotente porque Cloud Tasks garantiza entrega al menos una vez: si el manejador tarda más de lo previsto, si devuelve un error transitorio o si la instancia se recicla a mitad, la tarea se reintenta y el mismo pedido llega dos veces. Sin protección, el cliente recibiría dos correos de confirmación y el stock se descontaría dos veces.

La forma de garantizarlo para el correo de confirmación es registrar el hecho de forma transaccional en la base de datos:

La clave está en ON CONFLICT DO NOTHING sobre una clave primaria: la base de datos garantiza que solo una ejecución consigue insertar la fila, y las demás salen sin enviar nada. Devolver 204 en el segundo intento evita además reintentos infinitos.

Has visto qué significa realmente subir un nivel de abstracción. En App Engine desaparecen el sistema operativo, los parches, el servidor web, el balanceo, los certificados TLS, los health checks y las plantillas de instancia: todo lo que ocupó la lección 02-01 se reduce a un app.yaml y un gcloud app deploy. Conoces la diferencia decisiva entre el entorno estándar —sandbox, arranque en segundos, escalado a cero, barato— y el flexible —contenedores, arranque en minutos, sin escalado a cero—, y sabes que hoy el flexible ha quedado desplazado por Cloud Run.

Has diseccionado app.yaml línea a línea: runtime, entrypoint, clase de instancia, política de escalado, variables de entorno y handlers, incluida la idea de servir los estáticos desde la infraestructura de Google para no gastar instancias. Has desplegado el catálogo Flask de AlpinaShop y has obtenido una URL con HTTPS sin configurar nada. Has aprendido a desplegar con --no-promote, validar en la URL de la versión, repartir tráfico con afinidad por cookie para un canary y hacer rollback con un solo comando: prácticas de despliegue que en Compute Engine exigían plantillas versionadas y actualizaciones progresivas. Has entendido los tres modos de escalado y el compromiso central entre min_instances: 0 y el arranque en frío, con la decisión razonada de AlpinaShop: cero en desarrollo, uno en producción, tres en campaña. Has separado servicios con dispatch.yaml para que el panel de administración y el catálogo escalen por separado, has conectado Cloud SQL y Cloud Storage sin cambiar una línea de código gracias a las credenciales por defecto, has leído secretos de Secret Manager en el arranque, has visto los logs estructurados y Error Reporting, y has movido el trabajo pesado fuera de la petición con Cloud Tasks y cron.yaml, aprendiendo por el camino qué significa que una entrega sea al menos una vez y cómo escribir un manejador idempotente.

Y has terminado con una valoración honesta: App Engine es cómodo pero acoplado al formato de Google, y la inversión que haces en él no se acumula fuera de él. La alternativa que sí se acumula son los contenedores. En 02-05, Google Kubernetes Engine, daremos ese paso: repasaremos Kubernetes desde cero —contenedor, pod, Deployment, Service, nodo y plano de control—, compararemos los modos Autopilot y Standard, crearemos el clúster alpinashop-cluster, construiremos y publicaremos la imagen del catálogo en Artifact Registry, escribiremos los manifiestos de Deployment y Service, escalaremos con HorizontalPodAutoscaler y haremos actualizaciones sin corte con su rollback. Es el nivel de abstracción con más poder y también con más responsabilidad de todo el módulo.