Bereitstellung für die Ära der Agenten: Wie Databricks einen Self-Service-Infrastruktur-Automaten entwickelt hat

Bei Databricks ist unsere Field-Engineering-Organisation dafür da, Kunden zum Erfolg zu verhelfen. Das bedeutet, Demos zu erstellen, Probleme zu reproduzieren, Features mit echten Workloads zu testen und kurzfristig bereit zu sein, potenziellen Kunden genau zu zeigen, was auf der Plattform möglich ist. Noch nie war dies wichtiger als im Zeitalter von AI, in dem eine einzige Woche eine grundlegende Veränderung dessen bedeuten kann, was möglich ist. Mit dem Wachstum von Databricks ist es immer wichtiger – und anspruchsvoller – geworden, unsere Field-Organisation so zu unterstützen, dass sie schnell, kontrolliert und kostenbewusst agieren kann.

Um dieses Problem zu lösen, haben wir uns an die Entwicklung der Field Engineering Vending Machine gemacht, kurz FEVM. Wie bei jedem guten Verkaufsautomaten ist die Idee einfach: Sie sagen, was Sie brauchen, Sie bekommen es, und wenn Sie fertig sind, verschwindet es wieder. Was vielleicht am wichtigsten ist: FEVM basiert im Kern auf Databricks-nativen Komponenten und nutzt Agenten als First-Class-Citizens.

Wachstumsschmerzen bei der Skalierung

Vor etwas mehr als drei Jahren umfasste das Field Engineering weniger als 1.500 Personen. Eine kleine Anzahl gemeinsam genutzter Workspaces deckte die meisten Anwendungsfälle ab, und durch manuelle Wartung lief alles einigermaßen gut. Aber Databricks wuchs schnell. GTM umfasst heute über 7.000 Personen, wovon das Field Engineering einen erheblichen Teil ausmacht. Eine Infrastruktur, die bei einer bestimmten Größe funktioniert hat, erfordert bei einer anderen ein anderes Design.

Databricks-Workspaces sind für eine kleine Anzahl von Administratoren optimiert, die viele Benutzer verwalten, was für die meisten Enterprise-Bereitstellungen sinnvoll ist. Das Field Engineering hat jedoch andere Anforderungen: Fast jeder benötigt Zugriff auf Admin-Ebene, um seine Arbeit tatsächlich erledigen zu können. Das Konfigurieren von Demo-Umgebungen, das Testen von Preview-Features, das Ausführen kundenspezifischer Szenarien – all das erfordert die Kontrolle, die ein Admin-Zugriff bietet.

Bei der Skalierung führt die Koordinierung der Arbeit über gemeinsam genutzte Workspaces hinweg zu echter operativer Komplexität. Wenn mehrere Engineers während einer kritischen Demo in derselben Umgebung arbeiten, können sie sich gegenseitig in die Quere kommen, und Plattform-Limits – beispielsweise für Kataloge, Lakebase-Instanzen und gleichzeitige Workloads – werden zu einem akuten Problem statt zu einem Hintergrundthema. Die Kostenzuordnung lässt sich bei steigender Nutzung und unklareren Zuständigkeiten immer schwerer nachverfolgen.

Das Observability-Problem verschärfte diese Herausforderungen zusätzlich. Wenn in einem gemeinsam genutzten Workspace etwas Unerwartetes passierte, war eine manuelle Untersuchung erforderlich, um herauszufinden, was wann und warum geschah. Wir brauchten ein Modell, das jede Bereitstellungsaktion von Anfang an transparent, auditierbar und zuordenbar machte.

Die Erkenntnis, die FEVM prägte, war einfach: Was wäre, wenn jeder Engineer seine eigene isolierte Umgebung haben könnte, die in wenigen Minuten bereitgestellt, zentral verwaltet und automatisch bereinigt wird?

Auf Databricks bauen, für Databricks

Als Databricks Apps verfügbar wurde, war die Chance offensichtlich. Wir hatten Umgebungen bisher über eine Sammlung einzelner Jobs verwaltet – ein Job pro Aufgabe, die separat liefen und der Realität immer leicht hinterherhinkten. Apps boten uns die Möglichkeit, all das hinter einer einzigen Schnittstelle zu abstrahieren: Sagen Sie uns in einfachem Englisch, was Sie erreichen möchten, und wir finden heraus, welche Infrastruktur bereitgestellt werden muss.

Das wurde zum zentralen Designprinzip für FEVM: anwendungsfallbasierte Bereitstellung. Sie fordern keinen "Workspace" an. Sie beschreiben, was Sie tun möchten – sei es der Aufbau einer Demo für einen Finanzdienstleistungskunden, die Reproduktion eines Support-Problems oder die Durchführung einer Hackathon-Session –, und Sie erhalten eine für diesen Zweck konfigurierte Umgebung. Dies ist alles mit einem MCP im Kern abstrahiert, was bedeutet, dass Chat, externe Dienste und Agenten alle von einem einzigen Kontrollpunkt aus bedient werden. Mit dem Aufkommen von Tools wie Claude bedeutet dies, dass das Hinzufügen einer einfachen .md-Skill-Datei es Ihnen ermöglicht, auf der Befehlszeile in einfachem Englisch nach einer neuen Umgebung zu fragen und sich Minuten später anzumelden. Komplexere Workflows werden aus Nutzersicht ähnlich trivial.

Die App basiert auf einem React-Frontend mit einem Python-Backend und wird über Databricks Apps bereitgestellt. Terraform läuft im Hintergrund, um die eigentliche Bereitstellung von Cloud-Ressourcen über AWS, Azure und GCP hinweg zu übernehmen. Eine Status- und Konfigurationsdatenbank – ausgeführt auf Lakebase – verfolgt jede Ressource: was sie ist, wem sie gehört, wofür sie da ist und wann sie abläuft.

Die Entwicklungserfahrung mit Databricks Apps selbst war unkompliziert. Die komplexere Arbeit bestand in der Integration in das breitere Ökosystem: das Einrichten von Git-basierten Workflow-Starts, die Identitätsverwaltung über Unternehmenssysteme hinweg und die Sicherstellung, dass die Automatisierung administrativer Aktionen auf realer Backend-Infrastruktur innerhalb unserer Sicherheitsgrenzen blieb. Aus genau diesem Grund arbeiten wir mit einer Reihe von Sicherheitsausnahmen und haben bei jedem Schritt bewusst auf eine verantwortungsvolle Gestaltung geachtet. Neue Vorlagen werden eingehend geprüft, gehärtet und wiederholt getestet, um sicherzustellen, dass sie keine neuen Angriffsvektoren eröffnen.

Was die App tut

Wenn ein Field Engineer FEVM öffnet, wird er von einer Suchoberfläche begrüßt. Sie können einen Vorlagenkatalog durchsuchen, um den richtigen Umgebungstyp zu finden – beispielsweise stabiles Serverless auf AWS, ein Multi-Cloud-Setup oder eine Umgebung mit vorkonfigurierter Lakebase-Autoskalierung – und von dort aus konfigurieren. Sie wählen einen Cloud-Anbieter und eine Region aus, beschreiben, was sie erstellen, geben dem Ganzen einen Namen (oder akzeptieren einen zufälligen) und stellen es bereit.

Seit Kurzem unterstützen wir Agent-First-Workflows, mit denen Benutzer von zentral veröffentlichten Claude-Skills profitieren können. Dies ist eine immer beliebtere Option, die es Agenten ermöglicht, die UI zu umgehen und direkt auf die zugrunde liegenden FEVM-APIs zuzugreifen. Dies ist besonders leistungsstark bei mehrstufigen Workflows und Workflows mit mehreren Tools. Beispielsweise könnte ein Benutzer seinem Agenten befehlen, einen neuen Workspace hochzufahren, mehrere lokal entwickelte DABs bereitzustellen, in S3 gespeicherte Daten hochzuladen und dann ein Hydration-Skript auszuführen, um ein Dashboard zu befüllen. Diese Art von hyperpersonalisierter Einrichtung wäre ohne ein starkes Agenten-Framework nicht möglich – und Databricks Apps macht dies kinderleicht.

Wenn ein Benutzer oder Agent eine neue Ressource anfordert, ruft die App im Hintergrund das entsprechende Terraform-Template ab, übergibt es an einen Git Runner, passt die Bereendigungen an und fügt dann alle vom Benutzer angeforderten „Add-ons“ wie Lakebase, Notebooks oder in einem UC-Volume gehostete, vorkonfigurierte Assets hinzu. Builder-Umgebungen sind standardmäßig 90 Tage lang aktiv (mit Verlängerungsoptionen), während andere Ressourcentypen eine konfigurierbare TTL haben.

Sobald die Bereitstellung abgeschlossen ist, geht eine Slack-Benachrichtigung ein. Wenn das Ablaufdatum der Ressource näher rückt, wird eine weitere Benachrichtigung gesendet. Wenn sie gelöscht wird, werden Sie erneut benachrichtigt. Transparenz war vom ersten Tag an ein zentrales Designziel: Jedes Lifecycle-Ereignis ist sichtbar, und Engineers kennen stets den Status ihrer Ressourcen.

Wir verwalten auch gemeinsam genutzte Ressourcen über dieselbe Schnittstelle. Eigenständige Kataloge haben beispielsweise einen vom Workspace, an den sie angehängt sind, unabhängigen Lebenszyklus. Wird ein Workspace gelöscht, bleibt der Katalog bestehen. Wird ein neuer Workspace in derselben Region hochgefahren, wird der Katalog automatisch wieder angehängt. Diese Art des Lifecycle-Managements auf Ressourcenebene ist wichtig, da sowohl Unity Catalog als auch Lakebase harte Plattform-Limits haben. Bei Hunderten von Engineers, die aktiv Ressourcen bereitstellen, sorgt die zentrale Steuerung dafür, dass diese Limits nicht zum Hindernis werden.

Eine Admin-Ebene innerhalb der App ermöglicht es unserem Team, die globale Konfiguration – wie das Anpassen von Workspace-Limits je nach Cloud, das Überprüfen aktiver Bereitstellungen und das Optimieren von Standardeinstellungen – direkt über die UI zu verwalten.

Eine Skalierung, die sich unerwartet schnell bewährt hat

Während der BuildCon – einer unserer internen Engineering-Veranstaltungen – verarbeitete FEVM fast 1.200 Bereitstellungsanfragen an einem einzigen Tag. Engineers im gesamten Unternehmen fuhren Umgebungen hoch, erledigten ihre Arbeit und ließen sie wieder ablaufen – ganz ohne Koordinationsaufwand oder Ressourcenkonflikte. Bis heute sind wir auf keinerlei Skalierbarkeitsprobleme gestoßen, selbst bei mehr als 5.000 aktiven Nutzern. Zum Zeitpunkt der Erstellung dieses Berichts verwalten wir über 2.600 aktive Bereitstellungen in 3 Clouds!

Diese Zahl ist für uns nicht nur als Belastungstest wichtig, sondern auch als Proof of Concept. Die Hypothese hinter FEVM war, dass eine isolierte Just-in-Time-Bereitstellung die Reibungsverluste gemeinsam genutzter Umgebungen bei der Skalierung beseitigen könnte. Eine solche Anzahl von Aufrufen an einem einzigen Tag bestätigt, dass der Bedarf schon immer da war und die Engineers lediglich ein Tool brauchten, mit dem sie reibungslos agieren konnten.

Die agentenbasierte Zukunft, auf die wir hinarbeiten

Die umfassendere Vision, die wir bei Databricks anstreben, ist eine Agent-First-Field-Engineering-Organisation: Ein Engineer beschreibt eine Kundensituation in einfacher Sprache, ein Agent fährt eine entsprechend konfigurierte Umgebung hoch, ruft den relevanten Account-Kontext ab, versucht, das Problem zu reproduzieren oder die Demo zu erstellen, und liefert eine Zusammenfassung, die direkt an den Kunden weitergegeben werden kann. FEVM ist die Infrastrukturebene, die dies ermöglicht.

Wir haben die App zweimal umstrukturiert, um dorthin zu gelangen: Wir haben das Datenbankschema neu entworfen, das Frontend neu aufgebaut und die Art und Weise, wie wir den Status verwalten, neu überdacht. Wir haben AI genutzt, um das Coding zu beschleunigen, blieben aber bei der Architektur durchgehend federführend. Das Ergebnis ist ein System, dem wir vertrauen, dass es auch bei großer Skalierung zuverlässig läuft.

Was wir gelernt haben

Einige Prinzipien, die diese Entwicklung geprägt haben:

• Entwickeln Sie mit Blick auf die Nutzenden – egal, ob es sich um einen Menschen oder einen Agenten handelt. Wir haben hart daran gearbeitet, mit einer CUJ zu beginnen und Funktionen zu entwickeln, die genau auf diese Journey zugeschnitten sind. Das hilft uns, realistisch zu bleiben, was wirklich getan werden muss und was nur auf internen Bias beruht.
• Transparenz ist ein Feature, kein nachträglicher Gedanke. Jedes Lifecycle-Ereignis sichtbar zu machen – Bereitstellung, Ablauf, Löschung –, schafft Vertrauen bei Engineers, die für ihre tägliche Arbeit mit Kunden auf das Tool angewiesen sind.
• Die Integration in das Ökosystem ist harte Arbeit. Die Entwicklungserfahrung mit Databricks Apps war schnell und unkompliziert, aber die Anbindung von FEVM an Git, Slack, E-Mail, Corporate Identity und Multi-Cloud-Terraform hat den größten Teil des Entwicklungsaufwands ausgemacht – und auch den größten Mehrwert geliefert.

Entwickeln Sie für Databricks auf Databricks. Fast alles in FEVM läuft auf der Plattform selbst. Das gibt uns Einblicke aus erster Hand darüber, was im großen Maßstab funktioniert, und hält uns nah an der Produkterfahrung, die wir verkaufen.

Wie es weitergeht

Wir konzentrieren uns auf drei Dinge: den Ausbau der Bereitstellungsschnittstelle für natürliche Sprache, die Einführung der MCP-Integration für toolbasierten Zugriff und die Skalierung des Supports in der gesamten GTM-Organisation. Da Agenten immer mehr der Aufgaben übernehmen, die Field Engineers heute ausführen, wird FEVM zur Ressourcenebene, auf der diese Agenten ausgeführt werden – nicht nur ein Bereitstellungstool, sondern eine Kerninfrastruktur für einen agentischen Workflow.

Sehen Sie sich die Breakout-Session vom Data and AI Summit 2026 Provisioning for the Agentic Era: How Databricks Built a Self-Serve Infrastructure Vending Machine an, um weitere Details zur FE Vending Machine zu erfahren.

Um mehr über die Entwicklung produktionsreifer Apps auf Databricks zu erfahren, lesen Sie Databricks Apps, Lakebase und Agent Bricks.

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