¿Máquina virtual, contenedor o bare metal? La opción adecuada depende de la aplicación, del soporte del proveedor y de quienes la operarán a largo plazo. Un contenedor no hace automáticamente mantenible un ERP antiguo. Un servidor físico no es automáticamente más rápido. Una VM no justifica descuidar copias y actualizaciones. DAXS comienza por la carga concreta: sistema, dependencias, datos, recuperación y carga medible.
La comparación responde a la pregunta de dónde conviene ejecutar un servicio. Si ya se han elegido contenedores de aplicación, surge otra pregunta: ¿Docker Compose o Kubernetes para la operación? Ambas decisiones deben tomarse por separado.
¿Qué se separa realmente?
Una máquina virtual recibe hardware virtual y su propio sistema invitado. Permite, por ejemplo, un invitado Windows Server junto a invitados Linux en el mismo hipervisor. La VM es una unidad delimitada para parches, snapshots y recuperación; la aplicación sigue necesitando copias coherentes. En Proxmox VE esta vía utiliza KVM.
Un contenedor comparte el kernel del host. Hay que distinguir dos formas: un contenedor Proxmox LXC es un sistema Linux ligero; un contenedor de aplicación OCI suele empaquetar una aplicación y sus dependencias. Ninguno es una VM Windows ni proporciona aislamiento mediante un kernel propio. OCI también exige construcción de imágenes mantenida, un registro, actualizaciones de seguridad y una solución consciente para datos persistentes. Una VM Linux como host puede delimitar operación, copias y permisos; no es obligatoria técnicamente en todos los escenarios.
Bare Metal ejecuta el sistema y la aplicación directamente en un servidor físico. Puede encajar con restricciones del proveedor, hardware especial o requisitos de latencia demostrados. Reduce la consolidación de ese host y vincula más mantenimiento, repuestos y recuperación a la máquina física. También aquí deciden las mediciones y los compromisos de soporte, no afirmaciones generales de rendimiento.
Cinco cargas típicas y su primera vía de evaluación
Las siguientes vías son puntos de partida para probar, no aprobaciones generales de productos. La documentación, el contrato de licencia y una prueba de recuperación permiten una decisión sólida.
| Aplicación | Vía de evaluación | Pregunta crítica |
|---|---|---|
| ERP Windows con base de datos y soporte del proveedor | VM como punto de partida natural | ¿Qué combinación de sistema invitado, hipervisor, SQL y licencias está realmente admitida? |
| Servicio web Linux propio con build reproducible | Contenedor de aplicación OCI, posiblemente en una VM Linux | ¿Quién crea y actualiza imágenes, comprueba vulnerabilidades y opera registro, secretos y logs? |
| Appliance Linux de un proveedor | Examinar primero una VM admitida | ¿Acepta el proveedor la virtualización, los dispositivos virtuales y la vía de copia/recuperación prevista? |
| Base de datos con mucha carga de escritura | VM o bare metal según mediciones; contenedores solo con persistencia probada | ¿Cómo se comportan latencias p95/p99, IOPS, replicación y recuperación coherente en los picos? |
| Servicio con dongle, tarjeta especial o acceso directo a dispositivos | Probar passthrough en VM; considerar bare metal | ¿Siguen siendo posibles soporte, asignación de dispositivos y recuperación tras cambiar el host? |
Un contenedor de base de datos no es incorrecto por principio. Su sistema de archivos escribible no es el lugar para datos que deban sobrevivir al reemplazo del contenedor. Hay que planificar volúmenes, coherencia, copias y recuperación explícitamente. A la inversa, una VM no convierte una copia no probada en recuperación fiable.
Seis comprobaciones para decidir
- Proveedor y licencia: Comprobar por escrito sistemas, hipervisores, motores de contenedores y restricciones de hardware admitidos. Los derechos de Windows Server dependen de edición, núcleos licenciados, número de entornos virtuales y contrato; «una VM» no implica un precio fijo.
- Aislamiento y permisos: ¿Qué servicio puede afectar a otro? Los contenedores tienen namespaces y límites de recursos, pero comparten el kernel del host. Motor, privilegios, montajes, red y actualizaciones forman parte de la revisión de seguridad.
- Medir el rendimiento: Recoger carga CPU, RAM y E/S, latencias p95/p99, picos y ventanas batch con datos reales. Elegir bare metal solo por una supuesta «sobrecarga de virtualización» puede inmovilizar capacidad cara sin resolver el problema de almacenamiento o red.
- Datos y recuperación: Definir RPO y RTO por servicio. Practicar una restauración completa en otro host con base de datos, configuración, credenciales y dependencias.
- Cambios y personal: ¿Quién parchea el sistema invitado o el kernel host? ¿Quién reconstruye imágenes? ¿Quién puede atender de noche un rollback fallido o un cambio de hardware? Las competencias disponibles limitan cuántas plataformas pueden operarse razonablemente en paralelo.
- Dominio de fallo: Analizar por separado host, almacenamiento, red y copias. Ni un servidor bare metal único ni varios contenedores en un solo host adquieren alta disponibilidad por su nombre.
Comparar el esfuerzo antes de afirmar ahorros
Para tres o cinco años, comparar en cada columna la misma aplicación con igual carga y objetivo de recuperación. Incluir migración y puesta en marcha, hardware y repuestos, derechos de sistemas y aplicaciones, soporte de hipervisor o motor, energía, copias, monitorización y horas anuales de personal. OCI añade, por ejemplo, pipeline de build, registro, mantenimiento de imágenes y posible orquestación. Bare metal puede requerir hardware de sustitución y otra ventana de mantenimiento. En VM cuentan capacidad del host y sistemas invitados. Un clúster existente solo es «gratis» para el nuevo servicio si reservas, licencias y recursos operativos existen de verdad.
La fórmula básica verificable es: coste total durante n años = puesta en marcha y migración iniciales + n × (licencias anuales + soporte + energía + copias + horas operativas × tarifa interna por hora) + renovación prevista. n es tres o cinco. Sin ofertas concretas, mediciones y condiciones de soporte, ninguna modalidad tiene una ventaja general. La comparación también debe mostrar el coste de no alcanzar RPO/RTO, en vez de excluirlo del cálculo.
Cómo elegiría DAXS la modalidad
DAXS prepararía una breve lista de aplicaciones con responsable, flujo de datos, soporte del proveedor, dependencias y objetivo de recuperación. Después probaría dos candidatos realistas: carga próxima a producción, parches y upgrades, fallo de host o dispositivo y restauración en otra máquina. El resultado es una decisión justificable por aplicación, no una obligación de llevar todos los servicios a una plataforma.
Las VM Windows y Linux existentes suelen poder evaluarse gradualmente; Proxmox en la empresa describe la base de virtualización. Si los contenedores convencen, la comparación de Docker Compose y Kubernetes ayuda en el siguiente paso. Para una carga concreta, mediante Contacto DAXS puede convertir aprobaciones, mediciones y recuperación en una decisión operativa conjunta.
Fuentes: Proxmox VE: KVM y LXC · Docker Engine: modelo de seguridad · Docker Engine: datos persistentes · Microsoft: Windows Server Virtualization Licensing Guidance.
