Hasta hace poco, los servidores se alquilaban, configuraban y mantenían manualmente. Luego vinieron Docker, Kubernetes y CI/CD. Y ahora... Serverless: simplemente escribes una función y se ejecuta cuando es necesario. Sin servidores, actualizaciones y noches sin dormir.
Suena perfecto. ¿Pero es así en la práctica en 2025?
Analizamos si vale la pena cambiar a Serverless, a quién le conviene el backend clásico y por qué muchas empresas usan ambos enfoques al mismo tiempo 👇
🧠 En pocas palabras: ¿de qué se trata?
Enfoque | ¿Qué es esto? |
|---|---|
🧱 Backend clásico | Una aplicación de servidor que funciona constantemente. A menudo en Node, Python, Java, Go. |
☁️ Serverless | Código en forma de funciones (FaaS) que solo se ejecutan bajo demanda. No hay servidores. |
⚙️ Ejemplo: cómo funciona una solicitud de API
Paso | Backend clásico | Serverless |
|---|---|---|
El usuario envía una solicitud | El servidor recibe y procesa | La función se carga, se ejecuta |
El código se almacena en | Máquina virtual/contenedor | Plataforma en la nube (AWS Lambda, Cloud Functions, etc.) |
Pago | Durante el tiempo de funcionamiento del servidor (siempre) | Solo por llamadas |
📊 Comparación de enfoques
Parámetro | Backend clásico | Serverless |
|---|---|---|
💸 Precio | Fija, depende de la carga | Pagar por las llamadas puede ser más rentable |
⚡ Velocidad | Siempre «caliente», respuesta estable | Puede ser un comienzo frío |
📦 Facilidad de despliegue | Requiere habilidades de DevOps | Normalmente 1 equipo o CI |
🧩 Flexibilidad | Control total | Hay restricciones de plataforma |
🛠 Escalabilidad | Debe configurarse manualmente | Se escala automáticamente |
📁 Procesos largos, cron | Sin problemas | Requiere hacer cola (por ejemplo, en las colas) |
🧠 Desarrollo local | Completa | Necesito emular la plataforma |
🕹 ¿Dónde gana realmente Serverless?
Prototipos, MVP y startups 🚀
Lógica de cálculo por evento (carga de archivo, pago, correo electrónico)
Aplicaciones sin carga constante
Procesamiento de colas, webhooks
Cuando la escalabilidad automática es importante
🧱 ¿Y dónde es mejor el clásico?
Si necesita una respuesta estable sin demoras
Si hay muchas tareas en segundo plano
Cuando la aplicación funciona 24/7
Si se está construyendo una arquitectura compleja
Cuando se necesita un control total sobre la infraestructura
🤯 ¿Qué cambió en 2025?
Serverless ahora es más fácil: SDK, plantillas, menos problemas con la depuración
El backend clásico se ha convertido en una máquina DevOps: CI, microservicios, auto-deploy
Marcos (Next.js, Nuxt, Remix) admiten arquitectura híbrida
Multi-runtime: parte del código en el servidor, parte — Serverless
🔮 ¿Quién ganó?
Nadie. La flexibilidad gana: puedes combinar ambos enfoques y utilizar lo mejor de cada uno.
«Lógica empresarial en Serverless, API pesada y tareas en el backend habitual».
En nuestros proyectos, escribes el backend tanto a mano (Node, Python) como funciones Serverless. Aprendes a elegir un enfoque para una tarea, y no porque sea una «tendencia».