Por qué se acelera la migración de VMware a Kubernetes
Las conversaciones sobre migración desde VMware solían posponerse con facilidad. Muchas organizaciones aceptaban la complejidad de licencias, el acoplamiento al hardware y la sobrecarga de almacenamiento porque el modelo operativo era familiar y el coste del cambio parecía demasiado alto.
Ese cálculo ha cambiado. Hoy los responsables de infraestructura tienen que responder a tres preguntas:
- ¿Cuál es la plataforma a largo plazo para las máquinas virtuales y las aplicaciones stateful?
- ¿Cómo evitamos arrastrar al siguiente entorno las suposiciones de almacenamiento heredadas de VMware?
- ¿Cómo migramos por etapas sin crear caos operativo?
Para un conjunto cada vez mayor de equipos, la respuesta ya no es “sustituir VMware por otra pila aislada de hipervisor”. La dirección pasa por adoptar Kubernetes como modelo operativo de la infraestructura moderna, elegir un entorno como OpenShift, Rancher, Talos o Kubernetes upstream y usar KubeVirt cuando las VM sigan formando parte del paisaje.
Eso no significa que todas las cargas se conviertan en contenedores de la noche a la mañana. Significa que la plataforma objetivo puede sostener ambos mundos mientras los equipos modernizan a su propio ritmo.
Cómo es una arquitectura objetivo realista de VMware a Kubernetes
Una arquitectura objetivo realista tiene cuatro capas:
- Kubernetes como plano de control para orquestación, políticas, automatización y lifecycle management.
- OpenShift, Rancher, Talos o Kubernetes upstream como entorno operativo sobre el que el equipo se estandariza.
- KubeVirt como capa de virtualización para ejecutar VM dentro de Kubernetes cuando las cargas VM siguen formando parte del entorno.
- Simplyblock como plataforma de almacenamiento en bloques persistente para discos de VM, snapshots, clones y datos stateful.
La razón es sencilla: los proyectos de migración desde VMware suelen fracasar en la capa de almacenamiento y operación, no en la presentación. Ejecutar VM sobre Kubernetes es posible. Ejecutarlas con el perfil de rendimiento adecuado, con los data services correctos y con un day-2 sólido es lo que separa una plataforma destino real de un experimento.
Simplyblock añade aquí una capa de almacenamiento NVMe-first diseñada para entornos modernos. Los equipos pueden empezar con Kubernetes-native storage, orientar la plataforma hacia OpenShift, Rancher by SUSE o Talos, e incorporar KubeVirt storage cuando sigan existiendo casos de uso de VM. La misma base puede sostener después una estrategia más amplia de private cloud o platform engineering.
Qué plataforma destino encaja mejor
No todas las migraciones desde VMware terminan en la misma distribución de Kubernetes ni en el mismo modelo operativo. La mejor pregunta es qué plano de control y qué patrón operativo encajan con el equipo, con los requisitos de cumplimiento y con las expectativas de ciclo de vida.
OpenShift para estandarización enterprise
Los equipos ya alineados con Red Hat suelen buscar una ruta de migración que mantenga coherencia en seguridad, políticas y operaciones entre clústeres. Simplyblock para OpenShift es la referencia adecuada cuando OpenShift es el destino y el almacenamiento debe integrarse de forma limpia en las operaciones nativas de OpenShift.
Rancher para gestión de flotas multi-clúster
Las organizaciones que gestionan múltiples entornos Kubernetes entre unidades, regiones o clientes suelen preferir Rancher como capa operativa. Simplyblock para Rancher by SUSE y el Simplyblock + Rancher Virtualization Bundle son referencias naturales en ese escenario.
Talos para infraestructura mínima y controlada por API
Algunos equipos quieren dejar atrás no solo VMware, sino también la deriva asociada a hosts Linux generalistas. Simplyblock para Talos y el Simplyblock + Talos Virtualization Bundle encajan con ese modelo Kubernetes más declarativo y minimalista.
KubeVirt cuando las VM siguen teniendo sitio
Si las máquinas virtuales siguen formando parte del entorno objetivo, KubeVirt actúa como puente entre el legado y el nuevo modelo operativo. KubeVirt storage muestra cómo simplyblock soporta discos de VM, snapshots, clones y cargas virtualizadas sensibles al rendimiento sobre Kubernetes.
Qué cargas conviene mover primero
Una migración desde VMware no tiene por qué empezar por el parque de VM más crítico para el negocio. En la práctica, las primeras oleadas funcionan mejor cuando permiten validar la arquitectura objetivo sin introducir un riesgo innecesario.
Buenos candidatos iniciales incluyen:
- VM de desarrollo y pruebas
- servicios internos con requisitos moderados de rendimiento
- servicios compartidos gestionados por la plataforma
- aplicaciones basadas en VM que ya conviven con entornos Kubernetes
- nuevas cargas que, de otro modo, se desplegarían por defecto sobre VMware
Estas migraciones ayudan a validar el modelo operativo, comprobar el comportamiento del storage y afinar la plataforma antes de mover estates de producción más amplios.
Las cargas que normalmente requieren más preparación incluyen:
- bases de datos muy sensibles a la latencia
- sistemas con fuertes requisitos de cumplimiento
- appliances legacy con suposiciones técnicas rígidas
- grandes parques de VM con dependencias complejas de red y backup
Estas cargas también pueden migrar, pero una vez que la plataforma objetivo se haya probado y estandarizado.
Requisitos de almacenamiento que no puedes ignorar
Si una migración de VMware a Kubernetes va en serio, el almacenamiento no puede tratarse como un detalle.
1. El rendimiento de las VM sigue importando
Mover máquinas virtuales a KubeVirt no las hace automáticamente tolerantes a un almacenamiento ruidoso. Muchas siguen necesitando latencia predecible, throughput estable e IOPS consistentes, especialmente bases de datos, middleware y plataformas internas.
2. Snapshots, clones y recovery son requisitos operativos
Los programas de migración suelen centrarse demasiado en dónde corre el compute. Sin embargo, los workflows de storage importan igual o más. Los equipos siguen necesitando snapshots, clones, integración con backup y procesos de recovery para discos virtuales y datos stateful.
3. La multi-tenancy y la QoS ganan importancia
Cuando Kubernetes se convierte en una plataforma compartida, distintos equipos y cargas compiten por la misma infraestructura. El almacenamiento necesita controles claros de rendimiento e aislamiento, no solo capacidad bruta.
4. Escalar compute y storage por separado es un gran palanca económica
Una ventaja clave de la infraestructura software-defined es que compute y storage no tienen por qué crecer siempre al mismo tiempo. Esto importa especialmente en proyectos de reemplazo de VMware, donde los entornos heredados esconden patrones de escalado ineficientes dentro de bundles costosos.
Por eso Software-defined storage y NVMe-over-TCP storage pasan a ser temas estratégicos y no solo técnicos.
Un plan de migración por fases para reducir el riesgo
La mayoría de los equipos debería ver la migración desde VMware como una secuencia de hitos de plataforma, no como un cutover único.
Fase 1: Evaluar el estate actual
Mapea las cargas, los patrones de almacenamiento, las expectativas de recovery y las dependencias operativas dentro del entorno VMware actual. Identifica qué cargas son más sencillas de mover primero y cuáles requieren más diseño.
Fase 2: Construir la plataforma objetivo
Despliega Kubernetes, decide si el modelo operativo será OpenShift, Rancher, Talos o Kubernetes upstream, valida KubeVirt si las VM siguen dentro del scope y coloca la capa de almacenamiento adecuada por debajo. Es aquí donde deben probarse rendimiento, snapshots, clones e aislamiento de tenants, no asumirse.
Fase 3: Migrar primero las cargas de menor riesgo
Usa las primeras migraciones para validar:
- workflows de ciclo de vida de VM
- comportamiento del rendimiento del storage
- procesos de backup y recovery
- propiedad operativa
- observabilidad y runbooks de soporte
Fase 4: Ampliar el modelo mixto de VM y contenedores
Una vez que la plataforma se demuestra válida, los equipos pueden ejecutar VM y cargas contenedorizadas sobre la misma base Kubernetes. Es a menudo ahí donde el nuevo modelo empieza a generar la ventaja operativa y económica real.
Fase 5: Mover las cargas stateful estratégicas
Cuando la plataforma está estable, resulta mucho más factible migrar servicios VM y stateful más críticos con mayor confianza en rendimiento, escalabilidad y recovery.
Por qué simplyblock ayuda en un programa de migración desde VMware
Simplyblock es especialmente relevante en una estrategia VMware-to-Kubernetes porque cubre una de las brechas más difíciles: ofrecer almacenamiento en bloques moderno para máquinas virtuales y cargas stateful sin arrastrar el coste y la complejidad de las arquitecturas de almacenamiento heredadas.
En la práctica, eso suele significar:
- soportar discos de VM y datos persistentes sobre una plataforma compartida
- reducir la dependencia de pilas de almacenamiento ligadas al hardware
- habilitar snapshots y clones como parte de los workflows de plataforma
- hacer que los costes sean más previsibles con el tiempo
- dar a los equipos de plataforma una capa de storage alineada con las operaciones Kubernetes
Esto es especialmente valioso cuando el estado objetivo no es solo “salir de VMware”, sino “construir una mejor plataforma de largo plazo para workloads virtualizados y cloud-native”.
Si ese es tu objetivo, conviene leer esta página junto con:
- OpenShift storage
- Rancher by SUSE storage
- Talos storage
- Simplyblock + Rancher Virtualization Bundle
- Simplyblock + Talos Virtualization Bundle
- KubeVirt storage
- Kubernetes storage
- Persistent Storage for Kubernetes
- VMware vs Kubernetes
- KubeVirt vs VMware
FAQ sobre migración de VMware a Kubernetes
¿Es Kubernetes realmente un sustituto de VMware?
No directamente. Kubernetes es una plataforma de orquestación, mientras que VMware es una plataforma de virtualización. El modelo más realista combina Kubernetes, la capa operativa adecuada como OpenShift, Rancher o Talos, KubeVirt para las máquinas virtuales y una plataforma de almacenamiento capaz de soportar bien VM y cargas stateful. Esa combinación puede sustituir una parte importante de una infraestructura centrada en VMware si se diseña correctamente.
¿Todas las cargas de VMware pertenecen a Kubernetes?
No. Algunas cargas son mejores candidatas que otras para las primeras oleadas. El objetivo no es la pureza ideológica, sino mover las cargas adecuadas, construir una mejor plataforma objetivo y evitar que la próxima década quede atrapada por las mismas limitaciones.
¿Por qué el storage importa tanto en una migración desde VMware?
Porque el éxito no depende solo del compute. Discos de VM, snapshots, recovery, latencia predecible y aislamiento de cargas dependen directamente de la capa de almacenamiento. Un mal diseño del storage puede convertir una migración prometedora en una mala experiencia operativa.
¿Hay que elegir entre OpenShift, Rancher, Talos y KubeVirt?
No. OpenShift, Rancher y Talos describen el entorno operativo alrededor de Kubernetes. KubeVirt es la capa de virtualización que permite ejecutar VM dentro de ese entorno. Resuelven partes distintas de la arquitectura objetivo y pueden combinarse con la misma capa de almacenamiento de simplyblock.
¿Qué papel juega KubeVirt en una estrategia de salida de VMware?
KubeVirt permite ejecutar máquinas virtuales dentro de Kubernetes, lo que posibilita que los equipos se estandaricen en un solo plano de control mientras siguen soportando aplicaciones basadas en VM. Por eso actúa como un puente práctico para organizaciones que quieren modernizar sin exigir que todas las cargas se contenedoricen de inmediato.
¿Cuándo deberían empezar los equipos a planificar la migración?
Normalmente antes de lo que creen. Aunque la ejecución se haga por fases, el diseño de plataforma, la evaluación de cargas y la validación del storage requieren tiempo. Empezar pronto da más opciones y reduce la presión de tener que reaccionar más tarde.