Score on lo0 — Blog Técnico

KubeVela y Score: dar la plataforma por CLI sin enseñar Kubernetes al desarrollador

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

Tercer y último artículo de la tanda sobre reconstruir la nube on-premise. El mapa general te situó los huecos y Crossplane cubrió el plano de control de infraestructura. Aquí va la capa de encima, la que tu desarrollador toca todos los días: el autoservicio por CLI centrado en la aplicación.

TL;DR

Crossplane responde “dame una base de datos”, desde la infraestructura. KubeVela y Score responden “despliega mi aplicación”, desde el workload, y lo hacen por CLI, que es justo la experiencia amable que Crossplane deliberadamente no te da. Los dos comparten artículo porque cubren la misma capa desde ángulos distintos. KubeVela es una plataforma completa de entrega: usa el modelo OAM, donde tu equipo de plataforma escribe una vez unas definiciones en el lenguaje CUE y el desarrollador despliega toda su aplicación con un fichero de quince líneas y una CLI (vela up, vela status, vela logs) que se siente como Heroku por fuera y es GitOps por dentro. Score es más modesto y más portable: una especificación de workload en un solo fichero que se traduce por CLI a Docker Compose en local y a Kubernetes en producción, sin correr nada en el cluster.

Lo honesto de entrada son los límites. Ninguno de los dos aparece en la sección “Adopt” del radar tecnológico de la CNCF de principios de 2026, donde sí están Helm, Backstage y Argo CD: son nicho frente al mainstream. La versión 1.11 de KubeVela sigue en alfa, así que la estable es la 1.10; su comunidad es concentrada, con unas 33 personas contribuyendo en 2025. Score es joven, su implementación para Kubernetes tiene pocas estrellas y su patrocinador, Humanitec, fue adquirido por Akamai. Y el poder de KubeVela vive en CUE, un lenguaje poco común y difícil de depurar. La abstracción es real, pero cuando se rompe, tu desarrollador acaba mirando YAML de Kubernetes igual.

La analogía: el formulario de pedido frente a la lista de la compra

Desplegar en Kubernetes crudo es ir al mayorista con una lista de la compra técnica: tienes que saber que quieres un Deployment, un Service, un HorizontalPodAutoscaler, un Ingress, un ConfigMap y un ResourceQuota, y cómo se rellena cada uno. Funciona si conoces el almacén. Pero tu data scientist, que solo quiere servir su modelo, no debería tener que aprenderse el almacén.

KubeVela es un formulario de pedido. En vez de la lista técnica, marcas “quiero servir esta aplicación, con estas réplicas, con esta puerta de enlace”, y detrás alguien que sí conoce el almacén (tu equipo de plataforma) ha definido qué se pide exactamente para que eso funcione. El desarrollador rellena el formulario; la traducción a la lista técnica la hizo otro, una vez, para todos.

Score es el mismo formulario pero pensado para que te valga en dos tiendas distintas. Describes tu pedido una sola vez y la misma hoja sirve para el mercado de al lado (Docker Compose, tu portátil) y para el mayorista (Kubernetes, producción), sin reescribirla. Lo que cambia entre una tienda y otra lo pone quien traduce, no tú. Las dos analogías apuntan a lo mismo: separar lo que el desarrollador quiere de cómo se materializa, para que no tenga que aprender el almacén.

KubeVela: la aplicación como unidad

Qué es y en qué estado llega a 2026

KubeVela es un proyecto de la CNCF en nivel de incubación desde febrero de 2023. Nació como evolución del runtime de OAM en Kubernetes, con contribuciones de arranque de Alibaba Cloud, Microsoft y Upbound, y se apoya en el Open Application Model, la especificación que Alibaba y Microsoft co-crearon para describir aplicaciones de forma independiente de la infraestructura.

Te doy un dato de realismo sobre su tamaño de comunidad. La retrospectiva oficial de 2025 declara siete releases en el año, 124 commits y unas 33 personas contribuyendo, sobre algo más de 7.600 estrellas en GitHub. No es un proyecto en declive, pero es una comunidad concentrada, con la curva de crecimiento aplanada respecto a su etapa inicial bajo Alibaba. Y un aviso de versión importante: la rama estable es la 1.10, con parches regulares durante 2026; la 1.11 sigue en alfa, así que no te fíes de sus features como si estuvieran disponibles.

El modelo OAM en cinco piezas

Toda tu aplicación se describe en un solo fichero YAML de tipo Application, con cuatro secciones que te toca conocer por nombre. Los components son el artefacto que despliegas, sea una imagen, un chart de Helm o un servicio; los traits son requisitos operativos que cuelgas de cada componente, como el escalado, la puerta de enlace o el almacenamiento; las policies son estrategia global de la aplicación, como la topología multi-cluster o los SLO; y el workflow es el proceso de entrega por pasos, que puede incluir una pausa de aprobación manual o una notificación.

La clave del modelo es que los tipos de componente y de trait no son fijos: son módulos programables que mantiene tu equipo de plataforma, expresados como ComponentDefinition y TraitDefinition. El desarrollador solo consume un tipo y sus propiedades; nunca ve el YAML de Kubernetes que hay debajo. Ese es exactamente el “no exponer Kubernetes crudo” del que va todo esto: tu operador de plataforma escribe la definición una vez, tu data scientist escribe quince líneas de Application.

CUE, el poder y el peaje

Las definiciones se escriben en CUE, y aquí tienes a la vez la fuerza y la debilidad de KubeVela. CUE te deja parametrizar en serio: la definición declara qué inputs expone al desarrollador y qué recursos de Kubernetes renderiza a partir de ellos, con acceso a variables de contexto como el nombre de la aplicación. El flujo real parte de un YAML existente, que vela def init convierte en un esqueleto CUE; lo editas, lo validas con vela def vet y lo publicas con vela def apply, y queda disponible para todos tus desarrolladores.

El peaje es que CUE es un lenguaje poco común, con pocos expertos y difícil de depurar. El coste recae en tu equipo de plataforma, no en el desarrollador, que es la distribución correcta, pero es un coste real que tienes que fichar antes de adoptar. Nadie llega sabiendo CUE.

La CLI vela: Heroku por fuera, GitOps por dentro

Aquí está la respuesta a la pregunta que este blog viene arrastrando sobre el aprovisionamiento por CLI. El día a día con KubeVela se te parece a Heroku: vela up despliega la aplicación desde ficheros locales, vela status te muestra su estado, vela ls lista las aplicaciones, vela logs sigue los registros, vela exec ejecuta un comando dentro del contenedor sin que conozcas el nombre del pod, y vela port-forward te abre un túnel. Tienes incluso vela dry-run, que renderiza los recursos de Kubernetes sin aplicarlos, para que veas qué va a pasar.

La matización honesta es que es “imperativa en la superficie, declarativa por debajo”. Cuando haces vela up no estás ejecutando una orden imperativa tipo heroku scale, estás aplicando un objeto Application declarativo que un controlador reconcilia. La CLI te imita el flujo cómodo de Heroku, pero el modelo subyacente es GitOps, lo que significa que encaja con tu stack de Flux mediante el addon correspondiente, en vez de reemplazarlo.

Multi-cluster, que es lo que a ti te importa

Si tienes una plataforma con varios sites (site01 y site02, en mi caso) la parte de multi-cluster es la que decide. KubeVela orquesta desde un cluster central y solo los recursos ya renderizados llegan a los clusters gestionados, con gobierno centralizado. Una topology policy decide el destino por lista de clusters o por selector de etiquetas (por ejemplo, por región); una override policy ajusta imágenes, réplicas o traits por cluster sin tocar el componente; y el paso de despliegue en el workflow reparte, con la opción de un despliegue por fases: primero al cluster local, luego una puerta de aprobación manual, y solo entonces a producción. Es la clase de gobierno que on-premise tienes que construir y que la nube te daba servido.

VelaUX, el portal ligero de regalo

KubeVela trae una consola web opcional, VelaUX, que enciendes como un addon y te da dashboard, gestión de proyectos, entornos y ciclo de vida de las aplicaciones. Si quieres CLI primero es opcional, más útil para dar visibilidad y control de acceso a operadores que como vía principal. Es un portal ligero “de regalo” que no pretende competir con Backstage, pero que puede ahorrarte montar uno si tus necesidades son modestas.

Score: describe el workload una vez

Qué es y qué resuelve

Score es una especificación abierta de workload, agnóstica de plataforma y de entorno. La idea, en su propia formulación, es que definas el workload una vez y uses una implementación de Score para traducirlo a varias plataformas: Docker Compose, Kubernetes, Fly.io o Cloud Run. El problema que te ataca es concreto y familiar: la divergencia entre lo que corres en tu portátil con Docker Compose y lo que se despliega en producción con Kubernetes, dos descripciones que se desincronizan y te causan el clásico “en mi máquina funcionaba”.

En un fichero score.yaml el desarrollador declara sus contenedores, los puertos de servicio y los recursos que necesita como dependencias (una base de datos, un DNS, una ruta), y los parámetros específicos de cada entorno se inyectan al desplegar. Score entró en el sandbox de la CNCF en julio de 2024. Lo creó y donó Humanitec, una empresa de plataformas de desarrollador, unos dieciocho meses antes de su ingreso en la fundación.

Las dos implementaciones

Score no hace nada por sí solo: es una especificación que necesita una implementación que traduzca. Tienes dos oficiales. score-compose genera Docker Compose para desarrollo local, con comandos init y generate, y provisiona del orden de catorce tipos de recurso, desde Postgres o Redis hasta almacenamiento S3 o colas. score-k8s genera manifiestos de Kubernetes listos para kubectl apply, con flags para la imagen, el namespace y los provisioners. La CLI comercial de Humanitec, humctl, también soporta Score de forma nativa.

El dato de arquitectura más importante es que Score no corre nada en el cluster destino. Es traducción puramente de CLI: te genera manifiestos y se aparta. No hay controlador, no hay CRD, no hay reconciliación. Esa es a la vez su virtud (es ligero, portable y sin lock-in de runtime) y su límite (no orquesta ni despliega, solo traduce).

Score frente a KubeVela y a Helm

El propio posicionamiento oficial de Score aclara las capas, y te lo fijo porque es fácil confundirlas. Score es la capa de especificación de workload, centrada en el desarrollador: describe un workload y sus dependencias y se traduce a N plataformas por CLI, pero no orquesta ni despliega. KubeVela es una plataforma completa de entrega continua, centrada en la aplicación: orquesta múltiples componentes, aplica policies y workflows, hace multi-cluster, y para ello necesita su controlador en el cluster; es, en sus propias palabras, mucho más rico en features que Score. Helm es el empaquetado y el renderizado de manifiestos, sin la abstracción centrada en el desarrollador ni la portabilidad a Compose.

La síntesis limpia es que son capas complementarias, no sustitutas: Score genera, Helm o los manifiestos empaquetan, KubeVela orquesta y despliega. Si te los presentan como rivales, han confundido las capas.

Dónde encaja cada uno: la comparación transversal

Con Crossplane ya en la mano del artículo anterior, la comparación de las tres piezas de autoservicio se te ordena por la pregunta que responde cada una.

Score y KubeVela responden en el plano de la aplicación: el workload que un desarrollador despliega, “despliega esta app”. Crossplane responde en el plano de la infraestructura: el recurso que un desarrollador pide, “dame una Postgres gestionada”. Y Backstage responde en el plano del portal: el catálogo web y los caminos dorados, la capa de descubrimiento que no despliega ni provisiona por sí misma, sino que orquesta a las de abajo.

Lo interesante es que se combinan. Un score.yaml puede declarar sus recursos y delegar la provisión de esos recursos a Crossplane mediante un provisioner, mientras KubeVela orquesta el despliegue de la aplicación y Backstage sirve de fachada. No es un o esto o lo otro; es una pila donde cada capa hace su trabajo. Si tu equipo es pequeño, eliges una sola pieza y ya; la pila completa es para plataformas maduras.

El encaje con inferencia: patrón, no receta oficial

Igual que con Crossplane, aquí te toca honestidad: no existe una definición oficial y mantenida de KServe en el catálogo por defecto de KubeVela ni un tipo de recurso de inferencia en Score. Lo que sigue es un patrón de diseño con piezas confirmadas por separado, no una receta documentada.

El patrón con KubeVela sería que tu operador de plataforma define una vez, en CUE, un ComponentDefinition llamado por ejemplo inference-service, que por debajo renderiza un servicio de inferencia de KServe con runtime vLLM, con los límites de GPU, las cuotas de namespace y el autoescalado ya cableados. Tu data scientist escribe entonces una Application de quince líneas con el tipo inference-service y sus propiedades (el modelo, las réplicas), sin tocar KServe, sin conocer las cuotas de GPU ni la clase de runtime, y opera con vela up, vela status y vela logs. El multi-site te lo resuelven la topology policy, que decide en qué cluster con GPU aterriza, y la override policy, que ajusta réplicas o modelo por sitio, con una aprobación manual en el workflow antes de producción.

La alternativa con Score sería un score.yaml con un recurso de tipo inference-endpoint que score-k8s, con un provisioner a medida, emite como un servicio de inferencia de KServe. Más portable, pero hoy te exige ese provisioner propio, porque KServe no es un tipo por defecto. En ambos casos, la capa de abstracción se apoya en piezas que ya son estándar (KServe pasó a incubación en la CNCF a finales de 2025 y vLLM es su runtime generativo de referencia), pero la abstracción de inferencia la construyes tú. Tómalo como propuesta, no como caso probado.

Te dejo una nota: en 2026 KServe estrenó un tipo dedicado a modelos grandes, LLMInferenceService, todavía en alfa y con vLLM como runtime, que es el ladrillo que una definición de KubeVela o un provisioner de Score renderizarían por debajo. Y en la capa de infraestructura, no en esta, el equipo de Crossplane publicó Modelplane, un plano de control de inferencia hecho de composiciones que sirve vLLM directamente. Ninguno de los dos es un tipo de KubeVela ni de Score, pero ambos te confirman que el ladrillo de abajo se está estandarizando, que es lo que hace viable poner una fachada de autoservicio encima.

Caveats, sin adornos

Esta es la sección que separa el artículo del folleto, y con estos dos proyectos te hace especial falta.

La adopción es nicho, y hay un dato duro. El radar tecnológico de la CNCF de principios de 2026, sobre más de 400 desarrolladores, coloca en “Adopt” a Helm, Backstage y Argo CD. Ni KubeVela, ni Score, ni Crossplane se mencionan. Son herramientas de nicho frente al mainstream, y elegirlas es apostar por una curva de adopción que puede no despegar.

Score es joven y su patrocinador cambió de manos. Su implementación para Kubernetes tiene pocas estrellas, la especificación está en versiones 0.x, y Humanitec, que lo patrocina, fue adquirida por Akamai en 2025, así que te toca vigilar la continuidad de la inversión en la parte open source.

KubeVela tiene comunidad concentrada y v1.11 en alfa. Las 33 personas contribuyendo en 2025 y la curva de estrellas plana son señal de meseta. No construyas sobre features de la 1.11 hasta que sea estable.

La curva de CUE es real. El poder de KubeVela vive en definiciones CUE, y CUE es difícil. El coste recae en la plataforma, pero existe.

Y el riesgo de siempre con las abstracciones: la fuga. Tanto KubeVela como Score añaden una indirección sobre Kubernetes y KServe. Cuando algo falla por debajo, la abstracción se agrieta y tu desarrollador acaba mirando el YAML de KServe igualmente, más el lock-in en tus propias definiciones. Una abstracción que no aguanta el fallo te devuelve justo la complejidad que prometía esconder.

Para tu factoría de inferencia soberana

La decisión práctica se te ordena por el perfil de tus usuarios. Si tu gente vive en la CLI y piensa en aplicaciones, KubeVela te da la experiencia tipo Heroku sobre tu propio hierro, con multi-cluster real, a cambio de que tu equipo de plataforma aprenda CUE. Si lo que más te duele es la divergencia entre local y producción, Score te resuelve eso con lo mínimo, sin meter un runtime más en el cluster. Y si quieres las dos cosas más un portal, la pila Score, Crossplane, KubeVela y Backstage existe, pero es para una plataforma que ya sirve a muchos equipos, no para el arranque.

El criterio de sobriedad es el mismo que en toda esta tanda: estas herramientas te tapan un hueco real de la nube que dejaste, pero cada una es un sistema más que operar. Para dos equipos que se conocen, un buen Helm y un repositorio de GitOps ordenado te hacen el trabajo sin CUE ni definiciones propias. El autoservicio centrado en la aplicación empieza a pagarte cuando el número de gente que despliega supera al número de gente que sabe Kubernetes, que es justo el momento en que una factoría de inferencia deja de ser un proyecto y empieza a ser una plataforma.

Con esto se cierra la tanda. El mapa te dibujó los huecos de salir de la nube, Crossplane cubrió el plano de control de infraestructura, y KubeVela con Score cubren la cara que el desarrollador toca. Tu casa propia ya se parece bastante al hotel, y el dato se quedó dentro.

Ver también

De la nube pública a la privada: el mapa — el problema completo que esta tanda desglosa.
Crossplane: el plano de control de nube privada — la capa de infraestructura, complementaria a esta.
Backstage como portal de autoservicio — la tercera vía de autoservicio, la del portal web.
KServe y el protocolo abierto de inferencia — lo que las definiciones de inferencia materializarían por debajo.
GitOps del stack de inferencia con Flux — el motor con el que KubeVela convive.

Fuentes

KubeVela, State of KubeVela 2025 — https://kubevela.io/blog/2025/12/20/state-of-kubevela-2025/
CNCF, KubeVela brings software delivery control plane capabilities to the CNCF incubator — https://www.cncf.io/blog/2023/02/27/kubevela-brings-software-delivery-control-plane-capabilities-to-cncf-incubator/
KubeVela Docs, Core Concept — https://kubevela.io/docs/getting-started/core-concept/
KubeVela Docs, vela CLI reference — https://kubevela.io/docs/cli/vela/
KubeVela Docs, Custom Component with CUE — https://kubevela.io/docs/platform-engineers/components/custom-component/
KubeVela Docs, Multi-cluster delivery — https://kubevela.io/docs/case-studies/multi-cluster/
KubeVela Docs, VelaUX addon — https://kubevela.io/docs/reference/addons/velaux/
CNCF, Score accepted as a CNCF Sandbox Project — https://www.cncf.io/blog/2024/08/08/score-accepted-as-a-cncf-sandbox-project/
Score Docs, Overview — https://docs.score.dev/docs/
Score, Score vs the Open Application Model and KubeVela — https://score.dev/blog/score-vs-open-application-model-kubevela/
GitHub, score-compose — https://github.com/score-spec/score-compose
GitHub, score-k8s — https://github.com/score-spec/score-k8s
CNCF, KServe becomes a CNCF Incubating Project — https://www.cncf.io/blog/2025/11/11/kserve-becomes-a-cncf-incubating-project/
KServe Docs, Understanding LLMInferenceService — https://kserve.github.io/website/docs/model-serving/generative-inference/llmisvc/llmisvc-overview
Crossplane Blog, Building Modelplane on Crossplane — https://blog.crossplane.io/building-modelplane/ · https://modelplane.ai
CNCF y SlashData, Technology Radar Q1 2026: Platform Engineering — https://www.cncf.io/announcements/2026/03/24/cncf-and-slashdata-report-finds-platform-engineering-tools-maturing-as-organizations-prepare-for-ai-driven-infrastructure/

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/