De la nube pública a la privada: qué se pierde de verdad y qué proyectos tapan el hueco

Mon, 31 Aug 2026 09:15:00 +0200

Con este abro una tanda sobre el hueco más grande que te deja una plataforma soberana: cómo darles a tus equipos la experiencia de autoservicio de una nube pública, sin la nube pública. Aquí tienes el mapa del problema; los dos siguientes bajan al detalle de las herramientas, Crossplane como plano de control de infraestructura y KubeVela con Score como autoservicio centrado en la aplicación.

TL;DR

Salir de la nube pública tiene un caso de negocio sólido, y no me lo invento. 37signals declaró un ahorro cercano a los dos millones de dólares en 2024 tras repatriar, el análisis clásico de a16z cifra el gasto en nube en torno a la mitad del coste de ingresos de una empresa de software, y la encuesta de CIOs de Barclays de 2024 registró la intención de repatriación más alta de su historia. Si tu carga es base predecible y sostenida (que es justo la inferencia LLM continua de la que va este blog) los números te salen, y en Europa se suman los motivos de soberanía: el Data Act, la tensión con el CLOUD Act estadounidense, y esa dependencia de tres hiperescalares que controlan alrededor del 70 % del mercado cloud europeo.

Pero el problema no es el cómputo. Tu rack de GPU on-premise sirve tokens igual de bien que uno alquilado. Lo que la nube te vendía y ahora tienes que reconstruir es otra cosa: la elasticidad de pedir cien máquinas a las diez y devolverlas a las once, el catálogo de cientos de servicios gestionados con una guardia detrás, la API unificada de aprovisionamiento con permisos finos, la red multi-región, la factura que llega desglosada, y ese modelo en el que operar todo eso era problema de otro. Todo eso lo reconstruyes pieza a pieza con proyectos open source, y la reconstrucción tiene un coste que las cifras de ahorro no suelen contarte. Lo que viene es el mapa de qué pierdes, qué proyecto tapa cada hueco, y dónde queda un hueco que no vas a cerrar del todo con nada.

La analogía: dejar el hotel para montar casa propia

Piénsalo así: vivir en la nube pública es vivir en un hotel. Pagas caro la noche, pero no cambias bombillas, la recepción está abierta a las tres de la mañana, si necesitas otra habitación la pides y aparece, y cuando te vas no te llevas nada que mantener. Montar tu propia casa te sale mucho más barato por metro cuadrado si vas a quedarte años, y encima decides tú quién entra y dónde se guardan tus cosas. El problema llega el día que se rompe una tubería: ahí no llamas a recepción, porque la recepción eres tú.

La repatriación es esa mudanza. El ahorro es real y la propiedad del dato también, pero lo que en el hotel venía incluido en el precio de la noche ahora es tu lista de tareas: la fontanería es tu red, la caldera es tu almacenamiento, el conserje que te conseguía cualquier cosa es el catálogo de servicios gestionados que ya no tienes, y la factura detallada que te deslizaban bajo la puerta es un modelo de costes que te toca construir, porque la electricidad y la amortización no llegan desglosadas por inquilino. La casa te compensa, pero solo si cuentas lo que cuesta amueblarla y arreglar las tuberías, no únicamente el precio por metro frente al hotel.

El resto del artículo recorre esa lista de tareas y te dice, para cada una, qué herramienta open source hace el trabajo que antes te hacía el hotel.

Por qué esta conversación es de 2026, no de siempre

Repatriar no es nada nuevo, pero en 2026 se te juntan tres cosas que lo vuelven urgente si llevas una plataforma de IA europea.

La primera es económica, y la puso sobre la mesa Andreessen Horowitz en 2021 con The Cost of Cloud, a Trillion Dollar Paradox. Su tesis, que te toca leer sabiendo que a16z tiene intereses en el ecosistema que analiza, es que el gasto en nube promedia alrededor del 50 % del coste de ingresos en una empresa de software, y que recuperar la mitad de ese gasto liberaría márgenes que el mercado penaliza. El caso más limpio y que puedes verificar es el de 37signals: DHH publicó que su factura de nube bajó de 3,2 a 1,3 millones de dólares anuales tras repatriar, con una inversión inicial de unos 700.000 dólares en servidores Dell. Ahora el matiz honesto, que la propia prensa especializada subraya: esas cifras de ahorro no incluían el personal extra de operación, ni la energía, ni la refrigeración. Lo retomo en la sección de costes ocultos.

La segunda es de intención declarada. La encuesta de CIOs de Barclays de la primera mitad de 2024 registró que el 83 % planeaba repatriar alguna carga a nube privada u on-premise en los doce meses siguientes, la lectura más alta de la serie. Pero lee ese 83 % con precisión: es la proporción de responsables que piensan mover alguna carga, no el porcentaje de cargas ni de gasto que se mueve. Flexera, en su informe de 2025, te da la cifra más aterrizada: las empresas grandes han repatriado en torno al 21 % de las cargas que tenían en nube pública, y el ahorro de coste es la prioridad número uno para casi el 60 %.

La tercera es regulatoria y europea, y es la que convierte la repatriación en algo más que una decisión de FinOps. El Data Act de la Unión Europea entró en vigor en enero de 2024 y es aplicable desde septiembre de 2025; obliga a la portabilidad entre proveedores y, desde enero de 2027, prohíbe las tarifas de salida que hoy te encadenan a tu proveedor. Y por debajo late una tensión legal de fondo: el CLOUD Act estadounidense permite a las autoridades de Estados Unidos reclamar datos a un proveedor americano aunque los guarde en Frankfurt, que es justo el argumento de por qué una región europea de un hiperescalar no te da soberanía. Con AWS, Microsoft y Google controlando alrededor del 70 % del mercado cloud europeo, la conversación sobre nube soberana dejó de ser teórica. Esto lo desarrollé ya en on-premise soberano frente a hiperescalares.

Qué pierdes al salir de la nube, en concreto

Vamos al núcleo, ordenado por lo que más te va a doler. Y una cosa antes de empezar: ninguno de estos huecos es de cómputo. Todos son de lo que la nube ponía alrededor del cómputo.

La elasticidad de hardware desaparece. On-premise, la GPU que no compraste no existe. La nube te factura por hora precisamente porque asume el riesgo de la capacidad ociosa: te deja pedir un pico y devolverlo. Con hierro propio, el pico lo compras por adelantado y lo pagas esté o no en uso, así que tu rentabilidad depende de una utilización sostenida alta. Por debajo de cierto umbral de uso, la nube vuelve a ganarte. Es el hueco irreducible, el que no tapa ninguna herramienta, y si repatrías carga con picos extremos te estás equivocando de decisión.

Los servicios gestionados pasan a ser tu operación. Cada caja que dabas por hecha (la base de datos, la cola, el almacenamiento de objetos, el balanceador, el DNS, el gestor de secretos) deja de ser una casilla que marcas y pasa a ser un sistema que instalas, actualizas y vigilas tú. El caso 37signals lo enseña bien: salir del almacenamiento de objetos S3 fue lo último y lo más difícil, con petabytes de datos y un contrato que arrastraron durante años. Tu Postgres gestionado se convierte en operar CloudNativePG; tu S3 se convierte en operar MinIO; y así con cada servicio.

El plano de control de aprovisionamiento te toca construirlo. AWS te da una API unificada donde pides un recurso con permisos finos y aparece. On-premise eso no viene dado: tienes que montar el plano de control que traduce “quiero una base de datos” en recursos reales. Es exactamente el hueco de Crossplane, y por eso tiene su propio artículo.

La red gestionada la sustituyes pieza a pieza. La VPC, los grupos de seguridad, el NAT, el balanceador de carga: cada abstracción de red de la nube tiene su equivalente on-premise (Cilium para las políticas de red sobre eBPF, MetalLB para el balanceador sin ELB, Gateway API para la entrada L7), pero son piezas que ensamblas, no un servicio que enciendes. Buena parte de esto ya lo vimos en la vertical de red con Cilium y eBPF.

La facturación deja de existir como tal. En la nube el coste te llega desglosado por servicio y por etiqueta; tienes un Cost Explorer que responde “cuánto me cuesta este equipo”. On-premise no hay factura natural: hay una amortización de hardware, un recibo de la luz y unas nóminas, y repartir eso por carga es un modelo que te toca construir. OpenCost te ayuda con el reparto por carga dentro del cluster, pero el coste físico total (amortización más energía más personal) lo modelas aparte, como vimos en OpenCost y la imputación de coste.

La disponibilidad multi-zona la diseñas tú. Las tres zonas de disponibilidad que la nube te regala se convierten en varios sites, varios racks y varias acometidas eléctricas que tienes que planificar. 37signals lo resolvió con dos centros de datos y replicación entre ellos. Ni es gratis ni es automático.

Y por encima de todo, la guardia es tuya. La nube no te vendía solo cómputo: te vendía operación incluida. Cuando algo se cae a las tres de la mañana, en la nube hay un equipo de guardia del proveedor; con open source, ese equipo eres tú. Este es el coste que las hojas de cálculo de ahorro casi nunca meten, y es el que decide si tu repatriación fue una buena idea o una factura escondida.

El mapa de proyectos que tapan cada hueco

Con los huecos ordenados, el catálogo de sustitutos se lee solo. Te lo agrupo por capa, de lo más bajo a lo más cercano al desarrollador.

En el sustrato de infraestructura, lo que te replica las máquinas virtuales, la red virtual y los discos de EC2, tienes OpenStack como estándar clásico de nube privada completa, Harvester de SUSE como hiperconvergencia bare-metal sobre KubeVirt gestionada desde Kubernetes, y proyectos emergentes como Spinifex que reconstruyen una API compatible con AWS sobre hierro propio. Es la capa más pesada y la que menos toco en este blog, porque doy por hecho que tu cluster ya existe.

En el plano de control de aprovisionamiento, lo que replica la API de IAM y de recursos de AWS, está Crossplane, graduado en la CNCF en noviembre de 2025, que lleva el modelo de APIs declarativas de Kubernetes a la infraestructura. Junto a él, Cluster API para el aprovisionamiento declarativo de clusters. Y para que veas hasta dónde llega esto en nuestro terreno, el propio equipo de Crossplane publicó a mediados de 2026 Modelplane, un plano de control de inferencia construido sobre composiciones que sirve modelos con vLLM. Esta capa la desarrolla el artículo de Crossplane.

En la experiencia de autoservicio del desarrollador, lo que replica la consola y la CLI de AWS, tienes tres enfoques distintos que no debes confundir. Backstage es el portal web, el catálogo y las plantillas, y ya tiene su propio artículo. KubeVela lleva el autoservicio al modelo de la aplicación con una CLI amigable. Score define una especificación de workload portable entre entornos. KubeVela y Score comparten el tercer artículo porque cubren la misma capa desde ángulos que se complementan.

En los servicios gestionados on-premise, CloudNativePG te opera Postgres con alta disponibilidad y copias a almacenamiento de objetos, MinIO te da el almacenamiento S3-compatible, y OpenCost cubre esa imputación de coste que perdiste con Cost Explorer.

La forma de leer este mapa es que ninguna de estas piezas te sobra si quieres la experiencia de nube: son las casillas que la nube marcaba por ti y que ahora marcas una a una.

El hueco que no vas a cerrar

Te lo digo sin adornos, porque es la parte que los folletos de “sal de la nube” se saltan. Ninguna combinación de proyectos open source te reproduce el 100 % de la nube pública, y no por falta de madurez, sino por diseño.

Lo que no vas a replicar es, primero, la elasticidad instantánea de hardware: sigues comprando los picos por adelantado. Segundo, la profundidad y amplitud del catálogo de servicios gestionados, cientos de servicios con un acuerdo de nivel de servicio y una guardia detrás, que ningún equipo interno iguala. Tercero, la red global multi-región que la nube te da casi gratis. Y cuarto, ese modelo de responsabilidad operativa transferida: con open source, la operación te vuelve a casa.

La lectura correcta no es que repatriar sea mala idea, sino que cambias un gasto operativo predecible y una responsabilidad delegada por una inversión de capital más barata y una responsabilidad propia. Para carga base sostenida te sale a cuenta. Para todo lo demás, piénsatelo.

Cuándo NO repatriar

Esta sección tiene que estar, porque repatriar mal aplicado te sale caro. Hay tres señales claras de que la nube sigue siendo tu respuesta correcta.

La primera es carga con picos extremos o tráfico muy variable. La mayoría de despliegues de inferencia operan entre el 40 y el 65 % de utilización de GPU, y por debajo de aproximadamente el 70 % de uso sostenido la nube te gana en coste total. Si tu carga tiene valles largos, estás comprando hierro para que duerma.

La segunda es incertidumbre o arranque de proyecto. El punto de equilibrio a favor de comprar solo te aplica cuando la utilización es consistentemente alta y, sobre todo, medida y no proyectada. Comprar GPU contra una previsión optimista es la forma más rápida de acabar con un almacén de silicio ocioso. Dimensionar bien da para un artículo entero: dimensionar y justificar la inversión en GPU.

La tercera es la falta de equipo de operación. El coste total de propiedad on-premise incluye entre medio y un ingeniero a tiempo completo por servidor de GPU. Sin ese equipo, tu ahorro es ilusorio, porque la guardia que la nube incluía ahora no la cubre nadie. El propio a16z plantea su tesis como un enfoque híbrido, no como “salir de la nube” en absoluto.

Los números, para aterrizarlo

Para no dejarte la discusión en abstracto, aquí van los órdenes de magnitud, triangulando dos fuentes con sesgos opuestos, un proveedor de nube y una herramienta neutral de FinOps. Un H100 en la nube te ronda entre 2,90 y casi 7 dólares por GPU-hora según proveedor; comprado, una tarjeta H100 está en torno a 31.000 dólares y un sistema de ocho entre 250.000 y 320.000. A plena utilización, un H100 alquilado supera su precio de compra en menos de un año, y un sistema de ocho con hardware de segunda mano puede amortizarse en torno a siete meses. El coste total a tres años de un sistema de ocho H100, contando personal, colocation, energía y refrigeración, se estima entre 700.000 y 950.000 dólares, y el umbral donde on-premise te gana frente a los hiperescalares está alrededor del 80 % de utilización sostenida.

Las dos fuentes discrepan en el número exacto, como era de esperar, pero coinciden en el factor que decide: la utilización sostenida, medida y no proyectada. El desarrollo completo de este cálculo lo tienes en el TCO del cluster GPU on-premise. Aquí te vale la conclusión: para carga base continua los números salen, y ese es justo el perfil de una factoría de inferencia.

Para tu factoría de inferencia soberana

Todo lo anterior se te ordena en una decisión práctica. Si operas una plataforma de inferencia LLM sobre hierro propio, no estás decidiendo si repatriar (esa decisión ya la tomaste al montar el cluster), sino cómo reconstruir la experiencia de nube que tus equipos echan de menos.

La secuencia sensata empieza por el sustrato, que probablemente ya tienes en forma de RKE2 y almacenamiento. Sigue por el plano de control de aprovisionamiento, donde Crossplane te convierte el “abre un ticket y espera” en una API declarativa. Continúa por la experiencia del desarrollador, donde eliges entre el portal de Backstage, el modelo de aplicación de KubeVela o la especificación portable de Score, según si tu gente prefiere una web o una CLI. Y no te olvides de los servicios gestionados on-premise ni de la imputación de coste, porque sin factura tu plataforma pierde la disciplina que la nube imponía por defecto.

Los dos artículos siguientes bajan a las dos capas que menos cubiertas están en este blog: Crossplane para el plano de control de infraestructura, y KubeVela con Score para el autoservicio por CLI centrado en la aplicación. Con ellos, el mapa de esta capa te queda cubierto, y tu casa propia empieza a parecerse al hotel que dejaste, con la diferencia de que el dato se queda dentro.

Ver también

On-premise soberano frente a hiperescalares, con datos — el caso de negocio y de soberanía, en detalle.
El TCO de un cluster GPU on-premise — el cálculo completo del punto de equilibrio.
Backstage como portal de autoservicio — la capa de portal, la tercera vía de autoservicio.
Los cinco niveles de madurez de la plataforma — en qué momento cada una de estas piezas empieza a compensarte.
El mapa del blog por capas — dónde encaja todo esto en el stack completo.

Fuentes

Andreessen Horowitz (S. Wang, M. Casado), The Cost of Cloud, a Trillion Dollar Paradox — https://a16z.com/the-cost-of-cloud-a-trillion-dollar-paradox/
Data Center Dynamics, 37signals claims it saved almost 2M USD last year from cloud repatriation — https://www.datacenterdynamics.com/en/news/37signals-claims-it-saved-almost-2m-last-year-from-cloud-repatriation/
The Register, Developer pockets 2M USD in savings from going cloud-free — https://www.theregister.com/2024/10/21/37signals_aws_savings/
Barclays, Technology: 1H24 CIO Survey (PDF) — https://8198920.fs1.hubspotusercontent-na1.net/hubfs/8198920/Barclays_Cio_Survey_2024-1.pdf
Channelnomics, Breaking Down the 83% Public Cloud Repatriation Number — https://channelnomics.com/breaking-down-the-83-public-cloud-repatriation-number/
The New Stack, Updated Stats on Cloud Sustainability, Repatriation and Cost Optimization (Flexera 2025) — https://thenewstack.io/updated-stats-on-cloud-sustainability-repatriation-and-cost-optimization/
Comisión Europea, Data Act | Shaping Europe’s digital future — https://digital-strategy.ec.europa.eu/en/policies/data-act
EU Data Act, Article 29 — Gradual withdrawal of switching charges — https://www.eu-data-act.com/Data_Act_Article_29.html
Kiteworks, How the EU Data Act and GDPR Conflict with U.S. CLOUD Act — https://www.kiteworks.com/gdpr-compliance/eu-data-act-gdpr-cloud-conflict/
Computerworld, EU takes first steps to reduce reliance on US hyperscalers — https://www.computerworld.com/article/4181816/eu-takes-first-steps-to-reduce-reliance-on-us-hyperscalers.html
CNCF, Announces Graduation of Crossplane (6-nov-2025) — https://www.cncf.io/announcements/2025/11/06/cloud-native-computing-foundation-announces-graduation-of-crossplane/
CNCF, Score accepted as a CNCF Sandbox Project — https://www.cncf.io/blog/2024/08/08/score-accepted-as-a-cncf-sandbox-project/
Harvester HCI (SUSE) — https://harvesterhci.io/
CloudNativePG — https://cloudnative-pg.io/
Crossplane Blog, Building Modelplane on Crossplane — https://blog.crossplane.io/building-modelplane/ · https://modelplane.ai
Spheron, LLM Inference On-Premise vs GPU Cloud: 2026 Cost and Break-Even Analysis — https://www.spheron.network/blog/llm-inference-on-premise-vs-cloud/
CloudZero, H100 GPU Cost in 2026: Buy, Rent, and Cloud Pricing Compared — https://www.cloudzero.com/blog/h100-gpu-cost/

Nube-Privada on lo0 — Blog Técnico