Chaque facture cloud raconte une histoire, mais sa lecture peut nécessiter de traduire des millions de lignes de données provenant de dizaines de fournisseurs cloud et IA en informations exploitables pour un DAF, un responsable technique ou une équipe FinOps. C'est le problème que résout nOps. La plateforme de l'entreprise gère plus de 5 milliards de dollars de dépenses cloud annuelles pour des centaines de clients, transformant les données brutes de facturation et d'utilisation en tableaux de bord en temps réel où les entreprises peuvent voir exactement où va leur argent, jusqu'au département, au centre de coûts ou au tag personnalisé.
Les clients s'attendent à ce que cette visibilité soit immédiate. Lorsqu'une recommandation d'engagement change, qu'une dépense s'envole sur un compte inattendu ou qu'une nouvelle charge de travail d'IA commence à faire grimper les coûts, les tableaux de bord doivent le refléter en temps réel. nOps propose des vues de tableau de bord personnalisables, et les données qui les alimentent doivent rester fraîches et réactives pour la configuration unique de chaque client. En tant que partenaire Built on Databricks, nOps a récemment remplacé Apache Druid par Lakehouse//RT pour alimenter cette couche temps réel tout en réduisant les coûts d'infrastructure et en consolidant son architecture sur une plateforme unique et gouvernée.
Créer une couche temps réel pour la prochaine génération de clients d'entreprise
Pendant des années, la couche de requêtes en temps réel des tableaux de bord clients de nOps a fonctionné sur Apache Druid. L'entreprise a commencé par un déploiement auto-hébergé, puis est passée à un service Druid géré. Mais à mesure que la plateforme grandissait et que les clients d'entreprise formulaient des exigences de reporting de plus en plus complexes, l'écart entre les besoins de l'entreprise et ce que Druid pouvait offrir s'est creusé.
« Nous n'arrivions tout simplement pas à obtenir les performances dont nous avions besoin », a déclaré Jordan Stein, directeur de l'ingénierie chez nOps. « Et c'était vraiment difficile d'en tirer de la valeur. » Le défi n'était pas seulement une question de vitesse. nOps permet à ses clients de définir leurs propres correspondances, tags et regroupements, de sorte que les tableaux de bord de deux clients ne se ressemblent jamais. Les requêtes alimentant ces vues peuvent être extrêmement complexes, certaines atteignant 30 000 lignes de SQL avec correspondance de chaînes sur des billions de lignes. Alors que nOps décrochait des comptes d'entreprise plus importants, avec davantage de départements, de centres de coûts et d'exigences de reporting granulaires, les requêtes sont devenues plus longues et plus exigeantes. C'étaient les clients que nOps souhaitait le plus servir, et la couche temps réel existante freinait la plateforme.
L'équipe avait besoin d'une plateforme capable de gérer toute la complexité de ces requêtes sans obliger nOps à sortir ses données de S3. Avec environ 380 To de données d'infrastructure cloud dans S3 alimentant ses tables Delta, les dupliquer dans une couche de service séparée ajoutait des coûts, de la latence et une surcharge opérationnelle que l'équipe voulait éliminer complètement.
Lakehouse//RT : Zéro mouvement de données, retours arrière instantanés
nOps utilisait déjà les vues métriques Databricks en production et exécutait sa base de données d'application sur Lakebase lors du lancement de Lakehouse//RT. Le timing correspondait parfaitement à la recherche d'un nouveau moteur temps réel par l'équipe. « C'était exactement le problème que nous essayions de résoudre », a déclaré Stein. « Dès que nous avons eu accès à la solution, il est apparu clairement que Lakehouse//RT remplaçait directement notre couche Druid. »
L'exigence la plus critique était l'absence totale de mouvement de données. nOps possède environ 380 To de données dans S3, et les dupliquer dans une couche de service distincte était coûteux et complexe à gérer. Lakehouse//RT interroge directement les mêmes tables Delta, sans copie, sans pipelines d'ingestion et sans stockage secondaire. « Tout le monde sait qu'essayer de déplacer plus de 380 téraoctets de données d'une plateforme à une autre est un cauchemar, et c'est coûteux », a déclaré Stein. « Avec Lakehouse//RT, cela n'a nécessité aucun changement sur les données sous-jacentes. »
La migration a également permis des retours arrière instantanés sur les versions de tables. Sur Druid, rétablir une version de table signifiait soumettre un nouveau travail d'ingestion et attendre jusqu'à trois heures. Avec Lakehouse//RT qui lit directement dans les tables Delta, les retours arrière sont immédiats. « C'est l'un des changements qui a eu le plus d'impact pour nous », a déclaré Stein. « Les données que voit le client sont exactement la table que nous venons d'écrire. Nous n'avons pas besoin de courir après un double de ces données se trouvant à un autre endroit. »
Une réduction des coûts de plus de 6x et une plateforme de données unifiée
L'impact financier a été considérable. L'ancienne architecture de nOps reposait sur des clusters Druid actifs en permanence. Grâce à la mise à l'échelle automatique sans serveur (serverless autoscaling) de Lakehouse//RT, l'équipe a réduit ses dépenses d'infrastructure en temps réel à environ 16 % du coût précédent, soit une division par plus de 6. La migration a également éliminé 40 To de données de service dupliquées qui étaient stockées en dehors de S3 dans la couche de stockage secondaire Druid.
Au-delà des tableaux de bord, nOps a égalementchemine ses agents d'IA internes et son architecture MCP (Model Context Protocol) via Lakehouse//RT, ce qui a considérablement amélioré les temps de réponse et la qualité de l'expérience de chat conversationnel pour les clients. « Avoir des données sous-jacentes identiques entre ce que nous écrivons en backend et ce que le client voit en frontend est un énorme avantage », a déclaré Stein. « Il y a une réelle valeur à regrouper ces architectures interdépendantes en un seul endroit. »
En tant que partenaire Built on Databricks, l'expérience de nOps illustre pourquoi Lakehouse//RT convient parfaitement aux partenaires ISV qui développent des applications gourmandes en données. Les plateformes d'observabilité et de gestion des coûts cloud gèrent des volumes de données massifs, des requêtes complexes définies par les clients et l'attente d'une réactivité en temps réel. Lakehouse//RT permet aux ISV de traiter ces charges de travail directement depuis le lakehouse sans avoir à maintenir une base de données temps réel séparée, réduisant ainsi à la fois les coûts d'infrastructure et la complexité opérationnelle. La collaboration étroite entre nOps et l'équipe produit Databricks pendant la version bêta a encore accéléré la migration. « Ce genre de partenariat est très précieux lorsque vous avez des équipes capables de pousser les nouvelles technologies et de fournir des retours utiles », a déclaré Stein.
nOps a remplacé sa couche de requêtes en temps réel Apache Druid gérée par Databricks Lakehouse//RT, alimentée par le moteur Reyden. Lakehouse//RT interroge directement les mêmes tables Delta stockées dans S3, éliminant ainsi le besoin d'une base de données de service séparée, de duplication de données et de pipelines d'ingestion.