Gestión multicloud

«Multicloud» se usa a menudo como término estratégico: un motivo para diversificar y no depender de un único proveedor, negociar mejores precios o cumplir un requisito de residencia de datos. La gestión multicloud es la capa operativa, más concreta, que sostiene esa estrategia: las herramientas y procesos que permiten a un equipo de infraestructura ejecutar cargas de trabajo en varios proveedores sin tratar cada uno como un trabajo aparte. Sin ella, «multicloud» significa en la práctica una consola, un conjunto de credenciales y una terminología distintos para cada proveedor, y ningún lugar único donde responder una pregunta básica: qué infraestructura existe ahora mismo y quién la modificó por última vez.

Cada proveedor ofrece su propia consola, CLI, modelo IAM y vocabulario para los mismos elementos subyacentes: una máquina virtual, un grupo de seguridad, una zona DNS, un volumen de almacenamiento. Esa fragmentación es el problema real que resuelve la gestión multicloud. Empieza por el descubrimiento: conectar la cuenta de un proveedor y ver de inmediato un inventario de lo que ya se ejecuta ahí, antes de migrar o modificar nada. A partir de ahí aplica un único flujo de trabajo coherente a las acciones habituales del ciclo de vida —aprovisionar, iniciar, detener, redimensionar, eliminar— sin importar en qué proveedor esté el recurso. Las implementaciones más sólidas gestionan la configuración en vivo y de forma síncrona directamente en el proveedor, en lugar de a través de una copia en caché en su propia base de datos, de modo que un cambio realizado desde la herramienta es el mismo cambio que se vería al iniciar sesión en la consola propia de ese proveedor.

La gestión multicloud va más allá del ciclo de vida del cómputo y abarca las partes de la operación que realmente generan riesgo cuando son inconsistentes entre proveedores. El control de acceso debe funcionar igual en todas partes: inicio de sesión único, permisos basados en roles y elevación de privilegios sujeta a aprobación para acciones sensibles, en lugar de un modelo de identidad distinto por proveedor. Cada cambio debe poder atribuirse a alguien, por lo que un registro de auditoría que abarque todos los proveedores conectados importa aquí más que en una configuración de un solo proveedor: es la diferencia entre una pregunta que se puede responder y una investigación. Y como el coste de la infraestructura es una de las primeras cosas que se vuelve ilegible entre proveedores, la visibilidad de costes y la detección de anomalías deben estar en el mismo lugar que el aprovisionamiento, no en una hoja de cálculo aparte que se concilia una vez al mes. Muchos equipos también gestionan infraestructura que no es de nube en absoluto —servidores on-premise o bare-metal— y esperan que la misma disciplina de monitorización y parcheo se extienda también ahí.