Databricks Backstage trasforma FinOps in una sola query, ma la parte difficile si sposta a monte

Databricks ha completato un esperimento Backstage in tre parti con un risultato notevole: una singola query può collegare la responsabilità dell'infrastruttura al consumo giornaliero di Lakebase. Il progetto databricks backstage rimuove una barriera di integrazione che solitamente separa il platform engineering da FinOps. Tuttavia, evidenzia anche una dipendenza più complessa da metadati di servizio accurati.

La dimostrazione unisce il catalogo software live di Backstage ai record di fatturazione Databricks senza prima spostare entrambi i dataset in un sistema di reporting separato. Un analista FinOps può identificare una risorsa Lakebase, trovarne il proprietario e analizzarne l'utilizzo tramite una sola istruzione SQL.

Questo è più rilevante di un'altra integrazione con una dashboard. Backstage normalmente conserva i dati sulla responsabilità operativa, mentre un data warehouse contiene i record dei costi. I team collegano questi sistemi tramite job ETL, esportazioni, ticket e mappature gestite manualmente.

Il nuovo approccio sostituisce gran parte di questi spostamenti con la federazione, che interroga dati tra sistemi diversi attraverso un livello SQL condiviso. Tuttavia, non elimina il lavoro organizzativo alla base dell'addebito dei costi. Lo trasferisce invece in annotazioni del catalogo, identificatori delle risorse, controlli di accesso e semantica di fatturazione.

L'esperimento Databricks Backstage raggiunge il suo obiettivo FinOps

Il terzo esperimento trasforma il grafo di responsabilità di Backstage in un punto di accesso diretto per l'analisi dei costi cloud.

Databricks e Thoughtworks hanno utilizzato Backstage, il portale interno per sviluppatori open source di Spotify, come applicazione operativa per l'intera serie. Backstage gestisce un catalogo software che contiene servizi, componenti, proprietari, dipendenze e riferimenti all'infrastruttura.

I team hanno spostato lo stato PostgreSQL del portale in Lakebase, il servizio Postgres gestito di Databricks. Lakebase separa lo storage dal calcolo e integra i dati transazionali con l'ecosistema Databricks più ampio.

La prima parte si è concentrata sul branching del database. Secondo gli autori, Lakebase ha creato un branch del database in circa un secondo. Ciò ha reso pratico testare le migrazioni di Backstage su una copia isolata prima di modificare il database di produzione.

La seconda parte ha portato il database operativo sotto Unity Catalog, il livello di governance di Databricks per risorse di dati e IA. Questo passaggio ha reso il database Backstage visibile attraverso lo stesso piano di controllo utilizzato per i dati analitici.

La terza puntata applica questi cambiamenti precedenti a FinOps. La sua query centrale combina record di Backstage con la tabella di sistema per la fatturazione di Databricks.

Il lato Backstage utilizza final_entities, una tabella che contiene i record delle entità elaborate dal catalogo. Ogni entità rilevante include un'annotazione databricks/project-id che identifica il relativo progetto Lakebase.

Il lato della fatturazione utilizza system.billing.usage, che registra il consumo Databricks fatturabile. La query abbina l'annotazione del catalogo a usage_metadata.project_id, quindi filtra l'utilizzo Lakebase.

L'esempio pubblicato raggruppa il consumo per nome della risorsa Backstage, ID del progetto Lakebase e data. Il suo output di esempio attribuisce 39.8667 DBU l'8 aprile 2026 e 43.6231 DBU il 7 aprile.

Un DBU, o Databricks Unit, è una misura normalizzata utilizzata per rappresentare il consumo di elaborazione della piattaforma. La query riporta DBU anziché un addebito finale in valuta.

Questa distinzione è importante. La dimostrazione prova che l'utilizzo può essere attribuito a una risorsa catalogata. Non definisce un modello contabile completo per ogni sconto, impegno, rettifica o spesa condivisa.

Ciononostante, accorcia una tipica indagine FinOps. Un analista non deve più richiedere un'esportazione dei proprietari dei servizi prima di confrontarla con i dati di fatturazione del warehouse.

Il risultato collega inoltre le informazioni sui costi al luogo in cui gli sviluppatori scoprono già i servizi. Questo crea un percorso verso viste dei costi organizzate per sistemi, team o prodotti, anziché basate soltanto sui nomi delle risorse cloud.

La serie termina quindi in un punto diverso da quello di partenza. Il branching del database ha migliorato un flusso di lavoro ingegneristico. La governance unificata ha poi reso lo stato operativo interrogabile. Il passaggio finale converte questi cambiamenti tecnici in un meccanismo di reporting organizzativo.

Perché una sola query cambia il ruolo del team di piattaforma

Il cambiamento importante non è una SQL più breve; è l'eliminazione di una negoziazione ricorrente tra team di piattaforma, dati e finanza.

Un tipico portale interno per sviluppatori risponde a domande come chi possiede un servizio, quale repository lo contiene e quale infrastruttura lo supporta. Un sistema di fatturazione indica invece quanto consumo misurato abbia generato una risorsa.

Spesso queste risposte utilizzano identificatori incompatibili. Uno sviluppatore riconosce un servizio chiamato checkout-api, mentre una fattura cloud espone un account, un progetto, un cluster o un ID di risorsa opaco.

I team FinOps affrontano questa discrepanza con tag, regole di allocazione, modelli di reporting e revisioni manuali. Il FinOps Framework considera l'allocazione una capacità fondamentale, poiché i costi non allocati indeboliscono responsabilità e previsioni.

Backstage offre un potenziale livello di responsabilità per questo processo. Il suo catalogo associa già entità software a team e infrastruttura. La sfida consiste nel collegare queste associazioni ai record di fatturazione in modo affidabile.

L'esperimento Databricks porta il collegamento all'interno della piattaforma dati. Lakehouse Federation, una funzionalità per interrogare fonti esterne o operative senza ingestione convenzionale, espone il catalogo Backstage live accanto ai dati di fatturazione di sistema.

Questo approccio riduce la necessità di una pipeline dedicata che copi i record di responsabilità in un warehouse. Evita inoltre di attendere la successiva esecuzione pianificata della pipeline prima di risolvere una questione di costo.

La separazione del calcolo è centrale nella proposta. Lakebase può gestire le richieste transazionali di Backstage mentre un'altra risorsa di calcolo esegue query analitiche sui dati correlati.

Databricks descrive Lakebase Postgres come dotato di autoscaling, funzionamento scale-to-zero, branch, repliche di lettura e ripristino istantaneo. Si integra inoltre con Unity Catalog e Databricks Apps.

L'architettura mira a proteggere il portale dal carico di lavoro dell'analista. Un'aggregazione di grandi dimensioni non dovrebbe competere direttamente con le richieste interattive di Backstage solo perché entrambe fanno riferimento allo stesso stato sottostante.

Questa separazione cambia ciò che i team di piattaforma possono offrire. Possono trattare responsabilità e consumo come due viste dello stesso grafo di risorse, anziché come due dataset collegati dopo diversi passaggi di consegna.

Gli analisti FinOps ottengono un percorso diretto dal costo al proprietario responsabile. Gli ingegneri di piattaforma ottengono evidenze su quali servizi interni consumano capacità Lakebase. I responsabili engineering ottengono una potenziale base per il reporting a livello di team.

Anche gli sviluppatori affrontano una responsabilità più visibile. Una voce di catalogo smette di essere soltanto documentazione quando i suoi identificatori determinano dove viene assegnato il consumo dell'infrastruttura.

Questo cambiamento spinge i team di piattaforma a migliorare la qualità del catalogo. Devono decidere quali annotazioni sono obbligatorie, come validare gli identificatori e cosa accade quando le risorse passano da un proprietario a un altro.

I team dati affrontano un cambiamento correlato. Restano responsabili dell'accesso governato e della semantica di fatturazione, ma non devono più possedere ogni pipeline di integrazione che collega metadati operativi e record analitici.

Anche i team FinOps devono adattarsi. Un accesso più rapido non elimina la necessità di definire politiche di allocazione. Consente loro di applicare tali politiche più vicino al modello operativo corrente.

Il risultato è quindi una diversa divisione del lavoro. Il platform engineering mantiene un grafo di responsabilità affidabile, la piattaforma dati fornisce join governati e FinOps definisce come il consumo diventa responsabilità.

Questo assetto è interessante perché elimina l'attesa. È impegnativo perché gli errori nel grafo di responsabilità confluiscono ora direttamente nel reporting finanziario.

Il meccanismo è la federazione, non un nuovo database dei costi

Databricks presenta la federazione come alternativa alla copia dei dati del catalogo operativo in un altro archivio per il reporting dei costi.

La query principale parte dalla tabella delle entità elaborate di Backstage. Backstage crea questa rappresentazione dopo aver acquisito e normalizzato le definizioni del catalogo da fonti quali file YAML, plugin o sistemi esterni.

Il catalogo software considera le entità come record di metadati che descrivono componenti, sistemi, API, risorse, gruppi e utenti. Le relazioni collegano tali entità in un grafo di responsabilità e dipendenze.

Per l'esperimento, una risorsa Backstage contiene l'identificatore del progetto Lakebase in un'annotazione. La query SQL estrae tale identificatore dal documento JSON dell'entità.

Quindi collega l'identificatore ai metadati del progetto nella tabella di fatturazione. Il raggruppamento per risorsa, progetto e giorno produce un risultato di attribuzione comprensibile alle persone.

Questo meccanismo presenta tre proprietà significative.

Primo, il record operativo resta operativo. Backstage continua a utilizzare PostgreSQL per la normale attività del catalogo invece di attendere che una replica analitica accetti gli aggiornamenti.

Secondo, il record di fatturazione rimane nella tabella di sistema Databricks. La dimostrazione non richiede un'esportazione personalizzata prima che gli analisti possano utilizzarlo.

Terzo, il join avviene attraverso un ambiente di query governato. Unity Catalog può controllare la discovery e l'accesso tra gli oggetti partecipanti.

Databricks definisce questo approccio zero data movement. Più precisamente, l'utente non crea una pipeline separata per materializzare un altro dataset unito prima di eseguire l'analisi.

L'esecuzione della query trasferisce comunque richieste e risultati attraverso le interfacce rilevanti. La federazione dipende inoltre da connettori, credenziali, metadati e controlli delle prestazioni.

Questa precisazione non elimina il vantaggio. Chiarisce dove si sposta la complessità quando una pipeline ETL scompare.

Le pipeline tradizionali esprimono le mappature nel codice di trasformazione. Il design federato esprime una mappatura critica attraverso un'annotazione inserita nell'entità Backstage.

La mappatura diventa più facile da vedere, ma anche più facile da trascurare. Se l'annotazione è assente o errata, la query perde il collegamento tra risorsa e proprietario.

Un'implementazione matura validerebbe tale annotazione durante l'acquisizione nel catalogo. Potrebbe rifiutare identificatori di progetto non validi o segnalare entità che fanno riferimento a progetti Lakebase inesistenti.

I team avrebbero inoltre bisogno di regole per il ciclo di vita. Un servizio eliminato, un'applicazione trasferita o un progetto rinominato possono creare questioni di attribuzione storica a cui l'istantanea corrente del catalogo non può rispondere da sola.

La responsabilità in un determinato momento diventa particolarmente importante per l'addebito dei costi. Il proprietario attuale non dovrebbe ereditare automaticamente il consumo generato prima di un trasferimento del servizio.

Il raggruppamento giornaliero della dimostrazione offre un punto di partenza, ma l'allocazione storica richiede una cronologia durevole della responsabilità. I team potrebbero conservare modifiche al catalogo, snapshot di fatturazione o una tabella di mappatura con date di validità.

Il controllo degli accessi aggiunge un'altra decisione progettuale. Gli ingegneri potrebbero aver bisogno di visibilità sui propri servizi senza ricevere accesso illimitato ai record di fatturazione dell'intera azienda.

Unity Catalog può aiutare a definire i privilegi, ma ogni organizzazione deve stabilire il livello di dettaglio corretto. Le viste per team possono essere più sicure della concessione di un accesso esteso alla tabella di sistema sottostante.

Anche le prestazioni meritano attenzione. La query di esempio è compatta, ma i cataloghi Backstage in produzione possono contenere molte entità e grandi record JSON.

L’estrazione ripetuta dal JSON può diventare inefficiente su larga scala. I team potrebbero esporre annotazioni selezionate tramite una vista curata, lasciando invariato il catalogo di origine.

Questa ottimizzazione preserverebbe comunque il modello più ampio. La differenza è che un livello semantico governato si posizionerebbe sopra i dati operativi live, anziché ricorrere a una pipeline di esportazione disconnessa.

L’architettura databricks backstage non elimina quindi il data engineering. Concentra il lavoro ingegneristico attorno a contratti sui metadati, policy di accesso e interfacce di query.

È una collocazione più strategica per questo lavoro, a condizione che l’organizzazione accetti una disciplina più rigorosa del catalogo.

Il vero avversario è il passaggio ETL

L’esperimento mette in discussione un modello di integrazione incentrato sulla pipeline, non i concorrenti di PostgreSQL o altri portali per sviluppatori.

Tradizionalmente, i team separano l’elaborazione delle transazioni online dall’elaborazione analitica online. I sistemi transazionali danno priorità a scritture frequenti e a bassa latenza, mentre quelli analitici eseguono scansioni e aggregazioni su dataset molto più grandi.

Questa separazione ha prodotto due domini operativi. I team applicativi gestivano database come PostgreSQL, mentre i team dati copiavano record selezionati in data warehouse o lakehouse.

L’architettura era sensata perché i sistemi avevano layout di archiviazione, modelli di scalabilità e problematiche di resilienza diversi. Le query analitiche dirette potevano minacciare le prestazioni delle applicazioni.

Le moderne piattaforme cloud separano sempre più storage, calcolo e governance. Ciò rende alcuni dati accessibili attraverso più percorsi di calcolo specifici per carico di lavoro.

Lakebase si inserisce in questa tendenza. Databricks lo presenta come PostgreSQL gestito per applicazioni transazionali che necessitano anche della vicinanza ai dati del lakehouse.

L’esperimento Backstage sfrutta questa vicinanza per evitare un’esportazione specializzata delle responsabilità. L’alternativa principale non è un altro fornitore Postgres. È il processo consolidato di estrarre record dal catalogo, trasformare gli identificatori e caricarli in un modello di reporting.

L’ETL conserva vantaggi importanti. Un dataset materializzato può offrire prestazioni prevedibili, snapshot durevoli, controlli di qualità e isolamento dalle modifiche allo schema sorgente.

Può inoltre standardizzare i dati provenienti da più portali o provider cloud. Una query federata su un singolo database Backstage potrebbe non coprire un’azienda con più cataloghi e ambienti di fatturazione.

Il costo dell’ETL emerge in termini di latenza e responsabilità. Qualcuno deve pianificare la pipeline, monitorare gli errori, aggiornare gli schemi, riconciliare le mappature e intervenire quando gli utenti non si fidano dei suoi risultati.

Queste responsabilità spesso ricadono tra un team e l’altro. Il platform engineering comprende il catalogo dei servizi, il data engineering gestisce il warehouse e il FinOps comprende il modello di allocazione.

Un approccio federation-first elimina alcune copie e pianificazioni. Rende disponibile la fonte live, ma aumenta la dipendenza dalla sua disponibilità, dallo schema, dalla qualità dei metadati e dal comportamento delle query.

Questo è il compromesso centrale. L’ETL crea distanza dalla fonte e assorbe la sua instabilità. La federazione offre dati più freschi e meno copie, ma mantiene i consumatori più vicini ai cambiamenti operativi.

La scelta giusta dipende dalla decisione da supportare. L’analisi interattiva beneficia di dati di responsabilità aggiornati. Un chargeback mensile sottoposto ad audit richiede una cronologia stabile e regole riproducibili.

Per le organizzazioni più grandi è probabile un modello ibrido. Gli analisti possono utilizzare una query federata per indagare sull’utilizzo recente, quindi pubblicare risultati di allocazione approvati in un livello di reporting durevole.

Questo modello non invaliderebbe la dimostrazione. Utilizzerebbe la federazione per ridurre l’attrito esplorativo, preservando al tempo stesso record materializzati per processi finanziari formali.

Anche altre piattaforme PostgreSQL gestite possono partecipare ad architetture federate. AWS, Google Cloud, Microsoft e provider di database indipendenti offrono sistemi transazionali con integrazioni analitiche.

Backstage stesso resta indipendente dal database. Il suo supporto a PostgreSQL consente alle organizzazioni di scegliere l’infrastruttura in base a esigenze operative, normative e commerciali.

Il vantaggio di Databricks in questo esperimento deriva dalla vicinanza della piattaforma. Lakebase, le tabelle di fatturazione di sistema, la federazione e Unity Catalog esistono in un unico ambiente governato.

Questa comodità può anche creare un rischio di concentrazione. Un team che adotta l’intero modello diventa più dipendente da identificatori, schemi di fatturazione, autorizzazioni e servizi di query Databricks.

La pressione competitiva dell’articolo ricade quindi sugli stack interni frammentati. Fornitori e team di piattaforma devono spiegare perché copiare i metadati di responsabilità resti necessario quando una query governata può raggiungere la fonte.

Tuttavia, Databricks deve dimostrare che il diagramma più semplice resiste alla realtà operativa. Ciò include scala del catalogo, evoluzione dello schema, confini di accesso e requisiti di reporting di fine mese.

Cosa non dimostra il risultato con una sola query

Un proof of concept riuscito non garantisce un chargeback aziendale affidabile, perché la correttezza della query dipende da metadati organizzativi esterni al sistema di fatturazione.

Il risultato di esempio mostra che una risorsa Backstage può essere associata all’utilizzo Lakebase. Non mostra quale parte dell’infrastruttura di una grande organizzazione possa essere allocata in questo modo.

La copertura è la prima questione senza risposta. I team devono sapere quale percentuale dei progetti Lakebase rilevanti disponga di un’entità Backstage valida e di un’annotazione di progetto.

Un risultato può essere tecnicamente corretto pur rimanendo finanziariamente incompleto. I progetti non catalogati semplicemente scompaiono da una query incentrata sulle responsabilità, a meno che gli analisti non li identifichino separatamente.

L’accuratezza è la seconda questione. Un ID progetto valido può comunque riferirsi al servizio sbagliato, a un responsabile non aggiornato o a una risorsa condivisa che supporta più prodotti.

L’infrastruttura condivisa complica l’attribuzione perché un progetto può servire più team. Una singola annotazione Backstage non può esprimere ogni regola di allocazione proporzionale.

La semantica della fatturazione introduce una terza limitazione. Le DBU rappresentano il consumo, ma una visione completa dei costi può richiedere addebiti per infrastruttura cloud, crediti, impegni, imposte e rettifiche organizzative.

Il team FinOps deve decidere se la query supporti showback, chargeback, indagine sulle anomalie o pianificazione della capacità. Questi scopi richiedono livelli di precisione diversi.

Anche la responsabilità storica resta una questione irrisolta. Il catalogo live descrive più naturalmente lo stato attuale rispetto alle responsabilità passate.

Un trasferimento di servizio il 15 aprile non dovrebbe necessariamente riscrivere chi possedeva il consumo del 7 aprile. Report storici affidabili richiedono record di responsabilità sensibili al tempo.

Anche la stabilità dello schema è importante. La query accede a un’entità JSON e dipende da un nome di annotazione specifico. I team devono gestire quel campo come un contratto supportato.

Plugin Backstage, processori del catalogo e convenzioni organizzative possono modificare la forma delle entità. Anche Databricks può evolvere i metadati di fatturazione con lo sviluppo di Lakebase.

Gli utenti in produzione dovrebbero testare automaticamente questi contratti. Un job di validazione può identificare annotazioni mancanti, progetti sconosciuti, assegnazioni duplicate e utilizzo senza un responsabile.

La sicurezza introduce una pressione diversa. I metadati Backstage possono rivelare sistemi interni e strutture dei team, mentre i dati di fatturazione possono esporre schemi di consumo sensibili.

Combinare entrambi i dataset aumenta le informazioni disponibili da una singola query. È utile per l’analisi, ma aumenta l’impatto di autorizzazioni eccessivamente ampie.

Le organizzazioni necessitano di confini a livello di riga o vista che corrispondano al loro modello operativo. Un responsabile di servizio può aver bisogno dell’utilizzo di un solo team, mentre il FinOps centrale necessita di una copertura aziendale.

Rimane anche la dipendenza operativa. L’analisi federata dipende dalla disponibilità del database sorgente, del servizio di query, della configurazione delle identità e del livello di governance.

Databricks afferma che Lakebase isola il calcolo per carichi di lavoro diversi. Le evidenze indipendenti in produzione saranno comunque importanti per latenza, concorrenza, ripristino dai guasti e prestazioni analitiche prevedibili.

La serie originale ha incontrato anche una complicazione di autenticazione. Lakebase richiedeva una credenziale OAuth con ambito definito anziché un classico token di accesso personale Databricks.

Per il proof of concept, il team ha rinnovato una credenziale a breve durata tramite uno script. Le implementazioni in produzione necessitano di un processo di rotazione supportato che eviti di archiviare token rinnovati in posizioni non sicure.

Databricks Apps può creare un ruolo PostgreSQL per un service principal applicativo quando i team collegano una risorsa Lakebase. Questo percorso gestito è più adatto di un ciclo di rinnovo locale improvvisato.

La lezione più ampia non è che la federazione elimini il lavoro di governance. Lo rende visibile nel momento in cui un utente pone una domanda di business.

Il modello databricks backstage avrà successo solo quando la completezza del catalogo diventerà una metrica operativa. Senza questa disciplina, il FinOps a una sola query può produrre risposte rapide ma parziali.

Tre segnali mostreranno se il modello regge

La fase successiva deve misurare adozione, copertura dell’allocazione e affidabilità in produzione, anziché celebrare una dichiarazione SQL compatta.

Il primo segnale è un’implementazione riutilizzabile da Databricks, Thoughtworks o dalla community Backstage. I team dovrebbero osservare la disponibilità di processori del catalogo gestiti, regole di validazione, dashboard o template a supporto del modello.

Un pacchetto supportato rafforzerebbe l’ipotesi che questa architettura possa andare oltre una dimostrazione su misura. Dovrebbe definire schemi di annotazione, gestione delle credenziali, autorizzazioni e pratiche di deployment.

L’assenza di componenti riutilizzabili indebolirebbe l’affermazione. Ogni adottante dovrebbe ricreare autonomamente le mappature e i controlli più soggetti a errori.

Il secondo segnale è la copertura dell’allocazione nei cataloghi reali. La metrica utile è la percentuale di utilizzo Lakebase collegata a un’entità e a un responsabile Backstage attuali e validati.

Un’elevata copertura in ambienti di produzione in evoluzione sosterrebbe la federazione come input FinOps pratico. Un utilizzo persistentemente non allocato dimostrerebbe che la manutenzione dei metadati rimane il vincolo determinante.

La copertura dovrebbe essere accompagnata da dati di aggiornamento e conteggi delle eccezioni. I team devono sapere quanto rapidamente compaiono i nuovi progetti e con quale frequenza le mappature non superano la validazione.

Il terzo segnale è il comportamento in produzione con carichi di lavoro misti. Le organizzazioni dovrebbero misurare la latenza di Backstage mentre gli analisti eseguono query di fatturazione federate su cataloghi di grandi dimensioni.

Prestazioni stabili del portale rafforzerebbero l’argomento di Databricks sul calcolo separato. Interruzioni delle query, errori delle credenziali o colli di bottiglia della governance favorirebbero livelli di reporting materializzati per flussi di lavoro critici.

Il case study della query unica propone un’ipotesi chiara: governance condivisa e calcolo isolato possono ricollegare la responsabilità operativa ai dati analitici sui costi.

Ora i team hanno bisogno di prove su come questa ipotesi si comporti tra più account, risorse condivise, trasferimenti di servizi e controlli finanziari formali.

Per gli sviluppatori, l’azione immediata è semplice. Trattate le annotazioni del catalogo come dati di produzione, validate gli identificatori dell’infrastruttura e definite esplicitamente i cambiamenti di responsabilità.

Per i responsabili di piattaforma, chiedetevi se la pipeline dei costi esistente risponda a un requisito attuale o a un vecchio vincolo architetturale. La federazione può accelerare le indagini anche quando il reporting ufficiale rimane materializzato.

Per i team FinOps, testate la query databricks backstage rispetto ad allocazioni note prima di estenderla. La domanda importante non è se una query venga eseguita, ma se la sua risposta resti completa, spiegabile e riproducibile quando l’organizzazione cambia.