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

Serverless es una forma de ejecutar código en la que tú no configuras ni gestionas ningún servidor. Entregas tu código a un proveedor de nube, que lo ejecuta solo cuando algo lo dispara (una petición web, un archivo subido, una notificación de pago) y luego se detiene. Normalmente pagas por el tiempo en que tu código está en ejecución, no por una máquina parada sin hacer nada.

Por qué importa serverless cuando creas 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 creadores con IA despliegan los backends de esta forma. Entender el modelo te ayuda con tres preguntas prácticas:

• Coste. ¿Tu app te cuesta dinero mientras nadie la usa?
• Velocidad. ¿Por qué la primera petición tras un periodo tranquilo tarda más?
• Límites. ¿Por qué una tarea larga, como generar un informe grande o 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; simplemente, otra persona gestiona las máquinas. Para lo básico, consulta qué es un servidor.

Una analogía cotidiana

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

Serverless es como pedir un taxi. Pagas solo los viajes que haces, y si cien personas necesitan un viaje a la vez, llegan cien taxis. Pero puede haber una breve espera hasta que llega el coche (un arranque en frío), cada viaje 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 común, llamada funciones como servicio (FaaS):

1. Escribes una función: un pequeño fragmento de código que gestiona un tipo de evento, como «gestiona un POST a /api/bookings».
2. La despliegas. El proveedor la almacena y la conecta a un disparador: una URL, una programación, un archivo nuevo en el almacenamiento, un mensaje en una cola.
3. Llega un evento. El proveedor arranca 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 para, las copias se apagan. Sin nada en ejecución, no pagas nada por el cómputo.

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

export default async function handler(request) {
  const { name } = await request.json();
  return Response.json({ message: `Hello, ${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.

El término «serverless» también se usa de forma más laxa 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: una pequeña web de reservas

La web de reservas de un estudio de yoga recibe una oleada 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 que está casi parada el resto del tiempo.
• Con funciones serverless, GET /api/classes y POST /api/bookings son funciones. La avalancha del domingo levanta muchas copias automáticamente; un martes tranquilo por la mañana casi no se ejecuta nada y la factura es casi cero.

Los compromisos también aparecen. La primera persona que abre la web un martes por la mañana puede esperar un poco más por un arranque en frío. La base de datos tiene que gestionar muchas conexiones breves 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», puede superar el tiempo límite de la función y necesitar 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 duerme cuando está inactivo y se despierta con la siguiente petición: un ahorro parecido 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 creador de apps con IA

• «¿Este backend se ejecutará como funciones serverless o como un servidor siempre encendido o que duerme? ¿Qué significa eso para el coste?»
• «¿Alguna tarea puede tardar más que 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 se gestionan las conexiones a la base de datos si muchas copias se ejecutan a la vez?»
• «¿Cuánto tarda la primera petición tras un periodo en que la app ha estado inactiva?»

Cómo aloja Mythex las apps

Mythex no describe su alojamiento como funciones serverless. Cuando publicas, tu app se ejecuta como una aplicación web o un contenedor normal que Mythex gestiona por ti; no tienes que configurar ningún alojamiento. 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 solo arrancan cuando el tráfico es intenso (Pro permite hasta 3 por servicio). La base de datos Postgres asociada también se duerme tras 5 minutos de inactividad y se factura por el tiempo que estuvo despierta. Así obtienes gran 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 los límites de alojamiento en la documentación, y nuestras guías sobre alojamiento web y cómo reducir los costes de alojamiento.

Preguntas