Databricks Backstage Convierte FinOps en Una Consulta, pero la Parte Difícil se Desplaza Aguas Arriba

Databricks ha completado un experimento de Backstage en tres partes con un resultado llamativo: una única consulta puede conectar la propiedad de la infraestructura con el consumo diario de Lakebase. El diseño de databricks backstage elimina una frontera de integración que normalmente separa la ingeniería de plataformas de FinOps. Sin embargo, también deja al descubierto una dependencia más compleja: contar con metadatos de servicio precisos.

La demostración une el catálogo de software en tiempo real de Backstage con los registros de facturación de Databricks sin trasladar primero ambos conjuntos de datos a un sistema de informes independiente. Un analista de FinOps puede identificar un recurso de Lakebase, encontrar a su propietario e inspeccionar su uso mediante una sola sentencia SQL.

Esto tiene más consecuencias que otra integración de paneles. Backstage suele contener datos de propiedad operativa, mientras que un almacén de datos guarda los registros de costes. Los equipos conectan esos sistemas mediante trabajos ETL, exportaciones, tickets y mapeos mantenidos manualmente.

El nuevo enfoque reemplaza gran parte de ese movimiento con federación, que consulta datos entre sistemas a través de una capa SQL compartida. Sin embargo, no elimina el trabajo organizativo que sustenta la imputación de costes. En su lugar, traslada ese trabajo a las anotaciones del catálogo, los identificadores de recursos, los controles de acceso y la semántica de facturación.

El Experimento de Databricks Backstage Alcanza su Beneficio para FinOps

El tercer experimento convierte el grafo de propiedad de Backstage en un punto de entrada directo para el análisis de costes en la nube.

Databricks y Thoughtworks utilizaron Backstage, el portal interno de desarrolladores de código abierto de Spotify, como aplicación operativa durante toda la serie. Backstage mantiene un catálogo de software que contiene servicios, componentes, propietarios, dependencias y referencias de infraestructura.

Los equipos trasladaron el estado de PostgreSQL del portal a Lakebase, el servicio Postgres gestionado de Databricks. Lakebase separa el almacenamiento del cómputo e integra datos transaccionales con el entorno más amplio de Databricks.

La primera parte se centró en la creación de ramas de bases de datos. Según los autores, Lakebase creó una rama de base de datos en aproximadamente un segundo. Esto hizo viable probar migraciones de Backstage frente a una copia aislada antes de modificar la base de datos de producción.

La segunda parte incorporó la base de datos operativa a Unity Catalog, la capa de gobernanza de Databricks para activos de datos e IA. Ese paso hizo que la base de datos de Backstage fuera visible mediante el mismo plano de control utilizado para los datos analíticos.

La tercera entrega aplica esos cambios previos a FinOps. Su consulta central combina registros de Backstage con la tabla de facturación del sistema de Databricks.

El lado de Backstage utiliza final_entities, una tabla que contiene los registros de entidades procesados del catálogo. Cada entidad relevante incluye una anotación databricks/project-id que identifica su proyecto de Lakebase.

El lado de facturación utiliza system.billing.usage, que registra el consumo facturable de Databricks. La consulta hace coincidir la anotación del catálogo con usage_metadata.project_id y luego filtra el uso de Lakebase.

El ejemplo publicado agrupa el consumo por nombre de recurso de Backstage, ID de proyecto de Lakebase y fecha. Su salida de muestra atribuye 39.8667 DBU el 8 de abril de 2026 y 43.6231 DBU el 7 de abril.

Una DBU, o Databricks Unit, es una medida normalizada utilizada para representar el consumo de procesamiento de la plataforma. La consulta informa DBU en lugar de un cargo final en moneda.

Esta distinción importa. La demostración prueba que el uso puede atribuirse a un recurso catalogado. No establece un modelo contable completo para cada descuento, compromiso, ajuste o gasto compartido.

Aun así, acorta una investigación habitual de FinOps. Un analista ya no necesita solicitar una exportación de propiedad de servicios antes de compararla con datos de facturación del almacén.

El resultado también vincula la información de costes con el lugar donde los desarrolladores ya descubren servicios. Esto abre una vía hacia vistas de costes organizadas por sistemas, equipos o productos, en lugar de basarse únicamente en nombres de recursos de la nube.

Por ello, la serie termina en un lugar distinto de donde comenzó. La creación de ramas de bases de datos mejoró un flujo de trabajo de ingeniería. Después, la gobernanza unificada hizo que el estado operativo fuera consultable. El paso final convierte esos cambios técnicos en un mecanismo de informes organizativos.

Por Qué Una Consulta Cambia el Papel del Equipo de Plataforma

El cambio importante no es un SQL más corto; es eliminar una negociación recurrente entre los equipos de plataforma, datos y finanzas.

Un portal interno de desarrolladores típico responde preguntas como quién es propietario de un servicio, qué repositorio lo contiene y qué infraestructura lo respalda. Un sistema de facturación responde cuánto consumo medido generó un recurso.

Estas respuestas suelen utilizar identificadores incompatibles. Un desarrollador reconoce un servicio llamado checkout-api, mientras que una factura en la nube muestra una cuenta, un proyecto, un clúster o un ID de recurso opaco.

Los equipos de FinOps abordan ese desajuste con etiquetas, reglas de asignación, modelos de informes y revisión manual. El FinOps Framework considera la asignación una capacidad fundamental porque los costes sin asignar debilitan la responsabilidad y las previsiones.

Backstage ofrece una posible capa de propiedad para ese proceso. Su catálogo ya asocia entidades de software con equipos e infraestructura. El desafío consiste en conectar esas asociaciones con los registros de facturación de forma fiable.

El experimento de Databricks sitúa la conexión dentro de la plataforma de datos. Lakehouse Federation, una capacidad para consultar fuentes externas u operativas sin ingestión convencional, expone el catálogo de Backstage en tiempo real junto a los datos de facturación del sistema.

Este enfoque reduce la necesidad de una canalización dedicada que copie registros de propiedad a un almacén de datos. También evita tener que esperar a la siguiente ejecución programada de esa canalización antes de resolver una cuestión de costes.

El cómputo separado es central en la propuesta. Lakebase puede atender las solicitudes transaccionales de Backstage mientras otro recurso de cómputo ejecuta consultas analíticas sobre datos relacionados.

Databricks describe Lakebase Postgres como compatible con escalado automático, funcionamiento con escalado a cero, ramas, réplicas de lectura y restauración instantánea. También se integra con Unity Catalog y Databricks Apps.

La arquitectura busca proteger el portal de la carga de trabajo del analista. Una agregación grande no debería competir directamente con las solicitudes interactivas de Backstage solo porque ambas se refieren al mismo estado subyacente.

Esta separación cambia lo que los equipos de plataforma pueden ofrecer. Pueden tratar la propiedad y el consumo como dos vistas del mismo grafo de recursos, en lugar de como dos conjuntos de datos conectados tras varias transferencias.

Los analistas de FinOps obtienen una ruta directa desde el coste hasta el propietario responsable. Los ingenieros de plataforma obtienen evidencia sobre qué servicios internos consumen capacidad de Lakebase. Los líderes de ingeniería obtienen una posible base para informes a nivel de equipo.

Los desarrolladores también afrontan una responsabilidad más visible. Una entrada de catálogo deja de ser solo documentación cuando sus identificadores determinan dónde se asigna el consumo de infraestructura.

Este cambio presiona a los equipos de plataforma para mejorar la calidad del catálogo. Deben decidir qué anotaciones son obligatorias, cómo se validan los identificadores y qué ocurre cuando los recursos cambian de propietario.

Los equipos de datos afrontan un cambio relacionado. Siguen siendo responsables del acceso gobernado y de la semántica de facturación, pero ya no necesitan asumir la responsabilidad de cada canalización de integración que conecte metadatos operativos con registros analíticos.

Los equipos de FinOps también deben adaptarse. Un acceso más rápido no elimina la necesidad de definir políticas de asignación. Les permite aplicar esas políticas más cerca del modelo operativo actual.

Por tanto, el beneficio es una división del trabajo modificada. La ingeniería de plataformas mantiene un grafo de propiedad fiable, la plataforma de datos proporciona uniones gobernadas y FinOps define cómo el consumo se convierte en responsabilidad.

Este acuerdo resulta atractivo porque elimina esperas. Es exigente porque los errores en el grafo de propiedad ahora fluyen directamente hacia los informes financieros.

El Mecanismo es la Federación, No Una Nueva Base de Datos de Costes

Databricks presenta la federación como una alternativa a copiar datos operativos del catálogo en otro repositorio de informes de costes.

La consulta central comienza con la tabla de entidades procesadas de Backstage. Backstage crea esta representación tras ingerir y normalizar definiciones de catálogo procedentes de fuentes como archivos YAML, plugins o sistemas externos.

El catálogo de software trata las entidades como registros de metadatos que describen componentes, sistemas, API, recursos, grupos y usuarios. Las relaciones conectan esas entidades en un grafo de propiedad y dependencias.

Para el experimento, un recurso de Backstage contiene el identificador del proyecto de Lakebase en una anotación. La consulta SQL extrae ese identificador del documento JSON de la entidad.

Después une el identificador con los metadatos de proyecto de la tabla de facturación. La agrupación por recurso, proyecto y día produce un resultado de atribución comprensible para las personas.

Este mecanismo tiene tres propiedades significativas.

En primer lugar, el registro operativo sigue siendo operativo. Backstage continúa utilizando PostgreSQL para su actividad habitual de catálogo, en lugar de esperar a que una réplica analítica acepte actualizaciones.

En segundo lugar, el registro de facturación permanece en la tabla del sistema de Databricks. La demostración no requiere una exportación personalizada antes de que los analistas puedan utilizarlo.

En tercer lugar, la unión se realiza mediante un entorno de consulta gobernado. Unity Catalog puede controlar el descubrimiento y el acceso entre los objetos participantes.

Databricks denomina a esto movimiento cero de datos. Más precisamente, el usuario no crea una canalización independiente para materializar otro conjunto de datos unido antes de ejecutar el análisis.

La ejecución de consultas sigue transfiriendo solicitudes y resultados a través de las interfaces pertinentes. La federación también depende de conectores, credenciales, metadatos y controles de rendimiento.

Ese matiz no elimina la ventaja. Aclara dónde se traslada la complejidad después de que desaparece una canalización ETL.

Las canalizaciones tradicionales expresan los mapeos en código de transformación. El diseño federado expresa un mapeo crítico mediante una anotación ubicada en la entidad de Backstage.

El mapeo se vuelve más fácil de ver, pero también más fácil de pasar por alto. Si la anotación falta o es incorrecta, la consulta pierde la conexión entre recurso y propietario.

Una implementación madura validaría esa anotación durante la ingestión del catálogo. Podría rechazar identificadores de proyecto malformados o señalar entidades que hagan referencia a proyectos de Lakebase inexistentes.

Los equipos también necesitarían reglas de ciclo de vida. Un servicio eliminado, una aplicación transferida o un proyecto renombrado pueden generar cuestiones de atribución histórica que una instantánea actual del catálogo no puede responder por sí sola.

La propiedad en un momento determinado se vuelve especialmente importante para la imputación de costes. El propietario actual no debería heredar automáticamente el consumo generado antes de una transferencia de servicio.

La agrupación diaria de la demostración ofrece un punto de partida, pero la asignación histórica requiere un historial de propiedad duradero. Los equipos podrían conservar cambios del catálogo, instantáneas de facturación o una tabla de mapeo con fechas de vigencia.

El control de acceso añade otra decisión de diseño. Los ingenieros pueden necesitar visibilidad de sus propios servicios sin recibir acceso sin restricciones a los registros de facturación de toda la empresa.

Unity Catalog puede ayudar a definir privilegios, pero cada organización debe establecer el nivel de granularidad adecuado. Las vistas limitadas por equipo pueden ser más seguras que conceder un acceso amplio a la tabla subyacente del sistema.

El rendimiento también merece atención. La consulta de ejemplo es compacta, pero los catálogos de Backstage en producción pueden contener muchas entidades y registros JSON de gran tamaño.

La extracción repetida de JSON puede volverse ineficiente a escala. Los equipos podrían exponer anotaciones seleccionadas mediante una vista curada, sin modificar el catálogo de origen.

Esta optimización seguiría preservando el modelo más amplio. La diferencia sería que una capa semántica gobernada se situaría sobre los datos operativos en vivo, en lugar de una canalización de exportación desconectada.

Por lo tanto, la arquitectura de databricks backstage no elimina la ingeniería de datos. Concentra el trabajo de ingeniería en torno a contratos de metadatos, políticas de acceso e interfaces de consulta.

Es una ubicación más estratégica para ese trabajo, siempre que la organización acepte una disciplina de catálogo más estricta.

El verdadero adversario es la transferencia a ETL

El experimento cuestiona un modelo de integración centrado en pipelines, no a los competidores de PostgreSQL ni a otros portales para desarrolladores.

Tradicionalmente, los equipos separan el procesamiento de transacciones en línea del procesamiento analítico en línea. Los sistemas transaccionales priorizan escrituras frecuentes y de baja latencia, mientras que los sistemas analíticos exploran y agregan conjuntos de datos mucho mayores.

Esta separación dio lugar a dos dominios operativos. Los equipos de aplicaciones mantenían bases de datos como PostgreSQL, mientras que los equipos de datos copiaban registros seleccionados a almacenes de datos o lakehouses.

La arquitectura tenía sentido porque los sistemas contaban con diseños de almacenamiento, modelos de escalado y consideraciones de fallos diferentes. Las consultas analíticas directas podían poner en riesgo el rendimiento de las aplicaciones.

Las plataformas modernas en la nube separan cada vez más el almacenamiento, el cómputo y la gobernanza. Eso hace que algunos datos sean accesibles mediante múltiples rutas de cómputo específicas para cada carga de trabajo.

Lakebase se enmarca en esta tendencia. Databricks lo posiciona como PostgreSQL gestionado para aplicaciones transaccionales que también necesitan proximidad con los datos del lakehouse.

El experimento con Backstage aprovecha esa proximidad para evitar una exportación especializada de propiedad. La alternativa principal no es otro proveedor de Postgres. Es el proceso conocido de extraer registros de catálogo, transformar identificadores y cargarlos en un modelo de informes.

ETL mantiene ventajas importantes. Un conjunto de datos materializado puede ofrecer rendimiento predecible, instantáneas duraderas, controles de calidad y aislamiento frente a cambios en el esquema de origen.

También puede estandarizar datos procedentes de varios portales o proveedores de nube. Una consulta federada contra una base de datos de Backstage quizá no cubra a una empresa con múltiples catálogos y entornos de facturación.

El coste de ETL aparece en la latencia y la propiedad. Alguien debe programar el pipeline, supervisar fallos, actualizar esquemas, reconciliar mapeos y responder cuando los usuarios desconfían de sus resultados.

Estas responsabilidades suelen quedar entre equipos. La ingeniería de plataforma entiende el catálogo de servicios, la ingeniería de datos gestiona el almacén y FinOps entiende el modelo de asignación.

Un enfoque que prioriza la federación elimina algunas copias y programaciones. Pone a disposición la fuente en vivo, pero aumenta la dependencia de su disponibilidad, esquema, calidad de metadatos y comportamiento de consulta.

Esta es la disyuntiva central. ETL crea distancia respecto de la fuente y absorbe su inestabilidad. La federación ofrece datos actualizados y menos copias, pero mantiene a los consumidores más cerca de los cambios operativos.

La elección adecuada depende de la decisión que se quiera respaldar. La investigación interactiva se beneficia de datos de propiedad actualizados. La refacturación mensual auditada exige un historial estable y reglas reproducibles.

Es probable que las organizaciones más grandes adopten un modelo híbrido. Los analistas pueden utilizar una consulta federada para investigar el uso reciente y, después, publicar resultados de asignación aprobados en una capa de informes duradera.

Ese modelo no invalidaría la demostración. Utilizaría la federación para reducir la fricción exploratoria y preservaría los registros materializados para los procesos financieros formales.

Otras plataformas PostgreSQL gestionadas también pueden participar en arquitecturas federadas. AWS, Google Cloud, Microsoft y proveedores de bases de datos independientes ofrecen sistemas transaccionales con integraciones analíticas.

Backstage sigue siendo independiente de la base de datos. Su compatibilidad con PostgreSQL permite a las organizaciones elegir infraestructura según sus necesidades operativas, regulatorias y comerciales.

La ventaja de Databricks en este experimento proviene de la proximidad dentro de la plataforma. Lakebase, las tablas de facturación del sistema, la federación y Unity Catalog existen en un único entorno gobernado.

Esa comodidad también puede generar riesgo de concentración. Un equipo que adopte el patrón completo pasa a depender más de los identificadores, esquemas de facturación, permisos y servicios de consulta de Databricks.

Por tanto, la presión competitiva del artículo recae sobre las pilas internas fragmentadas. Los proveedores y los equipos de plataforma deben explicar por qué sigue siendo necesario copiar metadatos de propiedad cuando una consulta gobernada puede llegar a la fuente.

Sin embargo, Databricks debe demostrar que el diagrama más simple resiste la realidad operativa. Eso incluye la escala del catálogo, la evolución del esquema, los límites de acceso y las exigencias de informes de fin de mes.

Lo que el resultado de una sola consulta no resuelve

Una prueba de concepto exitosa no garantiza una refacturación empresarial fiable, porque la corrección de la consulta depende de metadatos organizativos ajenos al sistema de facturación.

El resultado de ejemplo muestra que un recurso de Backstage puede vincularse al uso de Lakebase. No muestra qué parte de la infraestructura de una organización grande puede asignarse de esta manera.

La cobertura es la primera pregunta sin respuesta. Los equipos necesitan saber qué porcentaje de los proyectos relevantes de Lakebase cuenta con una entidad válida de Backstage y una anotación de proyecto.

Un resultado puede ser técnicamente correcto y, aun así, estar incompleto desde el punto de vista financiero. Los proyectos no catalogados simplemente desaparecen de una consulta centrada en la propiedad, salvo que los analistas los identifiquen por separado.

La precisión es la segunda cuestión. Un ID de proyecto válido aún puede apuntar al servicio equivocado, a un responsable desactualizado o a un recurso compartido que respalda varios productos.

La infraestructura compartida complica la atribución, porque un proyecto puede dar servicio a varios equipos. Una única anotación de Backstage no puede expresar todas las reglas de asignación proporcional.

La semántica de facturación crea una tercera limitación. Las DBU representan consumo, pero una visión completa de costes puede requerir cargos de infraestructura en la nube, créditos, compromisos, impuestos y ajustes organizativos.

El equipo de FinOps debe decidir si la consulta sirve para showback, chargeback, investigación de anomalías o planificación de capacidad. Estos objetivos requieren distintos niveles de precisión.

La propiedad histórica es otra cuestión sin resolver. El catálogo en vivo describe el estado actual de forma más natural que la responsabilidad pasada.

Una transferencia de servicio el 15 de abril no debería necesariamente reescribir quién era responsable del consumo del 7 de abril. Los informes históricos fiables necesitan registros de propiedad con conciencia temporal.

La estabilidad del esquema también importa. La consulta accede a una entidad JSON y depende de un nombre de anotación específico. Los equipos deben gestionar ese campo como un contrato compatible y respaldado.

Los plugins de Backstage, los procesadores de catálogo y las convenciones organizativas pueden cambiar la forma de las entidades. Databricks también puede evolucionar los metadatos de facturación a medida que Lakebase se desarrolla.

Los usuarios de producción deberían probar esos contratos automáticamente. Un trabajo de validación puede identificar anotaciones ausentes, proyectos desconocidos, asignaciones duplicadas y uso sin responsable.

La seguridad plantea una presión distinta. Los metadatos de Backstage pueden revelar sistemas internos y estructuras de equipo, mientras que los datos de facturación pueden exponer patrones de consumo sensibles.

La combinación de ambos conjuntos de datos aumenta la información disponible desde una sola consulta. Es útil para el análisis, pero eleva el impacto de permisos excesivamente amplios.

Las organizaciones necesitan límites a nivel de fila o vista que se correspondan con su modelo operativo. Un responsable de servicio puede necesitar el uso de un equipo, mientras que FinOps central requiere cobertura empresarial.

También persiste la dependencia operativa. El análisis federado depende de que estén disponibles la base de datos de origen, el servicio de consultas, la configuración de identidad y la capa de gobernanza.

Databricks afirma que Lakebase aísla el cómputo para distintas cargas de trabajo. La evidencia independiente en producción seguirá siendo relevante para la latencia, la concurrencia, la recuperación ante fallos y un rendimiento analítico predecible.

La serie original también encontró una complicación de autenticación. Lakebase esperaba una credencial OAuth con ámbito específico, en lugar de un token de acceso personal clásico de Databricks.

Para la prueba de concepto, el equipo renovó una credencial de corta duración mediante un script. Los despliegues de producción necesitan un proceso de rotación compatible que evite almacenar tokens renovados en ubicaciones inseguras.

Databricks Apps puede crear un rol de PostgreSQL para el principal de servicio de una aplicación cuando los equipos adjuntan un recurso de Lakebase. Esta vía gestionada resulta más adecuada que un ciclo local improvisado de renovación.

La lección más amplia no es que la federación elimine el trabajo de gobernanza. Lo hace visible en el momento en que un usuario formula una pregunta de negocio.

El patrón de databricks backstage solo tendrá éxito cuando la completitud del catálogo se convierta en una métrica operativa. Sin esa disciplina, FinOps con una sola consulta puede generar respuestas rápidas pero parciales.

Tres señales mostrarán si el patrón se sostiene

La siguiente fase debe medir adopción, cobertura de asignación y fiabilidad en producción, en lugar de celebrar una sentencia SQL compacta.

La primera señal es una implementación reutilizable de Databricks, Thoughtworks o la comunidad de Backstage. Los equipos deberían estar atentos a procesadores de catálogo mantenidos, reglas de validación, paneles o plantillas que respalden el patrón.

Un paquete compatible reforzaría la idea de que esta arquitectura puede ir más allá de una demostración a medida. Debería definir esquemas de anotaciones, manejo de credenciales, permisos y prácticas de despliegue.

La ausencia de componentes reutilizables debilitaría la afirmación. Cada adoptante tendría que recrear de forma independiente los mapeos y controles más propensos a fallos.

La segunda señal es la cobertura de asignación en catálogos reales. La métrica útil es el porcentaje de uso de Lakebase vinculado a una entidad y un responsable de Backstage actuales y validados.

Una cobertura elevada en entornos de producción cambiantes respaldaría la federación como una entrada práctica para FinOps. Un uso persistentemente sin asignar demostraría que el mantenimiento de metadatos sigue siendo la restricción determinante.

La cobertura debería acompañarse de indicadores de actualización y recuentos de excepciones. Los equipos necesitan saber con qué rapidez aparecen nuevos proyectos y con qué frecuencia los mapeos no superan la validación.

La tercera señal es el comportamiento en producción bajo cargas de trabajo mixtas. Las organizaciones deberían medir la latencia de Backstage mientras los analistas ejecutan consultas de facturación federadas contra catálogos grandes.

Un rendimiento estable del portal reforzaría el argumento de Databricks sobre el cómputo separado. Las interrupciones de consultas, los fallos de credenciales o los cuellos de botella de gobernanza favorecerían las capas de informes materializadas para flujos de trabajo críticos.

El caso de estudio de una sola consulta propone una hipótesis clara: la gobernanza compartida y el cómputo aislado pueden reconectar la propiedad operativa con los datos analíticos de costes.

Ahora los equipos necesitan pruebas sobre cómo se comporta esa hipótesis en múltiples cuentas, recursos compartidos, transferencias de servicios y controles financieros formales.

Para los desarrolladores, la acción inmediata es sencilla. Traten las anotaciones de catálogo como datos de producción, validen los identificadores de infraestructura y definan explícitamente los cambios de propiedad.

Para los líderes de plataforma, la pregunta es si el pipeline de costes actual existe por una necesidad vigente o por una restricción arquitectónica heredada. La federación puede acortar las investigaciones incluso cuando los informes oficiales sigan materializados.

Para los equipos de FinOps, prueben la consulta de databricks backstage con asignaciones conocidas antes de ampliarla. La pregunta importante no es si se ejecuta una consulta. Es si su respuesta sigue siendo completa, explicable y reproducible cuando la organización cambia.