Todo discurso de venta de una plataforma de gestión de cloud híbrido empieza en el mismo sitio: un diagrama con tus servidores on-premise a la izquierda, un cloud público a la derecha, y una flecha entre ambos etiquetada como migración. La flecha es el producto. También es la razón por la que la mayoría de estos proyectos se estancan, porque la flecha cuesta dieciocho meses y el valor solo llega al final de ellos. La pregunta más útil es qué podrías gestionar desde un solo lugar mañana mismo, sin mover nada y sin reescribir nada.
Lo híbrido no es una decisión de arquitectura que la mayoría de equipos tomara a propósito. Es lo que obtienes después de una década: un rack de hardware propio que todavía ejecuta eso que nadie puede mover fácilmente, un ERP que nadie quiere tocar, cargas de trabajo en un hyperscaler porque un cliente lo pidió, cómputo más barato en algún proveedor europeo porque alguien hizo las cuentas, y unos cuantos servidores en una instalación de colocation anteriores a la mitad del equipo actual. Nadie diseñó esto. Todo el mundo tiene que operarlo.
Por qué lo híbrido suele significar dos equipos
El coste práctico de lo híbrido es organizativo. Los recursos cloud se gestionan desde un navegador con tokens de API y etiquetas; la infraestructura física se gestiona con SSH, una herramienta de configuración y memoria institucional. Dos conjuntos de herramientas, dos modelos mentales, dos colecciones de runbooks, y normalmente dos grupos de personas que describen el trabajo del otro como "el lado legacy" o "el lado caro". El inventario se convierte en una fusión de exportaciones. La revisión de accesos se convierte en dos revisiones de accesos. Los incidentes que cruzan esa frontera se convierten en una discusión sobre de quién es el problema.
La respuesta estándar de los proveedores es hacer que un lado se parezca al otro: instalar una pila de cloud privado en tu hardware, o trasladarlo todo al cloud público y acabar con el tema. Ambas son estrategias legítimas y ambas son enormes. También comparten una suposición que merece la pena cuestionar: que la unificación tiene que ocurrir en la capa de infraestructura. No es así. La mayor parte de lo que un equipo realmente necesita unificar vive un piso más arriba: inventario, accesos, registro de cambios, coste y la capacidad de actuar.
Lo que una plataforma de gestión de cloud híbrido no debe hacer
Una plataforma de gestión de cloud híbrido se gana su sitio por lo que se niega a exigir. No debe exigirte mover una carga de trabajo antes de resultar útil. No debe exigir un agente en cada máquina para mostrarte tu infraestructura cloud, ni una cuenta cloud para mostrarte tus racks. No debe convertirse en una nueva dependencia de tu ruta crítica - si se cae, tus sistemas siguen funcionando y pierdes visibilidad, no disponibilidad. Y no debe retener tu infraestructura como rehén en su propio formato.
Por eso construimos Sencai con un enfoque import-first. Conectas una cuenta de proveedor con credenciales delimitadas y tus instancias, redes y almacenamiento existentes aparecen tal cual son, no como cosas que tienes que recrear. Nadie que esté evaluando una plataforma de infraestructura tiene infraestructura vacía, y un producto que solo demuestra su valor una vez que has reconstruido algo dentro de él ha condenado su propia demo al fracaso. La primera sesión debería mostrarte tu infraestructura, incluidas las partes que habías olvidado en silencio.
Parte de lo que ya existe
En el lado cloud eso significa once proveedores detrás de una sola interfaz: Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode de Akamai y Oracle Cloud. No una abstracción de mínimo común denominador que esconda todo lo interesante - las redes, las reglas de firewall y los registros DNS se crean y modifican en el propio proveedor, así que lo que ves es lo que el proveedor realmente tiene, y cualquier cosa que configures sigue funcionando si dejas de usarnos mañana por la mañana.
En el lado físico, un agente instalado en el host incorpora tus propios servidores al mismo inventario: una máquina en tu propio rack, en una jaula de colocation, o un equipo en un proveedor con el que no integramos directamente. Aparece junto a los recursos cloud en lugar de en una sección aparte, porque la idea central es que "qué ejecutamos" tenga una sola respuesta. Para los equipos cuyas restricciones descartan por completo un plano de control alojado, existe una edición on-premise con licencia anual y soporte.
La mitad on-premise no es legacy
En este mercado existe una suposición perezosa según la cual el hardware propio es un estado transitorio de camino a algo mejor. A veces lo es. A menudo es la respuesta correcta: cargas de trabajo pesadas y predecibles cuya depreciación es tuya, datos que una normativa o un contrato mantienen dentro de un edificio concreto, requisitos de latencia que ninguna región puede satisfacer, y hardware con años de vida útil por delante. Tratar esa infraestructura como de segunda categoría en tus herramientas no acelera su retirada. Solo significa que se monitoriza peor.
Un único plano de control sobre ambas mitades cambia pequeñas cosas que se van sumando. El gasto se rastrea entre proveedores con límites, así que la pregunta de cuánto cuesta un entorno tiene una única respuesta en lugar de cinco exportaciones. Los roles y las invitaciones son por organización, así que la revisión de accesos es una sola revisión. Y cada cambio, tanto en cloud como on-premise, queda registrado en el mismo rastro de auditoría de solo escritura y encadenado mediante hash, exportado con el hash de cada entrada y el de su predecesora, para que un auditor pueda verificar la secuencia de forma independiente.
Qué te compra un único plano de control
El planteamiento honesto es que nada de esto hace que lo híbrido sea sencillo. Dos modelos de hosting siguen teniendo dos perfiles de fallo, dos procesos de compra y dos estructuras de coste, y ninguna interfaz elimina eso. Lo que sí elimina es el impuesto que pagas por la frontera entre ambos: los inventarios duplicados, la segunda revisión de accesos, el incidente en el que nadie puede decir qué estaba haciendo el lado on-premise en ese momento. Ese impuesto lo paga tu equipo más pequeño, de forma continua, y por eso lo híbrido se siente peor de lo que realmente es.
Así que la prueba que le pondríamos a cualquier plataforma de gestión de cloud híbrido, la nuestra incluida, es breve. ¿Puedes ver todo lo que ejecutas, alquilado y propio, en una sola lista, en menos de una hora, sin migrar nada? ¿Puedes decir quién cambió qué el mes pasado, a ambos lados de la frontera? ¿Puedes responder cuánto cuesta esto sin abrir cinco consolas? Si la respuesta es sí, lo híbrido vuelve a ser simplemente infraestructura. Si es no, no tienes una plataforma, tienes otra consola más.