Ogni fattura cloud racconta una storia, ma leggerla può richiedere la traduzione di milioni di voci da decine di provider cloud e AI in qualcosa su cui un CFO, un responsabile tecnico o un team FinOps possa effettivamente agire. È questo il problema che nOps risolve. La piattaforma dell'azienda gestisce più di 5 miliardi di dollari di spesa cloud annuale per centinaia di clienti, trasformando i dati grezzi di fatturazione e utilizzo in dashboard in tempo reale in cui le aziende possono vedere esattamente dove vanno a finire i loro soldi, fino al dipartimento, al centro di costo o al tag personalizzato.
I clienti si aspettano che questa visibilità sia immediata. Quando cambia una raccomandazione di impegno, quando la spesa sale vertiginosamente in un account inaspettato o quando un nuovo carico di lavoro AI inizia a far lievitare i costi, le dashboard devono riflettere tutto ciò in tempo reale. nOps offre viste della dashboard personalizzabili e i dati sottostanti devono rimanere freschi e reattivi in ogni configurazione unica dei clienti. In qualità di partner Built on Databricks, nOps ha recentemente sostituito Apache Druid con Lakehouse//RT per alimentare quel livello in tempo reale, riducendo al contempo i costi dell'infrastruttura e consolidando l'architettura su un'unica piattaforma governata.
Creazione di un livello in tempo reale per la prossima generazione di clienti aziendali
Per anni, il livello di query in tempo reale alla base delle dashboard dei clienti di nOps è stato eseguito su Apache Druid. L'azienda ha iniziato con una distribuzione autogestita, per poi passare a un servizio Druid gestito. Ma man mano che la piattaforma è cresciuta e i clienti aziendali hanno richiesto requisiti di reporting sempre più complessi, il divario tra ciò di cui l'azienda aveva bisogno e ciò che Druid poteva offrire si è allargato.
"Non riuscivamo a ottenere le prestazioni di cui avevamo bisogno", ha dichiarato Jordan Stein, Director of Engineering presso nOps. "Ed era davvero difficile trarne valore". La sfida non era solo la velocità. nOps consente ai clienti di definire le proprie mappature, i propri tag e raggruppamenti, quindi non esistono due dashboard di clienti uguali. Le query che alimentano queste viste possono essere estremamente complesse, alcune lunghe fino a 30.000 righe di SQL con corrispondenza di stringhe su trilioni di righe. Man mano che nOps acquisiva clienti aziendali più grandi con più dipartimenti, più centri di costo e requisiti di reporting più granulari, le query diventavano più lunghe e impegnative. Questi erano i clienti che nOps desiderava maggiormente servire, e il livello in tempo reale esistente stava frenando la piattaforma.
Il team aveva bisogno di una piattaforma in grado di gestire l'intera complessità di quelle query senza richiedere a nOps di spostare i propri dati da S3. Con circa 380TB di dati di infrastruttura cloud in S3 che alimentano le sue tabelle Delta, duplicarli in un livello di servizio separato aggiungeva costi, latenza e complessità operativa che il team voleva eliminare del tutto.
Lakehouse//RT: Zero movimento dei dati, rollback istantanei
nOps stava già utilizzando le viste delle metriche di Databricks in produzione e stava eseguendo il database della sua applicazione su Lakebase quando è stato lanciato Lakehouse//RT. Il tempismo ha coinciso perfettamente con la ricerca da parte del team di un nuovo motore in tempo reale. "Era esattamente il problema che stavamo cercando di risolvere", ha detto Stein. "Dal momento in cui abbiamo ottenuto l'accesso, è stato chiaro che Lakehouse//RT era un sostituto diretto per il nostro livello Druid".
Il requisito più critico era l'assenza di movimenti di dati. nOps ha circa 380TB di dati in S3, e duplicarli in un livello di servizio separato era costoso e complicato dal punto di vista operativo. Lakehouse//RT interroga direttamente le stesse tabelle Delta, senza copie, senza pipeline di inserimento e senza archiviazione secondaria. "Tutti sanno che cercare di spostare oltre 380 terabyte di dati su piattaforme diverse è un'impresa titanica ed è costoso", ha detto Stein. "Con Lakehouse//RT, non è stata richiesta alcuna modifica ai dati sottostanti".
La migrazione ha anche sbloccato i rollback istantanei delle versioni delle tabelle. Su Druid, eseguire il rollback della versione di una tabella significava inviare un nuovo processo di inserimento e attendere fino a tre ore. Con Lakehouse//RT che legge direttamente dalle tabelle Delta, i rollback avvengono immediatamente. "Questo è uno dei cambiamenti più importanti per noi", ha detto Stein. "I dati che il cliente vede sono la stessa tabella su cui abbiamo appena finito di scrivere. Non dobbiamo inseguire un duplicato di quei dati che si trova in un'altra posizione".
Riduzione dei costi di oltre 6 volte e piattaforma dati unificata
L'impatto finanziario è stato notevole. L'architettura precedente di nOps si basava su cluster Druid sempre attivi. Con l'autoscaling serverless di Lakehouse//RT, il team ha ridotto la spesa per l'infrastruttura in tempo reale a circa il 16% del costo precedente, ovvero più di 6 volte meno costosa. La migrazione ha anche eliminato 40TB di dati di servizio duplicati che erano stati archiviati all'esterno di S3 nel livello di archiviazione Druid secondario.
Oltre alle dashboard, nOps instrada anche i suoi agenti AI interni e l'architettura MCP (Model Context Protocol) attraverso Lakehouse//RT, il che ha migliorato significativamente i tempi di risposta e la qualità dell'esperienza di chat conversazionale per i clienti. "Avere i dati sottostanti uguali tra ciò che scriviamo nel backend e ciò che il cliente vede nel frontend è fondamentale", ha detto Stein. "C'è molto valore nel trasferire queste architetture interdipendenti in un unico posto".
In qualità di partner Built on Databricks, l'esperienza di nOps illustra il motivo per cui Lakehouse//RT è particolarmente adatto per i partner ISV che creano applicazioni con un utilizzo intensivo di dati. Le piattaforme di osservabilità e gestione dei costi cloud gestiscono volumi di dati enormi, query complesse definite dai clienti e l'aspettativa di reattività in tempo reale. Lakehouse//RT consente agli ISV di servire questi carichi di lavoro direttamente dal lakehouse senza mantenere un database in tempo reale separato, riducendo sia i costi dell'infrastruttura che la complessità operativa. La stretta collaborazione che nOps ha avuto con il team di prodotto di Databricks durante la beta ha ulteriormente accelerato la migrazione. "Questo tipo di partnership è molto preziosa quando si dispone di team in grado di promuovere la nuova tecnologia e fornire preziosi feedback", ha affermato Stein.
nOps ha sostituito il suo livello di query in tempo reale Apache Druid gestito con Databricks Lakehouse//RT, basato sul motore Reyden. Lakehouse//RT interroga direttamente le stesse tabelle Delta archiviate in S3, eliminando la necessità di un database di servizio separato, della duplicazione dei dati e delle pipeline di inserimento.