Backstage como portal de autoservicio: dar la plataforma LLM a tus equipos sin darles el cluster

· Por José Manuel Román

Este artículo abre la capa de plataforma y autoservicio: la que decide cómo entregas todo lo que hay debajo a los equipos que van a usarlo. Los tres artículos de la tanda son Backstage (el portal), Kubeflow (la caja de herramientas de ML) y Knative (apagar la GPU cuando nadie la usa).

TL;DR

Backstage resuelve un problema real de una plataforma que ha crecido: nadie sabe qué hay, quién lo mantiene ni cómo pedir uno nuevo sin abrir un ticket. Su respuesta son tres piezas, un catálogo de software que modela cada componente y sus relaciones, unas plantillas que crean recursos nuevos por un formulario en vez de por copia y pega, y TechDocs para tener la documentación junto al código. Sobre esas tres se construye el concepto que sostiene todo lo demás, el golden path: el camino soportado hecho también el más fácil, de modo que la gente lo toma porque está asfaltado, no porque se le obligue.

El precio es alto y hay que decirlo sin adornos. Backstage no es un producto que se instala, es una aplicación Node y React que se compila y se mantiene como código propio, con un coste declarado de dos a tres ingenieros a tiempo completo, y con las actualizaciones como su mayor punto de dolor. A agosto de 2026 sigue siendo proyecto incubating de la CNCF, no graduado, y no tiene un tipo de entidad nativo para modelos, datasets ni endpoints de inferencia: eso se modela a mano o se espera a una propuesta que todavía está abierta. La decisión no es de features, es de escala: por debajo de cierto tamaño de organización, un portal cuesta más de lo que ahorra.

La analogía: el directorio del polígono industrial

Una nave suelta no necesita cartel. Sabes qué hay dentro porque la construiste tú. Un polígono con doscientas naves, en cambio, necesita un directorio a la entrada: qué empresa está en cada parcela, a qué se dedica, quién es el responsable, y una oficina donde pedir una parcela nueva con las acometidas ya puestas en vez de negociar cada una por separado.

Una plataforma LLM empieza siendo una nave. Un cluster, un modelo, el equipo que lo montó. A los seis meses es un polígono: quince modelos servidos, tres pipelines de RAG, adapters de LoRA por todas partes, y una pregunta que se repite en cada reunión, ¿esto quién lo mantiene? Backstage es el directorio de ese polígono, con dos añadidos que un directorio corriente no tiene: la oficina que entrega parcelas llave en mano, y el archivo de planos de cada nave. El catálogo es el directorio, las plantillas son la oficina, TechDocs es el archivo.

La analogía también avisa del coste. El directorio no se mantiene solo. Alguien tiene que actualizarlo cuando una empresa se muda, y un directorio con la mitad de las parcelas mal etiquetadas es peor que no tener directorio, porque la gente deja de fiarse de él. En Backstage ese fallo tiene nombre, catalog rot, y es la primera causa de que un portal se abandone.

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

Backstage nació dentro de Spotify y se donó a la CNCF, que lo aceptó en septiembre de 2020 y lo pasó a nivel incubating en marzo de 2022. Ahí sigue: a agosto de 2026 es incubating, no graduado, un detalle que importa cuando alguien lo vende como estándar de facto. Es el portal de desarrollador más adoptado con diferencia (el balance oficial de 2025 declara más de 3.400 organizaciones que lo usan, 31.000 estrellas en GitHub y más de 250 plugins), pero adopción no es madurez de gobernanza, y una parte grande de esos plugins la mantiene la comunidad, no el core.

La arquitectura ha ido cambiando de piezas bajo los pies de quien lo opera. El New Backend System se estabilizó en 2024 y es ya el estándar. El New Frontend System pasó a ser el modo por defecto para aplicaciones nuevas en la versión 1.49, de marzo de 2026. La cadencia es de una versión menor al mes, y ese ritmo es justo el origen del mayor problema operativo, que veremos más abajo.

Las tres piezas

El catálogo de software

El corazón de Backstage es un catálogo de entidades. Cada pieza de la plataforma se describe en un fichero catalog-info.yaml que vive junto a su código, y Backstage lo descubre rastreando el repositorio. Los tipos de entidad son fijos: Component (algo que se ejecuta o se compila), API (un contrato que un componente expone), Resource (infraestructura que un componente necesita), System (un conjunto de componentes que forman una unidad), Domain (un conjunto de sistemas), más Group y User para la propiedad.

Lo potente está en las relaciones más que en las entidades, que Backstage calcula y navega: ownedBy conecta cada cosa con su equipo, providesApi y consumesApi dibujan quién depende de quién, partOf agrupa componentes en sistemas, dependsOn traza el grafo de dependencias. Con eso, la pregunta de la reunión (¿esto quién lo mantiene, y qué se rompe si lo tocamos?) deja de responderse por memoria y pasa a responderse por consulta.

Hay una decisión de diseño que condiciona todo lo que viene después: Backstage desaconseja crear tipos de entidad nuevos. Los plugins se compilan esperando los tipos de siempre, y un tipo inventado los deja ciegos. La vía soportada es reutilizar un tipo existente y distinguir con el campo spec.type (por ejemplo un Resource con type: llm-model), añadiendo los campos propios que hagan falta al spec.

Las plantillas

La segunda pieza es el Scaffolder, el motor de plantillas. Una plantilla es una entidad de tipo Template con tres partes: los parameters que se piden por un formulario, los steps que se ejecutan, y las actions que hacen el trabajo real (crear un repositorio, escribir el catalog-info.yaml, registrar el componente, disparar el pipeline de GitOps). El desarrollador entra en /create, elige una plantilla, rellena el formulario, y en una sola operación tiene el recurso creado, catalogado y desplegándose.

Esto es lo que convierte un directorio en una oficina. Sin plantillas, Backstage solo lista lo que ya existe. Con plantillas, es la puerta por la que se crea lo nuevo, y esa puerta es donde se materializa el golden path.

TechDocs

La tercera pieza es TechDocs, documentación como código. Los documentos se escriben en Markdown junto al código, se generan con MkDocs en el pipeline de CI, y se sirven dentro del propio portal, enlazados desde la ficha de cada componente. La ventaja está en los incentivos: la documentación que vive lejos del código se pudre; la que vive al lado y se revisa en el mismo pull request tiene alguna posibilidad de seguir siendo cierta.

El golden path, que es de lo que va todo esto

Spotify acuñó el término golden path para el camino recomendado y soportado de construir algo. Tiene dos mitades: las herramientas bendecidas, visibles en el portal, y un tutorial paso a paso en la documentación. La idea, en la formulación que repiten los informes de plataforma, es que nadie obliga a usar la carretera asfaltada; la gente la toma porque está asfaltada.

Los datos apoyan que el golden path es la variable que decide. El informe State of Platform Engineering de 2026, sobre 518 profesionales, cifra la adopción voluntaria por encima del 80 % cuando hay un golden path bien diseñado y por debajo del 20 % cuando no lo hay, y estima que en torno al 70 % de las iniciativas de plataforma no alcanzan adopción significativa sin él. Es un dato que reordena la prioridad: un portal sin golden paths es un catálogo bonito que nadie usa.

En Backstage, un golden path se implementa como una plantilla del Scaffolder. Para una plataforma LLM, un golden path típico sería “servir un modelo nuevo”: el formulario pide el modelo, el tamaño de GPU, el equipo propietario y el SLO; la plantilla crea el repositorio con el InferenceService, escribe el catalog-info.yaml, lo registra bajo el sistema correcto, y abre el pull request al repositorio de GitOps que ya tienes con Flux. Lo que antes era medio día de copiar el YAML del compañero y adivinar los valores pasa a ser un formulario de dos minutos con los valores correctos por defecto.

Autenticación y permisos

Para una plataforma soberana la pieza de identidad importa tanto como el catálogo. Backstage trae conectores de fábrica para GitHub, GitLab, Google, Microsoft, Okta, OIDC genérico y SAML, entre otros. Para on-premise el relevante es Keycloak, que encaja como cualquier otro proveedor OIDC, con un matiz que conviene tener presente: el conector de Keycloak lo mantiene la comunidad, no el core, así que su mantenimiento y su estanqueidad recaen en un plugin de terceros. Cuando ya has montado Keycloak como vimos en el artículo sobre autenticar el MCP, el portal se engancha al mismo emisor de identidad.

El framework de permisos aparece hoy como estable en la documentación y soporta RBAC, ABAC y lógica a medida. La letra pequeña: por defecto los endpoints no están protegidos, y la política de permisos la escribe el integrador. La solución de RBAC con interfaz gráfica más usada la trae la distribución de Red Hat, no el core. Es decir, para un control de acceso serio hay trabajo por encima de lo que da la caja.

El coste real, sin adornos

Aquí es donde un artículo honesto se separa del folleto. Backstage no es un producto instalable, es un framework que se compila y se mantiene como código propio. Eso tiene consecuencias medibles.

El análisis más citado, del proveedor de Backstage gestionado Roadie, cifra el esfuerzo en unos tres ingenieros a tiempo completo el primer año y dos a partir del segundo, con un tiempo hasta producción de seis a doce meses en modo autogestionado. La cifra viene de un vendedor con interés comercial en que compres su versión gestionada, así que hay que tomarla como orden de magnitud y no como dato neutral, pero la dirección la confirman fuentes independientes: el mantenimiento continuo se lleva en torno a una quinta parte del tiempo de ingeniería, y las actualizaciones son el mayor punto de dolor, citado por más de la mitad de quienes lo adoptan. Con una versión menor al mes y piezas de arquitectura cambiando bajo los pies, mantenerse al día es un trabajo permanente.

El otro coste es de adopción, no de ingeniería. Un análisis crítico muy repetido señala que muchas organizaciones se quedan en torno al 10 % de uso interno, frente al 99 % voluntario que Spotify logró en casa, y lo atribuye a tres fallos recurrentes: el catalog rot que ya mencionamos, la falta de un responsable de producto que trate el portal como un producto, y la ilusión de que Backstage se puede adoptar sobre lo que ya existe cuando en la práctica solo estandariza bien lo nuevo. La frase que resume el desencanto es que Backstage es un portal gratis igual que tendrías un coche gratis si alguien volcara todas las piezas de un Chevrolet sobre tu mesa.

Aplicado a una plataforma LLM: lo que hay y lo que no

Aquí toca corregir una expectativa habitual. En 2026 Backstage no tiene entidades nativas para modelos, datasets ni endpoints de inferencia. Hay tres cosas y ninguna es lo que uno espera:

Una propuesta abierta (la RFC 33060, de febrero de 2026) para modelar servidores de modelos como entidades de tipo API con type: ai-model-server. Está en discusión, no implementada.

Un módulo oficial que introduce un tipo AiResource, que suena a lo que buscamos pero es para otra cosa: gobernar las skills y reglas de los asistentes de código, no registrar modelos de inferencia.

Y un patrón real, el de las plantillas de MLOps que AWS documenta sobre SageMaker, donde Backstage actúa como el Scaffolder que crea entornos y pipelines, no como el registro de modelos. Es un caso de cloud, no on-premise, y usa Backstage por su mitad de plantillas, no por su catálogo de modelos.

La conclusión práctica para un stack propio es doble. Primero, lo que Backstage aporta hoy a una plataforma LLM es sobre todo la mitad de las plantillas: el golden path de “crea un servicio de inferencia nuevo” enganchado a tu GitOps. Segundo, si quieres catalogar los modelos, hoy se hace a mano con spec.type propios, tratando el modelo como Resource y su endpoint como API, hasta que la propuesta madure. El registro de los bytes del modelo sigue siendo trabajo del registro OCI, no del catálogo.

Los plugins de infraestructura que sí valen la pena en este stack existen y están razonablemente vivos: el de Kubernetes (core), el de Flux para ver el estado de GitOps desde el portal, el de Grafana para incrustar paneles en la ficha del componente, y el de ArgoCD para quien use Argo en lugar de Flux.

Alternativas: cuándo no montar Backstage

La decisión honesta no es qué portal, sino si portal. Las alternativas de tipo SaaS (Port, Cortex, OpsLevel, Humanitec) ganan en tiempo hasta el primer valor, que se mide en días en lugar de meses, y en no tener que mantener el framework, a cambio de una cuota por usuario que escala mal y de renunciar al on-premise puro. Roadie ofrece Backstage gestionado, que elimina el mantenimiento del framework conservando su extensibilidad, a cambio de una cuota por desarrollador y de sacar tu catálogo fuera.

Para una plataforma soberana, donde el on-premise y la propiedad del dato son requisitos, el SaaS puro suele quedar descartado por diseño, lo que deja la elección real entre Backstage autogestionado y no tener portal. Y ahí el criterio es el tamaño. Por debajo de un puñado de equipos, un README bien mantenido y un repositorio de GitOps ordenado hacen el mismo trabajo que el catálogo, sin el coste de dos ingenieros. El portal empieza a compensar cuando la carga cognitiva de saber qué hay y cómo pedirlo supera el coste de mantener la herramienta que lo responde.

Trampas operativas y escepticismo honesto

El catálogo se pudre si no se automatiza. Un catalog-info.yaml escrito a mano y nunca actualizado miente a las pocas semanas. La única defensa es generar y validar esas fichas en el pipeline, no confiar en que la gente las mantenga.

Sin responsable de producto, el portal muere. Backstage no es infraestructura que se instala y se olvida, es un producto interno con usuarios que hay que entender. Sin alguien que trate la adopción como un objetivo, acaba siendo un catálogo que nadie mira.

Las actualizaciones son un impuesto recurrente. Una versión al mes y piezas de arquitectura en migración significan que el portal nunca está terminado. Hay que presupuestar ese mantenimiento desde el principio, no descubrirlo el segundo trimestre.

Backstage no despliega nada. Es un portal, no un motor. Detrás de cada plantilla tiene que haber tu GitOps, tus operators y tu cluster haciendo el trabajo real. Si esa base no está sólida, el portal solo pone una fachada bonita sobre un caos.

El modelo de datos para IA todavía no existe. Quien monte Backstage esperando un catálogo de modelos listo para usar se va a encontrar modelando a mano. Es viable, pero es trabajo, y hay que saberlo antes.

Para una factoría de inferencia

Backstage encaja en el nivel de madurez alto de una plataforma, no en el arranque. En los cinco niveles de madurez es una herramienta del nivel en que la plataforma ya sirve a varios equipos y el cuello de botella ha dejado de ser técnico para ser de coordinación. Tres decisiones concretas se deducen de todo lo anterior.

La primera es no montarlo demasiado pronto. Si la plataforma la usan dos equipos que se conocen, el portal es coste sin retorno. El disparador es la carga cognitiva, no el calendario.

La segunda es empezar por las plantillas, no por el catálogo. El valor que se nota desde el primer día es el golden path que convierte medio día de copiar YAML en un formulario de dos minutos. El catálogo completo, con todas las relaciones, es un trabajo mayor que puede venir después.

La tercera es presupuestar el mantenimiento como una función, no como un proyecto. Dos ingenieros a tiempo parcial de forma indefinida, un responsable que mire la adopción, y la generación automática de las fichas del catálogo. Sin eso, el portal se degrada hasta que alguien pregunta por qué nadie lo usa, y la respuesta es que dejó de ser cierto.

El portal es la cara que tu plataforma le enseña a quien la usa. Vale la pena cuando hay suficiente plataforma detrás como para que enseñarla ordenadamente ahorre más de lo que cuesta mantener el escaparate. Antes de eso, es un escaparate de una tienda que aún no tiene género. Los otros dos artículos de esta tanda entran en ese género: la caja de herramientas de ML con Kubeflow y el ahorro de apagar la GPU con Knative.

Ver también

Fuentes