Crossplane on lo0 — Blog Técnico

Crossplane: el plano de control que convierte tu cluster en una API de nube privada

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

Segundo artículo de la tanda sobre reconstruir la experiencia de nube on-premise. El mapa general te situó los huecos; este entra en el plano de control de aprovisionamiento, esa API que on-premise no viene dada. El tercero sube una capa, al autoservicio centrado en la aplicación con KubeVela y Score.

TL;DR

Crossplane te resuelve el hueco del “abre un ticket y espera”. En la nube pides una base de datos por una API y aparece con permisos, copias y monitorización; on-premise ese aprovisionamiento lo haces a mano o por scripts. Crossplane lleva el modelo de APIs declarativas de Kubernetes a la infraestructura: tu equipo de plataforma define una API propia (una base de datos, un endpoint de inferencia) y el desarrollador la consume con un kubectl apply de pocos campos, mientras controladores dentro del cluster reconcilian el estado deseado contra la realidad y corrigen la deriva de forma continua. Se graduó en la CNCF en noviembre de 2025, con más de tres mil contribuidores y adoptantes como Nike, SAP, IBM o la nube científica de la NASA.

La diferencia con Terraform es de naturaleza, no de features: Terraform aplica un plan bajo demanda y se va; Crossplane es un plano de control que vive dentro del cluster y no deja de reconciliar. Eso te da autocorrección de deriva y GitOps nativo, y a cambio te quita la red de seguridad del plan y te obliga a operar el propio plano de control, con providers que crean cientos de definiciones de recursos y un estado que vive en etcd. Y te aviso de una cosa incómoda de entrada: Crossplane no es una CLI imperativa tipo aws ..., es declarativo primero. Sobre el encaje con inferencia GPU, que hasta hace poco era solo un patrón sin caso público, ya tienes una referencia real, Modelplane, del propio equipo de Crossplane, aunque en versión 0.1 y componiendo vLLM directamente sin pasar por KServe. Te lo detallo al final.

La analogía: el termostato frente al interruptor

Piénsalo así: Terraform es un interruptor de la luz. Lo accionas, la luz se enciende, y ahí se queda hasta que vuelvas a tocarlo. Si alguien más lo cambia, la luz obedece a quien lo tocó por última vez, y tú no te enteras hasta que vas a mirar. Es aprovisionamiento por acción puntual: ejecutas, aplica, termina.

Crossplane es un termostato. No le dices “enciende la calefacción”, le dices “quiero veintiún grados”, y a partir de ahí un mecanismo vigila la temperatura y actúa solo, de forma continua, para mantenerla. Si alguien abre una ventana y baja el termómetro, el termostato reacciona sin que tú intervengas. Eso es la reconciliación continua: declaras el estado deseado una vez y un controlador se encarga de que la realidad no se aparte de él.

La analogía también te avisa del coste. Un termostato es más cómodo que un interruptor, pero es un aparato más que tienes que instalar, alimentar y arreglar cuando falla, y si lo programas mal te ajusta la temperatura a algo que no querías, sin preguntar. Un interruptor no se rompe casi nunca y siempre sabes en qué estado está. Crossplane te da la comodidad del termostato a cambio de que operes el termostato.

Qué es Crossplane y en qué estado llega a 2026

Crossplane nació en Upbound en 2018 y siguió el recorrido de madurez de la CNCF sin atajos: sandbox en 2020, incubación en 2021 y graduación el 6 de noviembre de 2025. La graduación importa porque es el sello que la CNCF reserva para proyectos que considera listos para producción, el mismo nivel de Kubernetes o Prometheus. Las cifras que acompañaron el anuncio son sólidas: más de tres mil contribuidores de más de 450 organizaciones, más de mil autores de pull requests (lo que lo mete en el 10 % superior de los proyectos de la fundación por esa métrica), más de cien releases y dos auditorías de seguridad completadas. Entre los más de setenta adoptantes públicos tienes a Nike, Nokia, Grafana, la nube científica de la NASA, SAP e IBM.

La descripción oficial del proyecto es “el plano de control nativo de la nube”, y esa frase te resume exacto lo que hace. El principal vendor detrás sigue siendo Upbound, que en la graduación enmarcó el futuro del proyecto hacia infraestructura “AI-native”, un dato que te retomo al hablar de inferencia, con la cautela de que es posicionamiento de un vendor, no un caso probado.

La cadencia de releases es trimestral, con una ventana de soporte de nueve meses y tres versiones con mantenimiento activo en cualquier momento. A la fecha de escribir esto, la rama v2 es la vigente, con la v1.20 como último cierre de la rama v1.

El giro de la v2 (que te cambia cómo lo piensas)

Crossplane 2.0 llegó a disponibilidad general en agosto de 2025 y trae cuatro cambios estructurales que te toca conocer, porque buena parte del material antiguo describe un modelo que ya no es el recomendado.

El primero es que los recursos pasan a estar dentro de un namespace por defecto. Tanto los recursos compuestos como los gestionados, que antes eran de ámbito de cluster, ahora viven en un namespace, lo que te habilita control de acceso fino y multi-tenancy natural, justo lo que necesitas en una plataforma soberana con varios equipos.

El segundo es que una composición puede incluir cualquier recurso de Kubernetes, no solo recursos de Crossplane. Antes una composición se limitaba a los recursos gestionados del propio Crossplane; ahora puede incluir Deployments, Services o CRDs de terceros, así que puedes componer abstracciones que mezclan aplicación e infraestructura en un mismo objeto. Este cambio es el que hace viable el patrón de inferencia que verás.

El tercero es que desaparecen los Claims. En el modelo v1 había una dualidad entre el recurso compuesto, de ámbito de cluster, y el Claim, su cara dentro de un namespace que consumía el desarrollador. Al ser ahora el recurso compuesto directamente de namespace, esa dualidad sobra: el desarrollador consume el recurso compuesto sin intermediario. Si te encuentras documentación que habla de Claims, es del modelo anterior.

El cuarto es un tipo nuevo, Operations, para tareas operativas puntuales o programadas que ejecutan un pipeline de funciones hasta completarse, como un Job de Kubernetes pero dentro del modelo de Crossplane.

Hay una eliminación que merece punto y aparte, porque es la que más sorprende: en v2 se retiró el patch-and-transform nativo, el mecanismo clásico de parcheo de las composiciones. No se relegó, se quitó. Todo pasa ahora por composition functions, y a eso llego en un momento. La migración de v1 a v2 es en su mayoría sin rupturas y las APIs v1 siguen funcionando, así que adoptar v2 es opcional, pero el modelo nuevo es el que te toca aprender.

El modelo, pieza por pieza

Crossplane tiene una jerga densa y te la desmonto con calma, porque una vez colocadas las piezas el conjunto es coherente.

Un provider es un paquete que instala controladores y definiciones de recursos para hablar con una API externa, sea AWS, GCP, un cluster de Kubernetes remoto, Helm o Terraform. Se instala de forma declarativa, aplicando un objeto Provider. Los providers de los grandes proveedores cloud se generan con Upjet, un framework que produce el código a partir de los providers de Terraform, lo que te explica por qué existen tantos y también por qué algunos son enormes.

Un managed resource es la representación uno a uno, dentro de Kubernetes, de un recurso del proveedor externo: un bucket, una instancia, una base de datos. Es la unidad que el controlador reconcilia. Cuando creas un managed resource de tipo bucket, el controlador del provider crea el bucket real y luego vigila que siga existiendo y con la configuración que declaraste.

Sobre esos ladrillos construyes la abstracción, que es donde está el valor real, con tres conceptos:

La CompositeResourceDefinition, o XRD, define el esquema de tu API propia: qué campos puede pedir el usuario. Es la que convierte “una base de datos” en un tipo de recurso con sus parámetros.

La Composition es la plantilla y la lógica que, dado uno de esos recursos, materializa los N recursos gestionados que hacen falta por debajo. La documentación lo dice sin rodeos: una composición es un pipeline de composition functions.

El Composite Resource, o XR, es la instancia concreta: el objeto que el desarrollador crea con kubectl apply, con los pocos campos que la XRD expone.

El patrón completo es este: tu operador de plataforma publica la abstracción (la XRD más la Composition, que dicen “esto es lo que significa una base de datos aquí”), y el desarrollador solo aplica un recurso compuesto con cuatro campos. Deja de importarle cómo se construye por debajo, igual que en la nube no te importa cómo AWS te monta la base de datos gestionada.

Composition functions: la lógica real

El mecanismo de composición en v2, y el único, son las composition functions. Una composición es un pipeline de funciones que Crossplane invoca por gRPC; cada función recibe el estado observado, el deseado, su input y un contexto compartido, y encadena su salida a la siguiente. El YAML de los ejemplos es ilustrativo, pero por debajo no se procesa como YAML: se ejecuta como funciones.

Las funciones disponibles cubren varios estilos. Tienes function-patch-and-transform, que reimplementa el viejo modelo ahora como una función más. Están function-go-templating para plantillas al estilo Helm, function-kcl para el lenguaje KCL, function-python para lógica en Python y function-cue para CUE.

El porqué del cambio es lo que te interesa entender. El patch-and-transform clásico no tenía bucles ni condicionales, así que una operación tan simple como transformar un array de strings se te convertía en decenas de líneas de parcheo, y la comunidad lo llegó a calificar de directamente malo. Las funciones te dejan lógica de programación completa (bucles, condicionales, llamadas externas) en un lenguaje real. La contrapartida honesta es que la complejidad no desaparece: se te desplaza de “escribir parches verbosos” a “escribir y operar funciones”, que es otro tipo de trabajo, no menos trabajo.

Crossplane frente a Terraform, OpenTofu y Pulumi

Esta es la comparación que hace todo el mundo, y te la hago bien porque la diferencia es de categoría. Según la propia documentación de Pulumi, que compara con honestidad, Crossplane es un plano de control declarativo con reconciliación continua dentro de Kubernetes, mientras que Terraform y Pulumi son infraestructura como código de ejecución puntual, del lado del cliente y bajo demanda.

Las consecuencias prácticas se ordenan en pocos ejes. Ante la deriva de configuración, Crossplane la corrige de forma continua y automática, mientras Terraform y Pulumi la detectan solo cuando ejecutas un refresco. Crossplane necesita un cluster donde correr, porque son controladores; Terraform y Pulumi no. Crossplane es GitOps nativo, se aplica con kubectl y encaja con Flux sin adaptador; Pulumi necesita su operador de Kubernetes para lo mismo. Y en cuanto al lenguaje, Crossplane usa YAML y CRDs con lógica en las funciones, mientras Pulumi usa lenguajes de programación generales.

El punto que más se olvida es que no tienes que elegir uno u otro. Existe un provider de Terraform (y otro de OpenTofu, recomendado para versiones nuevas porque el de Terraform quedó congelado en la última versión con licencia libre) que ejecuta HCL dentro de Crossplane, envolviendo tus módulos existentes como un recurso gestionado. Puedes reutilizar toda tu inversión en Terraform y aun así ganar la reconciliación continua para lo que la necesite. Si ya tienes Terraform en producción, este patrón híbrido suele ser tu ruta sensata, no la reescritura.

Sobre la adopción comparada te toca ser sobrio: no hay una cifra oficial y fiable de “Crossplane frente a Terraform”, y la crítica documentada más repetida es que a Crossplane le falta el ecosistema maduro de módulos que Terraform lleva años acumulando. Es una diferencia cualitativa real, no un detalle.

La pregunta incómoda: ¿es una CLI tipo AWS?

Como en este blog vengo tirando del hilo del aprovisionamiento por CLI, te respondo directo: no. Crossplane no te ofrece una experiencia imperativa tipo aws s3 create-bucket. Es declarativo primero. Aprovisionas con kubectl apply de un recurso, y el binario crossplane te sirve para construir, empaquetar, probar y depurar, no para “crear un bucket” de un tirón.

Los subcomandos te lo dejan claro. crossplane render renderiza una composición y sus funciones en local, para que pruebes sin cluster. La familia crossplane xpkg build, push, install te gestiona los paquetes OCI de providers, configuraciones y funciones. Y crossplane beta validate, trace y top validan esquemas, dibujan el árbol de recursos y muestran el consumo dentro del cluster. Es la caja de herramientas del que construye la plataforma, no la del que la consume a diario. La CLI up de Upbound añade más, pero orientada a su producto comercial.

La conclusión te importa para fijar expectativas: la experiencia imperativa tipo consola de AWS, si la quieres, la construyes encima de Crossplane, con Backstage, un portal o un wrapper propio. Crossplane te pone la API declarativa; la cara amable la pones aparte. Si lo que buscas es una CLI imperativa de aprovisionamiento, encajas mejor con el modelo de KubeVela y Score, que es justo el tema del siguiente artículo.

Providers on-premise: aprovisionar sin tocar AWS

Para una plataforma soberana tu pregunta es qué puedes aprovisionar sin pisar una nube pública, y la respuesta es más de lo que parece, con madurez desigual.

El más versátil es provider-kubernetes, que gestiona cualquier objeto de Kubernetes en clusters remotos a través de un recurso Object. Es la base del patrón multi-cluster on-premise: desde un cluster central materializas recursos en tus RKE2 secundarios. Junto a él, provider-helm instala y gestiona charts de Helm de forma declarativa mediante un recurso Release, con lo que despliegas cosas como vLLM o KServe como parte de una composición.

Para la parte de identidad y almacenamiento tienes piezas concretas: provider-keycloak configura realms, clientes y roles de Keycloak de forma declarativa, útil para el IAM soberano que ya montamos en el artículo de autenticación con Keycloak; y provider-minio gestiona buckets y políticas del almacenamiento S3-compatible on-premise. Para vSphere no tienes un provider nativo de primera clase, pero lo cubres generándolo desde el provider de Terraform, el patrón habitual para infraestructura VMware.

Un aviso honesto: para KubeVirt, Harvester o CloudNativePG no hay providers nativos maduros y de primera clase; en la práctica los gestionas aplicando sus CRDs a través de provider-kubernetes o envolviendo su Terraform. Funciona, pero no es la experiencia pulida de un provider dedicado. Con la combinación de provider-kubernetes, provider-helm, provider-minio y provider-keycloak, más provider-terraform para lo que falte, montas un catálogo de autoservicio cien por cien on-premise, con la advertencia de que la madurez te varía pieza a pieza.

El encaje con inferencia GPU: de patrón a Modelplane

Esta es la sección que en la primera versión de este texto iba con la máxima cautela, porque no había un caso público de Crossplane orquestando GPU e inferencia y todo quedaba en patrón de diseño. A mitad de 2026 eso cambió, y el caso lo publicó el propio equipo que hace Crossplane.

Modelplane es un plano de control open source para inferencia de IA, con licencia Apache y una primera versión 0.1 de junio de 2026, y lo interesante es cómo está hecho: enteramente sobre composiciones de Crossplane y composition functions en Python, sin controladores propios. Compone vLLM directamente, con la imagen vllm/vllm-openai, sin pasar por KServe, y su API de autoservicio para los equipos de ML es un recurso ModelDeployment donde declaras el modelo, el motor, la topología y el hardware. Por debajo, un recurso ModelReplica representa cada réplica, y el equipo de plataforma declara sus pools de GPU con recursos InferenceCluster e InferenceClass, usando un modelo de atributos y expresiones CEL tomado de la asignación dinámica de recursos de Kubernetes. Su pieza más avanzada es un planificador de flota de dos niveles escrito como función pura, que coloca réplicas por toda la infraestructura y delega en el planificador de cada cluster. Es la prueba de que el patrón funciona, con el aviso de que es una versión 0.1 en desarrollo abierto, no algo para meter en producción a ciegas, y de que adoptarlo te ata la plataforma a sus tipos de recurso.

El otro habilitador reciente está en KServe, que estrenó un tipo dedicado a modelos grandes, LLMInferenceService, todavía en alfa y construido sobre el proyecto llm-d, con separación de prefill y decode y ejecución multi-nodo, y que corre vLLM como runtime. Es distinto del InferenceService clásico, reservado para el ML predictivo. Ese tipo nuevo es tu ladrillo ideal si prefieres componer KServe en vez de vLLM a pelo.

Con eso, el camino dorado propio deja de ser hipótesis. Defines una XRD, por ejemplo InferenceEndpoint, con campos como el modelo, el número y tipo de GPU y las réplicas. Su composición, aprovechando que en v2 puede incluir cualquier recurso de Kubernetes, materializa en un solo pipeline el namespace del equipo, la cuota para nvidia.com/gpu y un LLMInferenceService de KServe apuntando al modelo con runtime vLLM, y el desarrollador solo aplica el InferenceEndpoint con cuatro campos, sin conocer KServe ni las cuotas por debajo. KServe soporta vLLM y GPU de forma nativa, como vimos en el artículo sobre KServe.

La lectura honesta es que estás en la frontera, no en terreno trillado. Fuera de Modelplane, hecho por Upbound, todavía no hay un cuerpo de casos independientes montando Crossplane con vLLM, y el tipo de KServe está en alfa. Es una arquitectura coherente, con una referencia real que la respalda y un margen amplio para que seas de los primeros en documentarla sobre hierro propio.

Lo que te cuesta operar tu propio plano de control

Ninguna herramienta que te devuelve control es gratis, y Crossplane tiene costes bien documentados que te toca presupuestar antes, no descubrir después.

La curva de aprendizaje es empinada, reconocido incluso en la cobertura de su graduación. Los adoptantes reportan dificultades de depuración cuando una composición o un provider se comportan mal, y echan en falta el ecosistema de módulos de Terraform.

Las composiciones tienden a la complejidad. Hay practicantes que describen definiciones que abarcan miles de líneas con mala navegación, y la ausencia de un framework de testing integrado. Las funciones mejoran esto, pero como te dije, te desplazan la complejidad más que eliminarla.

No hay plan. A diferencia del ciclo plan y apply de Terraform, Crossplane aplica los cambios de inmediato. Pierdes la red de seguridad de revisar qué va a pasar antes de que pase, con el riesgo de modificaciones que no querías.

Operar el propio plano de control cuesta. Los providers grandes crean cientos de definiciones de recursos (el de GCP llegó a 347), con riesgo de indisponibilidad del servidor de API y de dejarte el cluster colgado. El estado vive en etcd, lo que te complica la recuperación ante desastres y la migración del control entre clusters. Y hay un peligro concreto: un borrado accidental de recursos cloud al actualizar XRDs, providers o composiciones, por la propiedad que Crossplane mantiene sobre lo que creó.

Hay quien decidió no adoptarlo. El equipo de Masterpoint lo descartó por la falta de fuentes de datos y de ignore_changes, por una cobertura incompleta de servicios de AWS, y por el coste de abandonar su experiencia acumulada en Terraform. Es una decisión legítima, y citártela es parte de un artículo honesto.

Cómo convive con lo que ya tienes

Si ya operas una plataforma, tu pregunta no es Crossplane sí o no, sino Crossplane con qué. Tres relaciones te importan.

Con Backstage son complementarios, no rivales. Backstage es el portal y las plantillas que generan manifiestos o pull requests, el día cero; Crossplane aprovisiona y reconcilia el estado real, el día dos. El patrón habitual, que algunos llaman el triángulo dorado, es Backstage como interfaz, Crossplane como plano de control y Argo CD o Flux como GitOps. Cada uno hace una capa.

Con Flux, que probablemente ya usas, la relación es de suma. Flux reconcilia manifiestos hacia los clusters, pero no te da una API de abstracción de plataforma: no sabe qué es “una base de datos”, solo aplica el YAML que le das. Crossplane te añade justo esa capa de abstracción, y ambos coexisten, con Flux desplegando los recursos compuestos y Crossplane materializándolos. Si ya tienes Flux, el valor de Crossplane es precisamente esa capa de API de autoservicio, a cambio del coste de operar el plano de control que te describí arriba.

Con KubeVela y Score, el tema del siguiente artículo, la frontera es de capa: Crossplane responde “dame una Postgres”, desde la infraestructura; KubeVela y Score responden “despliega mi aplicación”, desde el workload. No compiten, se apilan.

Para tu factoría de inferencia soberana

La decisión práctica se te reduce a esto. Crossplane tiene sentido cuando quieres exponer una API de autoservicio propia sobre tu infraestructura on-premise y estás dispuesto a operar un plano de control para conseguirlo. Si tu plataforma la usan dos equipos que se conocen y aprovisionas con un repositorio de Flux ordenado, Crossplane es coste sin retorno todavía. El disparador es la escala: cuando el aprovisionamiento manual se te convierte en un cuello de botella de tickets, la API declarativa empieza a pagarte su coste.

Tu ruta de entrada sensata no es reescribir todo. Es empezar por un provider que ya te sirva (provider-kubernetes y provider-helm cubren mucho), envolver tu Terraform existente con el provider correspondiente en vez de tirarlo, y modelar una sola abstracción de valor claro, probablemente el InferenceEndpoint que comentamos, como camino dorado. A partir de ahí, creces por demanda. Y siempre con la cuenta clara de que has cambiado la red de seguridad del plan y un puñado de scripts por un termostato que tienes que mantener encendido.

El siguiente artículo sube la capa, del recurso de infraestructura al workload de la aplicación, con KubeVela y Score, que es donde por fin aparece la CLI amable que Crossplane deliberadamente no te da.

Ver también

De la nube pública a la privada: el mapa — dónde encaja este plano de control en el conjunto.
KubeVela y Score: autoservicio por CLI — la capa de aplicación, la CLI que Crossplane no ofrece.
Backstage como portal de autoservicio — la interfaz que se monta encima del plano de control.
GitOps del stack de inferencia con Flux — el motor con el que Crossplane convive, no compite.
KServe y el protocolo abierto de inferencia — lo que el camino dorado de inferencia materializaría por debajo.

Fuentes

CNCF, Announces Graduation of Crossplane (6-nov-2025) — https://www.cncf.io/announcements/2025/11/06/cloud-native-computing-foundation-announces-graduation-of-crossplane/
Crossplane Blog, Announcing Crossplane’s CNCF Graduation — https://blog.crossplane.io/crossplane-cncf-graduation/
Crossplane Blog, Announcing Crossplane 2.0 — https://blog.crossplane.io/announcing-crossplane-2-0/
Crossplane Docs, What’s New in v2 — https://docs.crossplane.io/latest/whats-new/
Crossplane Docs, Compositions — https://docs.crossplane.io/latest/composition/compositions/
Crossplane Docs, Release Cycle — https://docs.crossplane.io/latest/learn/release-cycle/
Crossplane Docs, Crossplane CLI — https://docs.crossplane.io/latest/cli/
Upbound, Crossplane Graduates From CNCF, Upbound Redefines AI-Native Infrastructure — https://www.upbound.io/blog/crossplane-graduates-from-cncf-upbound-redefines-ai-native-infrastructure
InfoQ, Crossplane Reaches Production Maturity by Graduating CNCF — https://www.infoq.com/news/2025/11/crossplane-grad/
Pulumi Docs, Pulumi vs. Crossplane — https://www.pulumi.com/docs/iac/comparisons/crossplane/
Upbound Marketplace, provider-terraform — https://marketplace.upbound.io/providers/upbound/provider-terraform/latest
GitHub, provider-kubernetes — https://github.com/crossplane-contrib/provider-kubernetes
GitHub, provider-helm — https://github.com/crossplane-contrib/provider-helm
GitHub, provider-keycloak — https://github.com/crossplane-contrib/provider-keycloak
VSHN, provider-minio — https://github.com/vshn/provider-minio
Masterpoint, Crossplane: Why it Didn’t Work for Us — https://masterpoint.io/blog/passing-on-crossplane/
CECG, Crossplane: the good, the bad and the ugly — https://www.cecg.io/blog/crossplane-the-good-the-bad-the-ugly
Taloflow, Backstage vs Crossplane for Platform Engineering — https://www.taloflow.ai/guides/comparisons/backstage-vs-crossplane-platform-engineering
Crossplane Blog, Building Modelplane on Crossplane — https://blog.crossplane.io/building-modelplane/
Modelplane — https://modelplane.ai · https://github.com/modelplaneai/modelplane
KServe Docs, Understanding LLMInferenceService — https://kserve.github.io/website/docs/model-serving/generative-inference/llmisvc/llmisvc-overview

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/