I am Lino
20 de abril de 2026

Serverless, containers y VMs: elige tu veneno (y tu factura)

Publicado el 20 de abril de 2026  •  11 minutos  • 2329 palabras
Table of contents

Ponme en una reunión de arquitectura y te apuesto lo que quieras a que antes de diez minutos alguien dice “lo importante es el valor de negocio”… y a los quince ya estáis debatiendo si sois más de VMs, de contenedores o de serverless como si fueran casas de Hogwarts.

Lo gracioso es que las tres opciones son solo distintas formas de responder a la misma pregunta: "¿dónde leches se va a ejecutar mi código y quién se come los marrones?".

Lo demás son matices… y facturas.

Vamos a recorrer esas opciones como si fueran tres personajes en una novela de oficina: la VM veterana que lo ha visto todo, el contenedor hipster organizado y el serverless que promete que “ya no hace falta pensar en servidores” mientras te guiña un ojo.

La VM: el servidor de toda la vida, pero en la nube

La máquina virtual es ese compañero que lleva 15 años en la empresa, conoce todos los sistemas y nunca ha pedido cambio de silla.

Por fuera, la llamamos “VM” para sentirnos modernos; por dentro, sigue siendo un servidor completo : sistema operativo, paquetes, procesos, logs… todo tuyo.

Si vienes del mundo on-premises, la VM es la traslación más directa: lo que antes montabas en un hierro físico, ahora lo montas en una máquina virtual en AWS, Azure, tu proveedor favorito o incluso en tu propio datacenter. Tú decides el tamaño (CPU, RAM, disco), tú instalas el runtime, tú configuras el firewall, tú reinicias cuando se queda tonta.

¿Por qué sigue teniendo sentido en 2026, cuando podrías ponerlo “todo en contenedores” o “todo en serverless”?

Porque hay situaciones en las que esa controlitis explícita es una bendición, por ejemplo, en sistemas que necesitan control fino del SO, dependencias raras o drivers específicos, o para aplicaciones legacy (viejunas) que sería más caro reescribir que pagar para que vivan cómodas en una VM, y en especial para cargas largas y estables donde sabes que vas a tener una máquina encendida 24/7; no hay gran magia que hacer, solo que no se caiga.

El lado oscuro es predecible: un gran poder conlleva una gran responsabilidad.

Parchear, vigilar, configurar, automatizar… todo recae en tu equipo. La VM no te va a escalar sola porque haya más tráfico, ni va a decidir por sí misma cuándo conviene tener otra instancia detrás de un balanceador; eso lo haces tú, con tu CI/CD, tu Terraform o tus scripts de la vieja escuela.

Las comparativas entre VMs, serverless y contenedores lo resumen así: las VMs te dan más control y estabilidad mental a costa de que también seas tú quien se levante a mirar qué ha pasado si algo va mal.

Es ideal si quieres un mundo simple, o si te estás mudando poco a poco a la nube sin ganas de revolucionar media empresa reescribiendo aplicaciones que ya funcionaban.

El contenedor: el amigo ordenado que viaja ligero

Si la VM es el veterano que no se mueve de su mesa, los contenedores son justo lo contrario: llevar tu aplicación en una maleta muy bien ordenada . Todo lo que necesita para funcionar va dentro, y da igual en qué hotel te alojes mientras haya hueco para la maleta.

La gracia es que es brutalmente simple: empaquetas tu app y sus dependencias en una imagen (Docker, por ejemplo), y esa imagen se ejecuta igual en tu portátil, en una VM en la nube, en un cluster on-premises o en un edge (nombre “fino” para una raspberry pi 4 vieja) escondido en un armario. La famosa frase “en mi máquina funciona” pierde mucha fuerza cuando la “máquina” es la misma en todas partes.

Comparados con VMs, los contenedores son más ligeros: comparten el kernel del host, arrancan rápido, aprovechan mejor los recursos, y puedes tener muchos conviviendo en la misma máquina sin necesidad de crear un SO completo para cada uno. Precisamente por eso, muchas guías recomiendan contenedores para aplicaciones grandes o complejas que quieres desplegar de forma consistente y portable.

¿La letra pequeña? Que un contenedor no vive solo: suele venir en manada.

Cuando pasas de “tengo un contenedor” a “tengo una aplicación compleja de 15 servicios”, te aparece la necesidad de un orquestador: Kubernetes, ECS, Nomad o el sabor que esté de moda.

Y ahí es donde se te monta el circo y te crecen los enanos: tu problema ya no es solo desplegar código, sino entender despliegues, servicios, redes internas , ingress controllers, autoescalado, health checks y un largo etcétera.

Ahora bien, cuando te sientas a leer comparativas con calma, la historia se repite: para aplicaciones de cierto tamaño y vida larga, los contenedores ofrecen un equilibrio muy bueno entre control, portabilidad y uso eficiente de recursos. Eso sí, la fiesta de la orquestación tiene coste : más complejidad operativa, necesidad de especialización y más herramientas por entender.

El contenedor es ese colega que te ordena la casa y te deja todo etiquetado, pero que también te convence de que compres un armario nuevo para cada cosa. Maravilloso si tienes mucho que organizar; quizá excesivo para un estudio de una sola habitación.

Serverless: el “no te preocupes, yo me encargo” de la nube

Falta el tercer personaje: serverless, que se presenta en la fiesta diciendo: “tranqui, ya no hace falta que pienses en servidores”.

Técnicamente, claro que hay servidores, solo que no son tuyos. Pertenecen al proveedor cloud , que decide cuándo arrancarlos, cuándo pararlos y cómo cobrarte por cada milisegundo de uso.

La promesa es muy seductora: tú subes funciones o pequeños servicios, defines triggers (HTTP, colas, cron, eventos), y la plataforma se encarga de todo lo sucio: escalar cuando hay picos, bajar a cero cuando no hay tráfico, distribuir instancias entre zonas, reintentar cuando algo falla, y pasarte la factura a final de mes .

Para muchos tipos de carga – backends de APIs pequeñas, tareas batch, procesado de eventos, integraciones entre sistemas – esto es oro puro, y quien lo ha probado lo confirma: mayor productividad del desarrollador (menos tiempo en infra, más en lógica), escalado automático muy fino y un modelo de coste atractivo: pagas por invocación y recursos usados, no por tener máquinas calentando aire.

Pero la vida real, como siempre, añade matices. Hay artículos recientes que ponen serverless “bajo fuego” por tres motivos principales: complejidad, costes y lock-in.

La complejidad viene de que un sistema de tamaño medio puede acabar teniendo docenas o cientos de funciones dispersas, cada una con permisos, triggers y logs propios. Depurar eso sin buenas prácticas y buenas herramientas puede convertir una tarde tranquila en un CSI de la nube.

Con los costes pasa una paradoja similar a la que se ha visto en microservicios: para volúmenes pequeños o moderados, el modelo pay-per-use suele ser muy competitivo; pero a partir de ciertos niveles masivos, hay casos documentados donde sale mucho más barato montar algo propio y “aburrido”.

Figma, por ejemplo, se hizo famosa por replantearse parte de su arquitectura porque su factura serverless había crecido hasta cifras demenciales, y existen análisis comparativos muestran cómo a gran escala el modelo de Lambda+colas podía costar varias veces más que clusters dedicados bien afinados.

Por último aparece el viejo amigo: el lock-in. Serverless es, por definición, una gran fiesta en casa del proveedor: la forma en que declaras funciones, integraciones, colas, permisos y timeouts no suele ser fácilmente portátil a otro sitio. Hayt análisis recientes que se centran justo en este “dilema del lock-in y la complejidad en espiral” : si tratas de evitar totalmente el lock-in, pierdes muchas ventajas; si lo ignoras, puedes encontrarte con que moverte de plataforma es un proyecto millonario.

Serverless es el amigo que te invita a todo… pero que a cambio se queda con las llaves de tu casa, tu coche y, si te descuidas, la custodia de tu primogénito.

No es una pelea, es un triángulo amoroso (y de facturas)

Ya sé que a estas alturas esperas un veredicto definitivo, pero las comparativas serias son bastante menos emocionantes que muchos hilos de X: no hay ganador absoluto, hay contextos.

Las VMs brillan cuando necesitas estabilidad, compatibilidad y control: migrar sistemas legacy, ejecutar cosas muy específicas de sistema operativo, mantener aplicaciones que no merece la pena reescribir. Siguen siendo la base sobre la que, al final, se ejecuta casi todo lo demás ; incluso tus contenedores y tus funciones viven sobre VMs que no ves.

Los contenedores son la herramienta favorita cuando quieres empaquetar aplicaciones completas de forma portátil y consistente , con un control decente sobre recursos y redes, y estás dispuesto a invertir en herramientas de orquestación. Funcionan especialmente bien para servicios de larga duración, APIs de tamaño medio-grande, sistemas internos que quieres mover entre entornos sin sufrir (demasiado).

Serverless encaja como un guante en escenarios donde la carga es irregular , los componentes son pequeños, la latencia de arranque no es crítica y quieres minimizar todo lo que huela a “gestionar servidores”. Ideal para glue code entre sistemas, automatizaciones internas, APIs ligeras, jobs asíncronos. Mucho menos ideal para servicios que necesitan latencias bajas y constantes, estados complejos en memoria o control extremo de la configuración.

¿Y qué hace la gente sensata? Pues mezclar , más que elegir un modelo y meterlo en todas partes: VMs para lo que no quieres tocar todavía, contenedores para tu “core” de larga vida, serverless en los bordes para reaccionar a eventos y automatizar detalles.

Elige tu veneno… pero lee la etiqueta

Al final, decidir entre VMs, contenedores y serverless se parece peligrosamente a elegir hipoteca: todas tienen letras pequeñas, todas implican compromisos, y ninguna es “la correcta” sin contexto.

Las VMs te atan menos a patrones complejos, pero te regalan menos automatización. Los contenedores te dan portabilidad y consistencia, pero te piden que aprendas a domar un orquestador. Serverless te salva de pensar en servidores, pero te obliga a pensar en límites, facturas y dependencias con un proveedor concreto .

Los buenos artículos comparativos – los que no son solo marketing de un proveedor – coinciden en una idea incómoda: no elijas por moda, elige por caso de uso. Y, a ser posible, hazlo sabiendo que lo que decidas hoy no es eterno: mañana puedes mover una parte de serverless a contenedores, o consolidar contenedores en VMs, si tu tráfico, tu equipo o tu factura cambian.

Si hay que quedarse con una sola recomendación es esta: cuando alguien en tu equipo diga “tenemos que ser serverless” o “todo tiene que ir en contenedores”, intenta cambiar la frase por otra:

“Para este problema concreto, con este equipo y esta previsión de uso… ¿qué modelo de despliegue nos duele menos hoy y dentro de dos años?”

La respuesta no quedará tan bonita en una camiseta como un logo de Lambda o de Kubernetes, pero tiene muchas más papeletas de que te permita dormir por las noches… y pagar la factura sin sobresaltos.

Glosario rápido

Si has llegado hasta aquí sin googlear ninguno de estos términos, enhorabuena: o eres senior o eres mentiroso.

Fuentes y referencias

Lo que he leído para no inventarme nada, ordenado para que puedas fingir que tú también lo has leído.

Sígueme

Escribo y opino sobre tecnología, desarrollo de software y lo que se me pase por la cabeza.