Nos bastidores com o Lakebase, parte 3

Na primeira parte desta série, executar o Backstage no Databricks Lakebase nos deu ramificação de banco de dados de um segundo. Enquanto isso, na parte dois, o Unity Catalog absorveu esse banco de dados operacional no plano de governança corporativa.

Mas aqui está o retorno que realmente muda o organograma.

Em uma stack normal, responder a 'quem é o proprietário da infraestrutura que está aumentando nossos gastos na nuvem e quanto isso custou?' cruza duas fronteiras. O gráfico de propriedade reside no Backstage (de responsabilidade da engenharia de plataforma), enquanto os dados de custo residem em um data warehouse (governado pela equipe de dados). Responder a essa pergunta exige um pipeline de ETL, um ticket do Jira ou uma conversa no Slack.

Computação separada torna o compartilhamento viável

O motivo pelo qual um analista de FinOps pode executar consultas analíticas massivas no exato mesmo armazenamento subjacente sem impactar o portal ativo é que o Lakebase isola a computação por carga de trabalho.

O Backstage ganha seu próprio envelope de computação isolado e com escalonamento automático. Durante o uso normal do portal, as consultas de catálogo rodaram em 55–65 ms de ponta a ponta, e as buscas levaram de dois a quatro milissegundos. Como sua aplicação web e suas cargas de trabalho analíticas não estão disputando o mesmo cluster de computação, elas podem finalmente compartilhar com segurança o mesmo substrato de dados.

A solução alternativa: autenticação do Lakehouse Federation

Para fazer a junção dos dados em tempo real do Postgres com nossos dados analíticos de faturamento, usamos o Databricks Lakehouse Federation. No entanto, o conector Postgres do Lakehouse Federation atualmente suporta apenas credenciais estáticas de usuário/senha. Como o Lakebase autentica identidades de aplicativos por meio de JWTs OAuth, o mecanismo de federação precisa de um caminho de autenticação paralelo.

A solução alternativa é criar uma role nativa do Postgres com autenticação SCRAM-SHA-256, conectada à federação separadamente da identidade OAuth que o aplicativo usa:

Agora você está gerenciando dois caminhos de autenticação para o mesmo banco de dados.

O join de FinOps

Com o catálogo externo ativo, um analista de FinOps pode escrever uma única consulta que extrai o nome do recurso do Backstage diretamente da tabela operacional do Postgres e o junta às próprias linhas de faturamento do Lakebase em system.billing.usage:

Resultado real:

O lado esquerdo dessa linha vem diretamente de dentro do catálogo ativo do Postgres no Backstage; o lado direito vem de uma tabela de faturamento do sistema do Unity Catalog. Historicamente, essas duas coisas nunca estiveram no mesmo mecanismo SQL e, agora, elas se juntam com zero movimentação de dados.

Por que não usar apenas ETL?

Um cético poderia perguntar por que não usamos apenas um script em Python para sincronizar uma instância do RDS com uma tabela Delta uma vez por hora.

A resposta é a ramificação. Quando um desenvolvedor cria um clone de banco de dados efêmero de 1 segundo para testar um PR, você teria que provisionar dinamicamente novos pipelines de ETL apenas para obter visibilidade de custos nesse ambiente de teste temporário. Com o Lakebase, no momento em que a branch é criada, seus dados de faturamento e propriedade ficam instantaneamente disponíveis para consulta. (Nesta POC, a branch de teste descartada foi atribuída de forma automática e independente a 0.0107 DBU).

Operacionalizando a convergência

Esta série de três partes começou com uma ramificação de banco de dados de 1 segundo, passou pela governança unificada e chegou aqui — uma única consulta SQL que junta dados de propriedade operacional a dados de faturamento na nuvem com zero pipelines entre eles. Essa é a prova de que a convergência funciona tecnicamente. A pergunta que os profissionais farão a seguir é: o que é necessário para operacionalizar isso?

Duas coisas se destacaram nesta POC que vale a pena destacar para as equipes que planejam seguir esse caminho.

A lacuna de autenticação da federação

A solução alternativa do Lakehouse Federation que descrevemos – uma role nativa do Postgres com credenciais estáticas conectadas separadamente da identidade OAuth que o aplicativo usa – é a abordagem correta hoje. Toda equipe que deseja juntar seus dados operacionais do Lakebase com tabelas analíticas no Unity Catalog precisará configurar esse caminho de autenticação paralelo. De qualquer forma, a federação provavelmente não deveria ser executada como o usuário do seu aplicativo, então a separação traz uma vantagem de segurança, mas a rotação de senhas fica por sua conta. Para as equipes que adotam esse padrão, as etapas podem ser empacotadas em um script reutilizável – gerar uma senha segura, criar a role com permissões de apenas leitura, conectar a conexão, criar o catálogo externo. Configuração única, que leva minutos depois que você conhece o padrão. O suporte nativo a JWTs OAuth no Federation eliminaria completamente essa solução alternativa.

Visibilidade de custo de branch para equipes de desenvolvimento

O join de FinOps responde à pergunta da plataforma: quanto custa essa infraestrutura e quem é o proprietário dela? Mas os mesmos dados de faturamento contam uma segunda história que importa para os gerentes de engenharia: quanto custa o próprio processo de desenvolvimento?

No fluxo de trabalho de ramificação da parte um, cada pull request cria uma branch de CI efêmera e cada desenvolvedor tem sua própria feature branch. Elas aparecem como itens de linha independentes em system.billing.usage, detalhados por branch_id and endpoint_id. Um gerente de engenharia pode ver exatamente quanta computação a ramificação de dev/teste de sua equipe consumiu em um sprint em comparação com a produção — e tomar decisões informadas sobre as políticas de ciclo de vida das branches.

O ponto principal é que as branches efêmeras também devem ser tratadas como efêmeras nos dados de faturamento. As branches de CI criadas com um TTL curto expiram automaticamente se a limpeza falhar por qualquer motivo – um push direto para a main, um erro de fluxo de trabalho, um evento perdido. Sem controles de ciclo de vida, as branches órfãs podem se acumular silenciosamente, cada uma com um endpoint de computação ativo gerando cobranças contra o projeto. A branch de teste custou 0.0107 DBU. Isso é insignificante. Trinta branches órfãs rodando por um mês não são.

O ponto não é que a ramificação seja cara – é uma relação de custo versus ganho de produtividade. Quando uma equipe elimina dois dias de tempo de espera do ambiente por sprint e deixa de manter de 20% a 30% de sua base de código em objetos mock, os 0.0107 DBU por branch não são um item de linha a ser gerenciado – é o investimento em produtividade mais barato que a equipe já fez. E, ao contrário da maioria dos investimentos em produtividade, este é mensurável: a infraestrutura diz exatamente quanto custou, por branch, por desenvolvedor, por sprint. Essa é uma conversa que a maioria das equipes de engenharia nunca pôde ter com seu banco de dados.

O que vem a seguir

Antes de encerrarmos, há mais um ponto na história de FinOps que deve ser destacado. Os endpoints do Lakebase escalam para zero. Quando uma branch não está sendo consultada, sua computação é suspensa e a cobrança para. O valor de 0.0107 DBU é o custo de uma branch que rodou, não o custo de uma branch que existe; uma frota de branches efêmeras ociosas entre as execuções de teste não contribui em nada.

Ao longo desta série, provamos que a infraestrutura funciona – aplicativo real, benchmarks reais, governança real, dados de custo reais. Do nosso lado, a Databricks e a Thoughtworks estão trabalhando juntas para levar isso da POC para a prática: equipes de desenvolvimento reais, sprints reais, medições de velocidade reais. A restrição que manteve os dados operacionais e analíticos em mundos separados por trinta anos está se desfazendo.

Há um aprendizado prático para cada parte desta série. Crie um branch para sua próxima migração em um esquema real. Reescreva uma suíte com muitos mocks em relação a um branch. Combine seus dados de faturamento com seu gráfico de propriedade. As equipes que derem o primeiro passo definirão o que vem a seguir.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original