Despliega como Senior, paga como estudiante

Serverless en Google Cloud: Cloud Functions + Firestore + Cloud Storage con Terraform

Si vienes del mundo AWS y siempre quisiste probar Google Cloud sin gastar un centavo, este post es para ti. Vamos a levantar una API serverless completa: con base de datos, frontend y todo automatizado con Terraform, que corre dentro del Free Tier de GCP. Cero servidores que administrar, cero facturas sorpresa.

La idea es simple: montar una app de tareas (una “to-do list”) donde el backend es una función serverless, los datos viven en una base NoSQL administrada, y el frontend es un archivo estático servido desde el equivalente de S3. Todo desplegado con un terraform apply.

El mapa mental: de AWS a GCP
Lo mejor para aprender una nube nueva es anclarla a la que ya conoces. Si has trabajado con el stack serverless de AWS, estas son las equivalencias directas:

La arquitectura completa cabe en un diagrama de tres cajas:

Y así se ve con los servicios reales de Google Cloud:

Arquitectura serverless en GCP: el navegador consume el frontend desde Cloud Storage y la API desde Cloud Functions Gen 2, que lee y escribe en Firestore, corre sobre Cloud Run, se autentica con una Service Account y envía logs a Cloud Logging.
Costo total: $0. Todo entra en el Free Tier de GCP.

Lo que necesitas antes de empezar

Un detalle importante que a muchos los frena en el primer despliegue: aunque todo caiga en el Free Tier, GCP exige tener una cuenta de facturación vinculada al proyecto para poder crear Cloud Functions, Firestore y usar Cloud Build. No te van a cobrar por el consumo del demo, pero el billing debe estar habilitado. Al crear tu cuenta en el Free Tier obtienes además $300 de crédito para tus primeros 90 días.

Configurar credenciales GCP

# 1. Autenticarse con tu cuenta Google
gcloud auth login

# 2. Crear o seleccionar un proyecto
gcloud projects create mi-proyecto-serverless   # o usa uno existente
gcloud config set project mi-proyecto-serverless

# 3. Habilitar credenciales para Terraform (Application Default Credentials)
gcloud auth application-default login

# 4. Verificar que funciona
gcloud config get-value project

Terraform usa las Application Default Credentials automáticamente: no necesitas crear ni descargar claves JSON. Es más limpio y más seguro que andar rotando llaves de service account a mano.

Desplegar en 3 comandos

# 1. Entrar a la carpeta de Terraform
cd charla-serverless-gcp/demo/terraform

# 2. Inicializar Terraform (descarga el provider de GCP)
terraform init

# 3. Desplegar toda la infraestructura
terraform apply -var="gcp_project_id=TU_PROJECT_ID"

Terraform se encarga de todo: habilita las APIs necesarias (Cloud Functions, Cloud Build, Firestore, Cloud Run, Artifact Registry), crea la base de datos, la service account con sus permisos, los buckets y la función.

Al terminar, imprime las URLs:

api_url      = "https://tasks-demo-api-xxxx-uc.a.run.app/tasks"
frontend_url = "https://storage.googleapis.com/tasks-demo-frontend-xxxx/index.html"

Abres el frontend_url en el navegador y ya tienes la app funcionando.

Un dato del mundo real: el primer despliegue de la Cloud Function tarda alrededor de 3 minutos y medio. No es que se haya colgado, es Cloud Build compilando tu código en la nube. Esa es una de las diferencias que se sienten viniendo de Lambda, donde subes un ZIP y arranca casi al instante. Aquí ganas un runtime más flexible y mejor manejo de dependencias, a cambio de un build inicial más lento.

Probar la API

BASE="https://tasks-demo-api-xxxx-uc.a.run.app"

# Crear una tarea
curl -s -X POST "$BASE/tasks" \
  -H "Content-Type: application/json" \
  -d '{"title": "Mi primera tarea serverless en GCP ☁️"}'

# Listar tareas
curl -s "$BASE/tasks"
Respuesta del POST:
{
  "id": "76f1b416-5934-4851-ad95-014490eda3b7",
  "title": "Mi primera tarea serverless en GCP ☁️",
  "completed": false,
  "created_at": "2026-08-06T17:42:20.555504+00:00"
}

La tarea queda persistida en Firestore y el GET la devuelve. API serverless funcional, de punta a punta, sin haber tocado un solo servidor.

Las diferencias que se sienten viniendo de AWS

Routing más simple
En AWS necesitabas API Gateway con sus recursos, métodos e integraciones. En GCP, Cloud Functions Gen 2 expone una URL HTTPS directamente y el routing lo hace tu propio código Python. Menos piezas de infraestructura que mantener.

Sin módulos por cada método HTTP
El Terraform de AWS solía tener módulos para lambda_method y cors_options por cada endpoint. En GCP no existe ese concepto: una sola función maneja todos los métodos (GET, POST, etc.) y el CORS lo resuelves en el código o en el bucket.

Firestore vs DynamoDB
DynamoDB te pide definir hash_key y el billing_mode. Firestore trabaja con colecciones y documentos sin esquema, sin configuración de capacidad. Escribes y lees; la escala la maneja Google.

Cloud Run por debajo
Las Cloud Functions Gen 2 corren sobre Cloud Run internamente. Por eso el endpoint termina siendo una URL *.run.app y no una cloudfunctions.net. Esto te da, gratis, mejor cold start, concurrencia por instancia y la posibilidad de migrar a contenedores el día que lo necesites.

Limpiar todo al terminar

terraform destroy -var="gcp_project_id=TU_PROJECT_ID"

En cerca de un minuto borra todo. Un detalle con Firestore: la base de datos (default) es única por proyecto y por defecto Terraform la “abandona” (deletion_policy = ABANDON) en lugar de borrarla. Si quieres que el destroy también elimine la base —útil si vas a repetir el demo desde cero en el mismo proyecto— pon deletion_policy = "DELETE" en el recurso google_firestore_database.

El repositorio
Todo el código, el handler.py de la función, el frontend, y el módulo de Terraform completo, está en GitHub para que lo clones, lo despliegues y lo adaptes:

Repo: https://github.com/VillaviH/charla-serverless-gcp

La estructura es mínima y fácil de leer:

Para cerrar
Serverless no tiene por qué ser caro ni complicado, y no está atado a una sola nube. Si ya dominas el stack de AWS, GCP te resulta familiar en un par de horas: los conceptos son los mismos, cambian los nombres y algunos detalles de implementación. La mejor forma de aprenderlo es exactamente esta, desplegar algo real, probarlo, y destruirlo sin miedo a la factura.

Clona el repo, levántalo en tu propia cuenta y cuéntame cómo te fue. Y si vas a llevar esto a producción, recuerda cerrar los accesos públicos.

Despliega como senior, paga como estudiante.

Hernán Villavicencio - AWS Community Builder - linkedin.com/in/hvillavicencio