Comment nOps a reconstruit sa plateforme d'optimisation cloud sur Databricks Lakebase, et pourquoi d'autres ISV devraient faire de même

nOps, un partenaire Databricks Built On gérant plus de 4 milliards de dollars de dépenses cloud annuelles, a migré son application de production vers Databricks Lakebase. Le résultat a été une architecture plus rapide et plus simple qui a éliminé le lien entre leur application et leur analyse, et un guide pour les ISV qui cherchent à faire de même.

Chaque ISV construisant sur Databricks atteint éventuellement le même carrefour architectural : vos analyses résident dans le Lakehouse, mais votre application a besoin d'une base de données relationnelle pour les lectures et écritures à faible latence. Vous ajoutez donc une instance Postgres séparée (peut-être RDS, peut-être quelque chose d'auto-géré) et soudain, vous maintenez des pipelines ETL, des cron jobs et une logique de détection de changements juste pour maintenir deux systèmes synchronisés.

nOps a vécu cette réalité pendant des années. Et puis ils ont trouvé une meilleure solution.

nOps : Automatiser les économies cloud à grande échelle

Pour ceux qui ne connaissent pas, nOps est une plateforme automatisée d'optimisation des coûts cloud qui gère les remises basées sur les engagements sur AWS, GCP et Azure. Leur approche est distinctement "toujours active". Ils surveillent, achètent et échangent des engagements cloud sur une base horaire, en utilisant l'apprentissage automatique pour équilibrer les taux d'épargne effectifs contre le risque de verrouillage des engagements. Le modèle est basé sur la performance : nOps ne facture qu'un pourcentage des économies supplémentaires qu'ils génèrent.

C'est une opération intensive en données. Chaque heure, nOps analyse les modèles d'utilisation sur des milliers de comptes clients, évalue les portefeuilles d'engagements sur trois fournisseurs cloud majeurs et des dizaines de services, et prend des décisions d'achat automatisées. En plus de cela, ils fournissent une visibilité des coûts, des prévisions et une détection des anomalies via une plateforme FinOps centralisée.

La colonne vertébrale analytique de tout cela a longtemps été Databricks Lakehouse. Mais l'application front-end, la plateforme sur laquelle les clients se connectent pour voir leurs économies, gérer les budgets et explorer les données de coûts, avait besoin de quelque chose de plus.

Le problème : deux mondes, faiblement connectés

L'architecture précédente de nOps était un schéma familier pour les ISV sur Databricks. Les analyses avancées et le calcul des métriques s'exécutaient dans le Lakehouse. Les données destinées aux clients (configurations de compte, préférences utilisateur, état spécifique au client en évolution rapide) résidaient dans une base de données relationnelle séparée alimentée par des fournisseurs tiers et des solutions maison.

Les coutures entre ces deux systèmes créaient une friction réelle. Des travaux planifiés et la détection de changements basée sur cron étaient nécessaires pour maintenir la base de données front-end et le Lakehouse synchronisés. Les données qui étaient "en direct" dans un système pouvaient prendre des minutes ou plus pour apparaître dans l'autre. Et la surcharge opérationnelle de la gestion d'une pile de bases de données séparée, avec ses propres préoccupations de mise à l'échelle, de sauvegarde et de sécurité, détournait le temps d'ingénierie de ce que nOps fait le mieux : la construction de l'automatisation des engagements.

Lorsque nOps est passé d'une couverture uniquement AWS à une couverture multi-cloud sur GCP et Azure début 2026, les charges de travail croissantes ont mis à rude épreuve cette architecture. L'équipe a décidé de reconstruire la plateforme, en se concentrant cette fois sur leur spécialité et en choisissant une infrastructure qui fonctionne simplement.

La décision : pourquoi Lakebase

nOps a sélectionné Databricks Lakebase, une base de données PostgreSQL entièrement gérée intégrée directement au Lakehouse, comme colonne vertébrale OLTP pour leur nouvelle plateforme.

Jordan Stein, Directeur Produit chez nOps, a souligné trois facteurs qui ont fait de Lakebase le bon choix :

• Couplage étroit avec le Lakehouse. C'était le facteur le plus important. Avec Lakebase, les équipes d'ingénierie de données de nOps peuvent accéder immédiatement aux données clients fréquemment modifiées à partir de leurs pipelines Lakehouse sans travaux planifiés, cron jobs ou latence. Comme Jordan l'a dit : "Nous parlons de travaux planifiés qui devaient s'exécuter, de cron jobs qui venaient récupérer ces changements, alors qu'aujourd'hui, nous savons qu'au moment où c'est en direct, nous pouvons le consommer. Cela a été un game changer pour nous."
• Mise à l'échelle et arrêt automatiques. Même avec des paramètres d'arrêt automatique agressifs pendant le développement, l'équipe nOps a été "choquée par la performance". Le calcul serverless de Lakebase s'adapte aux demandes de charge de travail et se met à l'échelle à zéro lorsqu'il est inactif, ce qui est important pour une entreprise d'optimisation des coûts qui prêche par l'exemple.
• Facilité d'adoption. La restauration à un instant T s'est déjà avérée précieuse. Les rôles OAuth flexibles simplifient le contrôle d'accès. Et comme Lakebase réside dans l'espace de travail Databricks, leurs équipes travaillent sur une plateforme qu'elles connaissent déjà. Aucun nouvel outil à apprendre, aucune console séparée à gérer.

L'architecture : une plateforme, étroitement intégrée

Voici à quoi ressemble la nouvelle architecture de nOps :

Lakebase sert de base de données PostgreSQL centrale et de source unique de vérité pour l'application front-end et leur infrastructure d'IA.

Databricks Lakehouse consomme en continu les données de Lakebase pour l'analyse et le calcul des métriques.

La plateforme nOps découvre et affiche automatiquement les vues de métriques Databricks, de sorte que les métriques standardisées calculées dans le Lakehouse apparaissent de manière cohérente dans le front-end.

Les données circulent dans une seule direction, de Lakebase vers le Lakehouse pour l'analyse, sans retour d'écriture direct nécessaire. Cela maintient l'architecture propre et la source de vérité sans ambiguïté.

Le reste de la pile suit la même approche : Vercel pour l'hébergement et l'observabilité, WorkOS pour l'authentification, et Databricks pour tout ce qui concerne les données.

Entendez-le de nOps

Jordan Stein a récemment présenté l'histoire complète de la migration de nOps vers Lakebase dans une présentation de mise en avant des partenaires. Regardez la vidéo pour entendre comment s'est déroulée la transition, ce qui les a surpris en termes de performance, et comment l'intégration du Lakehouse a changé leurs flux de travail d'ingénierie de données :

Le guide ISV : pourquoi Lakebase change la donne

L'histoire de nOps n'est pas unique. Presque tous les ISV construisant sur Databricks sont confrontés à la même tension entre OLTP et analyse. Ce qui mérite une attention particulière, c'est la manière dont Lakebase résout ce problème de manière si nette.

Éliminez la taxe de synchronisation. Le code le plus coûteux dans la pile de tout ISV est souvent le code qui déplace les données entre les systèmes. L'intégration native de Lakebase avec Unity Catalog et la synchronisation Delta Lake en un clic remplacent les pipelines ETL personnalisés par une infrastructure gérée. C'est du temps d'ingénierie que vous récupérez.

Un modèle de gouvernance. Lorsque votre base de données OLTP est enregistrée en tant qu'actif Unity Catalog, vous bénéficiez d'une gouvernance unifiée, d'une lignée et d'un contrôle d'accès sur les données opérationnelles et analytiques. Fini la gestion des politiques de sécurité à deux endroits.

La compatibilité Postgres signifie zéro réécriture. Lakebase est PostgreSQL entièrement géré. Vos bibliothèques existantes, ORM et outils SQL fonctionnent immédiatement. Les extensions comme pgvector et PostGIS sont prises en charge. Vous migrez en pointant votre application vers une nouvelle chaîne de connexion, pas en réécrivant des requêtes.

Des économies d'échelle qui ont du sens. La tarification basée sur l'utilisation avec mise à l'échelle à zéro signifie que vous ne payez pas pour la capacité inactive. Pour les ISV ayant des charges de travail variables (et quel ISV n'a pas de charges de travail variables ?), cela a un impact direct sur l'économie unitaire.

Livrez plus rapidement. Lorsque votre base de données d'application et votre entrepôt de données font partie de la même plateforme, une catégorie entière de travail d'intégration disparaît. Votre équipe livre des fonctionnalités au lieu de maintenir la plomberie.

Premiers adoptants, impact réel

nOps est un bon exemple de ce à quoi ressemble un partenaire Built On innovant. Plutôt que d'attendre que Lakebase mûrisse à travers plusieurs cycles de publication, ils ont reconnu l'adéquation architecturale tôt, se sont engagés dans une migration de production et constatent déjà des résultats : des pipelines de données plus rapides, une surcharge opérationnelle réduite et une meilleure expérience pour leurs clients.

Cette volonté d'agir tôt est également stratégiquement intelligente. En construisant sur Lakebase maintenant, nOps a une intégration plus étroite avec la plateforme Databricks que les concurrents qui assemblent encore des piles de bases de données séparées. Leur plateforme est plus simple à exploiter et plus rapide à étendre.

Commencer

Explorer Lakebase. Si vous êtes un ISV construisant sur Databricks, ou envisagez de le faire, apprenez-en davantage sur Lakebase et comment il peut simplifier votre architecture.

Explorer nOps. Si votre organisation cherche à réduire les coûts cloud sur AWS, GCP ou Azure sans risque d'engagement, visitez nOps pour voir comment leur plateforme d'optimisation automatisée, désormais alimentée par Databricks Lakebase, peut vous aider.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original