Dans les coulisses de Lakebase, partie 3

Dans la première partie de cette série, l'exécution de Backstage sur Databricks Lakebase nous a permis de créer des branches de base de données en une seconde. Dans la deuxième partie, quant à elle, Unity Catalog a intégré cette base de données opérationnelle dans le plan de gouvernance de l'entreprise.

Mais voici le véritable avantage qui redessine l'organigramme.

Dans une architecture classique, répondre à la question « à qui appartient l'infrastructure qui fait grimper nos dépenses cloud, et combien cela a-t-il coûté ? » implique de franchir deux frontières. Le graphe de propriété se trouve dans Backstage (géré par l'ingénierie de plateforme), tandis que les données de coûts résident dans un data warehouse (gouverné par l'équipe des données). Répondre à cette question nécessite un pipeline ETL, un ticket Jira ou un fil de discussion Slack.

La séparation du calcul rend le partage viable

Si un analyste FinOps peut exécuter des requêtes analytiques massives sur le même stockage sous-jacent sans impact sur le portail en production, c'est parce que Lakebase isole le calcul par charge de travail.

Backstage bénéficie de sa propre enveloppe de calcul isolée avec mise à l'échelle automatique. Lors d'une utilisation normale du portail, les requêtes de catalogue s'exécutent en 55 à 65 ms de bout en bout, et les recherches prennent de deux à quatre millisecondes. Comme votre application web et vos charges de travail analytiques ne se disputent pas le même cluster de calcul, elles peuvent enfin partager le même substrat de données en toute sécurité.

La solution de contournement : l'authentification par fédération Lakehouse

Pour associer les données Postgres en production à nos données de facturation analytiques, nous utilisons Databricks Lakehouse Federation. Cependant, le connecteur Postgres de Lakehouse Federation ne prend actuellement en charge que les identifiants statiques utilisateur/mot de passe. Comme Lakebase authentifie les identités des applications via des JWT OAuth, le moteur de fédération a besoin d'un chemin d'authentification parallèle.

La solution de contournement consiste à créer un rôle Postgres natif avec une authentification SCRAM-SHA-256, connecté à la fédération indépendamment de l'identité OAuth utilisée par l'application :

Vous gérez désormais deux chemins d'authentification pour la même base de données.

La jointure FinOps

Une fois le catalogue externe actif, un analyste FinOps peut écrire une seule requête qui extrait le nom de la ressource Backstage directement de la table Postgres opérationnelle, et la joint aux lignes de facturation de Lakebase dans system.billing.usage :

Résultat réel :

La partie gauche de cette ligne provient directement du catalogue Postgres Backstage en production ; la partie droite provient d'une table de facturation système de Unity Catalog. Historiquement, ces deux éléments n'ont jamais partagé le même moteur SQL, et ils sont désormais joints sans aucun mouvement de données.

Pourquoi ne pas simplement utiliser un ETL ?

Un sceptique pourrait se demander pourquoi nous n'utilisons pas simplement un script Python pour synchroniser une instance RDS avec une table Delta une fois par heure.

La réponse réside dans la création de branches. Lorsqu'un développeur crée un clone de base de données éphémère en une seconde pour tester une PR, vous devriez provisionner dynamiquement de nouveaux pipelines ETL juste pour obtenir une visibilité sur les coûts de cet environnement de test temporaire. Avec Lakebase, dès que la branche est créée, ses données de facturation et de propriété peuvent être interrogées instantanément. (Dans ce POC, la branche de test supprimée s'est vu attribuer automatiquement et indépendamment 0,0107 DBU).

Opérationnaliser la convergence

Cette série en trois parties a commencé par une branche de base de données créée en une seconde, s'est poursuivie avec une gouvernance unifiée et se termine ici : une seule requête SQL qui joint les données de propriété opérationnelles aux données de facturation cloud, sans aucun pipeline entre elles. C'est la preuve que la convergence fonctionne sur le plan technique. La question que les professionnels se poseront ensuite est la suivante : que faut-il pour opérationnaliser cela ?

Deux éléments clés ressortent de ce POC et méritent d'être signalés aux équipes qui envisagent de suivre cette voie.

Le défi de l'authentification de la fédération

La solution de contournement de Lakehouse Federation que nous avons décrite – un rôle Postgres natif avec des identifiants statiques configurés séparément de l'identité OAuth utilisée par l'application – est la bonne approche aujourd'hui. Chaque équipe souhaitant joindre ses données opérationnelles Lakebase à des tables analytiques dans Unity Catalog devra configurer ce chemin d'authentification parallèle. De toute façon, la fédération ne devrait probablement pas s'exécuter en tant qu'utilisateur de votre application, cette séparation présente donc un avantage en matière de sécurité, mais la rotation des mots de passe reste à votre charge. Pour les équipes adoptant ce modèle, les étapes peuvent être regroupées dans un script réutilisable : générer un mot de passe sécurisé, créer le rôle avec des autorisations en lecture seule, configurer la connexion, créer le catalogue externe. Une configuration unique, qui ne prend que quelques minutes une fois le modèle compris. La prise en charge native des JWT OAuth dans Federation éliminerait complètement cette solution de contournement.

Visibilité des coûts des branches pour les équipes de développement

La jointure FinOps répond à la question de la plateforme : combien coûte cette infrastructure et à qui appartient-elle ? Mais ces mêmes données de facturation racontent une autre histoire essentielle pour les responsables de l'ingénierie : combien coûte le processus de développement lui-même ?

Dans le flux de travail de branching de la première partie, chaque pull request crée une branche CI éphémère et chaque développeur dispose de sa propre branche de fonctionnalité. Celles-ci apparaissent comme des éléments de ligne indépendants dans system.billing.usage, ventilés par branch_id et endpoint_id. Un responsable de l'ingénierie peut voir exactement quelle quantité de calcul la création de branches de développement/test de son équipe a consommée au cours d'un sprint par rapport à la production, et prendre des décisions éclairées concernant les politiques de cycle de vie des branches.

L'essentiel est que les branches éphémères soient également traitées comme telles dans les données de facturation. Les branches CI créées avec un TTL court expirent automatiquement si le nettoyage échoue pour une raison quelconque : un push direct vers main, une erreur de workflow, un événement manqué. Sans contrôle du cycle de vie, les branches orphelines peuvent s'accumuler discrètement, chacune d'elles facturant un point de terminaison de calcul actif sur le projet. La branche de test a coûté 0,0107 DBU. C'est dérisoire. Trente branches orphelines actives pendant un mois ne le sont pas.

Le but n'est pas de dire que la création de branches coûte cher, c'est un arbitrage entre coût et gain de productivité. Lorsqu'une équipe élimine deux jours d'attente d'environnement par sprint et cesse de maintenir 20 à 30 % de sa base de code dans des objets fictifs, les 0,0107 DBU par branche ne sont plus une ligne de dépenses à gérer : c'est l'investissement de productivité le plus rentable que l'équipe ait jamais réalisé. Et contrairement à la plupart des investissements de productivité, celui-ci est mesurable : l'infrastructure vous indique exactement ce qu'elle a coûté, par branche, par développeur, par sprint. C'est une discussion que la plupart des équipes d'ingénierie n'ont jamais pu avoir avec leur base de données.

Quelle est la suite ?

Avant de conclure, il convient de souligner un autre aspect de l'histoire du FinOps. Les points de terminaison Lakebase se réduisent à zéro. Lorsqu'une branche n'est pas interrogée, son calcul est suspendu et la facturation s'arrête. Le chiffre de 0,0107 DBU correspond au coût d'une branche qui a fonctionné, et non au coût d'une branche existante ; une flotte de branches éphémères inactive entre deux exécutions de test ne coûte rien.

Tout au long de cette série, nous avons prouvé que l'infrastructure fonctionne : une application réelle, des benchmarks réels, une gouvernance réelle, des données de coût réelles. De notre côté, Databricks et Thoughtworks collaborent pour passer du POC à la pratique : de vraies équipes de développement, de vrais sprints, de vraies mesures de vélocité. La contrainte qui a maintenu les données opérationnelles et analytiques dans des mondes distincts pendant trente ans est en train de disparaître.

Il y a un enseignement clé à retenir dès lundi matin pour chaque volet de cette série. Créez une branche pour votre prochaine migration sur un schéma réel. Réécrivez une suite de tests riche en mocks par rapport à une branche. Associez vos données de facturation à votre graphe de propriété. Les équipes qui se lanceront en premier définiront la suite.

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