El problema oculto que espera a los equipos que reemplazan la automatización de VMware
La parte de las migraciones de VMware que se pasa por alto
Cuando las empresas empiezan a planificar su salida de VMware, la conversación suele girar en torno a hipervisores, clústeres de almacenamiento y redes. Los equipos comparan ESXi con KVM, debaten entre Ceph y cabinas SAN y analizan si la migración en caliente funciona igual. En algún punto de todas esas discusiones sobre infraestructura, una pieza importante del ecosistema de VMware desaparece de la vista: la automatización.
Un ingeniero se topó hace poco con este mismo problema mientras preparaba el paso de la mayor parte de su capa de virtualización a Proxmox. Su organización dependía mucho de VMware Aria Automation. Los equipos internos podían entrar en un portal, elegir una plantilla de máquina Windows o Linux, desplegarla ellos mismos y ver al instante el nombre de host, la dirección IP y la consola remota.
A los desarrolladores les encantaba, y a los equipos de infraestructura todavía más. Entonces empezó la planificación de la migración y, de repente, ese sistema de autoservicio no tenía un sustituto evidente. Darse cuenta de esto se está convirtiendo en una de las sorpresas más habituales para las organizaciones que abandonan VMware.
La capa de automatización de VMware hacía más de lo que la gente creía
VMware Aria Automation es más que una herramienta de comodidad. En muchas organizaciones funciona como la puerta de entrada a la infraestructura.
Los desarrolladores y los equipos internos ya no abren tickets de soporte para pedir servidores. Entran en un portal, eligen una plantilla y lanzan máquinas nuevas cuando las necesitan. El sistema se encarga del aprovisionamiento, asigna la red y da acceso a la consola si algo sale mal.
Desde el punto de vista del equipo de infraestructura, resuelve varios problemas a la vez. Estandariza la construcción de VMs, impone plantillas y elimina el aprovisionamiento manual. Y, sobre todo, evita que los ingenieros se conviertan en el cuello de botella cada vez que alguien necesita un entorno nuevo.
Cuando las organizaciones empiezan a migrar fuera de VMware, a menudo descubren que Proxmox por sí solo no incluye un equivalente completo a esa experiencia de portal, y ahí es donde la cosa se pone interesante.
La primera respuesta: construir tu propia automatización
Un ingeniero con experiencia respondió con la solución de la que dependen muchos equipos de infraestructura sin hacer mucho ruido: construyeron su propio sistema.
Su entorno usa Ansible para aprovisionar máquinas virtuales tanto en VMware como en Proxmox. Cuando alguien necesita un servidor, introduce un nombre de host y elige el tipo de máquina en un menú desplegable. Un script de construcción lanza el despliegue, obtiene la dirección IP asignada por DHCP y la guarda en una base de datos local. En unos cinco minutos, el servidor nuevo está listo.
La interfaz web que hay delante del sistema se escribió internamente, pero las herramientas de automatización de debajo son componentes de infraestructura estándar.
Ese enfoque dice mucho. Proxmox es muy fácil de automatizar mediante scripts a través de su API, y muchos equipos construyen sus propias capas de aprovisionamiento en lugar de depender de un único gran producto de automatización. También significa que la automatización pasa a ser responsabilidad del equipo de infraestructura.
El enfoque de cadena de herramientas que adoptan muchos equipos
En lugar de una plataforma centralizada como VMware Aria, los entornos Proxmox suelen apoyarse en combinaciones de herramientas.
Algunos ingenieros propusieron plataformas de orquestación como AWX, Rundeck, Semaphore, Jenkins, GitLab CI, Airflow o TeamCity. Estos sistemas pueden disparar flujos de automatización que interactúan con la API de Proxmox para crear y configurar máquinas virtuales. Las plantillas suelen construirse con Cloud-Init o con herramientas de gestión de configuración como Ansible.
Desde el punto de vista del usuario, la experiencia puede seguir pareciendo un portal de autoservicio, mientras que entre bastidores varios sistemas trabajan juntos para ofrecer ese flujo.
Este enfoque modular da flexibilidad, pero también exige más planificación de arquitectura. VMware empaquetaba muchas de esas capacidades en una sola plataforma, y las pilas de infraestructura abierta tienden a repartirlas entre varias herramientas.
Las plataformas comerciales siguen existiendo
No todas las organizaciones quieren construir su propia capa de automatización. Un ingeniero comentó que su empresa usa CloudBolt para el aprovisionamiento en autoservicio. En su entorno, los usuarios pueden desplegar infraestructura desde un portal, ver la dirección IP y el nombre de host de la VM y acceder a la consola directamente desde la interfaz.
CloudBolt también puede disparar flujos de orquestación y acciones de gestión de configuración durante la construcción de los servidores, y admite Proxmox como proveedor de recursos. Para las organizaciones que quieren una experiencia parecida a la de VMware sin construirlo todo internamente, herramientas como esta pueden cubrir el hueco.
También traen costes de licencias y otra plataforma que gestionar, lo que devuelve la conversación a los mismos compromisos que dieron pie a la discusión sobre la migración.
Algunos ingenieros proponen enfoques más sencillos
No todo el mundo cree que haga falta una gran plataforma de automatización. Una respuesta propuso usar scripts sencillos combinados con plantillas de VM y dejar que los usuarios los lancen desde interfaces ligeras como OliveTin. En ese modelo, la automatización son básicamente scripts envueltos en una interfaz web.
Otro comentario señaló que a veces la solución más sencilla es apoyarse directamente en funciones de Proxmox como Cloud-Init, el agente de invitado QEMU y la API de Proxmox. Con esas piezas en su sitio, el aprovisionamiento automatizado de VMs se vuelve relativamente sencillo. La pega es que los administradores tienen que montar el flujo ellos mismos, porque ningún producto ofrece la experiencia completa.
Por qué existe este problema
A Proxmox no le faltan funciones en este terreno. El reto viene de una filosofía distinta.
VMware construyó un ecosistema en el que el hipervisor, la plataforma de automatización, la pila de red y las herramientas de gestión pertenecen al mismo fabricante. Esa integración estrecha facilita estandarizar los entornos grandes.
Proxmox vive en un mundo muy distinto. Forma parte del ecosistema más amplio de infraestructura abierta, donde las herramientas son modulares e intercambiables y montas los componentes que encajan con tu flujo de trabajo en lugar de comprar una plataforma gigante.
Para los ingenieros a los que les gusta construir sistemas, esa flexibilidad es muy potente. Para los equipos acostumbrados al enfoque todo en uno de VMware, puede dar la impresión de que falta algo importante.
El momento en que la planificación de la migración se vuelve real
Por eso la cuestión de la automatización suele convertirse en un punto de inflexión en las migraciones de VMware. Sustituir el hipervisor es relativamente fácil, sustituir la arquitectura de almacenamiento es asumible y las diferencias de red se pueden aprender. Sustituir los flujos de trabajo de los que la gente depende a diario, es decir, los portales, los pipelines de automatización y los sistemas de aprovisionamiento, es un trabajo más difícil.
Muchas organizaciones descubren que la migración implica reconstruir la capa operativa que está por encima de las máquinas virtuales, además de mover las propias máquinas. En ese punto, el plan de salida de VMware deja de ser un ejercicio técnico y se convierte en un rediseño de la infraestructura.