serverless · cloud · arquitectura
Qué es serverless, exactamente
La palabra es un término de marketing que se ha quedado, y engaña a casi todo el mundo la primera vez. Serverless no significa que no haya servidor. Significa que nunca ves uno: no eliges su tamaño, no instalas sus actualizaciones, no decides cuántos poner en marcha. Todo eso lo hace otro, y a ti se te cobra lo que tu código hizo de verdad.
Qué quita realmente
En un VPS alquilas una máquina. Existe venga alguien o no, eliges su RAM y sus vCPU, parcheas su kernel y decides cuándo añadir una segunda. Cada una de esas decisiones es tuya, y cada hora de la factura también.
Serverless quita la máquina como unidad sobre la que razonar. Le entregas a la plataforma un trozo de código y un disparador: una petición HTTP, un mensaje en una cola, un fichero que aterriza en el almacenamiento. La plataforma se ocupa de que ese código se ejecute cuando el disparador ocurre. Cuántas copias se ejecutan, y sobre qué, no es tu problema ni tu decisión.
Ese es todo el intercambio, dicho sin adornos: cedes el control del runtime a cambio de no operarlo nunca.
Las dos familias
Function as a Service es la parte en la que se piensa primero. Despliegas una función, la plataforma la ejecuta por evento, y desaparece. AWS Lambda, Google Cloud Functions y Azure Functions son los ejemplos conocidos.
Los servicios gestionados serverless son la mitad más grande y menos comentada: bases de datos, colas, almacenamiento de objetos y búsqueda, facturados por petición o por unidad de trabajo en vez de por instancia aprovisionada. La mayoría de los sistemas serverless reales son sobre todo esto, con una cantidad modesta de código de función sujetando las piezas.
La facturación y por qué el scale to zero es el titular
Una máquina alquilada se factura por tiempo de reloj. Cuesta lo mismo a las tres de la madrugada sin visitas que en el pico. Serverless factura por invocación más los recursos que esa invocación consumió mientras corría.
La consecuencia es el scale to zero: sin tráfico no hay nada en marcha y no hay nada que pagar. Para un proyecto personal, una herramienta interna usada dos veces por semana o una carga a picos que está parada casi siempre, esta es la ventaja de verdad, y es grande.
El mismo mecanismo funciona en sentido contrario bajo carga. La plataforma arranca tantas copias concurrentes como exijan los eventos, sin que configures ningún autoescalador, y esa es la segunda ventaja real.
Las restricciones que el argumentario omite
Arranques en frío. Cuando ninguna copia de tu función está caliente, la primera petición paga la inicialización del runtime y de tus dependencias antes de que tu código empiece siquiera. Bundles más pequeños y runtimes más ligeros lo reducen. Los proveedores venden capacidad precalentada, que funciona y que deshace en silencio el scale to zero, porque precalentado significa pagado mientras está ocioso.
Ausencia de estado. Nada de lo que guardes en memoria o en disco local está garantizado la próxima vez. Dos invocaciones pueden caer en instancias distintas, y una instancia desaparece cuando la plataforma lo decide. El estado va a una base de datos o a un almacenamiento de objetos, siempre.
Límites de ejecución. Una invocación tiene una duración máxima y un techo de memoria. Los procesos por lotes largos y todo lo que mantenga una conexión abierta durante horas encajan mal, y llegar al límite no es un aviso sino un fallo.
Acoplamiento. El cuerpo de la función suele ser portable. Las formas de los eventos, el modelo de identidad y los servicios gestionados que lo rodean no lo son, y ahí es donde marcharse más tarde cuesta de verdad.
Dónde se cruza la curva de coste
La facturación por invocación es barata cuando la máquina habría estado ociosa y cara cuando habría estado ocupada. Por debajo de cierta carga estable, serverless gana con holgura. Por encima, pagas una prima por unidad de trabajo por una elasticidad que ya no usas, y un servidor encendido siempre, aunque modesto, sale más barato y más previsible.
La regla honesta es mirar la forma del tráfico más que su volumen. A picos, ocasional e impredecible: ventaja serverless. Estable y continuo: ventaja máquina alquilada por meses, y en ese punto el trabajo de operación que recuperas es un precio justo por una factura que deja de sorprender.
Si tu carga resulta estar del lado estable, un VPS es la respuesta sencilla, y Docker más algo de disciplina te devuelve casi toda la reproducibilidad que hacía atractivo el serverless al principio.
Un servidor para el lado estable de la curva
Cuando el tráfico deja de ser a picos, la facturación por invocación cuesta más que una máquina que iba a estar ocupada de todos modos. DigitalOcean ofrece VPS y servidores cloud con control root completo, facturados al mes y no por llamada.
Ver DigitalOcean Cloud →Enlace de afiliado - ayuda a mantener estas guías gratuitas.
En resumen
Serverless significa que los servidores son problema de otro, no que no existan. Ganas scale to zero, concurrencia automática y cero parcheo. Aceptas arranques en frío, ausencia de estado, límites de ejecución y una factura que sigue al uso y no al tiempo. Encaja con el trabajo a picos e intermitente, y deja de encajar cuando el tráfico se vuelve lo bastante estable como para que una máquina alquilada hubiera estado ocupada de todos modos.