¿Qué es serverless? La computación sin servidor explicada de forma sencilla

Serverless es una forma de ejecutar código en la que no configuras ni gestionas servidores tú mismo. Entregas tu código a un proveedor de nube, y lo ejecuta solo cuando algo lo activa (una petición web, un archivo subido, una notificación de pago) y después se detiene. Normalmente pagas por el tiempo en que tu código se está ejecutando, no por una máquina parada.

Por qué importa serverless cuando construyes con IA

Cuando creas una app con IA y miras las opciones de alojamiento o el código, te encontrarás con «funciones serverless», «funciones edge» o «funciones en la nube». Muchas plataformas de alojamiento las ofrecen, y algunos constructores de IA despliegan backends de esta forma. Entender el modelo te ayuda con tres preguntas prácticas:

• Coste. ¿Tu app costará dinero mientras nadie la usa?
• Velocidad. ¿Por qué la primera petición tras un periodo tranquilo es más lenta?
• Límites. ¿Por qué una tarea larga (generar un informe grande, procesar un vídeo) se cortó por tiempo de espera?

También conviene saber qué no es serverless: no es la ausencia de backend. Sigues teniendo código en el servidor; alguien más ejecuta las máquinas. Para lo básico, consulta qué es un servidor.

Una analogía cotidiana

Un servidor tradicional es como tener un coche en propiedad. Siempre está ahí, listo para salir al instante, pero lo pagas (seguro, aparcamiento, mantenimiento) conduzcas o no.

Serverless es como pedir un taxi. Pagas solo los trayectos que haces, y si cien personas necesitan un viaje a la vez, llegan cien taxis. Pero puede haber una pequeña espera a que llegue el coche (un arranque en frío), cada trayecto tiene una duración máxima, y el conductor no te recuerda del viaje anterior (las funciones son sin estado).

Cómo funcionan las funciones serverless

En su forma más habitual, llamada functions as a service (funciones como servicio):

1. Escribes una función: un pequeño trozo de código que gestiona un tipo de evento, como «gestionar un POST a /api/bookings».
2. La despliegas. El proveedor la guarda y la conecta a un disparador: una URL, un horario, un nuevo archivo en el almacenamiento, un mensaje en una cola.
3. Llega un evento. El proveedor inicia una copia de tu función (o reutiliza una ya caliente), la ejecuta y devuelve el resultado.
4. Se escala solo. Si llegan mil peticiones a la vez, el proveedor ejecuta muchas copias en paralelo, hasta los límites de tu cuenta.
5. Se queda inactiva. Cuando el tráfico se detiene, las copias se apagan. Sin nada en ejecución, no pagas nada por cómputo.

Una función serverless muy sencilla en JavaScript podría verse así:

export default async function handler(request) {
  const { name } = await request.json();
  return Response.json({ message: `Hola, ${name}` });
}

No hay código para arrancar un servidor, abrir un puerto ni mantener un proceso en marcha. La plataforma se encarga de todo eso.

«Serverless» también se usa de forma más amplia para otros servicios gestionados que escalan automáticamente y cobran por uso, como las bases de datos serverless, que se pausan cuando están inactivas.

Términos clave

Un ejemplo práctico: un pequeño sitio de reservas

El sitio de reservas de un estudio de yoga recibe una avalancha de visitas cada domingo por la noche, cuando se publica el nuevo horario, y muy pocas el resto de la semana.

• Con un servidor siempre encendido, el estudio paga una máquina las 24 horas, dimensionada para el pico del domingo por la noche y casi inactiva el resto del tiempo.
• Con funciones serverless, GET /api/classes y POST /api/bookings son funciones. La avalancha del domingo pone en marcha muchas copias automáticamente; un martes tranquilo por la mañana casi no se ejecuta nada y la factura es cercana a cero.

También aparecen los compromisos. La primera persona que abra el sitio el martes por la mañana podría esperar un momento extra por un arranque en frío. La base de datos tiene que gestionar muchas conexiones de corta duración desde muchas copias de funciones, lo que puede requerir un pool de conexiones. Y si el estudio quiere más adelante una tarea de «generar el PDF de asistencia anual de todos», podría superar el límite de tiempo de la función y tendría que ejecutarse en otro sitio.

Cuándo encaja serverless y cuándo no

Malentendidos habituales

• «Serverless significa que no hay backend». Significa que no hay servidores que gestionar. Sigues escribiendo y asegurando código de backend.
• «Serverless siempre es más barato». Es barato con poco volumen, pero el precio por petición puede sumar mucho con un volumen alto y constante.
• «Serverless escala infinitamente». Las plataformas tienen límites de concurrencia, y tu base de datos puede convertirse en el cuello de botella mucho antes que las funciones.
• «Los archivos guardados en una función estarán ahí la próxima vez». El almacenamiento local es temporal. Usa una base de datos o un almacenamiento de archivos.
• «Escalar a cero es lo mismo que serverless». Están relacionados, pero no son idénticos. Algunas plataformas ejecutan tu app como un servidor normal que se duerme cuando está inactivo y se despierta con la siguiente petición: ahorro similar y un retraso similar en la primera petición, pero sin los límites de tiempo por petición de las funciones.

Qué pedir a tu constructor de IA

• «¿Este backend se ejecutará como funciones serverless o como un servidor siempre encendido o que se duerme? ¿Qué significa eso para el coste?»
• «¿Alguna tarea probablemente superará el límite de tiempo de la plataforma? Si es así, ¿cómo la gestionamos?»
• «Guarda todo lo que deba persistir en la base de datos o en el almacenamiento de archivos, no en la memoria ni en archivos locales.»
• «¿Cómo deben gestionarse las conexiones a la base de datos si se ejecutan muchas copias a la vez?»
• «¿Cuánto tarda la primera petición después de que la app haya estado inactiva?»

Cómo aloja las apps Mythex

Mythex no describe su alojamiento como funciones serverless. Cuando publicas, tu app se ejecuta como una app web normal o un contenedor que Mythex gestiona por ti; no hay alojamiento que configurar. Es escalar a cero: las apps publicadas y sus bases de datos se duermen cuando están inactivas y se despiertan con la siguiente visita, una app dormida no gasta nada en cómputo, y las máquinas adicionales se inician solo cuando el tráfico es alto (Pro permite hasta 3 por servicio). La base de datos Postgres adjunta también se duerme tras 5 minutos inactiva y se factura por el tiempo que ha estado despierta. Así que obtienes buena parte del beneficio de «pagar por lo que usas», con el mismo tipo de retraso en la primera petición tras un periodo tranquilo. Consulta límites de alojamiento en la documentación, y nuestras guías sobre alojamiento web y cómo reducir los costes de alojamiento.

Preguntas