Hinter den Kulissen von Lakebase, Teil 3

Im ersten Teil dieser Serie ermöglichte uns die Ausführung von Backstage auf Databricks Lakebase ein Datenbank-Branching in Sekundenschnelle. Im zweiten Teil wiederum integrierte Unity Catalog diese operative Datenbank in die Governance-Ebene des Unternehmens.

Doch hier ist der entscheidende Nutzen, der das Organigramm tatsächlich verändert.

In einem normalen Stack überschreitet die Beantwortung der Frage „Wer ist für die Infrastruktur verantwortlich, die unsere Cloud-Ausgaben in die Höhe treibt, und was hat sie gekostet?“ zwei Grenzen. Der Ownership-Graph befindet sich in Backstage (verwaltet vom Platform Engineering), während die Kostendaten in einem Data Warehouse liegen (verwaltet vom Datenteam). Die Beantwortung dieser Frage erfordert eine ETL-Pipeline, ein Jira-Ticket oder einen Slack-Thread.

Getrenntes Compute macht gemeinsame Nutzung möglich

Der Grund, warum ein FinOps-Analyst massive analytische Abfragen auf genau demselben zugrunde liegenden Speicher ausführen kann, ohne das Live-Portal zu beeinträchtigen, liegt darin, dass Lakebase das Compute pro Workload isoliert.

Backstage erhält eine eigene isolierte, automatisch skalierende Compute-Umgebung. Bei normaler Portalnutzung liefen Katalogabfragen in 55–65 ms End-to-End, und Suchanfragen dauerten zwei bis vier Millisekunden. Da Ihre Webanwendung und Ihre analytischen Workloads nicht um denselben Compute-Cluster konkurrieren, können sie sich endlich sicher dasselbe Datensubstrat teilen.

Der Workaround: Lakehouse-Federation-Authentifizierung

Um die Live-Postgres-Daten mit unseren analytischen Abrechnungsdaten zusammenzuführen, verwenden wir Databricks Lakehouse Federation. Der Postgres-Connector von Lakehouse Federation unterstützt derzeit jedoch nur statische Benutzer-/Passwort-Anmeldedaten. Da Lakebase App-Identitäten über OAuth-JWTs authentifiziert, benötigt die Federation-Engine einen parallelen Authentifizierungspfad.

Der Workaround besteht darin, eine native Postgres-Rolle mit SCRAM-SHA-256-Authentifizierung zu erstellen, die unabhängig von der von der App verwendeten OAuth-Identität mit der Federation verknüpft ist:

Sie verwalten nun zwei Authentifizierungspfade für dieselbe Datenbank.

Der FinOps-Join

Sobald der externe Katalog live ist, kann ein FinOps-Analyst eine einzige Abfrage schreiben, die den Backstage-Ressourcennamen direkt aus der operativen Postgres-Tabelle abruft und ihn mit den eigenen Abrechnungszeilen von Lakebase in system.billing.usage zusammenführt:

Tatsächliches Ergebnis:

Die linke Seite dieser Zeile stammt direkt aus dem Live-Postgres-Katalog von Backstage; die rechte Seite stammt aus einer Systemabrechnungstabelle von Unity Catalog. Diese beiden Dinge befanden sich in der Vergangenheit noch nie in derselben SQL-Engine und werden nun ohne jegliche Datenverschiebung zusammengeführt.

Warum nicht einfach ETL verwenden?

Ein Skeptiker könnte fragen, warum wir nicht einfach ein Python-Skript verwenden, um eine RDS-Instanz einmal pro Stunde mit einer Delta-Tabelle zu synchronisieren.

Die Antwort lautet Branching. Wenn ein Entwickler einen flüchtigen Datenbank-Klon in Sekundenschnelle erstellt, um einen PR zu testen, müssten Sie dynamisch neue ETL-Pipelines bereitstellen, nur um Kostentransparenz für diese temporäre Testumgebung zu erhalten. Mit Lakebase sind die Abrechnungs- und Ownership-Daten in dem Moment, in dem der Branch erstellt wird, sofort abfragbar. (In diesem POC wurde der verworfene Test-Branch automatisch und unabhängig mit 0,0107 DBU veranschlagt).

Konvergenz operationalisieren

Diese dreiteilige Serie begann mit einem Datenbank-Branch in Sekundenschnelle, ging über eine einheitliche Governance und landete hier – einer einzigen SQL-Abfrage, die operative Ownership-Daten ohne Pipelines dazwischen mit Cloud-Abrechnungsdaten zusammenführt. Das ist der Beweis, dass Konvergenz technisch funktioniert. Die Frage, die sich Praktiker als Nächstes stellen werden, lautet: Was ist nötig, um dies zu operationalisieren?

Zwei Dinge sind bei diesem POC besonders aufgefallen, die für Teams, die diesen Weg einschlagen möchten, erwähnenswert sind.

Die Authentifizierungslücke bei der Federation

Der von uns beschriebene Lakehouse Federation-Workaround – eine native Postgres-Rolle mit statischen Anmeldedaten, die separat von der von der App verwendeten OAuth-Identität verknüpft ist – ist heute der richtige Ansatz. Jedes Team, das seine operativen Lakebase-Daten mit analytischen Tabellen in Unity Catalog zusammenführen möchte, muss diesen parallelen Authentifizierungspfad einrichten. Die Federation sollte ohnehin wahrscheinlich nicht als Ihr Anwendungsbenutzer ausgeführt werden, sodass die Trennung einen Sicherheitsvorteil bietet, aber die Passwortrotation liegt in Ihrer Verantwortung. Für Teams, die dieses Muster übernehmen, können die Schritte in einem wiederholbaren Skript zusammengefasst werden – ein sicheres Passwort generieren, die Rolle mit Leserechten erstellen, die Verbindung herstellen, den externen Katalog erstellen. Einmalige Einrichtung, die in wenigen Minuten erledigt ist, sobald man das Muster kennt. Eine native Unterstützung von OAuth-JWTs in der Federation würde diesen Workaround komplett überflüssig machen.

Kostentransparenz von Branches für Entwicklerteams

Der FinOps-Join beantwortet die Plattformfrage: Was kostet diese Infrastruktur und wer ist dafür verantwortlich? Aber dieselben Abrechnungsdaten erzählen eine zweite Geschichte, die für Engineering Manager wichtig ist: Was kostet der Entwicklungsprozess selbst?

Im Branching-Workflow aus Teil eins erstellt jeder Pull-Request einen flüchtigen CI-Branch und jeder Entwickler hat seinen eigenen Feature-Branch. Diese werden als unabhängige Posten in system.billing.usage aufgeführt, aufgeschlüsselt nach branch_id und endpoint_id. Ein Engineering Manager kann genau sehen, wie viel Compute das Dev/Test-Branching seines Teams in einem Sprint im Vergleich zur Produktion verbraucht hat – und fundierte Entscheidungen über Richtlinien für den Lebenszyklus von Branches treffen.

Der Schlüssel liegt darin, dass flüchtige Branches auch in den Abrechnungsdaten als flüchtig behandelt werden sollten. CI-Branches, die mit einer kurzen TTL erstellt wurden, laufen automatisch ab, wenn die Bereinigung aus irgendeinem Grund fehlschlägt – ein direkter Push auf den Main-Branch, ein Workflow-Fehler, ein verpasstes Ereignis. Ohne Lebenszyklus-Kontrollen können sich verwaiste Branches unbemerkt ansammeln, wobei jeder einzelne mit einem aktiven Compute-Endpunkt Kosten für das Projekt verursacht. Der Test-Branch kostete 0,0107 DBU. Das ist minimal. Dreißig verwaiste Branches, die einen Monat lang laufen, sind es nicht.

Es geht nicht darum, dass Branching teuer ist – es ist eine Abwägung zwischen Kosten und Produktivitätsgewinn. Wenn ein Team zwei Tage Wartezeit auf Umgebungen pro Sprint einspart und aufhört, 20–30 % seiner Codebasis in Mock-Objekten zu pflegen, sind die 0,0107 DBU pro Branch kein Kostenfaktor, den man mühsam verwalten muss – es ist die günstigste Produktivitätsinvestition, die das Team je getätigt hat. Und im Gegensatz zu den meisten Produktivitätsinvestitionen ist diese messbar: die Infrastruktur zeigt Ihnen genau, was sie gekostet hat – pro Branch, pro Entwickler, pro Sprint. Das ist ein Gespräch, das die meisten Engineering-Teams noch wie vor mit ihrer Datenbank führen konnten.

Wie es weitergeht

Bevor wir zum Schluss kommen, gibt es noch einen weiteren Punkt zur FinOps-Story, der hervorgehoben werden sollte. Lakebase-Endpunkte skalieren auf Null. Wenn ein Branch nicht abgefragt wird, pausiert sein Compute und die Abrechnung stoppt. Der Wert von 0,0107 DBU entspricht den Kosten für einen ausgeführten Branch, nicht für einen existierenden Branch; eine Flotte flüchtiger Branches, die zwischen Testläufen ungenutzt bleibt, verursacht keinerlei Kosten.

In dieser Serie haben wir bewiesen, dass die Infrastruktur funktioniert – echte App, echte Benchmarks, echte Governance, echte Kostendaten. Von unserer Seite aus arbeiten Databricks und Thoughtworks zusammen, um dies vom POC in die Praxis zu übertragen: echte Entwicklungsteams, echte Sprints, echte Velocity-Messungen. Die Einschränkung, die operative und analytische Daten dreißig Jahre lang in getrennten Welten hielt, löst sich auf.

Aus jedem Teil dieser Serie lässt sich eine direkte Erkenntnis für den Montagmorgen mitnehmen. Erstellen Sie einen Branch für Ihre nächste Migration auf einem echten Schema. Schreiben Sie eine mock-intensive Suite für einen Branch um. Verknüpfen Sie Ihre Abrechnungsdaten mit Ihrem Ownership-Graphen. Die Teams, die zuerst handeln, werden bestimmen, was als Nächstes kommt.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag