Dietro le quinte con Lakebase, parte 3

Nella prima parte di questa serie, l'esecuzione di Backstage su Databricks Lakebase ci ha permesso di ottenere il branching del database in un secondo. Nella seconda parte, invece, Unity Catalog ha assorbito quel database operativo nel piano di governance aziendale.

Ma ecco il vero vantaggio che cambia concretamente l'organigramma.

In uno stack normale, rispondere alla domanda "chi possiede l'infrastruttura che fa lievitare la nostra spesa cloud e quanto è costata?" supera due confini. Il grafico della proprietà risiede in Backstage (gestito dal platform engineering), mentre i dati sui costi si trovano in un data warehouse (governato dal team dei dati). Rispondere a questa domanda richiede una pipeline ETL, un ticket Jira o una discussione su Slack.

Il compute separato rende fattibile la condivisione

Il motivo per cui un analista FinOps può eseguire query analitiche massive sullo stesso identico storage sottostante senza influire sul portale attivo è che Lakebase isola il compute per ogni workload.

Backstage ottiene il proprio ambiente di compute isolato e con scalabilità automatica. Durante il normale utilizzo del portale, le query del catalogo sono state eseguite in 55-65 ms end-to-end e le ricerche hanno richiesto da due a quattro millisecondi. Poiché l'applicazione web e i workload analitici non competono per lo stesso cluster di compute, possono finalmente condividere in sicurezza lo stesso substrato di dati.

La soluzione alternativa: autenticazione di Lakehouse Federation

Per unire i dati Postgres attivi ai nostri dati di fatturazione analitici, utilizziamo Databricks Lakehouse Federation. Tuttavia, il connettore Postgres di Lakehouse Federation attualmente supporta solo credenziali statiche utente/password. Poiché Lakebase autentica le identità delle app tramite JWT OAuth, il motore di federazione richiede un percorso di autenticazione parallelo.

La soluzione alternativa consiste nel creare un ruolo Postgres nativo con autenticazione SCRAM-SHA-256, collegato alla federazione separatamente dall'identità OAuth utilizzata dall'app:

Ora stai gestendo due percorsi di autenticazione per lo stesso database.

Il join FinOps

Con il catalogo esterno attivo, un analista FinOps può scrivere una singola query che estrae il nome della risorsa Backstage direttamente dalla tabella Postgres operativa e lo unisce alle righe di fatturazione di Lakebase in system.billing.usage:

Risultato reale:

La parte sinistra di quella riga proviene direttamente dall'interno del catalogo Postgres attivo di Backstage; la parte destra proviene da una tabella di fatturazione di sistema di Unity Catalog. Storicamente queste due cose non sono mai state nello stesso motore SQL, e ora si uniscono con zero spostamento di dati.

Perché non usare semplicemente l'ETL?

Un diffidente potrebbe chiedere perché non usiamo semplicemente uno script Python per sincronizzare un'istanza RDS con una tabella Delta una volta all'ora.

La risposta è il branching. Quando uno sviluppatore crea un clone di database effimero in un secondo per testare una PR, dovresti configurare dinamicamente nuove pipeline ETL solo per ottenere visibilità sui costi in quell'ambiente di test temporaneo. Con Lakebase, nel momento in cui viene creato il branch, i suoi dati di fatturazione e proprietà sono immediatamente interrogabili. (In questo POC, il branch di test eliminato è stato attribuito in modo automatico e indipendente a 0,0107 DBU).

Rendere operativa la convergenza

Questa serie in tre parti è iniziata con un branch di database creato in un secondo, è passata attraverso una governance unificata ed è arrivata qui: una singola query SQL che unisce i dati operativi di proprietà ai dati di fatturazione cloud con zero pipeline tra di essi. Questa è la prova che la convergenza funziona dal punto di vista tecnico. La domanda che i professionisti si porranno ora è: cosa serve per renderla operativa?

Da questo POC sono emersi due elementi che vale la pena evidenziare per i team che intendono seguire questo percorso.

Il gap di autenticazione della federazione

La soluzione alternativa di Lakehouse Federation che abbiamo descritto (un ruolo Postgres nativo con credenziali statiche collegate separatamente dall'identità OAuth utilizzata dall'app) è l'approccio corretto oggi. Ogni team che desidera unire i propri dati operativi di Lakebase con le tabelle analitiche in Unity Catalog dovrà configurare questo percorso di autenticazione parallelo. La federazione probabilmente non dovrebbe essere eseguita come utente dell'applicazione in ogni caso, quindi la separazione offre un vantaggio in termini di sicurezza, ma la rotazione delle password è a tuo carico. Per i team che adottano questo pattern, i passaggi possono essere pacchettizzati in uno script ripetibile: genera una password sicura, crea il ruolo con permessi di sola lettura, configura la connessione, crea il catalogo esterno. Una configurazione una tantum, che richiede pochi minuti una volta compreso il pattern. Il supporto nativo per i JWT OAuth nella federazione eliminerebbe completamente questa soluzione alternativa.

Visibilità dei costi dei branch per i team di sviluppo

Il join FinOps risponde alla domanda sulla piattaforma: quanto costa questa infrastruttura e chi ne è il proprietario? Ma gli stessi dati di fatturazione raccontano una seconda storia importante per gli engineering manager: quanto costa il processo di sviluppo in sé?

Nel workflow di branching della prima parte, ogni pull request crea un branch CI effimero e ogni sviluppatore ha il proprio feature branch. Questi vengono visualizzati come singole voci indipendenti in system.billing.usage, suddivise per branch_id e endpoint_id. Un engineering manager può vedere esattamente quanto compute ha consumato il branching di dev/test del proprio team in uno sprint rispetto alla produzione, e prendere decisioni informate sulle policy del ciclo di vita dei branch.

Il punto chiave è che i branch effimeri dovrebbero essere trattati come tali anche nei dati di fatturazione. I branch CI creati con un TTL breve scadono automaticamente se la pulizia fallisce per qualsiasi motivo (un push diretto su main, un errore del workflow, un evento mancato). Senza controlli sul ciclo di vita, i branch orfani possono accumularsi silenziosamente, ciascuno con un endpoint di compute attivo che incide sulla fatturazione del progetto. Il branch di test è costato 0,0107 DBU. È una cifra insignificante. Trenta branch orfani in esecuzione per un mese non lo sono.

Il punto non è che il branching sia costoso: si tratta di un bilanciamento tra costi e aumento di produttività. Quando un team elimina due giorni di attesa dell'ambiente per sprint e smette di mantenere il 20-30% del proprio codebase in oggetti mock, lo 0,0107 DBU per branch non è una voce di spesa da gestire: è l'investimento in produttività più economico che il team abbia mai fatto. E a differenza della maggior parte degli investimenti in produttività, questo è misurabile: l'infrastruttura ti dice esattamente quanto è costata, per branch, per sviluppatore, per sprint. Questa è una conversazione che la maggior parte dei team di ingegneria non ha mai potuto avere con il proprio database.

I primi passi

Prima di concludere, c'è un altro punto della storia di FinOps che vale la pena sottolineare. Gli endpoint Lakebase scalano a zero. Quando un branch non viene interrogato, il suo compute viene sospeso e la fatturazione si interrompe. La cifra di 0,0107 DBU è il costo di un branch che è stato eseguito, non il costo di un branch esistente; una flotta di branch effimeri inattivi tra un'esecuzione di test e l'altra non contribuisce in alcun modo ai costi.

Nel corso di questa serie, abbiamo dimostrato che l'infrastruttura funziona: app reali, benchmark reali, governance reale, dati sui costi reali. Da parte nostra, Databricks e Thoughtworks stanno lavorando insieme per portare questo progetto dal POC alla pratica: team di sviluppo reali, sprint reali, misurazioni della velocità reali. Il vincolo che ha tenuto i dati operativi e analitici in mondi separati per trent'anni si sta dissolvendo.

C'è un insegnamento pratico per il lunedì mattina per ogni parte di questa serie. Crea un branch per la tua prossima migrazione su uno schema reale. Riscrivi una suite ricca di mock su un branch. Unisci i tuoi dati di fatturazione al tuo grafo di proprietà. I team che si muovono per primi definiranno ciò che verrà dopo.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale