El problema de salir de VMware: backups, tiempo de inactividad y todo lo que nadie puso en las diapositivas
La propuesta para dejar VMware suele empezar con una hoja de cálculo, lo cual tiene sentido, porque la factura es lo primero que aparece. Tras los cambios de licencias de Broadcom, muchos equipos de TI empezaron a hacer la misma cuenta: ¿cuánto pagamos ahora, cuánto pagábamos antes y qué haría falta para irnos a otra parte? Para algunas empresas, la respuesta parece lo bastante obvia como para lanzar una búsqueda seria de alternativas.
Pero la hoja de cálculo es la parte fácil. La parte difícil es todo lo que no encaja limpiamente en una comparación de precios: la cadena de copias de seguridad que lleva años funcionando sin una queja, el appliance del fabricante que solo se porta bien de verdad dentro de un mundo con forma de VMware y la ventana de mantenimiento que existe sobre el papel pero no en la vida real. Está el viejo sistema de monitoreo que nadie quiere pero del que todos dependen, y la extraña dependencia entre un sistema "temporal" de 2017 y una aplicación crítica que ahora mueve medio negocio. Ahí es donde la salida de VMware empieza a complicarse.
En una discusión sobre infraestructura en internet, una empresa de la India hizo una pregunta sencilla: para las organizaciones que ya se han ido de VMware, ¿cuál fue el mayor reto en la realidad? Querían la respuesta de verdad, no la versión del marketing ni la de las diapositivas. Enumeraron los sospechosos habituales: la complejidad de la migración, el riesgo de tiempo de inactividad, la curva de aprendizaje del equipo, la fiabilidad del soporte, la compatibilidad, el rendimiento y la gestión operativa. Las respuestas convergieron rápido en un tema. Descubrir todo lo que VMware te facilitaba en segundo plano suele dar más miedo que convertir las máquinas virtuales.
Uno de los comentarios más certeros lo dijo sin rodeos: lo difícil suele estar fuera de la conversión de las VMs, en el transporte de las copias de seguridad, los snapshots, los appliances de fabricantes, el monitoreo y las ventanas de mantenimiento, todas esas cosas raras que VMware gestionaba con tanta suavidad que los equipos dejaron de notarlas. El consejo fue directo: haz un piloto de dependencias y restauración antes de enamorarte del logotipo de una plataforma nueva. Todo plan de migración debería imprimir esa frase en la primera página.
Todas las demos de plataformas parecen limpias. Se mueven unas cuantas VMs, se ilumina un panel y alguien enseña una carga de trabajo funcionando tan contenta en Proxmox, Hyper-V, OpenShift Virtualization, XenServer, Nutanix o lo que haya en la lista corta. La sala se relaja un poco. Quizá esto no sea tan terrible.
Entonces alguien pregunta por las copias de seguridad, y no se refiere a "¿podemos hacer backup?" en el sentido vago del camino feliz. La pregunta que de verdad necesitan responder es más fea: ¿podemos hacer las copias como las hacemos ahora, con las mismas expectativas de punto de recuperación, las mismas expectativas de tiempo de recuperación, la misma consistencia de aplicación, el mismo comportamiento de los snapshots, la misma eficiencia de transporte y la misma confianza a las 2:17AM, cuando una restauración es lo único que se interpone entre una caída y una mañana muy mala? Ahí es donde la historia de la migración fácil empieza a tambalearse.
La ventaja de VMware siempre ha ido más allá del hipervisor, hasta el ecosistema que lo rodea. Los fabricantes de backup, los de almacenamiento, las herramientas de monitoreo, los productos de seguridad y los fabricantes de appliances lo conocen. Años de integraciones se han ido acumulando alrededor de vSphere y vCenter hasta que VMware se convirtió menos en un producto y más en el suelo bajo el centro de datos. Puedes cambiar un suelo. Lo que no quieres es descubrir a mitad del trabajo que la fontanería estaba anclada a él.
Las copias de seguridad salieron una y otra vez en la discusión, a veces en un párrafo entero y a veces como aviso de una sola palabra: "¡Backups!". Esa respuesta de una palabra dice mucho. La gente de infraestructura no se pone dramática con las copias de seguridad porque le guste el drama. Se pone dramática porque las copias de seguridad son el punto donde la teoría se encuentra con el miedo.
Un trabajo de copia de seguridad que técnicamente termina no es lo mismo que un plan de recuperación que funciona, y una VM restaurada que arranca no es lo mismo que un servicio que vuelve limpiamente. Las copias basadas en snapshots que eran rutina en una plataforma pueden convertirse en un suplicio en otra, sobre todo cuando el almacenamiento se comporta de otra forma, el almacenamiento compartido tiene sus salvedades o el nuevo stack no encaja limpiamente con el antiguo. Una persona que está pasando a sus clientes a Proxmox dijo que la experiencia había sido estupenda en general, pero que el mayor obstáculo era que el almacenamiento y los snapshots funcionan de otra manera. No es una nota a pie de página menor, porque significa que todo el modelo operativo se está moviendo bajo los pies del equipo.
Otra persona señaló como problemas importantes el soporte de los fabricantes y el ciclo de vida del almacenamiento en bloque, y añadió que Proxmox con almacenamiento compartido por iSCSI puede funcionar, pero obliga a los equipos a replantearse muchas cosas, y las copias basadas en snapshots se convierten en un verdadero quebradero de cabeza. Ese tipo de detalle rara vez llega a los resúmenes de migración para la dirección, y debería.
Luego están los appliances. Todo entorno VMware los tiene. Algunos son oficiales, otros vinieron de fabricantes y otros los desplegó hace años alguien que ya no trabaja allí. Unos cuantos son appliances Linux que llevan tanto tiempo funcionando sin dar guerra que nadie recuerda su contraseña de root, y mucho menos sus dependencias de drivers. Mover cargas de trabajo normales es un trabajo, y mover appliances es otro más difícil.
Un equipo que se pasó a OpenShift Virtualization dijo que los appliances fueron el mayor reto. Algunos fabricantes ofrecen imágenes para KVM, algunos appliances se pueden convertir y otros no incluyen los drivers necesarios para funcionar bien en KVM. Es un problema muy práctico, sin nada de filosófico y sin debate sobre código abierto frente a software comercial. Es solo una caja que antes arrancaba y ahora puede que no.
Cuando el appliance pertenece a un fabricante que solo certifica VMware, la cosa se pone todavía más incómoda. El equipo de migración, el negocio y la nueva plataforma pueden estar listos mientras que la matriz de soporte del fabricante no lo está. En ese punto, elegir una "alternativa a VMware" deja de ser una elección de producto y se convierte en una negociación con cada fabricante del stack.
El tiempo de inactividad es la otra trampa. Todo el mundo quiere menos, y todo el mundo presupuesta demasiado poco.
VMware malacostumbró a muchos equipos en esto. vMotion hizo que muchas tareas de mantenimiento resultaran aburridas en el mejor sentido posible. Los hosts se podían vaciar, las cargas de trabajo se podían mover y los parches pasaron a ser algo más parecido a una rutina controlada que a un número de funambulismo. Un empleado de VMware en la discusión sostuvo que la virtualización al estilo Kubernetes y algunos stacks más nuevos siguen por detrás de VMware en APIs de backup y en madurez de las ventanas de mantenimiento. Puso como ejemplos el parcheo en vivo de ESXi y las mejoras de vMotion, un pulido operativo difícil de sustituir de la noche a la mañana.
No tienes que comprar todo ese argumento para ver la idea general. VMware ha tenido décadas para limar las aristas de la operación diaria. Las alternativas pueden ser buenas, y algunas pueden encajar mejor en ciertas organizaciones, pero cambiar de plataforma significa volver a aprender qué aristas cortan.
Las ventanas de mantenimiento parecen sencillas hasta que mueves sistemas que "tienen que estar encendidos todo el tiempo". Una persona que acababa de terminar la migración de un cliente y estaba pasando un laboratorio a Hyper-V dijo que las migraciones en sí fueron bastante fluidas con herramientas como Veeam y StarWind. Lo que las frenó fueron las aplicaciones críticas y las ventanas de mantenimiento. Esa misma persona advirtió a los equipos de que empezaran pronto, sobre todo si las licencias por suscripción imponen una fecha límite, porque esperar al último minuto lo cambia todo. Una caída en un laboratorio es molesta. El tiempo de inactividad en producción, con cientos de sistemas y cientos de usuarios, es harina de otro costal.
A la dirección a veces se le escapa que el riesgo de la migración no se reparte por igual. Diez VMs fáciles pueden hacer que un plan parezca más sano de lo que es, mientras que un appliance testarudo ligado a un flujo de trabajo crítico puede quemar todo el calendario.
También está la deuda técnica, claro. Las migraciones desde VMware tienen la costumbre de convertirse en arqueología de infraestructura. Empiezas moviendo cargas de trabajo y luego encuentras la vieja dependencia de autenticación, después la suposición sobre el almacenamiento, después la excepción del backup, después el appliance que nadie parcheó porque tocarlo parecía traer mala suerte. Un comentarista lo expresó bien: este es el momento de ocuparse de los esqueletos del armario de los que no te has ocupado. Duele, y también es útil.
Una salida de VMware puede ser un proyecto de limpieza disfrazado de proyecto de ahorro. Eso no es malo, pero hay que tratarlo con honestidad. Si el entorno está lleno de dependencias sin documentar y la migración se pone difícil, la culpa es del desorden antiguo. Puede que VMware simplemente fuera lo bastante bueno escondiéndolo.
Así que sáltate el concurso de plataformas como primer paso y empieza con una prueba de restauración. Empieza por la aplicación más fea, el appliance que nadie quiere tocar, la carga de trabajo con la menor tolerancia al tiempo de inactividad y el fabricante cuyo portal de soporte todavía dice solo VMware. El logotipo nuevo puede esperar.
Lo que decide el resultado es si el equipo puede recuperar, parchear, monitorear, hacer snapshots, dar soporte y operar el entorno sin inventarse una crisis nueva cada semana. Una plataforma más barata que exige más trabajo manual puede seguir mereciendo la pena. Una plataforma más abierta con una curva de aprendizaje más empinada puede seguir siendo la decisión correcta a largo plazo. Una renovación de VMware puede incluso tener sentido para algunos entornos grandes o muy integrados. Aquí no hay una única respuesta limpia, y probablemente por eso la discusión resultó tan realista.
Dejar VMware es posible, y muchos equipos lo están haciendo. Algunos suenan aliviados, otros suenan agotados y otros van por la mitad de la salida y siguen descubriendo qué estaba atornillado al armazón.
La gran lección es sencilla: no confundas la conversión de VMs con la migración de plataforma. La VM es solo lo que se ve. A su alrededor están las copias de seguridad, el almacenamiento, los snapshots, la política de red, el monitoreo, el soporte de los fabricantes, los hábitos de mantenimiento, la memoria muscular del equipo y años de suposiciones que nadie dijo en voz alta. Esa es la plataforma real, y es todo lo que nadie puso en las diapositivas.