VPS vs. Serverless vs. Bare Metal

Una de las decisiones más importantes al desplegar una aplicación es dónde la ejecutas: un VPS, funciones serverless o un servidor bare metal. No hay una respuesta única; depende del tráfico, del presupuesto, del control que necesites y de la complejidad que quieras asumir. En este artículo comparo VPS, serverless y bare metal de forma directa: qué ofrecen, qué sacrificas y cuándo tiene sentido cada uno.

El contexto: ¿dónde vive tu código?

Tu código tiene que ejecutarse en algún sitio. Las opciones principales son:

Bare metal: Un servidor físico (o una máquina virtual dedicada) que tú administras. Tienes el OS, el runtime, la app y todo lo que instales. Control total; también responsabilidad total.
VPS (Virtual Private Server): Un slice de un servidor físico, con CPU, RAM y disco asignados. Lo administras tú (OS, updates, app), pero el proveedor gestiona el hardware y la virtualización. Equilibrio entre control y gestión.
Serverless (FaaS, etc.): No “tienes” un servidor; subes funciones o contenedores y la plataforma los ejecuta cuando llegan peticiones. Escalas a cero y pagas por uso; cedes control del runtime y del ciclo de vida.

Cada opción implica un trade-off entre control, coste, escalabilidad y operación.

Bare Metal

Qué es: Un servidor físico (o una VM “dedicada” que se comporta como tal) donde instalas el SO, el runtime y tu aplicación. No compartes CPU/RAM con otros clientes del mismo host.

Ventajas:

Control total: Kernel, red, disco, todo es tuyo. Puedes optimizar hasta el último detalle.
Rendimiento predecible: Sin “vecinos” que compitan por recursos en el mismo host.
Coste a largo plazo: Si la carga es estable y alta, el coste por recurso puede ser menor que muchas instancias VPS o que serverless con mucho tráfico.
Sin límites de tiempo de ejecución: Procesos largos, workers, colas, lo que quieras.

Desventajas:

Operación: Tú te encargas de updates, backups, monitoreo, seguridad. Requiere tiempo o un equipo que sepa de sistemas.
Escalabilidad manual: Aumentar capacidad suele implicar comprar o alquilar otro servidor, migrar o balancear.
Punto único de fallo: Si no diseñas alta disponibilidad (varios nodos, balanceador), un fallo de hardware puede tumbar el servicio.

Cuándo tiene sentido: Cargas estables y predecibles, necesidad de máximo control o rendimiento (bases de datos pesadas, procesamiento intensivo), equipos con experiencia en sistemas, o presupuesto que prioriza coste a largo plazo sobre “no tocar nada”.

VPS

Qué es: Una máquina virtual con CPU, RAM y disco asignados. Puedes elegir el SO (Linux, etc.) e instalar lo que quieras. El proveedor (DigitalOcean, Linode, Hetzner, AWS EC2, etc.) gestiona el hardware y la hipervisión.

Ventajas:

Control sin gestionar hardware: SSH, root, instalas lo que necesites. Más simple que bare metal en cuanto a hardware.
Escalabilidad más sencilla: Aumentar tamaño de la VPS o añadir más VPS y un balanceador es estándar.
Precio predecible: Planes mensuales por tamaño; no pagas por invocación como en serverless.
Flexibilidad: Cualquier stack (Node, Go, Python, contenedores, bases de datos pequeñas/medianas).

Desventajas:

Tú operas: Updates, seguridad, backups, logs. Si no lo automatizas, puede convertirse en carga.
Puede haber “ruido de vecinos”: En VPS compartidos, otros clientes en el mismo host pueden afectar el rendimiento (aunque menos que en shared hosting).
No escala a cero: Aunque no tengas tráfico, pagas la VPS. Para proyectos muy pequeños o con tráfico irregular, el coste fijo puede ser alto.

Cuándo tiene sentido: Aplicaciones web “tradicionales”, APIs, backends con tráfico moderado y predecible, cuando quieres control pero no quieres comprar ni gestionar hardware. Muy común para startups y proyectos medianos.

Serverless (FaaS, contenedores sin servidor)

Qué es: Subes código (funciones) o contenedores; la plataforma (AWS Lambda, Google Cloud Functions, Vercel, Netlify, etc.) los ejecuta cuando llegan peticiones. No reservas un servidor; pagas por invocación, tiempo de ejecución y a veces por GB-s.

Ventajas:

Escala a cero: Sin tráfico, no pagas (o pagas muy poco). Ideal para tráfico irregular o picos impredecibles.
Escalabilidad automática: La plataforma escala instancias según la demanda; no configuras máquinas a mano.
Menos operación de servidores: No administras OS ni capacidad; la plataforma gestiona el runtime (con límites).
Despliegue simple: Muchas veces es “push y listo”; integración con Git y CI/CD muy directa.

Desventajas:

Cold starts: La primera invocación (o después de inactividad) puede ser más lenta porque la plataforma arranca el entorno.
Límites: Tiempo máximo de ejecución, memoria, tamaño del paquete. Procesos muy largos o muy pesados no encajan bien.
Vendor lock-in y coste con escala: Lógica atada a APIs del proveedor; con mucho tráfico el coste puede dispararse respecto a una VPS fija.
Debugging y observabilidad: Distribuido, stateless; hay que diseñar logs, trazas y métricas con cuidado.

Cuándo tiene sentido: APIs con tráfico irregular, webhooks, procesamiento por eventos, sitios estáticos con funciones en el borde, proyectos que priorizan “no tocar servidores” y aceptan los límites de la plataforma.

Comparativa rápida

Criterio	Bare Metal	VPS	Serverless
Control	Máximo	Alto	Bajo
Operación	Tú todo	Tú todo	Plataforma
Coste tráfico bajo	Alto (fijo)	Medio (fijo)	Bajo (uso)
Coste tráfico alto	Puede bajar	Predecible	Puede subir
Escala a cero	No	No	Sí
Cold start	No	No	Sí
Procesos largos	Sí	Sí	Limitado

Mi perspectiva personal

No existe “la mejor” opción; existe “la más adecuada para tu contexto”. Bare metal tiene sentido cuando el coste a largo plazo y el control son prioritarios y tienes capacidad de operación. VPS es el punto medio más común: control, precio predecible y escalabilidad razonable sin gestionar hardware. Serverless brilla cuando el tráfico es irregular, quieres escalar a cero y aceptas límites de tiempo y de modelo de ejecución.

Muchos proyectos empiezan en VPS o serverless y, si crecen y el coste o el control se vuelven críticos, evalúan bare metal o arquitecturas híbridas (por ejemplo, API en VPS y workers o tareas puntuales en serverless). La clave es saber qué estás intercambiando: control por comodidad, coste fijo por coste variable, o viceversa. Con eso claro, la decisión “¿dónde debería vivir mi código?” deja de ser una moda y se convierte en una elección consciente.