Plano de control en la nube
Un plano de control en la nube es la capa de interfaces, API y servicios que te permite aprovisionar, configurar y gestionar infraestructura, independiente del plano de datos, que es el que realmente ejecuta tus cargas de trabajo y mueve tu tráfico. Cada proveedor incluye el suyo; el término también abarca los sistemas que gestionan varios proveedores como un único plano.
Toda infraestructura tiene dos capas independientes. El plano de datos es la infraestructura en sí: las máquinas virtuales que ejecutan tu aplicación, la red que mueve paquetes entre ellas, el disco que atiende lecturas y escrituras. El plano de control es todo lo que usas para decidir cómo debe ser esa infraestructura y para modificarla: la API, la consola, la CLI, el sistema de permisos que decide quién puede hacer un cambio. Cuando creas una VM en la consola de un proveedor, redimensionas un disco o abres un puerto en el firewall, estás operando el plano de control. La instancia que arranca, los gigabytes adicionales que quedan disponibles, el tráfico que empieza a fluir: eso es el plano de datos respondiendo a lo que le indicó el plano de control.
La distinción resulta más útil cuando un equipo trabaja con más de un proveedor. AWS tiene un plano de control. También lo tienen Google Cloud, Azure, Hetzner y cualquier otro proveedor, cada uno con su propia consola, su propio formato de API, sus propias credenciales, su propia idea de cómo se llama un 'security group' o una 'firewall rule'. Un equipo que trabaja con tres nubes y veinte servidores bare-metal en realidad está operando tres o cuatro planos de control independientes en paralelo, además de lo que use para gestionar los servidores que no están en ninguna nube. Nada obliga a esos planos de control a coincidir entre sí, y nada fuera de tu propio proceso mantiene visible, para alguien que mira otro, un cambio hecho en uno de ellos.
'Plano de control en la nube' también se usa en un sentido más estricto: dentro de Kubernetes, el plano de control es el API server, el scheduler y el controller-manager que deciden dónde se ejecutan los pods, a diferencia de los kubelets y contenedores que realmente los ejecutan en los nodos. Un plano de control 'multicloud' o 'unificado' extiende la misma idea entre proveedores: un único lugar para ver y actuar sobre infraestructura que reside físicamente en varias cuentas, regiones y proveedores distintos, en lugar de una interfaz por proveedor. No sustituye a los planos de control de cada proveedor subyacente —una solicitud sigue terminando como una llamada a la API de AWS, o de Hetzner, o al fleet agent en un servidor bare-metal—, sino que se sitúa delante de ellos para que quien hace el cambio solo tenga que aprender un sistema.
Por qué esta distinción importa a nivel operativo
La mayoría de los incidentes de infraestructura y de las lagunas de auditoría se remontan a problemas del plano de control, no del plano de datos: un cambio que nadie registró, un permiso que nadie revocó, una regla de firewall abierta en la consola de un proveedor que nadie más del equipo puede ver. Cuando cada nube tiene su propio plano de control y su propio registro de auditoría, "quién cambió esto y cuándo" se convierte en una pregunta que respondes iniciando sesión en tres o cuatro consolas distintas y comparando marcas de tiempo a mano, o que directamente no respondes. Para los equipos sujetos a marcos de cumplimiento como NIS2, esa laguna no es solo un inconveniente: el historial de cambios, el control de acceso y la evidencia de incidentes son precisamente lo primero que pide un auditor o un regulador, y un plano de control fragmentado es la razón por la que esa evidencia a menudo no existe en un único lugar.
Cómo encaja Sencai
Sencai es un plano de control que se sitúa por encima de los nativos: se conecta a cuentas de once proveedores de nube, además de servidores on-premise y bare-metal, mediante un fleet agent ligero, e inventaría lo que ya está en ejecución en el momento en que se conecta una cuenta, sin necesidad de migración. A partir de ahí, aprovisionar, iniciar, detener, redimensionar y eliminar instancias funciona igual sin importar el proveedor. Puedes conectar cuentas existentes (nada se mueve, las credenciales siguen siendo revocables en el proveedor) o dejar que Sencai aprovisione y facture la capacidad directamente, y combinar ambos enfoques en una misma organización. Cada acción en cada proveedor conectado queda registrada en un único log de auditoría de solo adición y encadenado por hash, de modo que "quién cambió esto y cuándo" es una consulta, no una investigación.
Ver inventario y aprovisionamiento →