Función sin servidor

¿Qué es una función sin servidor?

Una función sin servidor (serverless) es un fragmento pequeño de código que un proveedor cloud ejecuta bajo demanda como respuesta a un evento, como una petición HTTP, la subida de un archivo o un mensaje de una cola. Tú despliegas el código; el proveedor aprovisiona, escala y parchea los servidores, y pagas por la ejecución en lugar de por máquinas inactivas. En esta página se usa AWS Lambda como ejemplo.

Cómo funciona una función sin servidor

Escribes un handler y lo conectas a un disparador. Cuando llega un evento, la plataforma necesita un entorno de ejecución. Si hay uno listo y libre, lo reutiliza (arranque en caliente, warm start). Si no, crea uno nuevo: descarga el código, inicia el runtime y ejecuta tu código de inicialización, y solo entonces llama al handler (arranque en frío, cold start). Por defecto, cada entorno atiende una petición a la vez, así que más peticiones simultáneas significan más entornos.

AWS define la concurrencia como las peticiones en curso a la vez y da una fórmula sencilla: concurrencia = peticiones medias por segundo x duración media en segundos. Con 100 peticiones por segundo y 500 ms por petición, son 50 entornos.

Ejemplo

Una tienda guarda fotos de producto en un bucket. Cada subida dispara una función que crea una miniatura y la guarda de nuevo. No hay servidor que mantener encendido: en una importación masiva se ejecutan cientos de funciones en paralelo y por la noche, ninguna. Una segunda función tras un endpoint de API podría servir el catálogo a la web.

Límites importantes (AWS Lambda)

• Timeout: hasta 900 segundos (15 minutos) por invocación. Los trabajos más largos hay que dividirlos o llevarlos a otro servicio.
• Memoria: de 128 MB a 10.240 MB, con CPU asignada en proporción.
• Concurrencia: 1.000 ejecuciones concurrentes por región por defecto (cuota ampliable), compartidas por todas las funciones de la cuenta.
• Ritmo de escalado: cada función puede añadir como máximo 1.000 entornos de ejecución cada 10 segundos, de modo que una ráfaga muy súbita puede ser limitada.
• Carga útil: 6 MB para una petición o respuesta síncrona.
• Cold starts: según AWS afectan normalmente a menos del 1 % de las invocaciones y añaden desde menos de 100 ms hasta más de 1 segundo. La concurrencia aprovisionada inicializa entornos de antemano para reducirlos.

Los límites y valores por defecto cambian, así que consulta la página actual de cuotas de AWS Lambda antes de dimensionar nada.

Errores comunes

• Suponer que escala sin límite. La función puede escalar, pero la base de datos, la API de terceros o el microservicio que hay detrás a menudo no. Una ráfaga de funciones puede agotar las conexiones a la base de datos.
• Juzgar la velocidad por la media. Los cold starts viven en la cola. Mira p95 y p99, consulta latencia.
• Meter trabajos largos en una función. Todo lo que se acerque al timeout necesita una cola u otro servicio.
• No probar nunca una ráfaga. Una función que va bien a 10 peticiones por segundo puede limitarse cuando el tráfico salta; un spike test lo detecta.
• Configurar a mano. Memoria, timeout y concurrencia deben estar en código, consulta infraestructura como código.

Probar y monitorizar funciones sin servidor

Haz un test de carga del endpoint público delante de la función, normalmente un API gateway, con un perfil que supere el pico esperado, y compara percentiles, tasa de errores y limitación. LoadFocus load testing puede enviar ese tráfico desde 25 regiones cloud con JMeter o k6; el plan Free cubre 10 usuarios virtuales durante 60 segundos. Recuerda que tu proveedor cloud factura cada invocación de prueba. Para el método completo, consulta performance testing serverless architectures (en inglés). En producción, la monitorización de APIs, como LoadFocus API Monitoring (los checks gratuitos se ejecutan cada 5 minutos), muestra cómo se comportan esos endpoints con el tiempo, incluida la primera llamada lenta ocasional.

Preguntas frecuentes

¿Las funciones sin servidor no tienen servidores?

Sí los tienen. Siguen ejecutando tu código. El término significa que no los aprovisionas, parcheas ni escalas tú mismo.

¿Qué es un cold start?

El tiempo extra que tarda la plataforma en crear un entorno de ejecución nuevo antes de poder ejecutar tu handler. Las peticiones posteriores que reutilizan el entorno se lo ahorran.

¿Cómo se factura una función sin servidor?

En las funciones de eventos de AWS Lambda, por petición más el tiempo de ejecución multiplicado por la memoria configurada (GB-segundos). Si no llegan peticiones, no pagas computación.

¿Cuándo no conviene usar una función sin servidor?

Para trabajos más largos que el timeout, para cargas que necesitan latencia muy baja y estable en cada petición, o con tráfico tan constante e intenso que los servidores siempre encendidos salen más baratos. Mide antes de decidir.