Máquinas virtuales, contenedores y funciones
Las tres formas de correr código en la nube no son tres niveles de modernidad: son tres respuestas distintas a qué arranca, cuánto tarda en arrancar y qué pasa cuando no hay tráfico. Elegir mal se paga en plata o en latencia.
Para este tema conviene tener claro:Imágenes, contenedores y registros
Datos de proveedores verificados contra la documentación oficial el 16 de sept de 2026.
La misma API —recibe una foto, guarda metadatos, genera una miniatura— puede correr en una máquina virtual, en un contenedor o en una función, y andar bien en las tres. No hay una respuesta correcta universal, pero sí hay tres preguntas que la determinan: qué tenés que empaquetar, cuánto tarda en estar lista una unidad nueva y qué pagás cuando nadie la usa.
Todo lo demás —modernidad, moda, lo que hizo la empresa del blog que leíste— es ruido.
Tres unidades de entrega
Lo que cambia entre las tres opciones es la unidad que el proveedor sabe arrancar por vos.
| Máquina virtual | Contenedor | Función | |
|---|---|---|---|
| Qué entregás | Una imagen de disco o una VM que instalás | Una imagen con tu app y sus dependencias | Un archivo de código y un manifiesto |
| Qué lleva adentro | Sistema operativo completo | Tu app, bibliotecas y un sistema de archivos mínimo | Sólo tu función: el runtime lo pone el proveedor |
| Cuánto tarda en estar lista | De decenas de segundos a minutos | De unos segundos a decenas de segundos | De milisegundos a unos segundos |
| Unidad de cobro típica | Tiempo encendida, esté o no trabajando | Recursos reservados mientras corre | Invocaciones y tiempo de ejecución |
| Qué pagás sin tráfico | Todo | Todo, salvo que escale a cero | Prácticamente nada |
| Cuánto control tenés | Kernel, drivers, discos, red | Proceso, dependencias, límites de recursos | El código y poco más |
Antes de seguir, predecí
Cuándo la máquina virtual sigue siendo la respuesta
La VM tiene mala prensa y sigue siendo la opción correcta más seguido de lo que se admite. Gana cuando necesitás algo que las capas de arriba no te dejan tocar:
- Software que no se containeriza fácil: licencias atadas al hardware, agentes que necesitan acceso privilegiado, aplicaciones que asumen un sistema completo con sus servicios.
- Control del sistema operativo: un kernel particular, módulos, parámetros de red, drivers de GPU con una versión exacta.
- Estado local pesado: una base de datos que administrás vos, un caché en disco, algo que quiere un volumen rápido y previsible.
- Carga constante y previsible: si un servicio trabaja parejo las 24 horas, la capacidad reservada suele ser lo más barato por unidad de trabajo.
Contenedores: el punto medio que se volvió norma
Un contenedor resuelve el problema que más duele en el día a día: que lo que probaste sea lo que corre. La imagen lleva la aplicación y sus dependencias, y se ejecuta igual en tu máquina, en integración continua y en producción.
Eso abre dos caminos bastante distintos, y confundirlos es el error de arquitectura más caro de esta unidad:
| Camino | Qué administrás | Cuándo conviene |
|---|---|---|
| Contenedores gestionados | La imagen, la configuración y cuántas réplicas querés | La mayoría de las aplicaciones web y APIs: arranca en minutos y escala solo |
| Kubernetes gestionado | Además, manifiestos, redes internas, políticas, operadores y actualizaciones del clúster | Muchos equipos y servicios, necesidades finas de despliegue o portabilidad entre nubes |
Más a fondo · nivel seniorEl tamaño de la imagen no es cosmética
Una imagen de 900 MB contra una de 80 MB cambia el tiempo de arranque de una réplica nueva, y el tiempo de arranque es lo que define si el autoescalado llega a tiempo a un pico. También cambia la superficie de ataque —cada paquete instalado es algo que hay que parchear— y el costo de transferencia y almacenamiento en el registro.
Las dos técnicas que más rinden: compilaciones en varias etapas, donde las herramientas de build quedan fuera de la imagen final, y una imagen base mínima. Y un detalle de caché que se paga solo: copiar primero el manifiesto de dependencias, instalarlas, y recién después copiar el código. Así un cambio de una línea no invalida la capa de dependencias.
Funciones: pagar por trabajo, no por tiempo
Una función se despliega sin elegir máquina: el proveedor arranca instancias cuando llegan pedidos y las apaga cuando dejan de llegar. El cobro se acerca al trabajo real —cantidad de invocaciones y tiempo de ejecución— y sin tráfico tiende a cero.
El precio de esa comodidad tiene tres partes concretas:
Lo que hay que aceptar para usar funciones
- Arranque en frío. La primera invocación después de un rato de inactividad paga la inicialización del entorno. Va de milisegundos a algunos segundos según runtime y tamaño del paquete, y se nota en APIs con tráfico esporádico y usuarios esperando.
- Límites duros. Hay un tope de duración por invocación, de memoria y de tamaño del paquete. Un trabajo que tarda una hora no entra: hay que partirlo o mover ese caso a un contenedor.
- Sin estado ni disco propio. Entre invocaciones no se garantiza nada. Todo lo que tiene que sobrevivir va a una base, una cola o un almacenamiento de objetos.
El árbol de decisión que funciona
Cuatro preguntas, en este orden, resuelven la elección en la mayoría de los casos reales:
Para elegir dónde corre un servicio
- ¿Necesitás algo del sistema operativo que no te dejan tocar? Si sí, máquina virtual. Fin del análisis.
- ¿El trabajo es por eventos, corto y de volumen irregular? Si sí, empezá por funciones y verificá los límites de duración, memoria y concurrencia contra tu caso.
- ¿Es un servicio de larga vida que atiende pedidos? Contenedores gestionados: es el punto medio con menos sorpresas.
- ¿Tenés varios equipos, muchos servicios y necesidades finas de despliegue? Recién ahí Kubernetes empieza a devolver lo que cuesta.
| Necesidad | AWS | Google Cloud | Azure |
|---|---|---|---|
| Máquinas virtuales | Amazon EC2 | Compute Engine | Azure Virtual Machines |
| Capacidad interrumpible y barata | EC2 Spot | Spot VMs | Azure Spot Virtual Machines |
| Contenedores administrados | Amazon ECS con Fargate | Cloud Run | Azure Container Apps |
| Kubernetes gestionado | Amazon EKS | Google Kubernetes Engine | Azure Kubernetes Service |
| Registro de imágenes | Amazon ECR | Artifact Registry | Azure Container Registry |
| Funciones por evento | AWS Lambda | Cloud Run functions | Azure Functions |
| Trabajos por lotes | AWS Batch | Cloud Run jobs y Batch | Azure Container Apps jobs |
Cierre
Autoevaluación
¿Lo entendiste?
Práctica