Hay dos formas de dejar que otra empresa opere tu infraestructura. En la primera, le compras cloud a esa empresa: ellos tienen las cuentas de proveedor, ellos reciben la factura, tú recibes una factura con margen y una dirección de soporte. En la segunda - trae tu propio cloud, normalmente abreviado BYOC - conservas tus propias cuentas con Hetzner, AWS u OVHcloud, tu propio contrato, tu propia factura, y le concedes a una plataforma de gestión credenciales delimitadas para operarlas en tu nombre. Los dos modelos parecen similares en una demo y se comportan de forma completamente distinta el día en que quieres salir.
El modelo de reventa no es una estafa; es un negocio legítimo con ventajas reales, sobre todo en torno a una única factura y un único sitio donde reclamar. Lo que renuncias es menos visible. Tu relación contractual es con el reseller, no con el proveedor, así que el SLA que realmente puedes hacer cumplir es el suyo. Los descuentos por compromiso de uso, los créditos de startup y los precios negociados pasan todos por ellos. Y la identidad del recurso, la cuenta en la que realmente viven los servidores, pertenece a otra persona, lo que significa que salir es una migración y no una cancelación.
Qué conservas cuando conservas el contrato
Con BYOC, la relación con el proveedor se queda donde un abogado esperaría que estuviera. Las instancias están en tu cuenta. Los tickets de soporte los abres tú. La factura llega en el formato que tu equipo financiero ya concilia, de una empresa a la que ya le hiciste due diligence, bajo una jurisdicción sobre la que ya razonaste. Si tu postura de cumplimiento depende de quién opera legalmente un servicio - que, después de Schrems II, es la pregunta interesante, más que dónde están físicamente los servidores -, no has añadido un eslabón a esa cadena por adoptar un plano de control.
La prueba de salida hace que la diferencia sea concreta. Si la plataforma de gestión desapareciera de la noche a la mañana, ¿qué pasa? Con reventa, tus servidores están en una cuenta que no controlas y la respuesta implica abogados. Con BYOC, los servidores siguen funcionando exactamente igual; has perdido una consola, un inventario y algo de automatización, lo cual es molesto pero no existencial. Esa asimetría vale más que cualquier lista de características, y es lo primero que hay que comprobar antes de firmar nada.
Lo que BYOC exige a la plataforma
El precio de este modelo es que la plataforma ahora custodia credenciales de producción reales de cuentas que no le pertenecen. Esa obligación hay que tomársela al pie de la letra. Las credenciales se cifran en reposo con AES-256-GCM, están delimitadas a una única organización, nunca se comparten entre tenants, y nunca se devuelven en una respuesta de API - los campos son privados tanto a la salida como cifrados a la entrada. Cada uno de esos puntos es un requisito aburrido que se vuelve interesante la primera vez que a un endpoint de listado normal y corriente se le pide que serialice un registro de credenciales.
Y luego está el modo de fallo que nadie planifica. Un job de provisioning llega sin ninguna credencial adjunta: un bug, una condición de carrera, un mensaje de una versión antigua de un servicio. El comportamiento tentador es recurrir al token de proveedor propio de la plataforma para que el job tenga éxito. Publicamos ese comportamiento una vez y hizo exactamente lo que siempre iba a hacer - creó una máquina real en la propia cuenta de la plataforma, facturada a la parte equivocada, invisible en el inventario del cliente. El comportamiento por defecto ahora es fail-closed. Un job sin credencial se rechaza, y activar el fallback requiere una variable de entorno explícita.
Dónde se complica el BYOC multiproveedor
Un proveedor es una integración; once es un problema de taxonomía. Sencai opera hoy Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode de Akamai y Oracle Cloud, además de servidores on-premise y bare-metal a través de un agente instalado en el host. Cada uno de ellos tiene su propio modelo de autenticación, su propio sistema de cuotas, su propio vocabulario, y su propia opinión sobre si un firewall pertenece a una máquina, a una red o a un proyecto. Normalizar eso sin mentir al respecto es la mayor parte de la ingeniería.
La línea que intentamos mantener es que el plano de control opera el proveedor, no una copia de él. Cuando creas una red, una regla de firewall o una zona DNS en Sencai, la llamada va a la API del proveedor y el objeto existe ahí - visible en su consola, eliminable con su CLI, real para cualquiera que nunca haya oído hablar de nosotros. Una plataforma que solo registra intenciones en su propia base de datos produce un inventario muy convincente de cosas que puede que no existan.
La facturación sigue la misma lógica. Como la factura se queda con el proveedor, el trabajo de la plataforma no es facturarte a ti. Es atribución y control. El gasto se rastrea por organización y proyecto en todas las cuentas conectadas, con límites que tú defines, así que la pregunta "cuánto costó el mes pasado el pipeline por lotes" tiene una sola respuesta en lugar de cuatro exportaciones en cuatro formatos. Esta es también la parte en la que BYOC lo pone genuinamente más difícil que la reventa, porque no hay un único libro contable del que leer; las cifras hay que extraerlas y conciliarlas proveedor por proveedor.
Para quién es trae tu propio cloud
BYOC le sienta bien a los equipos con una infraestructura que ya existe y restricciones que ya son reales: unos cuantos cientos de máquinas acumuladas a lo largo de tres años, un requisito de jurisdicción del equipo de compras de un cliente, una mezcla de proveedores que ocurrió en lugar de diseñarse. Le sienta peor si partes de cero, quieres exactamente una factura, y no tienes ninguna opinión sobre dónde se ejecuta nada. Un reseller o un único hyperscaler será más sencillo, y deberías quedarte con lo más sencillo. Nadie necesita un plano de control multicloud para una cuenta y once servidores.
Dos cosas se vuelven más críticas con BYOC y merecen un diseño deliberado en lugar de buenas intenciones. La primera es el aislamiento: las credenciales pertenecen a una organización, la pertenencia ocurre por invitación, y los roles deciden quién puede gastar dinero o tocar un firewall - porque aquí el radio de impacto es una cuenta de producción real, no un sandbox. La segunda es el rastro de auditoría. Cada acción que la plataforma realiza en tu nombre debería quedar registrada de solo escritura, con el actor, el recurso y un ID de correlación, en un formato que puedas exportar. Estás delegando operaciones, así que el registro de esas operaciones es lo que tienes en lugar de haberlas hecho tú mismo.
Así que estas son las preguntas que merece la pena hacerle a cualquiera que te venda trae tu propio cloud. ¿A nombre de quién está el contrato con el proveedor? ¿Qué puede hacer exactamente la credencial que le has entregado, y puedes reducir su alcance? ¿Qué pasa con la infraestructura en marcha si mañana dejas de pagarles? ¿Puedes exportar el registro de todo lo que hicieron dentro de tus cuentas, y comprobarlo de forma independiente? Unas buenas respuestas a esas cuatro preguntas son lo que separa externalizar tus operaciones de externalizar tu infraestructura - y solo una de las dos es reversible un martes cualquiera.