Google Cloud: el mapa de un sistema que ya está en producción

En el módulo 3 lo dijimos: tu IA muere al cerrar la terminal. Le pusiste un agente y ahora vive, pero vive dentro de tu computador. Bajas la tapa y se apaga. Hoy lo sacas de ahí, y de paso te muestro cómo se ve esto cuando ya no es un ejercicio sino un sistema que un cliente usa todos los días.

No necesitas un computador prendido 24 horas cobrándote 24 horas. Necesitas algo como la luz del sensor: se prende cuando alguien pasa, se apaga cuando no hay nadie. Eso es Cloud Run. Despierta tu app cuando alguien la llama, la duerme cuando nadie mira y cobra solo el rato que estuvo despierta. Por eso lo escogimos para apps pequeñas: casi todas están dormidas casi todo el tiempo.

Este es el sistema, y no es un dibujo de ejemplo: está corriendo. La app vive en Cloud Run. Guarda el día a día en Firestore. Cuando necesita entender un texto, llama a Vertex AI. Los PDF que genera los deja en un bucket. Cada noche todo eso pasa a BigQuery, y de BigQuery sale el tablero que ve el cliente. Seis piezas. Ninguna se escogió por moda.

Firestore es la bodega del día a día: guarda cada registro como una ficha suelta, sin tablas ni columnas fijas, y responde rapidísimo cuando la app pide una. BigQuery es otra cosa: ahí no se guarda para consultar de a uno, se guarda para preguntarle a millones de filas al tiempo. Una sirve para operar. La otra para entender. Meterlo todo en una sola es el error clásico.

Adentro de BigQuery los datos viven en dos capas. Bronce es lo que llegó tal cual, sin tocar, con sus errores y sus duplicados. Oro es lo mismo ya limpio, cruzado y listo para mirar. Nunca se borra el bronce: si el proceso de limpieza salió mal, se vuelve a correr desde el crudo. Es la diferencia entre la bodega y el plato servido.

Lo que mueve los datos de Firestore a BigQuery no es una persona: es un programador de tareas que corre todas las noches a la una. Si falla, llega un correo. Ese detalle separa un sistema entregado de un experimento: alguien se entera cuando algo se rompe, sin tener que revisar. Y todo existe dos veces, en pruebas y en producción, porque nadie ensaya sobre los datos del cliente.

Encima de la capa oro se conecta Looker Studio, el que muchos todavía llaman Data Studio. Arma gráficas, se comparte con un enlace y no cuesta nada. Ahí entra el cliente. Fíjate en el orden: él nunca toca la base de datos, ni el código, ni la nube. Ve un tablero. Todo lo de atrás existe para que ese tablero esté al día.

Aquí está la razón de fondo de la arquitectura. Firestore no cobra hasta cierto uso, y un sistema pequeño no llega. Looker Studio es gratis. BigQuery no cobra el primer terabyte de consultas del mes, y un negocio mediano no lo toca. Vertex cobra por texto, y le mandas el pedazo que necesita, no la base entera. Lo que queda es Cloud Run, unos pocos miles de pesos. La cuenta grande de este sistema es el tiempo de quien lo arma.

Tres cosas. La capa gratis es por cuenta de facturación, no por proyecto: diez proyectos se reparten la misma. Si dejas la app despierta para que responda al instante, pagas el mes completo aunque nadie entre. Y al subir tu app entran dos ayudantes que también cobran: el que arma el paquete y el que guarda las copias viejas, que nadie borra. Cloud Run te marca cero mientras el cobro entra por el otro lado.

Toma la carpeta de tu agente. El despliegue no lo escribes: conectas Cloud Run a tu Claude Code y se lo pides en español. Google te pide una tarjeta para abrir la cuenta, y el ejercicio entero cabe en lo gratis. Te devuelve una dirección https. Ábrela en el celular, cierra el computador del todo y vuelve a abrirla: sigue viva. Después pídele que borre el servicio y entra a facturación a mirar el número.

Ese es el sistema completo. Cada pieza entró porque hacía algo que las otras no hacían, y las que no hacían falta se quedaron por fuera. Google Cloud tiene doscientos servicios más. No los necesitas. Necesitas saber cuál pieza resuelve cuál problema, y eso ya lo tienes.