Para entender qué resuelve serverless, primero necesitas entender qué duele.
Todo developer ha escrito código que funciona en su máquina. Lo corres, responde, todo bien. Pero llega el momento en que alguien más necesita usarlo. Un usuario. Diez. Mil.
Y ahí empieza la parte que nadie te enseñó en el tutorial.
Llevo más de 20 años construyendo aplicaciones. Y te puedo decir que una de las cosas que más tiempo me ha quitado en mi carrera no fue escribir código. Fue mantener vivo el lugar donde ese código corre.
Porque tu código necesita vivir en algún lugar. Necesita una máquina que esté encendida 24/7, que escuche peticiones, que responda rápido. Y esa máquina no se mantiene sola.
Todos hablan de serverless. "Usa serverless", "la nube se encarga", "no necesitas servidores". Pero antes de entender qué resuelve serverless, necesitas entender qué es un servidor y por qué mantenerlo es un trabajo en sí mismo.
Porque no puedes apreciar lo que serverless resuelve si no entiendes primero lo que duele.
¿Qué es un servidor?
Piensa en un local comercial.
Tiene una dirección (una IP). Tiene varias puertas, cada una atiende un servicio distinto, por una entran los clientes, por otra los proveedores, por otra el correo. Esas son los puertos. Y adentro hay alguien atendiendo (tu aplicación corriendo).
Eso es un servidor: una máquina que corre un sistema operativo y escucha en un puerto, esperando que alguien le hable.
Ahora, esa máquina puede ser física: un equipo real en un rack, en un datacenter, con cables y ventiladores. Es como ser dueño del edificio completo. Tú controlas todo, desde los cimientos hasta el techo.
O puede ser virtual: una máquina virtual (VM) que comparte el hardware físico con otras VMs. Es como rentar un piso dentro de un edificio. Tienes tu propio espacio, tu propia puerta, pero compartes la estructura con otros inquilinos.
Al final del día, ambos hacen lo mismo: corren un sistema operativo y escuchan en un puerto esperando que alguien les hable.
El ciclo request-response
Cada vez que interactúas con una aplicación, pasa lo mismo:
- Tu dispositivo (el cliente) envía una petición, con una ruta (path), un método (GET, POST...) y a veces datos adicionales (body)
- El servidor la recibe y la procesa, corre código, consulta una base de datos, llama a otro servicio
- El servidor te devuelve una respuesta
Eso es todo. No hay magia.
Cada vez que abres una app, haces scroll, o le das "enviar", este ciclo se repite. Miles de veces por segundo si tienes suerte.
Lo que nadie te dice: mantener un servidor es un trabajo
Para que tu código llegue a los usuarios, necesita una máquina corriendo. Y esa máquina necesita mantenimiento constante:
- Aprovisionamiento: Decidir qué configuración necesita tu máquina (memoria, procesamiento, almacenamiento), configurarla, instalar todo lo que tu app necesita para correr.
- Patching: Mantener el sistema operativo y las dependencias actualizadas para que tu servidor esté protegido contra vulnerabilidades conocidas.
- Monitoreo: Saber si tu servidor está vivo, si está respondiendo lento, si se está quedando sin memoria.
- Escalamiento: Cuando la demanda de usuarios crece y un servidor no alcanza, poner más. Cuando sobran, apagarlos para no pagar de más.
Tu código puede ser perfecto. Pero si el servidor se cae a las 3am, adivina quién recibe la llamada.
Y entonces llega el tráfico
Imagina que tienes una tienda online. Arranca con 100 usuarios. Un servidor la maneja sin problema. Todo tranquilo.
Pero llega el Hot Sale. De repente son 10,000 usuarios simultáneos.
El servidor se satura. Los requests se acumulan. Los usuarios ven errores, timeouts, pantallas en blanco.
¿La solución? Escalar. Pero hay dos caminos:
- Escalar verticalmente: ponerle más CPU, más RAM, más disco a la misma máquina. Es lo más simple, pero tiene un techo. Llega un punto donde no puedes seguir agrandando una sola máquina (y mientras la upgradeas, tu app está abajo).
- Escalar horizontalmente: agregar más máquinas que se repartan el trabajo. No tiene techo teórico, pero ahora tienes un problema nuevo: coordinar múltiples servidores.
En la práctica, la mayoría de las aplicaciones que crecen terminan escalando horizontalmente. Y ahí es donde la complejidad explota.
Más servidores significa más configuración, más monitoreo, más patching, más costo. Y ahora imagina que necesitas hacer un update de tu app. Tienes que redeployar en cada servidor, coordinar el rollout, y asegurarte de que nada se rompa en el proceso.
Escalar no es solo "agregar más máquinas". Es un problema de orquestación, de costos, y de tiempo.
¿Y si no tuvieras que hacer nada de esto?
Esa es exactamente la idea detrás de serverless: tú escribes el código, alguien más se encarga del servidor, del scaling, del patching, de todo.
Ojo: esto no significa que tener servidores administrados sea malo o incorrecto. Para muchos workloads, es la opción correcta. Pero para ciertos casos de uso, la carga operacional es desproporcionada al valor que entrega tu aplicación. Serverless es una respuesta a ese problema específico.
No es magia. Es un modelo diferente de cómo se ejecuta tu código. Y en el próximo artículo vamos a ver exactamente cómo funciona.
Lo que quiero que te lleves
- Un servidor es una máquina (física o virtual) que corre tu código y escucha peticiones. Eso es todo.
- Mantenerlo vivo es un trabajo: aprovisionamiento, patching, monitoreo, escalamiento.
- Escalar es el punto donde la complejidad explota y donde el costo se dispara (pagar por una máquina al 5% de CPU la mayor parte del día es más común de lo que crees).
- Serverless existe porque para ciertos casos de uso, esa carga operacional es desproporcionada. No es la única solución válida, pero es una que vale la pena entender.
¿Te resultó útil este artículo? Si conoces a alguien que está empezando en cloud y siempre le dicen "usa serverless" sin explicarle por qué, compártele este artículo. Y si ya pasaste por el dolor de mantener servidores a las 3am, me encantaría escuchar tu historia.
Top comments (1)
Excelente post :)
Es el tipo de cosas de las que estoy agradecido con la carrera de ing en sistemas en laa que hicimos algunas prácticas en su servidor físico (ahí conocí cosas interesantes como los discos duros que se cambian en caliente y configuraciones de firewall, del OS, de apache y nginx) y con mis primeros trabajos en empresas cuyo servidor era una PC a la que teníamos que ponerle una notita de NO APAGAR. SI LA APAGAS NO HAY NÓMINA.
Esas experiencias me dieron perspectiva de qué significa tener, configurar y mantener un servidor on premise, qué significa rentar un servidor como VPS, y cuando conocí el "serverless" fue un boom en mi cabeza.
Y de la experiencia profesional debo decir que aprendí sobre la marcha que cada desición que tomemos tiene una consecuencia jaja. Estas consecuencias son notorias después de un tiempo normalmente. Así que es bueno tomaarse un tiempo para escoger lo más apropiado y no dejarse llevar por los sesgos que tengamos en el momento.