Qué son serverless y FaaS

Qué es la computación serverless

La computación serverless es un modelo de computación en la nube en el que el proveedor de la nube gestiona la infraestructura de forma automática. A diferencia del hosting web clásico, se encarga del escalado y la asignación de recursos en tu lugar. A pesar del nombre, los servidores siguen existiendo, pero tú no piensas en ellos ni los configuras. Escribes el código, lo despliegas y el proveedor de la nube se ocupa de todo lo demás, incluidos el sistema operativo, el entorno de ejecución, el escalado y la alta disponibilidad. Pagas únicamente por el tiempo de ejecución del código, no por el tiempo en que el servidor espera peticiones.

Serverless es una evolución desde los servidores físicos, pasando por las máquinas virtuales y los contenedores, hasta un modelo de computación completamente abstraído. Cada paso de esta evolución elimina una capa de responsabilidad del desarrollador y la transfiere al proveedor de la nube. En el modelo serverless, el desarrollador se centra exclusivamente en la lógica de negocio, mientras que el proveedor de la nube se ocupa de todo lo demás, lo que acelera drásticamente el desarrollo y reduce los costes operativos para muchos tipos de aplicaciones.

Functions as a Service (FaaS)

FaaS es la forma más reconocible de computación serverless. En el modelo FaaS, escribes funciones pequeñas e independientes que se ejecutan en respuesta a eventos. Cada función tiene una única responsabilidad claramente definida, recibe datos de entrada, ejecuta la lógica y devuelve un resultado. El proveedor de la nube crea automáticamente una instancia para ejecutar la función, la ejecuta y apaga la instancia al terminar. Si llegan 1000 peticiones simultáneas, el proveedor crea automáticamente 1000 instancias.

Principales proveedores de FaaS

• AWS Lambda: el primer y más maduro servicio FaaS, lanzado en 2014
• Google Cloud Functions: el FaaS de Google con buena integración con Firebase
• Azure Functions: el FaaS de Microsoft con excelente soporte para .NET
• Cloudflare Workers: edge computing con distribución global y aislamiento V8
• Vercel Functions: optimizado para Next.js y frameworks de frontend
• Netlify Functions: sencillo para sitios Jamstack

Cada proveedor tiene particularidades en cuanto a lenguajes de programación admitidos, tiempo máximo de ejecución, límites de memoria y métodos de activación (triggers). Para un enfoque más clásico, considera el servicio de cloud hosting. AWS Lambda admite Node.js, Python, Java, Go, .NET y Ruby, con un tiempo máximo de ejecución de 15 minutos y hasta 10 GB de memoria. Cloudflare Workers usa el runtime V8 con un límite de tiempo de CPU de 50 ms (plan gratuito), pero con una latencia extremadamente baja porque se ejecuta en ubicaciones edge.

Cómo funcionan las funciones serverless

Cuando un evento activa una función serverless, el proveedor de la nube pasa por varios pasos. Primero, comprueba si hay una instancia caliente ya inicializada y lista para ejecutarse. Si no la hay, se crea una nueva instancia, lo que se denomina cold start (arranque en frío). El cold start incluye el arranque del contenedor, la carga del runtime, la carga de tu código y la ejecución de la lógica de inicialización. Tras esto, la función handler se ejecuta con los datos del evento.

El problema del cold start

El cold start es la fuente más habitual de latencia en la arquitectura serverless. Para funciones Node.js, el cold start suele tardar entre 100 y 500 ms; para Python, entre 200 y 800 ms; y para Java puede ser de 1 a 5 segundos o más debido a la inicialización de la JVM. Tras la primera ejecución, la instancia permanece caliente durante un tiempo (normalmente de 5 a 15 minutos) y las peticiones posteriores se ejecutan mucho más rápido porque se saltan la inicialización.

Las estrategias para reducir el cold start incluyen usar runtimes ligeros (Node.js y Python son más rápidos que Java), minimizar el tamaño del paquete de despliegue, usar concurrencia aprovisionada (pagar por instancias precalentadas) y evitar la inicialización pesada en la función handler. AWS Lambda SnapStart para Java y Cloudflare Workers, que usa aislados (isolates) de V8 en lugar de contenedores, reducen significativamente el cold start hasta un nivel insignificante para la mayoría de las aplicaciones.

Casos de uso de serverless

La arquitectura serverless es ideal para ciertos tipos de carga de trabajo, mientras que para otros puede resultar cara o poco práctica. Comprender el caso de uso adecuado es clave para aplicar con éxito el modelo serverless en la práctica.

Escenarios ideales

• Backends de API: APIs REST o GraphQL que gestionan peticiones HTTP
• Procesamiento de eventos: reaccionar a la subida de un archivo, un cambio en la base de datos o un mensaje en una cola
• Tareas programadas: tareas cron que se ejecutan de forma periódica
• Procesamiento de imágenes y vídeo: redimensionado, compresión, transcodificación bajo demanda
• Chatbots e inferencia de IA: procesamiento de mensajes de usuario y llamadas a modelos de IA
• Webhooks: recepción y procesamiento de llamadas webhook desde servicios externos
• Procesamiento de datos IoT: procesamiento de datos de sensores y dispositivos

Escenarios menos adecuados

Serverless no es óptimo para procesos de larga duración que duren más de 15 minutos, para aplicaciones que requieran una latencia baja constante (el problema del cold start), para cargas de trabajo con tráfico constantemente alto donde un servidor dedicado resulta más barato, ni para aplicaciones que requieran un sistema de archivos local o conexiones WebSocket de larga duración. En estos casos, los contenedores o los servidores tradicionales son una mejor opción.

Modelo de precios

Una de las mayores ventajas del modelo serverless es el pago por uso. No pagas por el tiempo de inactividad del servidor, sino únicamente por el tiempo en que tu código se ejecuta de forma activa. AWS Lambda cobra por número de peticiones (0,17 € por millón de peticiones) y por la duración de la ejecución medida en GB-segundos (cuánta memoria usa la función multiplicada por la duración de la ejecución en segundos).

Comparación de costes

Para un sitio pequeño o una API con 100 000 peticiones al mes, donde cada petición tarda 200 ms con 256 MB de memoria, el coste mensual en AWS Lambda sería de menos de un euro. El servidor EC2 equivalente t3.micro cuesta unos 7,30 € al mes incluso cuando no hace nada la mayor parte del tiempo. Para este tipo de carga de trabajo, serverless es drásticamente más barato.

Sin embargo, el cálculo cambia a gran escala. Para una aplicación con 100 millones de peticiones al mes, los costes de serverless pueden superar los 170 € al mes, mientras que un servidor dedicado con una capacidad similar costaría menos. El llamado serverless cost cliff (precipicio de coste) surge cuando la carga de trabajo supera cierto umbral en el que un servidor alquilado de forma permanente resulta más rentable. Para cada aplicación, es importante hacer un análisis de costes para la carga de trabajo prevista antes de elegir un modelo.

Ventajas de la arquitectura serverless

• Sin gestión de infraestructura: no te preocupas de servidores, parches ni escalado
• Escalado automático: de cero a un millón de peticiones sin ninguna configuración
• Pago por uso: pagas únicamente por la ejecución, no por el tiempo de inactividad
• Desarrollo más rápido: centrarse en el código en lugar de en la infraestructura acelera la entrega
• Alta disponibilidad: el proveedor de la nube garantiza la disponibilidad sin tu intervención
• Escalado a cero: sin costes cuando no hay tráfico

Inconvenientes y retos

La arquitectura serverless también plantea retos específicos. El vendor lock-in (dependencia del proveedor) es real, porque cada proveedor tiene APIs, servicios y herramientas específicos que dificultan la migración a otro proveedor. La latencia del cold start puede ser problemática para aplicaciones que requieran una respuesta rápida y constante. La depuración y la monitorización son más complejas, porque las funciones se ejecutan en entornos efímeros sin acceso a las herramientas de diagnóstico tradicionales.

El desarrollo y las pruebas en local también suponen un reto, porque es difícil replicar el entorno de la nube de forma local. Herramientas como AWS SAM, Serverless Framework y LocalStack ayudan, pero no pueden simular por completo el comportamiento en producción. Los límites en el tamaño del paquete de despliegue, el tiempo de ejecución y la memoria pueden obligar a refactorizar aplicaciones existentes. Por último, para equipos sin experiencia en servicios en la nube, la curva de aprendizaje puede ser pronunciada.