di Bryan Smith
nOps, un partner Databricks Built On che gestisce oltre 4 miliardi di dollari di spesa cloud annuale, ha migrato la propria applicazione di produzione su Databricks Lakebase. Il risultato è stata un'architettura più veloce e semplice che ha eliminato il collegamento tra la loro app e la loro analisi, e un manuale per gli ISV che desiderano fare lo stesso.
Ogni ISV che costruisce su Databricks raggiunge infine lo stesso bivio architetturale: le tue analisi risiedono nel Lakehouse, ma la tua applicazione necessita di un database relazionale per letture e scritture a bassa latenza. Quindi, aggiungi un'istanza Postgres separata (magari RDS, magari qualcosa di autogestito) e improvvisamente ti ritrovi a mantenere pipeline ETL, cron job e logica di rilevamento delle modifiche solo per mantenere sincronizzati due sistemi.
nOps ha vissuto quella realtà per anni. E poi hanno trovato un modo migliore.
Per chi non lo sapesse, nOps è una piattaforma automatizzata di ottimizzazione dei costi cloud che gestisce sconti basati su impegni su AWS, GCP e Azure. Il loro approccio è decisamente "sempre attivo". Monitorano, acquistano e scambiano impegni cloud su base oraria, utilizzando il machine learning per bilanciare i tassi di risparmio effettivi contro il rischio di blocco degli impegni. Il modello è basato sulle prestazioni: nOps addebita solo una percentuale dei risparmi incrementali che genera.
È un'operazione ad alta intensità di dati. Ogni ora, nOps analizza i modelli di utilizzo su migliaia di account cliente, valuta i portafogli di impegni su tre principali provider cloud e dozzine di servizi, e prende decisioni di acquisto automatizzate. Oltre a ciò, forniscono visibilità dei costi, previsioni e rilevamento delle anomalie attraverso una piattaforma FinOps centralizzata.
La spina dorsale analitica per tutto questo è stata a lungo Databricks Lakehouse. Ma l'applicazione front-end, la piattaforma a cui i clienti accedono per vedere i loro risparmi, gestire i budget ed esplorare i dati sui costi, necessitava di qualcosa di più.
L'architettura precedente di nOps era un modello familiare per gli ISV su Databricks. Analisi avanzate e calcolo delle metriche venivano eseguiti nel Lakehouse. I dati rivolti ai clienti (configurazioni dell'account, preferenze utente, stato specifico del cliente in rapida evoluzione) risiedevano in un database relazionale separato alimentato da fornitori terzi e soluzioni proprietarie.
Le giunture tra questi due sistemi creavano attrito reale. Erano necessari processi pianificati e rilevamento delle modifiche basato su cron per mantenere sincronizzati il database front-end e il Lakehouse. I dati che erano "live" in un sistema potevano impiegare minuti o più per apparire nell'altro. E l'overhead operativo della gestione di uno stack di database separato, con le sue preoccupazioni di scalabilità, backup e sicurezza, sottraeva tempo di ingegneria a ciò che nOps fa meglio: costruire l'automazione degli impegni.
Quando nOps si è espansa da AWS a copertura multi-cloud su GCP e Azure all'inizio del 2026, i carichi di lavoro crescenti hanno messo a dura prova questa architettura. Il team ha deciso di ricostruire la piattaforma, concentrandosi questa volta sulla loro specialità e scegliendo un'infrastruttura che semplicemente funziona.
nOps ha selezionato Databricks Lakebase, un database PostgreSQL completamente gestito integrato direttamente con il Lakehouse, come spina dorsale OLTP per la loro nuova piattaforma.
Jordan Stein, Director of Product presso nOps, ha indicato tre fattori che hanno reso Lakebase la scelta giusta:
Ecco come appare la nuova architettura di nOps:
Lakebase funge da database Postgres centrale e singola fonte di verità sia per l'applicazione front-end che per la loro infrastruttura AI.
Databricks Lakehouse consuma continuamente dati da Lakebase per analisi e calcolo delle metriche.
La piattaforma nOps scopre e visualizza automaticamente le Viste Metriche Databricks, in modo che le metriche standardizzate calcolate nel Lakehouse appaiano in modo coerente nel front-end.
I dati fluiscono in un'unica direzione, da Lakebase al Lakehouse per l'analisi, senza necessità di scrittura diretta. Questo mantiene l'architettura pulita e la fonte di verità inequivocabile.
Il resto dello stack segue lo stesso approccio: Vercel per l'hosting e l'osservabilità, WorkOS per l'autenticazione e Databricks per tutto ciò che riguarda i dati.
Jordan Stein ha recentemente illustrato l'intera storia della migrazione di nOps a Lakebase in una presentazione spotlight per partner. Guarda il video per sentire come è andata la transizione, cosa li ha sorpresi riguardo alle prestazioni e come l'integrazione con il Lakehouse ha cambiato i loro flussi di lavoro di data engineering:
La storia di nOps non è unica. Quasi ogni ISV che costruisce su Databricks affronta la stessa tensione tra OLTP e analisi. Ciò che vale la pena notare è con quanta chiarezza Lakebase la risolve.
Elimina il costo della sincronizzazione. Il codice più costoso nello stack di qualsiasi ISV è spesso il codice che sposta i dati tra i sistemi. L'integrazione nativa di Lakebase con Unity Catalog e la sincronizzazione Delta Lake con un clic sostituiscono le pipeline ETL personalizzate con infrastrutture gestite. Questo è tempo di ingegneria che recuperi.
Un modello di governance. Quando il tuo database OLTP è registrato come asset di Unity Catalog, ottieni governance unificata, lineage e controllo degli accessi sui dati operativi e analitici. Non dovrai più gestire le policy di sicurezza in due posti.
La compatibilità Postgres significa riscrittura zero. Lakebase è PostgreSQL completamente gestito. Le tue librerie esistenti, ORM e strumenti SQL funzionano immediatamente. Estensioni come pgvector e PostGIS sono supportate. Migri puntando la tua app a una nuova stringa di connessione, non riscrivendo le query.
Economia di scala che ha senso. Il prezzo basato sull'utilizzo con scalabilità a zero significa che non paghi per la capacità inattiva. Per gli ISV con carichi di lavoro variabili (e quale ISV non ha carichi di lavoro variabili?) questo impatta direttamente sull'economia unitaria.
Rilascia più velocemente. Quando il tuo database applicativo e il tuo data warehouse sono sulla stessa piattaforma, un'intera categoria di lavoro di integrazione scompare. Il tuo team rilascia funzionalità invece di mantenere la plomberia.
nOps è un buon esempio di ciò che rappresenta un partner Built On innovativo. Piuttosto che aspettare che Lakebase maturi attraverso molteplici cicli di rilascio, hanno riconosciuto presto l'adattamento architetturale, si sono impegnati in una migrazione di produzione e stanno già vedendo i risultati: pipeline di dati più veloci, minore overhead operativo e una migliore esperienza per i loro clienti.
Questa volontà di muoversi presto è anche strategicamente intelligente. Costruendo ora su Lakebase, nOps ha un'integrazione più stretta con la piattaforma Databricks rispetto ai concorrenti che stanno ancora rattoppando stack di database separati. La loro piattaforma è più semplice da gestire e più veloce da estendere.
Esplora Lakebase. Se sei un ISV che costruisce su Databricks, o lo stai considerando, scopri di più su Lakebase e su come può semplificare la tua architettura.
Esplora nOps. Se la tua organizzazione sta cercando di ridurre i costi cloud su AWS, GCP o Azure senza il rischio di impegni, visita nOps per vedere come la loro piattaforma di ottimizzazione automatizzata, ora potenziata da Databricks Lakebase, può aiutarti.
(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale
Iscriviti al nostro blog e ricevi gli ultimi articoli direttamente nella tua casella di posta.