¿Qué es serverless? El futuro de la arquitectura sin servidor

01¿Qué es serverless?

Pese a su nombre, serverless no significa «sin servidores». Su código sigue ejecutándose en máquinas de un centro de datos; la diferencia es que esas máquinas las gestiona el proveedor de nube y no usted. Las actualizaciones del sistema operativo, la planificación de capacidad, el balanceo de carga y las averías de hardware dejan de ser asunto suyo.

Un servidor tradicional está encendido las 24 horas, los 7 días de la semana, haya peticiones o no, y se paga en consecuencia. En una arquitectura sin servidor, en cambio, el código se activa solo cuando se dispara, hace su trabajo y se apaga. Sin tráfico, el coste se acerca a cero.

Este enfoque forma parte de la tendencia general del mundo del software: abstraer la complejidad de la infraestructura para que el equipo se concentre solo en la lógica de negocio. Tratamos estas tendencias en un marco más amplio en nuestro artículo tendencias de software 2026.

02Cómo funciona Function as a Service

En el modelo Function as a Service (FaaS) usted divide la aplicación en funciones pequeñas, centradas en una sola tarea. Cada función se dispara con un evento: una petición HTTP, un mensaje que llega a una cola, un archivo subido al almacenamiento o una tarea programada.

AWS Lambda, Azure Functions, Google Cloud Functions y Cloudflare Workers son ejemplos conocidos de este modelo. La lógica es la misma en todos; el entorno de ejecución, los límites de tiempo y los detalles de precios varían según el proveedor.

1. Ocurre un evento; por ejemplo, un usuario envía un formulario.
2. El proveedor prepara un entorno de ejecución para la función o reutiliza uno que ya está listo.
3. La función procesa el evento, devuelve el resultado y lo escribe en una base de datos.
4. Si aumenta la demanda, el proveedor ejecuta en paralelo muchas copias de la misma función.

export const handler = async (event) => {
  const ad = event.queryStringParameters?.ad || 'visitante';
  return {
    statusCode: 200,
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ mesaj: `Merhaba ${ad}` })
  };
};

03Ventajas de serverless

Las ventajas de serverless se notan sobre todo en los equipos con tráfico irregular que quieren lanzar productos con rapidez.

Piense en un sitio de reservas cuyo tráfico se multiplica en temporada turística, o en una tienda que hace unas pocas grandes campañas al año. En una arquitectura clásica tendría que reservar capacidad de servidor para el día de máxima demanda y pagar en balde por esa capacidad el resto del año. En una arquitectura sin servidor, la capacidad se amplía y se reduce por sí sola según la demanda.

• Escalado automático: el tráfico repentino de una campaña puede atenderse sin planificar la capacidad.
• Pago por uso: no se paga por servidores inactivos; las cargas con poco tráfico pueden resultar muy económicas.
• Menos carga operativa: los parches, las actualizaciones y la vigilancia del hardware corren a cargo del proveedor.
• Desarrollo rápido: el equipo se concentra en la lógica de negocio y no en la infraestructura, y las nuevas funciones salen antes.
• La alta disponibilidad suele ser una característica predeterminada de la plataforma.

04Límites e inconvenientes

Serverless no es una solución mágica. Es excelente para algunas cargas de trabajo y, para otras, puede resultar más caro y complejo que un servidor tradicional.

Arranque en frío

Una función que lleva mucho tiempo sin invocarse se inicia desde cero con la primera petición; esto se llama arranque en frío (cold start). Este retraso es irrelevante para la mayoría de las tareas, pero puede notarse en páginas que esperan una respuesta inmediata. Aquí marca la diferencia la ligereza del entorno de ejecución; por eso los lenguajes compilados que explicamos en el artículo qué es Rust despiertan interés en el mundo serverless.

Límites de tiempo y de recursos

El tiempo de ejecución, la memoria y el tamaño del paquete de las funciones están limitados. Por ejemplo, en AWS Lambda una invocación puede durar como máximo 15 minutos. Los procesamientos de datos que duran horas o las tareas que exigen una conexión permanente abierta no encajan con este modelo.

Dependencia del proveedor

Las funciones suelen escribirse muy ligadas a los servicios de colas, almacenamiento y bases de datos del proveedor. Esto dificulta trasladarse más adelante a otra plataforma. Se conoce como vendor lock-in y debe tenerse en cuenta siempre al tomar la decisión de arquitectura.

Previsibilidad del coste

Serverless, que es barato con poco tráfico, puede resultar más caro que un servidor fijo con mucho tráfico sostenido. Es imprescindible configurar alertas de presupuesto para escenarios como un bucle defectuoso que genere millones de invocaciones. Además, el tráfico de red, el almacenamiento de registros (logs) y las tarifas de los servicios conectados se suman a la factura total.

05Serverless frente al servidor clásico

La elección correcta depende del carácter de la carga de trabajo. La siguiente tabla resume las tendencias generales; para una decisión firme hay que calcular con datos reales de tráfico.

06¿Qué tareas encajan con serverless?

Serverless rinde más en tareas breves y orientadas a eventos. En el flujo digital diario de un negocio, este tipo de tareas son más numerosas de lo que se cree.

• Procesar los envíos de formularios y mandar un correo o una notificación.
• Redimensionar automáticamente las imágenes de producto subidas y convertirlas a WebP.
• Recibir los webhooks de los sistemas de pago, de envíos y de marketplaces; estos flujos forman parte de los proyectos de integraciones de e-commerce.
• Tareas nocturnas de informes, copias de seguridad y limpieza.
• Funciones de formulario y de contador en proyectos de diseño de landing pages que reciben tráfico repentino durante las campañas.
• Reglas de enrutamiento y personalización que se ejecutan en el borde, cerca del navegador.

07Serverless en rendimiento y velocidad

Como las funciones sin servidor pueden distribuirse por distintas regiones del mundo, pueden responder cerca del usuario. En especial los servicios que se ejecutan en el borde, combinados con sitios estáticos, ofrecen experiencias muy rápidas.

Sin embargo, la velocidad no depende de una sola capa. El peso de la página, la optimización de imágenes, la caché y las consultas a la base de datos influyen tanto como la infraestructura. El trabajo de velocidad y rendimiento, que aborda este conjunto, apunta a los valores de Core Web Vitals (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1).

En las funciones que se ejecutan en el borde, los módulos Wasm que explicamos en el artículo qué es WebAssembly se usan cada vez más; su ligereza y su arranque rápido reducen el problema del arranque en frío.

08La arquitectura adecuada para su negocio

Para una empresa, la pregunta de fondo no es «¿serverless sí o no?», sino «¿qué arquitectura es más fiable y sostenible para esta carga de trabajo?». La decisión de arquitectura no debe responder a modas, sino al patrón de tráfico, al presupuesto, a las capacidades del equipo y al plan de crecimiento.

Las operaciones centrales, como pedidos, stock y facturas, suelen mantenerse en una estructura previsible y siempre activa. Las tareas secundarias, como el procesamiento de imágenes, las notificaciones y los informes, pueden pasar a funciones serverless. En los proyectos de plataforma e-commerce, soluciones integradas y soluciones de software de Aurora, la arquitectura también se plantea con este equilibrio según la necesidad.