Capítulo 26 — Introducción a Cloud Functions para Firebase¶

Recursos visuales propuestos¶

Antes de desarrollar este capítulo conviene distinguir entre recursos que ayudan a construir intuición y recursos que describen arquitectura real. Los conceptos introductorios como qué es serverless, la comparación entre servidor tradicional y Cloud Functions, el ciclo de vida de una función, los casos de uso y la diferencia entre cold start y warm start se entienden mejor mediante imágenes didácticas, porque buscan fijar ideas de forma progresiva y accesible. En cambio, la arquitectura completa de Cloud Functions, el flujo de ejecución, la integración con Firestore, Authentication y Storage, y la arquitectura serverless deben representarse como diagramas SVG, ya que requieren mostrar relaciones entre varios servicios, etapas de ejecución y componentes administrados por Google Cloud.[cite:1][cite:2]

Imágenes didácticas¶

¿Qué es Serverless? Conviene como imagen didáctica porque su objetivo es explicar un paradigma, no una topología técnica detallada.
Comparación servidor tradicional vs Cloud Functions. Es mejor como imagen didáctica porque facilita comprender el cambio de modelo operativo.
Ciclo de vida de una función. Debe ser imagen didáctica porque ayuda a seguir la secuencia de activación, ejecución y finalización.
Casos de uso. Conviene como imagen didáctica porque clasifica situaciones donde Functions aporta valor real.
Cold Start vs Warm Start. Debe ser imagen didáctica porque permite explicar latencia y reutilización de instancias con claridad conceptual.

Diagramas SVG¶

Arquitectura completa de Cloud Functions. Debe resolverse como SVG porque incluye Firebase, Cloud Run, Eventarc, runtime, escalado y origen de eventos.[cite:1]
Flujo de ejecución. Conviene SVG porque requiere mostrar desde el evento o solicitud hasta la respuesta y el ciclo de la instancia.
Integración con Firestore, Authentication y Storage. Debe ser SVG porque representa múltiples fuentes de eventos y consumos backend dentro del ecosistema Firebase.
Arquitectura Serverless. Debe ser SVG porque muestra cómo desaparece la administración explícita del servidor y se delega en la plataforma gestionada.

Objetivos de aprendizaje¶

Al finalizar este capítulo, el lector será capaz de:

Comprender qué es una Cloud Function y qué significa realmente el modelo serverless.
Explicar por qué surgió la computación serverless y qué problemas resuelve frente a un backend tradicional.
Entender la relación entre Cloud Functions para Firebase, Google Cloud Functions, Cloud Run y la infraestructura subyacente de Google Cloud.[cite:1][cite:2]
Describir qué ocurre internamente cuando una función se ejecuta, incluyendo instancias, tiempo de arranque, concurrencia y escalado.[cite:1][cite:2]
Identificar casos de uso apropiados para Functions dentro del proyecto oficial del libro.
Distinguir entre Cloud Functions v1 y v2, así como comprender por qué v2 es el punto de partida recomendado para funciones nuevas.[cite:1]

Introducción¶

Hasta este punto del manual, el lector ya conoce cómo almacenar datos, autenticar usuarios, guardar archivos y publicar una aplicación web. Sin embargo, toda arquitectura moderna llega tarde o temprano a una necesidad que no puede resolverse solo desde el frontend: ejecutar lógica del lado del servidor.

Esa lógica puede ser muy diversa. A veces se necesita procesar una imagen después de una carga, generar un PDF institucional, enviar correos automáticos, validar datos sensibles, integrar una API externa, programar automatizaciones o producir notificaciones que no deberían depender del navegador del usuario. En esos escenarios, Cloud Functions para Firebase aparece como una pieza central del ecosistema.[cite:1]

La idea clave es poderosa: escribir backend sin administrar servidores tradicionales. La plataforma se encarga del aprovisionamiento, la ejecución, el escalado y buena parte de la infraestructura operativa. El equipo se concentra en la lógica de negocio. Ese es el corazón del paradigma serverless.

Este capítulo introduce ese modelo desde una perspectiva arquitectónica. No se entrará todavía en HTTP Functions, Callable Functions, triggers o Scheduler como temas específicos. El objetivo actual es más fundamental: entender qué es Cloud Functions, cómo se integra con Google Cloud, por qué la segunda generación cambió profundamente el producto y cuándo conviene utilizarla en aplicaciones reales.

Desarrollo completo¶

Introducción al paradigma¶

¿Qué es una Cloud Function?¶

Una Cloud Function es una unidad de código backend que se ejecuta en infraestructura administrada por la plataforma cuando ocurre una solicitud o un evento determinado. En el ecosistema Firebase, Cloud Functions for Firebase permite desplegar esa lógica sin tener que mantener manualmente un servidor propio.

Desde la documentación oficial, la visión moderna del producto se entiende mejor a partir de su segunda generación. Firebase explica que Cloud Functions (2nd gen) despliega las funciones como servicios sobre Cloud Run, y permite activarlas usando Eventarc y Pub/Sub.[cite:1] Esto significa que ya no se trata únicamente de “trozos de código aislado”, sino de servicios empaquetados y ejecutados sobre una base más flexible y potente.

¿Qué significa Serverless?¶

“Serverless” no significa que no existan servidores. Significa que el equipo no gestiona directamente los servidores que ejecutan su lógica. Los servidores siguen existiendo, pero quedan abstraídos detrás de una plataforma administrada.

En un enfoque tradicional, el desarrollador o el equipo de infraestructura debe decidir y operar elementos como:

tamaño de servidor;
sistema operativo;
capacidad de escalado;
balanceo;
despliegue;
mantenimiento y parches;
consumo base incluso sin tráfico.

En un enfoque serverless, gran parte de esa responsabilidad pasa al proveedor cloud. El equipo define el código, el runtime y ciertas opciones de ejecución, mientras la plataforma decide cómo ejecutarlo y escalarlo en función de la demanda.[cite:2]

¿Por qué nació el modelo serverless?¶

Nació como respuesta a un problema práctico: muchas aplicaciones necesitan backend, pero no todas justifican el costo operativo de mantener servidores tradicionales. Durante años, desplegar backend significó administrar procesos persistentes, infraestructura de base, parches, capacidad ociosas y operación continua incluso para cargas intermitentes.

Serverless apareció para resolver mejor los casos donde el trabajo backend es puntual, basado en eventos o variable en el tiempo. En lugar de pagar por máquinas encendidas permanentemente, se ejecuta código cuando se necesita y se escala según la demanda. Este modelo encaja muy bien con aplicaciones móviles, web y sistemas impulsados por eventos.

Ventajas frente a un servidor tradicional¶

Las ventajas más claras son:

menor operación de infraestructura;
escalado automático;
pago por uso en lugar de capacidad fija;
integración natural con eventos del ecosistema cloud;
menor tiempo para poner en producción lógica backend.

La documentación de la comparación de versiones muestra que, en segunda generación, estas ventajas se amplían todavía más gracias a Cloud Run, tamaños de instancia mayores, tiempos de ejecución más largos y concurrencia mejorada.[cite:1]

Casos de uso¶

Cloud Functions resulta especialmente útil cuando el backend debe reaccionar a eventos o ejecutar tareas acotadas de manera flexible. Ejemplos típicos:

procesar imágenes al cargarse un archivo;
generar PDFs institucionales;
enviar correos transaccionales;
integrar APIs externas;
validar datos antes de operaciones sensibles;
automatizar procesos internos;
publicar notificaciones o tareas derivadas.

Todos estos casos aparecerán más adelante en el proyecto transversal del libro.

Arquitectura¶

Relación entre Firebase Functions y Google Cloud Functions¶

Históricamente, Cloud Functions para Firebase ha sido la forma orientada a desarrolladores Firebase de construir backend serverless sobre la infraestructura de Google. En la actualidad, la distinción importante está en que Cloud Functions para Firebase 2nd gen ya se apoya explícitamente en Cloud Run y Eventarc como parte de su arquitectura.[cite:1]

Esto implica que Firebase ofrece una capa de experiencia integrada con el ecosistema, mientras que debajo existen servicios Google Cloud especializados que ejecutan y conectan la lógica.

Cloud Run¶

La documentación oficial es contundente: Cloud Functions (2nd gen) está construida sobre Cloud Run. Las funciones se construyen con Cloud Build y se despliegan como servicios de Cloud Run usando el runtime por defecto de Cloud Run.[cite:1]

Esta es una de las ideas más importantes del capítulo. Significa que las funciones de segunda generación heredan capacidades de una plataforma más moderna:

mayor personalización del entorno;
mejor infraestructura de ejecución;
mayor escalabilidad;
mejor manejo de concurrencia;
integración con más fuentes de eventos.

Contenedores¶

Aunque el desarrollador escribe funciones y no contenedores manuales, la infraestructura moderna se apoya en imágenes construidas y almacenadas en Artifact Registry. La documentación de administración explica que, como parte del despliegue, se generan imágenes de contenedor y se almacenan en Artifact Registry.[cite:2]

Esto no es un detalle menor. Quiere decir que la función, en segunda generación, entra en una cadena de build y despliegue mucho más cercana al modelo contemporáneo de servicios cloud nativos.

Regiones¶

Las funciones no existen en una nube abstracta sin ubicación. Se despliegan en regiones concretas. La documentación de administración muestra incluso el procedimiento seguro para cambiar de región, destacando que una migración bien hecha debe crear la nueva función, desplegarla y luego eliminar la anterior para evitar pérdida de eventos.[cite:2]

La elección de región afecta:

latencia hacia usuarios o servicios vecinos;
residencia de datos y cumplimiento;
costos y topología de arquitectura;
cercanía a Firestore, Storage u otros componentes.

Escalabilidad automática¶

Una de las mayores promesas de Cloud Functions es el escalado automático. Por defecto, la plataforma ajusta el número de instancias en función de la cantidad de solicitudes entrantes y puede escalar hasta cero en periodos sin tráfico.[cite:2]

Esto representa una diferencia fundamental frente a un backend tradicional siempre encendido. No se parte de la idea de “un servidor base que siempre existe”, sino de una capacidad elástica gestionada por la plataforma.

Tiempo de ejecución¶

Cada función vive dentro de un runtime concreto. La documentación actual de Firebase Functions soporta runtimes Node.js 22 y 20, con Node.js 18 ya marcado como deprecado.[cite:2] También existe soporte para Python en versiones modernas mediante configuración de firebase.json.[cite:2]

Esto significa que Cloud Functions no es un entorno opaco. El equipo puede elegir el runtime y alinear su backend con una base tecnológica clara.

Ciclo de vida de una función¶

El ciclo de vida de una función puede resumirse así:

El código se despliega.
Firebase construye los artefactos necesarios.
La función queda disponible como servicio serverless.[cite:1][cite:2]
Cuando llega un evento o solicitud, la plataforma asigna una instancia existente o crea una nueva.
La función ejecuta su lógica.
Devuelve respuesta o concluye su procesamiento.
La instancia puede quedar disponible para nuevas ejecuciones o escalar a cero si deja de ser necesaria.

Este ciclo es muy distinto al de un servidor tradicional persistente. En serverless, la unidad de ejecución vive dentro de una elasticidad controlada por la plataforma.

Funcionamiento¶

¿Qué ocurre cuando se ejecuta una función?¶

Cuando una función se ejecuta, la plataforma determina si ya existe una instancia disponible capaz de atender la solicitud o el evento. Si existe, reutiliza esa instancia. Si no, crea una nueva. Este comportamiento es el que da lugar a la diferencia entre cold start y warm start.

En segunda generación, además, una misma instancia puede atender múltiples solicitudes simultáneas gracias a la concurrencia configurable.[cite:1][cite:2] Eso cambia de manera importante la forma en que el sistema absorbe picos de tráfico.

Cold Start¶

Un cold start ocurre cuando la plataforma necesita inicializar una nueva instancia antes de ejecutar la función. Eso añade latencia porque hay que arrancar el runtime, cargar dependencias, preparar el contenedor y dejarlo listo para procesar la solicitud.

La documentación oficial explica que el uso de concurrencia y minInstances en segunda generación puede ayudar a reducir cold starts en ciertas cargas.[cite:2] También aclara que la cantidad óptima depende del patrón de tráfico de la aplicación.

Warm Start¶

Un warm start ocurre cuando la solicitud puede ser atendida por una instancia ya inicializada. En ese caso la latencia suele ser menor porque se evita buena parte del costo de arranque.

Desde el punto de vista del desarrollador, warm start es una consecuencia de reutilización eficiente de instancias. La meta no es eliminar por completo el cold start, sino diseñar la arquitectura considerando su impacto y utilizando las opciones de la plataforma de forma inteligente.

Tiempo de respuesta¶

El tiempo de respuesta de una función depende de múltiples factores:

si la instancia estaba fría o caliente;
complejidad del trabajo realizado;
CPU y memoria asignadas;
cercanía regional a los servicios consumidos;
concurrencia;
tamaño de dependencias cargadas.

Aquí se vuelve evidente que serverless no elimina la necesidad de pensar en rendimiento. Solo cambia el lugar donde se toman ciertas decisiones.

Concurrencia¶

La comparación oficial de versiones indica que Cloud Functions v1 maneja una solicitud concurrente por instancia, mientras que v2 soporta hasta 1000 solicitudes simultáneas por instancia.[cite:1] La guía de administración añade que el valor por defecto de concurrencia en v2 es 80 y puede configurarse entre 1 y 1000.[cite:2]

Este cambio es enorme. Significa que una función v2 puede absorber ráfagas de tráfico con menos instancias nuevas, reduciendo cold starts y mejorando latencia cuando el tipo de trabajo lo permite.[cite:1][cite:2]

Escalado automático¶

El escalado en v2 combina número de instancias, concurrencia por instancia y opciones como minInstances y maxInstances.[cite:2] Esto permite un control mucho más fino que en primera generación.

Por ejemplo:

minInstances ayuda a mantener instancias calientes para funciones críticas en latencia.[cite:2]
maxInstances permite contener costos o proteger servicios de respaldo como bases de datos legadas.[cite:2]
la concurrencia bien ajustada reduce el número de arranques fríos.[cite:2]

Integración¶

Firestore¶

Cloud Functions se integra estrechamente con Firestore como origen de eventos y como servicio backend de lectura o escritura. Aunque los triggers específicos se verán más adelante, desde ahora conviene entender que Firestore y Functions forman una pareja muy potente: la base de datos almacena el estado y la función ejecuta procesos derivados del cambio de estado.

Authentication¶

Authentication también se integra con Functions. Más adelante se verán eventos y hooks concretos, pero la idea general es clara: la autenticación resuelve identidad, y Functions permite ejecutar lógica complementaria alrededor de procesos de alta, bloqueo, verificación o perfilado, según el tipo de evento soportado por la versión de Functions utilizada.[cite:1]

Cloud Storage¶

Cloud Storage es uno de los casos más naturales de integración. Cuando un archivo se carga, cambia o se archiva, una función puede encargarse de procesamiento adicional. Esto encaja perfectamente con escenarios como miniaturas, compresión, OCR, metadatos o generación de derivados.

Hosting¶

Hosting y Functions forman una combinación especialmente potente cuando el frontend necesita un backend sin salir del ecosistema Firebase. Hosting publica la interfaz; Functions ejecuta lógica del servidor; el usuario ve una sola aplicación coherente.

Cloud Scheduler¶

Cloud Scheduler entra en juego cuando no basta con reaccionar a eventos espontáneos y se necesita ejecución programada. Aunque los detalles vendrán más adelante, es importante saber desde ahora que Functions también puede encajar en automatizaciones temporales dentro de una arquitectura serverless.

Pub/Sub¶

La documentación de comparación de versiones destaca la integración con Eventarc y Pub/Sub en la segunda generación.[cite:1] Esto amplía de forma importante el universo de eventos y patrones de integración disponibles para el backend serverless.

Versiones¶

Cloud Functions v1¶

La primera generación es la versión original del producto. Sigue soportada, pero con capacidades más limitadas en triggers, configurabilidad y ejecución.[cite:1]

Cloud Functions v2¶

La segunda generación es la recomendada para nuevas funciones siempre que sea posible.[cite:1] Está construida sobre Cloud Run y Eventarc, soporta mayor concurrencia, mayor tamaño de instancias, tiempos de ejecución más largos y mejor cobertura de eventos.[cite:1]

Diferencias¶

La tabla oficial destaca diferencias muy concretas:

v1: hasta 9 minutos de timeout; v2: hasta 60 minutos para funciones HTTP y hasta 9 minutos para funciones activadas por eventos.[cite:1]
v1: hasta 8 GB RAM y 2 vCPU; v2: hasta 16 GiB RAM y 4 vCPU.[cite:1]
v1: 1 solicitud concurrente por instancia; v2: hasta 1000.[cite:1]
v1 usa por defecto la service account de App Engine; v2 usa la service account compute por defecto de Google Cloud.[cite:1]

Ventajas de v2¶

Las ventajas principales de v2 son:

infraestructura basada en Cloud Run;
concurrencia mejorada;
mejor escalado;
más control sobre CPU, memoria y runtime;
tiempos de procesamiento más largos;
integración más amplia con eventos mediante Eventarc.[cite:1][cite:2]

Compatibilidad¶

La propia documentación aclara que v1 y v2 pueden coexistir en el mismo archivo fuente. Esto es importante porque algunos tipos de eventos todavía presentan limitaciones en v2, como Analytics events o ciertos eventos básicos de Authentication.[cite:1]

En otras palabras: el camino recomendado es preferir v2 para nuevas funciones, pero entender que la coexistencia con v1 sigue siendo una herramienta práctica de compatibilidad.

Casos de uso¶

Procesamiento de imágenes¶

Uno de los usos más comunes es reaccionar a una carga en Storage y procesar una imagen: redimensionarla, generar miniaturas, convertir formato o aplicar análisis automatizado. Este patrón encaja muy bien con el proyecto del libro para fotografías de perfil, credenciales e imágenes institucionales.

Envío de correos¶

Otra necesidad clásica es el correo transaccional. El frontend no debería contener credenciales sensibles ni depender del navegador del usuario para mandar correos institucionales. Functions resuelve ese backend de forma segura y centralizada.

Generación de PDFs¶

La generación de PDFs es un ejemplo excelente de lógica del servidor. Crear documentos oficiales, constancias, credenciales o reportes suele requerir plantillas, validación y acceso controlado a datos. Functions permite centralizar ese proceso y ejecutarlo bajo reglas backend.

Integración con APIs¶

Muchas aplicaciones necesitan hablar con sistemas externos: CRMs, pasarelas, APIs de firma, servicios de mensajería, sistemas escolares o plataformas de facturación. Functions sirve como capa de integración para encapsular credenciales y orquestar esos flujos.

Automatización¶

Automatizar significa reaccionar sin intervención manual. Cuando cambia un dato, se crea un archivo o se cumple una condición temporal, una función puede ejecutar la acción necesaria.

Validación de datos¶

El frontend puede validar experiencia de usuario, pero la validación sensible y confiable debe ocurrir en backend. Functions es una ubicación natural para esa lógica cuando se requiere aplicar reglas de negocio que no deben depender solo del cliente.

Ventajas¶

Escalabilidad¶

Cloud Functions escala automáticamente y v2 mejora esta propiedad gracias a Cloud Run y la concurrencia configurable.[cite:1][cite:2]

Pago por uso¶

El modelo económico resulta atractivo porque la plataforma escala según demanda. Aunque hay que vigilar costos reales, especialmente en cargas intensivas o mal diseñadas, el enfoque serverless evita pagar infraestructura fija innecesaria en muchos escenarios.

Seguridad¶

Functions centraliza lógica sensible en backend y reduce la exposición de secretos, integraciones o reglas críticas al navegador del usuario. Además, puede usar service accounts y permisos controlados para acceder a recursos cloud.[cite:2]

Mantenimiento reducido¶

No hay que administrar directamente servidores de aplicación, balanceadores ni ciclos completos de parchado del entorno base. La plataforma absorbe buena parte de esa carga operativa.

Limitaciones¶

Cold Starts¶

Los cold starts siguen siendo una limitación inherente al modelo serverless, especialmente en cargas esporádicas. v2 reduce parte del problema mediante concurrencia y minInstances, pero no lo elimina mágicamente.[cite:1][cite:2]

Límites de ejecución¶

Aunque v2 amplía tiempos, memoria y CPU, sigue habiendo límites. No toda carga de trabajo encaja bien en Functions. Trabajos extremadamente largos, persistentes o con requisitos muy particulares pueden necesitar otro tipo de servicio.

Costos¶

Pago por uso no significa siempre “barato”. Funciones mal diseñadas, con exceso de memoria, alta frecuencia, demasiadas dependencias o uso incorrecto de concurrencia pueden generar costos mayores a los esperados. Además, la documentación advierte que en v2 el default de CPU puede incrementar precio por milisegundo para funciones de baja memoria respecto a ciertos casos de v1.[cite:2]

Cuándo NO utilizar Cloud Functions¶

No conviene usar Functions cuando:

se necesita un servidor persistentemente conectado por largos periodos;
el trabajo requiere control muy específico del entorno más allá de lo razonable para Functions;
una aplicación exige procesos backend continuos o sesiones persistentes típicas de otro modelo;
la latencia ultraestable es crítica y no se quiere asumir cold starts en ningún caso;
el patrón encaja mejor en Cloud Run, GKE u otra arquitectura dedicada.

Casos reales¶

Proyecto transversal del libro¶

En la plataforma educativa, Cloud Functions cumplirá un papel decisivo como backend de procesos que no deberían ejecutarse en cliente:

Generación de credenciales: crear documentos oficiales o versiones imprimibles.
Procesamiento de imágenes: adaptar fotografías para credenciales, perfiles o evidencias.
Envío de correos: comunicar altas, cambios o avisos institucionales.
Generación de PDFs: constancias, reportes o comprobantes.
Validaciones: verificar reglas de negocio antes de cerrar procesos críticos.
Automatizaciones: reaccionar a cambios en datos o archivos.
Notificaciones: disparar procesos internos o externos según eventos.

Todo esto complementa Firestore, Storage, Authentication y Hosting sin obligar al equipo a construir un backend tradicional desde cero.

Plataforma educativa¶

Una escuela digital necesita tanto frontend como procesos internos. El frontend gestiona interacción. Functions gestiona automatización y reglas sensibles. Esta separación es una señal de madurez arquitectónica.

SaaS documental¶

Un SaaS documental puede usar Functions para convertir archivos, indexar contenido, generar resúmenes, validar metadatos o integrar servicios de firma electrónica.

E-commerce ligero¶

Un sistema comercial puede apoyarse en Functions para confirmar pagos, validar inventario, producir comprobantes o integrar pasarelas externas sin exponer secretos en cliente.

Comparaciones técnicas¶

Servidor tradicional vs Cloud Functions¶

Aspecto	Servidor tradicional	Cloud Functions
Infraestructura	Se administra directamente	La administra la plataforma
Escalado	Requiere diseño y operación explícita	Escalado automático [cite:2]
Pago	Suele incluir capacidad fija	Orientado a uso y ejecución
Operación	Más mantenimiento	Menor carga operativa
Eventos	Requiere construcción manual	Integración nativa con eventos Firebase y Google Cloud [cite:1]
Concurrencia	Depende del servidor y framework	En v2 configurable hasta 1000 por instancia [cite:1][cite:2]

Cloud Functions v1 vs v2¶

Aspecto	v1	v2
Base tecnológica	Generación original	Construida sobre Cloud Run y Eventarc [cite:1]
Timeout	Hasta 9 min [cite:1]	Hasta 60 min HTTP, 9 min eventos [cite:1]
Memoria	Hasta 8 GB [cite:1]	Hasta 16 GiB [cite:1]
CPU	Hasta 2 vCPU [cite:1]	Hasta 4 vCPU [cite:1]
Concurrencia	1 por instancia [cite:1]	Hasta 1000 por instancia [cite:1]
Recomendación	Compatibilidad y legado	Opción preferida para funciones nuevas [cite:1]

Cloud Functions vs backend propio¶

Criterio	Cloud Functions	Backend propio
Velocidad de inicio	Alta para casos comunes	Menor, requiere infraestructura
Control fino	Medio	Alto
Operación	Baja	Alta
Elasticidad	Muy buena	Depende del diseño
Persistencia	No orientada a procesos persistentes	Sí, si se diseña así
Ajuste ideal	Eventos, integraciones, tareas acotadas	Sistemas con control específico o procesos persistentes

Buenas prácticas¶

Empezar por funciones pequeñas y bien delimitadas.
Diseñar cada función con una responsabilidad clara.
Modularizar el código y compartir utilidades comunes.
Evitar dependencias innecesarias para reducir tamaño y tiempos de arranque.
Elegir región con criterio de latencia y cercanía a otros servicios.
Pensar en idempotencia para evitar efectos secundarios duplicados.
Ajustar memoria, timeout, concurrencia y límites con base en pruebas, no por intuición.[cite:2]
Preferir v2 para funciones nuevas cuando no exista una limitación concreta de compatibilidad.[cite:1]
Mantener bajo control los artefactos generados en Artifact Registry para evitar costos acumulados.[cite:2]
Usar service accounts limitadas cuando la función no necesita permisos amplios.[cite:2]

Errores comunes¶

Pensar que serverless significa “sin backend”.
Llevar a Functions lógica que en realidad debería vivir en frontend o en otra capa.
No considerar cold starts al diseñar flujos sensibles en latencia.
Asumir que el escalado automático corrige cualquier mal diseño.
Ignorar costos de memoria, CPU, concurrencia o minInstances.[cite:2]
Usar demasiadas dependencias y aumentar el peso del runtime.
Elegir v1 por costumbre sin evaluar ventajas reales de v2.[cite:1]
No documentar qué procesos deben ejecutarse en backend y cuáles no.

Resumen¶

Cloud Functions para Firebase es la pieza del ecosistema que permite ejecutar lógica backend sin administrar directamente la infraestructura subyacente. En la actualidad, su evolución más importante está en la segunda generación, donde Firebase despliega las funciones como servicios sobre Cloud Run y las integra con Eventarc y Pub/Sub para ampliar su alcance y flexibilidad.[cite:1]

Entender el paradigma serverless implica asumir una idea central: los servidores siguen existiendo, pero la responsabilidad de operarlos pasa a la plataforma. El equipo define código, runtime y opciones de ejecución; Google Cloud se encarga del aprovisionamiento, la escalabilidad y buena parte del plano operativo.[cite:1][cite:2]

La arquitectura de ejecución explica muchas de sus ventajas y limitaciones. Functions puede escalar automáticamente, incluso hasta cero en momentos sin tráfico, pero también está sujeta a cold starts, límites de ejecución y decisiones de configuración como memoria, CPU, concurrencia, minInstances y maxInstances.[cite:2] Por eso no basta con decir que serverless escala: hay que entender cómo escala y a qué costo.

La comparación entre v1 y v2 deja claro por qué Firebase recomienda usar v2 para nuevas funciones siempre que sea posible. Más memoria, más CPU, mayor timeout, mejor concurrencia y una base tecnológica moderna sobre Cloud Run convierten a la segunda generación en el punto de partida natural para arquitecturas actuales.[cite:1]

En el proyecto transversal del libro, Cloud Functions será el backend de procesos críticos que no deben vivir en cliente: generación de credenciales, procesamiento de imágenes, correos institucionales, PDFs, validaciones y automatizaciones. Con ello, el sistema evoluciona de una aplicación basada solo en servicios de datos y frontend a una arquitectura completa, capaz de ejecutar lógica de negocio real en producción.

Conceptos clave¶

Cloud Function.
Serverless.
Functions as a Service.
Cloud Functions for Firebase.
Cloud Run.[cite:1]
Eventarc.[cite:1]
Pub/Sub.[cite:1]
Artifact Registry.[cite:2]
Runtime.
Región.[cite:2]
Escalado automático.[cite:2]
Cold start.[cite:2]
Warm start.
Concurrencia.[cite:1][cite:2]
minInstances.[cite:2]
maxInstances.[cite:2]
Cloud Functions v1.[cite:1]
Cloud Functions v2.[cite:1]

Preguntas de repaso¶

¿Qué es una Cloud Function y qué tipo de problema resuelve dentro de una arquitectura Firebase?
¿Qué significa realmente serverless y por qué no implica la desaparición de los servidores?
¿Por qué surgió el modelo serverless como alternativa a ciertas arquitecturas tradicionales?
¿Qué relación existe entre Cloud Functions v2 y Cloud Run?[cite:1]
¿Qué ocurre internamente cuando una función debe ejecutarse por primera vez y no hay instancias disponibles?
¿Qué diferencia existe entre cold start y warm start?
¿Por qué la concurrencia de v2 cambia de forma importante el comportamiento del escalado?[cite:1][cite:2]
¿Qué ventajas concretas ofrece v2 sobre v1?[cite:1]
¿Cuándo no conviene usar Cloud Functions como solución backend?
¿Qué procesos del proyecto del libro deberían implementarse en Functions y por qué?

Ejercicios prácticos¶

Redacta una explicación breve y profesional de serverless para un equipo que solo ha trabajado con servidores tradicionales.
Dibuja la arquitectura conceptual de Cloud Functions v2 indicando el papel de Cloud Run, Eventarc y Artifact Registry.[cite:1][cite:2]
Clasifica las siguientes tareas entre frontend, Firestore, Storage o Functions: generar un PDF, enviar un correo, convertir una imagen, validar una operación crítica y mostrar una lista de alumnos.
Diseña una propuesta inicial de backend serverless para la plataforma educativa del libro sin escribir todavía código.
Explica qué decisiones tomarías para minimizar cold starts en una función crítica de latencia.[cite:2]
Compara una función v1 y una v2 para una tarea con picos de tráfico repentinos y justifica cuál elegirías.[cite:1][cite:2]
Propón una estrategia de organización modular para un proyecto de Functions que crecerá con el resto del manual.
Analiza qué riesgos de costo podrían aparecer si una función usa demasiada memoria, demasiadas dependencias o minInstances de forma inadecuada.[cite:2]
Explica cuándo preferirías otra alternativa de backend distinta de Cloud Functions.
Diseña un checklist conceptual previo a la creación de la primera función del proyecto oficial.

Bibliografía y referencias oficiales¶

Cloud Functions version comparison: https://firebase.google.com/docs/functions/version-comparison [cite:1]
Manage functions | Cloud Functions for Firebase: https://firebase.google.com/docs/functions/manage-functions [cite:2]