Cómputo sin servidor

El espectro no te mostró esta parte

La lección de cómputo ubicó a las funciones sin servidor en el extremo derecho del espectro de control contra comodidad: el proveedor administra todo excepto tu código, y una función arranca en milisegundos. Ese diagrama cumple su función mostrando dónde queda sin servidor frente a máquinas virtuales y contenedores, pero no muestra qué significa en la práctica que "el proveedor administre todo", ni dónde están los límites de esa comodidad. Ambas cosas importan en el momento en que tú eres quien decide si una carga de trabajo pertenece o no a una función sin servidor.

Sin servidor es el nombre de marketing, no el mecanismo

"Sin servidor" es el nombre que la industria le puso al modelo, no una descripción literal. AWS corre tu función dentro de una micro máquina virtual aislada, sobre su propia flota de servidores físicos, usando una tecnología de virtualización llamada Firecracker sobre su Nitro System; Azure y Google Cloud hacen lo equivalente en su propio hardware. Lo que "sin servidor" te quita no es el servidor, es tu trabajo de elegirlo, dimensionarlo, parcharlo y escalarlo. Compáralo con IaaS, donde tú eliges el tipo de instancia, o incluso con PaaS, donde al menos eliges un runtime y una política de escalado. Una función sin servidor no te entrega ninguna de esas 2 perillas: tú entregas una función, la conectas a un disparador, y el proveedor decide cuántas copias correr, dónde, y cuánto vive cada una.

El ciclo basado en eventos: inactivo, invocar, ejecutar, inactivo otra vez

Una función sin servidor no se queda corriendo y esperando trabajo como lo hace una máquina virtual. Imagina una función que genera una miniatura cada vez que un cliente sube una foto a un bucket de almacenamiento. La mayor parte del día, cero copias de esa función están corriendo en algún lado, y no cuesta nada. En el momento en que una foto llega al bucket, el evento dispara una invocación: la plataforma busca o crea un entorno de ejecución, corre tu código handler contra el evento, y devuelve un resultado. Cuando el flujo de subidas se detiene por un rato, la plataforma libera ese entorno, y la función vuelve a cero.

Arranques en frío y arranques en caliente

Esa distinción entre "busca o crea" tiene nombre. Si un entorno de ejecución de una invocación reciente sigue disponible, la plataforma lo reutiliza, un arranque en caliente, que corre tu handler casi de inmediato. Si no, después de un período inactivo o de una ráfaga de tráfico nuevo, la plataforma primero tiene que inicializar un entorno nuevo, cargar tu runtime e importar tus dependencias antes de correr tu handler siquiera, un arranque en frío. Ese trabajo de inicialización no es gratis en tiempo ni en dinero: la facturación actual de AWS Lambda cuenta la fase de inicialización de un arranque en frío como tiempo facturado, igual que el handler mismo. Una función invocada constantemente casi nunca paga el costo del arranque en frío, porque sus entornos se mantienen en caliente; una función invocada en ráfagas ocasionales lo paga en la primera solicitud de cada ráfaga.

La matemática detrás de "pagas solo por lo que corre"

El precio on-demand de AWS Lambda cobra $0.20 por millón de solicitudes más $0.0000166667 por GB-segundo de tiempo de ejecución, con un nivel gratuito de 1 millón de solicitudes y 400,000 GB-segundos cada mes, para siempre.

Toma una función configurada con 512 MB de memoria (0.5 GB) que corre 400 milisegundos (0.4 segundos), invocada 100,000 veces al mes, generar miniaturas para una app pequeña de fotos, digamos. Esa carga usa 100,000 x 0.5 x 0.4 = 20,000 GB-segundos y 100,000 solicitudes, ambas cómodamente dentro del nivel gratuito. La factura: $0.

Ahora escala esa misma función a 5 millones de invocaciones al mes, una app más ocupada, o la misma app ya crecida. Eso es 5,000,000 x 0.5 x 0.4 = 1,000,000 GB-segundos, de los cuales 600,000 son facturables después del nivel gratuito, más 4,000,000 de solicitudes facturables. La duración cuesta cerca de 600,000 x $0.0000166667, unos $10.00, y las solicitudes agregan otros 4 x $0.20 = $0.80, para una factura cercana a $10.80 al mes. Compara eso con la t3.micro de la lección de cómputo, cerca de $7.59 al mes corriendo todo el tiempo, haga trabajo o no. A volumen bajo e irregular, sin servidor gana claramente, es gratis. A volumen alto y constante, una instancia siempre encendida puede ganarle en precio, y eso antes de preguntar siquiera si una sola t3.micro aguantaría 5 millones de solicitudes sin caerse.

Dónde deja de encajar una función sin servidor

2 límites importan tanto como la matemática del costo. Primero, el tiempo de ejecución: las funciones de AWS Lambda tienen un tope de 15 minutos por invocación; un trabajo de codificación de video que corre 2 horas simplemente no cabe dentro de una función común, sin importar qué tan bien salga la cuenta del precio. Segundo, el estado: un entorno de ejecución puede reutilizarse entre invocaciones, pero nada lo garantiza, así que una función no puede depender de que los datos se queden en memoria ni de que una conexión se mantenga abierta de una invocación a la siguiente. Una carga de trabajo que necesita un pool de conexiones de base de datos de larga duración, un trabajo por lotes de varias horas, o estado en memoria garantizado, pertenece a un contenedor o una máquina virtual en su lugar.

Pistas de examen: identificar el encaje en un escenario

Dónde te deja esto

Sin servidor no elimina los servidores, elimina tu trabajo de administrarlos, y te cobra solo por los milisegundos que tu código realmente corre. Ese trato paga a volumen bajo o irregular y puede perder contra una instancia siempre encendida a volumen alto y constante, que es justo por qué "sin servidor siempre es más barato" es una trampa, no una regla. La siguiente lección deja atrás la pregunta de quién administra el servidor y hace una distinta: cómo debería dividirse la aplicación misma en piezas, y cómo corren esas piezas igual en todas partes. Eso es lo que responden contenedores y microservicios.