Busca en todas las páginas de la documentación
"Serverless" es un nombre de marketing para un cambio arquitectónico real: en lugar de aprovisionar un servidor que permanece listo para manejar solicitudes, le entregas a un proveedor una función y un conjunto de eventos que deberían activarla, y el proveedor decide cuándo, dónde y cuántas veces ejecutarla.
Todavía hay servidores debajo; el nombre se refiere a quién los gestiona, no a si existen.
Conceptos Básicos de Serverless muestra cómo se ve eso en código para AWS Lambda; esta página es el modelo de ejecución subyacente a esos ejemplos: qué sucede realmente entre la llegada de un evento y el retorno de tu manejador, y por qué ese modelo da forma a casi todas las prácticas en esta sección.
Un servidor Node tradicional se inicia una vez, mantiene un proceso activo indefinidamente y maneja cada solicitud dentro de ese mismo proceso de larga duración, lo que significa que las cachés en memoria, las conexiones abiertas a la base de datos y el estado a nivel de módulo sobreviven entre solicitudes.
Una función serverless invierte eso: tu código no tiene control sobre cuándo se inicia un proceso, cuánto tiempo vive o si la próxima invocación reutiliza el mismo.
En cambio, una plataforma Function-as-a-Service (FaaS) —AWS Lambda, Azure Functions, Google Cloud Functions— posee un entorno de ejecución: una instancia de tiempo de ejecución en un entorno aislado que la plataforma crea bajo demanda, le entrega una o más invocaciones y, finalmente, la cierra cuando decide que el entorno ya no es útil para mantenerlo.
Tu único contrato real con la plataforma es el manejador: una función con una firma definida que la plataforma llama una vez por invocación, y cuyo valor de retorno (o promesa resuelta) la plataforma convierte en una respuesta o una señal de finalización.
Todo lo demás —creación de procesos, enrutamiento de solicitudes a un entorno disponible, escalado del número de entornos concurrentes hacia arriba o hacia abajo— es trabajo de la plataforma, que es el significado real de "serverless": no la ausencia de servidores, sino la ausencia de tu responsabilidad de gestionarlos.
Una forma sencilla de entender este modelo: piensa en el proveedor como si ejecutara un grupo de trabajadores idénticos e intercambiables que solo aparecen cuando hay un trabajo publicado, y a quienes el proveedor es libre de enviar a casa en el momento en que hay una pausa.
Cada invocación se divide en una de dos categorías, y la diferencia entre ellas es la mayor fuente de varianza de latencia serverless.
Un arranque en frío ocurre cuando la plataforma no tiene un entorno de ejecución existente listo para tu evento, por lo que tiene que crear uno desde cero: descargar tu paquete de despliegue, iniciar el tiempo de ejecución del lenguaje, ejecutar cualquier código de nivel superior (fase de inicialización) en tu módulo antes de que tu manejador sea siquiera accesible, y finalmente llamar al manejador.
Una invocación cálida ocurre cuando la plataforma ya tiene un entorno de ejecución sobrante de una invocación anterior y simplemente vuelve a llamar a tu manejador dentro de él, omitiendo todos los pasos anteriores excepto la llamada al manejador.
Llega el evento
-> la plataforma busca un entorno de ejecución inactivo
encontrado -> invocación cálida: llama al manejador directamente
ninguno -> arranque en frío: crea el entorno, ejecuta el código de inicialización y luego llama al manejador
-> el manejador se ejecuta, devuelve un resultado
-> el entorno permanece cálido por un tiempo, o se cierra si está inactivo demasiado tiempo
Esta es la razón por la que la ubicación del código dentro de un archivo de manejador importa más en serverless que en un servidor normal: cualquier cosa declarada a nivel superior del módulo (un cliente de base de datos, un esquema de configuración analizado) se ejecuta una vez por entorno, no una vez por invocación; por lo tanto, crearla fuera del manejador permite que las invocaciones cálidas omitan ese costo, mientras que crearla dentro del manejador lo paga en cada llamada.
// Se ejecuta una vez por entorno de ejecución, se reutiliza en invocaciones cálidas
const client = createDatabaseClient();
export const handler = async (event: RequestEvent) => {
// Se ejecuta en cada invocación; este entorno puede ser nuevo o cálido
return client.query(event.id);
};La otra consecuencia de este modelo es la ausencia de estado: debido a que no puedes predecir si la próxima invocación aterrizará en este mismo entorno o en uno recién creado, cualquier estado del que dependa tu manejador —una sesión, un contador, una caché— tiene que vivir en un servicio de respaldo (una base de datos, almacenamiento de objetos, una caché gestionada) en lugar de en una variable local, o tu código se comportará de manera diferente dependiendo de un detalle de implementación que no controlas.
La concurrencia sigue la misma lógica desde la otra dirección: la plataforma puede iniciar muchos entornos de ejecución en paralelo para manejar eventos simultáneos, que es donde serverless obtiene su historia de escalado elástico, pero también significa que tu manejador debe asumir que podría estar ejecutándose muchas veces, simultáneamente, contra recursos compartidos aguas abajo como un límite de conexión de base de datos.
El tiempo de ejecución y la memoria no son ilimitados como lo son efectivamente en un servidor que aprovisionas tú mismo: cada plataforma limita cuánto tiempo puede ejecutarse una sola invocación y cuánta memoria obtiene un entorno de ejecución, y exceder cualquiera de ellos termina la invocación.
Ese límite es un límite arquitectónico real, no solo un control de ajuste: el trabajo que realmente necesita ejecutarse durante horas o mantener una conexión persistente abierta (un WebSocket, un long-poll) no se ajusta en absoluto al modelo y pertenece a una capa de cómputo siempre activa; consulta El Modelo de Orquestación de Contenedores para esa alternativa.
La latencia del arranque en frío en sí misma ha evolucionado como una preocupación operativa de primera clase: paquetes de despliegue más pequeños, menos importaciones pesadas en el ámbito del módulo y características como la concurrencia aprovisionada/reservada (mantener un número determinado de entornos precalentados) existen específicamente para gestionar la varianza que introduce un arranque en frío; Mitigación de Arranques en Frío cubre las tácticas concretas.
Los recursos adyacentes a la red añaden su propia complejidad: adjuntar una función a una red privada (una VPC, para llegar a una base de datos privada) puede ralentizar los arranques en frío, porque la plataforma ahora tiene que aprovisionar interfaces de red como parte de la creación del entorno, un costo que no existe para una función que solo se comunica con servicios públicos orientados a Internet.
La observabilidad también se ve diferente aquí: no hay un proceso de larga duración al que adjuntar un perfilador en pleno vuelo, por lo que la depuración serverless se basa en gran medida en registros estructurados y rastreo distribuido emitidos por invocación, correlacionados por un ID de solicitud, en lugar de inspeccionar un proceso en ejecución.
| Modelo de Cómputo | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Serverless (FaaS) | Sin costo inactivo; escala a cero y a muchos automáticamente | Arranques en frío, límites de tiempo de ejecución, sin estado persistente local | HTTP con picos, trabajo en segundo plano impulsado por eventos, trabajos programados |
| Contenedores siempre activos (K8s/ECS) | Latencia baja predecible; las conexiones de larga duración funcionan naturalmente | Paga por capacidad inactiva; tú eres el propietario del escalado y la supervisión de procesos | Tráfico de línea base constante, WebSockets, trabajos de larga duración |
| VM/servidor tradicional | Control total sobre el entorno de ejecución | Mayor carga de operaciones; planificación manual de la capacidad | Cargas de trabajo heredadas, requisitos de tiempo de ejecución especializados |
Se refiere a quién es responsable de gestionar el servidor, no a si existe uno. El proveedor de la nube se encarga del aprovisionamiento, escalado y parcheo del entorno de ejecución; tú solo proporcionas la función y los eventos que deben activarla.
Una instancia de tiempo de ejecución en un entorno aislado que la plataforma crea para ejecutar tu función: inicia el tiempo de ejecución del lenguaje, ejecuta el código de nivel superior de tu módulo una vez y luego puede atender una o más invocaciones del manejador antes de que la plataforma finalmente lo cierre.
Un arranque en frío significa que la plataforma tuvo que crear un entorno de ejecución completamente nuevo antes de poder llamar a tu manejador, pagando el costo del inicio del tiempo de ejecución y el código de inicialización de tu módulo. Una invocación cálida reutiliza un entorno sobrante de una llamada anterior, pasando directamente al manejador.
El código a nivel superior del módulo se ejecuta una vez por entorno de ejecución y es reutilizado por cada invocación cálida que ese entorno atiende, mientras que el código dentro de la función del manejador se ejecuta en cada llamada. Crear recursos costosos como clientes fuera del manejador evita pagar ese costo repetidamente.
No de forma fiable; no puedes controlar si la próxima invocación reutiliza el entorno actual o aterriza en uno nuevo, por lo que cualquier estado que deba persistir pertenece a un servicio de respaldo externo, como una base de datos o una caché gestionada, no a una variable local.
La plataforma gestiona un grupo elástico y compartido de entornos de ejecución en tu nombre, y un tiempo de ejecución por invocación ilimitado haría imposible dimensionar o facturar ese grupo de manera predecible. Las cargas de trabajo que realmente necesitan una ejecución de larga duración o una conexión persistente pertenecen a un cómputo siempre activo.
La plataforma crea entornos de ejecución adicionales en paralelo a medida que llegan eventos concurrentes, en lugar de enrutar más solicitudes a través de un solo proceso. Por eso, las invocaciones concurrentes también pueden ejercer una presión inesperada sobre los recursos posteriores, como el límite de conexiones de una base de datos.
Cuando necesitas conexiones de larga duración (WebSockets, long-polling), latencia predecible inferior a 10 ms independientemente de los arranques en frío, o tráfico constante las 24 horas del día donde un servidor siempre activo en realidad costaría menos que el precio por invocación.
Sí, acceder a un recurso privado como una base de datos dentro de una VPC generalmente requiere que la plataforma aprovisione interfaces de red como parte de la creación del entorno de ejecución, lo que puede añadir una latencia medible específicamente a los arranques en frío.
No hay un proceso en ejecución al que adjuntar un perfilador o depurador en vivo entre invocaciones, por lo que la observabilidad serverless se basa en registros estructurados y rastreos distribuidos emitidos por invocación y correlacionados por un ID de solicitud.
No universalmente; tiende a ganar para el tráfico con picos o intermitente donde un contenedor de otro modo estaría inactivo, pero con un tráfico alto y sostenido, el modelo de costo por invocación puede exceder lo que costaría un servidor siempre activo dimensionado correctamente.
El entorno de ejecución, no la definición de la función en sí. Tu función es solo código que la plataforma carga en cualquier entorno de ejecución que decida crear o reutilizar para un evento dado.
Versiones de pila: Esta página es conceptual y no está ligada a una versión de pila específica.
Revisado por Chris St. John·Última actualización: 15 jul 2026