Databricks Backstage Transforma FinOps em Uma Consulta, mas a Parte Difícil Vai para a Origem

A Databricks concluiu um experimento de Backstage em três partes com um resultado marcante: uma única consulta pode conectar a propriedade da infraestrutura ao consumo diário do Lakebase. O design databricks backstage elimina uma fronteira de integração que normalmente separa a engenharia de plataforma de FinOps. No entanto, também expõe uma dependência mais difícil de metadados de serviço precisos.

A demonstração une o catálogo de software ativo do Backstage aos registros de cobrança da Databricks sem antes mover ambos os conjuntos de dados para um sistema de relatórios separado. Um analista de FinOps pode identificar um recurso do Lakebase, localizar seu responsável e examinar seu uso com uma única instrução SQL.

Isso é mais relevante do que outra integração de dashboard. O Backstage normalmente armazena dados de responsabilidade operacional, enquanto um data warehouse mantém os registros de custos. As equipes conectam esses sistemas por meio de jobs de ETL, exportações, tickets e mapeamentos mantidos manualmente.

A nova abordagem substitui grande parte desse movimento por federação, que consulta dados entre sistemas por meio de uma camada SQL compartilhada. Ainda assim, ela não elimina o trabalho organizacional por trás do chargeback. Em vez disso, transfere esse trabalho para anotações de catálogo, identificadores de recursos, controles de acesso e semântica de cobrança.

O Experimento Databricks Backstage Alcança Seu Retorno em FinOps

O terceiro experimento transforma o grafo de propriedade do Backstage em um ponto de entrada direto para a análise de custos em nuvem.

Databricks e Thoughtworks usaram o Backstage, o portal interno de desenvolvedores de código aberto da Spotify, como aplicação operacional ao longo da série. O Backstage mantém um catálogo de software contendo serviços, componentes, responsáveis, dependências e referências de infraestrutura.

As equipes migraram o estado PostgreSQL do portal para o Lakebase, o serviço Postgres gerenciado da Databricks. O Lakebase separa armazenamento de computação e integra dados transacionais ao ambiente mais amplo da Databricks.

A primeira parte focou no branching de banco de dados. Segundo os autores, o Lakebase criou uma ramificação de banco de dados em cerca de um segundo. Isso tornou prático testar migrações do Backstage em uma cópia isolada antes de alterar o banco de dados de produção.

A segunda parte colocou o banco de dados operacional sob o Unity Catalog, a camada de governança da Databricks para ativos de dados e IA. Essa etapa tornou o banco de dados do Backstage visível pelo mesmo plano de controle usado para dados analíticos.

A terceira parte aplica essas mudanças anteriores a FinOps. Sua consulta central combina registros do Backstage com a tabela de cobrança do sistema da Databricks.

No lado do Backstage, é usada a tabela final_entities, que contém os registros de entidades processadas pelo catálogo. Cada entidade relevante inclui uma anotação databricks/project-id que identifica seu projeto Lakebase.

No lado da cobrança, é usada a tabela system.billing.usage, que registra o consumo faturável da Databricks. A consulta associa a anotação do catálogo a usage_metadata.project_id e filtra o uso do Lakebase.

O exemplo publicado agrupa o consumo por nome do recurso no Backstage, ID do projeto Lakebase e data. Sua saída de exemplo atribui 39,8667 DBUs em 8 de abril de 2026 e 43,6231 DBUs em 7 de abril.

Uma DBU, ou Databricks Unit, é uma medida normalizada usada para representar o consumo de processamento da plataforma. A consulta informa DBUs, e não uma cobrança final em moeda.

Essa distinção é importante. A demonstração prova que o uso pode ser atribuído a um recurso catalogado. Ela não estabelece um modelo contábil completo para todos os descontos, compromissos, ajustes ou despesas compartilhadas.

Ainda assim, ela encurta uma investigação comum em FinOps. Um analista não precisa mais solicitar uma exportação de responsáveis por serviços antes de compará-la aos dados de cobrança do data warehouse.

O resultado também conecta informações de custo ao lugar onde os desenvolvedores já descobrem serviços. Isso cria um caminho para visões de custos organizadas por sistemas, equipes ou produtos, em vez de apenas por nomes de recursos de nuvem.

A série, portanto, termina em um ponto diferente daquele em que começou. O branching de banco de dados melhorou um fluxo de trabalho de engenharia. A governança unificada então tornou o estado operacional consultável. A etapa final transforma essas mudanças técnicas em um mecanismo de relatórios organizacionais.

Por Que Uma Consulta Muda o Papel da Equipe de Plataforma

A mudança importante não é um SQL mais curto; é a eliminação de uma negociação recorrente entre as equipes de plataforma, dados e finanças.

Um portal interno de desenvolvedores típico responde a perguntas como quem é responsável por um serviço, qual repositório o contém e qual infraestrutura o sustenta. Um sistema de cobrança responde quanto consumo medido um recurso gerou.

Essas respostas frequentemente usam identificadores incompatíveis. Um desenvolvedor reconhece um serviço chamado checkout-api, enquanto uma fatura de nuvem apresenta uma conta, projeto, cluster ou ID de recurso opaco.

As equipes de FinOps lidam com essa incompatibilidade usando tags, regras de alocação, modelos de relatórios e revisão manual. O FinOps Framework trata a alocação como uma capacidade essencial porque custos não alocados enfraquecem a responsabilização e as previsões.

O Backstage oferece uma possível camada de propriedade para esse processo. Seu catálogo já associa entidades de software a equipes e infraestrutura. O desafio é conectar essas associações aos registros de cobrança de maneira confiável.

O experimento da Databricks coloca essa conexão dentro da plataforma de dados. O Lakehouse Federation, uma capacidade de consultar fontes externas ou operacionais sem ingestão convencional, expõe o catálogo ativo do Backstage ao lado dos dados de cobrança do sistema.

Essa abordagem reduz a necessidade de um pipeline dedicado que copie registros de propriedade para um data warehouse. Ela também evita esperar a próxima execução agendada desse pipeline antes de resolver uma questão de custo.

A computação separada é central para a proposta. O Lakebase pode atender às solicitações transacionais do Backstage enquanto outro recurso de computação executa consultas analíticas sobre dados relacionados.

A Databricks descreve o Lakebase Postgres como compatível com escalonamento automático, operação scale-to-zero, branches, réplicas de leitura e restauração instantânea. Ele também se integra ao Unity Catalog e ao Databricks Apps.

A arquitetura busca proteger o portal da carga de trabalho dos analistas. Uma grande agregação não deve competir diretamente com as solicitações interativas do Backstage apenas porque ambas se referem ao mesmo estado subjacente.

Essa separação muda o que as equipes de plataforma podem oferecer. Elas podem tratar propriedade e consumo como duas visões do mesmo grafo de recursos, em vez de dois conjuntos de dados conectados após várias transferências.

Analistas de FinOps ganham uma rota direta do custo ao responsável. Engenheiros de plataforma ganham evidências sobre quais serviços internos consomem capacidade do Lakebase. Líderes de engenharia ganham uma possível base para relatórios no nível das equipes.

Os desenvolvedores também enfrentam uma responsabilização mais visível. Uma entrada de catálogo deixa de ser apenas documentação quando seus identificadores determinam para onde o consumo de infraestrutura é atribuído.

Essa mudança pressiona as equipes de plataforma a melhorar a qualidade do catálogo. Elas precisam decidir quais anotações são obrigatórias, como os identificadores são validados e o que acontece quando recursos mudam de responsável.

As equipes de dados enfrentam uma mudança relacionada. Elas continuam responsáveis pelo acesso governado e pela semântica de cobrança, mas não precisam mais controlar todos os pipelines de integração que conectam metadados operacionais a registros analíticos.

As equipes de FinOps também precisam se adaptar. O acesso mais rápido não elimina a necessidade de definir políticas de alocação. Ele permite aplicá-las mais perto do modelo operacional atual.

O retorno é, portanto, uma divisão de trabalho alterada. A engenharia de plataforma mantém um grafo de propriedade confiável, a plataforma de dados fornece joins governados e FinOps define como o consumo se transforma em responsabilização.

Esse arranjo é atraente porque elimina a espera. É exigente porque erros no grafo de propriedade agora fluem diretamente para os relatórios financeiros.

O Mecanismo É Federação, Não Um Novo Banco de Dados de Custos

A Databricks apresenta a federação como uma alternativa à cópia de dados operacionais do catálogo para outro repositório de relatórios de custos.

A consulta central começa com a tabela de entidades processadas do Backstage. O Backstage cria essa representação após ingerir e normalizar definições de catálogo de fontes como arquivos YAML, plugins ou sistemas externos.

O catálogo de software trata entidades como registros de metadados que descrevem componentes, sistemas, APIs, recursos, grupos e usuários. As relações conectam essas entidades em um grafo de propriedade e dependências.

Para o experimento, um recurso do Backstage contém o identificador do projeto Lakebase em uma anotação. A consulta SQL extrai esse identificador do documento JSON da entidade.

Em seguida, ela associa o identificador aos metadados de projeto da tabela de cobrança. O agrupamento por recurso, projeto e dia produz um resultado de atribuição que as pessoas conseguem entender.

Esse mecanismo tem três propriedades significativas.

Primeiro, o registro operacional permanece operacional. O Backstage continua usando PostgreSQL para sua atividade normal de catálogo, em vez de esperar que uma réplica analítica aceite atualizações.

Segundo, o registro de cobrança permanece na tabela de sistema da Databricks. A demonstração não exige uma exportação personalizada antes que os analistas possam utilizá-lo.

Terceiro, o join ocorre por meio de um ambiente de consulta governado. O Unity Catalog pode controlar a descoberta e o acesso entre os objetos participantes.

A Databricks chama isso de movimentação zero de dados. Mais precisamente, o usuário não cria um pipeline separado para materializar outro conjunto de dados unido antes de executar a análise.

A execução da consulta ainda transfere solicitações e resultados pelas interfaces relevantes. A federação também depende de conectores, credenciais, metadados e controles de desempenho.

Essa nuance não elimina a vantagem. Ela esclarece para onde vai a complexidade depois que um pipeline de ETL desaparece.

Pipelines tradicionais expressam mapeamentos em código de transformação. O design federado expressa um mapeamento crítico por meio de uma anotação inserida na entidade do Backstage.

O mapeamento se torna mais fácil de visualizar, mas também mais fácil de ignorar. Se a anotação estiver ausente ou incorreta, a consulta perde a conexão entre recurso e responsável.

Uma implementação madura validaria essa anotação durante a ingestão do catálogo. Ela poderia rejeitar identificadores de projeto malformados ou sinalizar entidades que referenciam projetos Lakebase inexistentes.

As equipes também precisariam de regras de ciclo de vida. Um serviço excluído, uma aplicação transferida ou um projeto renomeado podem criar questões de atribuição histórica que um snapshot atual do catálogo não consegue responder sozinho.

A propriedade em um momento específico torna-se especialmente importante para o chargeback. O responsável de hoje não deve herdar automaticamente o consumo gerado antes de uma transferência de serviço.

O agrupamento diário da demonstração fornece um ponto de partida, mas a alocação histórica exige um histórico durável de propriedade. As equipes podem reter alterações do catálogo, snapshots de cobrança ou uma tabela de mapeamento com vigência definida.

O controle de acesso acrescenta outra decisão de design. Engenheiros podem precisar de visibilidade sobre seus próprios serviços sem receber acesso irrestrito aos registros de cobrança de toda a empresa.

O Unity Catalog pode ajudar a definir privilégios, mas cada organização deve estabelecer o nível de granularidade correto. Visões delimitadas por equipe podem ser mais seguras do que conceder amplo acesso à tabela de sistema subjacente.

O desempenho também merece atenção. A consulta de exemplo é compacta, mas catálogos Backstage em produção podem conter muitas entidades e grandes registros JSON.

A extração repetida de JSON pode se tornar ineficiente em escala. As equipes podem expor anotações selecionadas por meio de uma visualização curada, mantendo o catálogo de origem intacto.

Essa otimização ainda preservaria o modelo mais amplo. A diferença é que uma camada semântica governada ficaria sobre os dados operacionais ativos, em vez de um pipeline de exportação desconectado.

A arquitetura de databricks backstage não elimina, portanto, a engenharia de dados. Ela concentra o trabalho de engenharia em contratos de metadados, políticas de acesso e interfaces de consulta.

Esse é um lugar mais estratégico para esse trabalho, desde que a organização aceite uma disciplina mais rígida para o catálogo.

O Verdadeiro Oponente É a Transferência para ETL

O experimento desafia um modelo de integração orientado a pipelines, não concorrentes do PostgreSQL ou outros portais para desenvolvedores.

Tradicionalmente, as equipes separam o processamento de transações online do processamento analítico online. Sistemas transacionais priorizam gravações frequentes e de baixa latência, enquanto sistemas analíticos examinam e agregam conjuntos de dados muito maiores.

Essa separação gerou dois domínios operacionais. As equipes de aplicações mantinham bancos de dados como PostgreSQL, enquanto as equipes de dados copiavam registros selecionados para data warehouses ou lakehouses.

A arquitetura fazia sentido porque os sistemas tinham layouts de armazenamento, modelos de escalabilidade e preocupações de falha distintos. Consultas analíticas diretas poderiam comprometer o desempenho das aplicações.

Plataformas modernas de nuvem separam cada vez mais armazenamento, computação e governança. Isso torna alguns dados acessíveis por múltiplos caminhos de computação específicos para cada carga de trabalho.

Lakebase se insere nessa tendência. Databricks o posiciona como PostgreSQL gerenciado para aplicações transacionais que também precisam de proximidade com dados de lakehouse.

O experimento com Backstage usa essa proximidade para evitar uma exportação especializada de propriedade. A principal alternativa não é outro fornecedor de Postgres. É o processo conhecido de extrair registros de catálogo, transformar identificadores e carregá-los em um modelo de relatórios.

ETL mantém vantagens importantes. Um conjunto de dados materializado pode oferecer desempenho previsível, snapshots duráveis, verificações de qualidade e isolamento de alterações no esquema da fonte.

Ele também pode padronizar dados de vários portais ou provedores de nuvem. Uma consulta federada contra um banco de dados Backstage pode não abranger uma empresa com múltiplos catálogos e ambientes de faturamento.

O custo do ETL aparece na latência e na responsabilidade. Alguém precisa agendar o pipeline, monitorar falhas, atualizar esquemas, reconciliar mapeamentos e responder quando os usuários desconfiam de sua saída.

Essas responsabilidades frequentemente ficam entre equipes. A engenharia de plataforma entende o catálogo de serviços, a engenharia de dados é responsável pelo warehouse e FinOps entende o modelo de alocação.

Uma abordagem que prioriza federação remove algumas cópias e agendamentos. Ela disponibiliza a fonte ativa, mas aumenta a dependência de sua disponibilidade, esquema, qualidade de metadados e comportamento de consulta.

Essa é a principal troca. O ETL cria distância em relação à fonte e absorve sua instabilidade. A federação oferece dados atualizados e menos cópias, mas mantém os consumidores mais próximos das mudanças operacionais.

A escolha certa depende da decisão que será apoiada. A investigação interativa se beneficia de dados atuais de propriedade. Um chargeback mensal auditado exige histórico estável e regras reproduzíveis.

Um modelo híbrido é provável para organizações maiores. Analistas podem usar uma consulta federada para investigar o uso recente e, em seguida, publicar resultados aprovados de alocação em uma camada durável de relatórios.

Esse modelo não invalidaria a demonstração. Ele usaria a federação para reduzir o atrito exploratório, preservando registros materializados para processos financeiros formais.

Outras plataformas gerenciadas de PostgreSQL também podem participar de arquiteturas federadas. AWS, Google Cloud, Microsoft e provedores independentes de bancos de dados oferecem sistemas transacionais com integrações analíticas.

O próprio Backstage permanece neutro em relação ao banco de dados. Seu suporte a PostgreSQL permite que as organizações escolham a infraestrutura com base em necessidades operacionais, regulatórias e comerciais.

A vantagem da Databricks neste experimento vem da proximidade da plataforma. Lakebase, tabelas de faturamento do sistema, federação e Unity Catalog existem em um único ambiente governado.

Essa conveniência também pode criar risco de concentração. Uma equipe que adota o padrão completo torna-se mais dependente de identificadores, esquemas de faturamento, permissões e serviços de consulta da Databricks.

A pressão competitiva do artigo, portanto, recai sobre stacks internos fragmentados. Fornecedores e equipes de plataforma devem explicar por que ainda é necessário copiar metadados de propriedade quando uma consulta governada pode alcançar a fonte.

No entanto, a Databricks precisa provar que o diagrama mais simples resiste à realidade operacional. Isso inclui escala do catálogo, evolução de esquemas, limites de acesso e exigências de relatórios de fim de mês.

O Que o Resultado de Uma Consulta Não Resolve

Uma prova de conceito bem-sucedida não garante um chargeback empresarial confiável, pois a correção da consulta depende de metadados organizacionais externos ao sistema de faturamento.

O resultado de exemplo mostra que um recurso Backstage pode ser associado ao uso do Lakebase. Ele não mostra quanto da infraestrutura de uma grande organização pode ser alocado dessa forma.

A cobertura é a primeira questão sem resposta. As equipes precisam saber que porcentagem dos projetos Lakebase relevantes possui uma entidade Backstage válida e uma anotação de projeto.

Um resultado pode estar tecnicamente correto e ainda assim ser financeiramente incompleto. Projetos não catalogados simplesmente desaparecem de uma consulta focada em propriedade, a menos que os analistas os identifiquem separadamente.

A precisão é a segunda questão. Um ID de projeto válido ainda pode apontar para o serviço errado, um proprietário desatualizado ou um recurso compartilhado que atende a vários produtos.

A infraestrutura compartilhada complica a atribuição porque um projeto pode atender a várias equipes. Uma única anotação Backstage não consegue expressar todas as regras de alocação proporcional.

A semântica de faturamento cria uma terceira limitação. DBUs representam consumo, mas uma visão completa de custos pode exigir cobranças de infraestrutura em nuvem, créditos, compromissos, impostos e ajustes organizacionais.

A equipe de FinOps deve decidir se a consulta serve para showback, chargeback, investigação de anomalias ou planejamento de capacidade. Essas finalidades exigem diferentes níveis de precisão.

A propriedade histórica é outra questão não resolvida. O catálogo ativo descreve o estado atual de maneira mais natural do que a responsabilidade passada.

Uma transferência de serviço em 15 de abril não deveria necessariamente reescrever quem era responsável pelo consumo de 7 de abril. Relatórios históricos confiáveis exigem registros de propriedade sensíveis ao tempo.

A estabilidade do esquema também importa. A consulta acessa uma entidade JSON e depende de um nome específico de anotação. As equipes devem gerenciar esse campo como um contrato suportado.

Plugins do Backstage, processadores de catálogo e convenções organizacionais podem alterar a estrutura das entidades. A Databricks também pode evoluir os metadados de faturamento à medida que Lakebase se desenvolve.

Usuários de produção devem testar esses contratos automaticamente. Um trabalho de validação pode identificar anotações ausentes, projetos desconhecidos, atribuições duplicadas e uso sem proprietário.

A segurança apresenta uma pressão diferente. Os metadados do Backstage podem revelar sistemas internos e estruturas de equipe, enquanto os dados de faturamento podem expor padrões sensíveis de consumo.

Combinar ambos os conjuntos de dados aumenta as informações disponíveis em uma única consulta. Isso é útil para análise, mas aumenta o impacto de permissões excessivamente amplas.

As organizações precisam de limites em nível de linha ou de visualização que correspondam ao seu modelo operacional. Um proprietário de serviço pode precisar ver o uso de uma equipe, enquanto a FinOps central precisa de cobertura empresarial.

A dependência operacional também permanece. A análise federada depende da disponibilidade do banco de dados de origem, do serviço de consulta, da configuração de identidade e da camada de governança.

A Databricks afirma que Lakebase isola a computação para diferentes cargas de trabalho. Evidências independentes em produção continuarão sendo importantes para latência, concorrência, recuperação de falhas e desempenho analítico previsível.

A série original também encontrou uma complicação de autenticação. Lakebase esperava uma credencial OAuth com escopo, em vez de um token clássico de acesso pessoal da Databricks.

Para a prova de conceito, a equipe renovou uma credencial de curta duração por meio de um script. Implantações em produção precisam de um processo de rotação suportado que evite armazenar tokens renovados em locais inseguros.

Databricks Apps pode criar uma função PostgreSQL para uma service principal de aplicação quando as equipes anexam um recurso Lakebase. Esse caminho gerenciado é mais adequado do que um ciclo improvisado de renovação local.

A lição mais ampla não é que a federação elimina o trabalho de governança. Ela torna a governança visível no momento em que um usuário faz uma pergunta de negócio.

O padrão de databricks backstage terá sucesso apenas quando a completude do catálogo se tornar uma métrica operacional. Sem essa disciplina, FinOps com uma única consulta pode produzir respostas rápidas, mas parciais.

Três Sinais Mostrarão se o Padrão se Sustenta

A próxima fase precisa medir adoção, cobertura de alocação e confiabilidade em produção, em vez de celebrar uma instrução SQL compacta.

O primeiro sinal é uma implementação reutilizável da Databricks, Thoughtworks ou da comunidade Backstage. As equipes devem acompanhar processadores de catálogo mantidos, regras de validação, dashboards ou modelos que apoiem esse padrão.

Um pacote suportado reforçaria o argumento de que essa arquitetura pode ir além de uma demonstração personalizada. Ele deveria definir esquemas de anotação, tratamento de credenciais, permissões e práticas de implantação.

A ausência de componentes reutilizáveis enfraqueceria a alegação. Cada adotante precisaria recriar de forma independente os mapeamentos e controles mais propensos a falhas.

O segundo sinal é a cobertura de alocação em catálogos reais. A métrica útil é a porcentagem do uso de Lakebase vinculada a uma entidade e proprietário Backstage atuais e validados.

Uma cobertura elevada em ambientes de produção em constante mudança apoiaria a federação como uma entrada prática para FinOps. O uso persistentemente não alocado mostraria que a manutenção de metadados continua sendo a principal restrição.

A cobertura deve ser acompanhada de métricas de atualização e contagem de exceções. As equipes precisam saber com que rapidez novos projetos aparecem e com que frequência os mapeamentos falham na validação.

O terceiro sinal é o comportamento em produção sob cargas de trabalho mistas. As organizações devem medir a latência do Backstage enquanto analistas executam consultas federadas de faturamento contra grandes catálogos.

Um desempenho estável do portal reforçaria o argumento da Databricks sobre computação separada. Interrupções de consulta, falhas de credenciais ou gargalos de governança favoreceriam camadas materializadas de relatórios para fluxos de trabalho críticos.

O estudo de caso de uma consulta oferece uma hipótese clara: governança compartilhada e computação isolada podem reconectar a propriedade operacional aos dados analíticos de custo.

Agora as equipes precisam de evidências sobre como essa hipótese se comporta em múltiplas contas, recursos compartilhados, transferências de serviço e controles financeiros formais.

Para desenvolvedores, a ação imediata é simples. Tratem as anotações de catálogo como dados de produção, validem identificadores de infraestrutura e definam explicitamente mudanças de propriedade.

Para líderes de plataforma, perguntem se o pipeline de custos existente atende a uma necessidade atual ou a uma restrição arquitetural antiga. A federação pode encurtar investigações mesmo quando os relatórios oficiais permanecem materializados.

Para equipes de FinOps, testem a consulta de databricks backstage em relação a alocações conhecidas antes de ampliá-la. A pergunta importante não é se uma consulta é executada. É se sua resposta permanece completa, explicável e reproduzível quando a organização muda.