El problema de contenedores y lambdas

Antes de entender por qué los isolates son revolucionarios hay que entender qué reemplazan. Durante dos décadas, la unidad de aislamiento en la nube fue el sistema operativo: un proceso, un contenedor o una máquina virtual por inquilino. Es un modelo sólido y seguro, pero cobra un impuesto que casi nadie mira de frente: para atender una petición, primero hay que arrancar algo. Ese arranque es el cold start, y su coste no es accidental, sino estructural.

La unidad de aislamiento es el sistema operativo

En la arquitectura clásica, cuando dos inquilinos no deben verse entre sí, se les separa con una frontera que impone el hardware o el kernel. Esa frontera puede tomar tres formas, cada una más pesada que la anterior.

Un proceso los separa en espacios de direcciones distintos, gobernados por el kernel. Un contenedor va un paso más allá: son procesos aislados con namespaces y cgroups, que fingen tener su propio sistema de ficheros y su propia red.

Una máquina virtual llega al extremo: un kernel invitado completo corriendo sobre un hipervisor, con la ilusión de una máquina física entera para él solo.

En los tres casos, la garantía de aislamiento la da una capa por debajo de tu código. Y en los tres, esa capa tiene peso: espacios de direcciones, tablas de páginas, a veces un kernel entero.

Durante años la ingeniería empujó ese límite con brío: imágenes más finas, arranque perezoso, microVMs diseñadas desde cero para iniciar rápido, como Firecracker, que baja el arranque de una máquina virtual de segundos a una fracción de segundo.

Cada avance recortó la latencia, pero ninguno la llevó a cero, porque el objeto que se arranca sigue siendo, en esencia, un sistema operativo en miniatura. Optimizar el arranque dentro de este paradigma es limar una piedra que nunca desaparece del todo.

Conviene fijar el mejor caso de la generación anterior para medir bien el salto que viene: aun con Firecracker y una imagen mínima, hablamos de decenas de milisegundos en el mejor día y de segundos en el peor. Cero nunca estuvo sobre la mesa.

flowchart TB
HW[Hardware fisico] --> HV[Hipervisor]
HV --> G1[Kernel invitado tenant A]
HV --> G2[Kernel invitado tenant B]
G1 --> R1[Runtime Node o JVM]
G2 --> R2[Runtime Node o JVM]
R1 --> C1[Tu codigo A]
R2 --> C2[Tu codigo B]
style C1 fill:#a6e3a1,color:#11111b
style C2 fill:#89b4fa,color:#11111b

El detalle demoledor es este: cada petición que llega a un inquilino frío necesita que toda esa columna exista y esté viva antes de ejecutar una sola línea útil.

Aislar en el sistema operativo significa pagar por arrancar el sistema operativo.

Anatomía de un cold start

Un cold start no es un evento único: es una cadena de fases, cada una con su latencia. Cuando llega una petición y no hay una instancia caliente disponible, el proveedor recorre este camino:

En el modelo lambda, lo que escribes fuera del handler es exactamente lo que se paga en cada arranque en frío:

// Modelo lambda: el codigo fuera del handler corre en el arranque en frio
const db = crearConexion();          // se ejecuta al arrancar la instancia
const modelo = cargarModeloPesado(); // 300 ms extra en cada cold start

export async function handler(evento) {
  // esto ya corre con la instancia caliente
  return await db.consulta(evento.id);
}

La suma de fases va desde unos 100 ms para un Node mínimo hasta varios segundos para runtimes pesados.

Y no es una latencia que pagues una sola vez: la pagas cada vez que el sistema tiene que crear una instancia nueva. Bajo un pico de tráfico, cuando llegan mil peticiones a la vez y no hay instancias calientes suficientes, ese impuesto se multiplica justo en el peor momento.

El coste que no se ve: densidad y facturación

El cold start es la cara visible del problema. Debajo hay dos costes estructurales más.

El primero es la concurrencia. Una instancia lambda atiende una petición a la vez. Para servir mil peticiones simultáneas necesitas mil instancias, y cada una puede pasar por su propio arranque en frío.

El segundo es la memoria: cada instancia carga una copia completa del runtime del lenguaje y tus dependencias, decenas o cientos de megabytes que existen aunque la instancia esté ociosa esperando trabajo.

Eso limita cuántos inquilinos caben en una máquina: la densidad es baja, y la densidad baja es cara de operar.

Los orquestadores como Kubernetes suavizan el arranque manteniendo pods calientes, pero el reverso es el de siempre: pagas por capacidad encendida a la espera, o aceptas la latencia de arrancar pods nuevos cuando el tráfico sube de golpe.

Pon números al último coste. Una función facturada por gigabyte-segundo que reserva 512 MB y tarda 800 ms de reloj —de los cuales 600 son espera de red— paga por los 800, no por los 200 de CPU real.

Tres cuartas partes de esa línea de la factura son tiempo en que la máquina existía sin calcular nada. Multiplícalo por millones de invocaciones y el aire se convierte en la partida dominante del gasto.

Cold start y facturación por reloj parecen dos quejas distintas, pero comparten una sola raíz: existe una máquina dedicada que hay que arrancar y mantener viva por petición. Ataca esa raíz y las dos desaparecen a la vez.

Por qué esto no es un bug

Guarda este mapa mental: aislar en el sistema operativo obliga a arrancar el sistema operativo. Todo el resto del nivel es la historia de cómo se rompe esa cadena.