Despliega como Senior, paga como estudiante

Hernán Villavicencio S — Fri, 07 Aug 2026 20:24:14 +0000

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

Actualización de AWS WAF generado por un template de CloudFormation

Hernán Villavicencio S — Wed, 10 Dec 2025 20:26:58 +0000

El problema:
• Alerta por correo y en el panel de AWS Health Dashboard.
• El 15 de diciembre del 2025 finaliza el ciclo de vida de soporte de la versión 3.9 de python que utilizan las funciones lambdas que son generadas cuando se levanta el servicio de AWS WAF mediante el stack de cloudformation.

Arquitectura intervenida

Análisis del problema
• Se descargo y reviso los template del stack de cloudformation del servicio AWS WAF levantado en la arquitectura mencionada.
• De la revisión efectuada se puede observar en los template que el runtime de python de las funciones lambdas se crearon con python 3.8.
• En la consola de aws las funciones lambdas muestran en el runtime la version de python 3.9, esto entendemos que algún momento AWS realizo el trabajo de actualización de las funciones una vez que finalizo el ciclo de vida del soporte, pero no se realizo la actualización en los template del stack de cloudformation, por lo tanto en la consola de aws se observaba en “draft”.

Solución:

Primero descargue los template del stack de cloudformation y los guardamos en formato yml, como se muestra en la figura:

Utilizando KIRO modificamos el archivo principal del stack, reemplanzado en el parametro “Runtime: python3.8” por la versión 3.12, tal como se muestra en la figura:

Para actualizar el template en el stack del Cloudformation escogí la opción “Make a direct update”, como se muestra en la figura:

En la siguiente pantalla escogemos primero la opción “Replace existing template” y luego especificamos el archivo del template modificado en la opción “Upload a template file” y damos click en el botón “Next”, como se muestra en la figura:

Ahora en la siguiente ventana en mi caso deje como estaban los detalles del stack sin modificar nada y para seguir damos click en el botón “next”, tal como se muestra en la figura:

En este paso no modificamos nada, excepto en la parte final que debemos marcar los check la opción “Capabilities” y dar click en el botón “next”, como se muestra en la figura:

En esta última pantalla debemos revisar todo lo configurado y dar click en el boton “submit” para enviar a actualizar el stack de Cloudformation.

Luego de la actualización del stack completo en Cloudformation lo veremos de esta forma, tal como se muestra en la imagen:

Para finalizar debemos revisar que efectivamente las funciones lambdas se esten ejecutando con el runtime python versión 3.12, tal como se muestra en la figura:

Bibliografía

DEV Community: Hernán Villavicencio S

Despliega como Senior, paga como estudiante

Actualización de AWS WAF generado por un template de CloudFormation