Databricks startet Private Network Gateway für Serverless Compute

Warum das Netzwerk Serverless ausbremste

Databricks beschreibt Serverless Compute als vollständig verwaltet, intelligent und versionslos. Für viele Teams blieb laut Databricks ein Schritt besonders aufwendig: das Netzwerk, also ein privater Zugang von Serverless Compute zu Datenbanken, Anwendungen und Systemen im eigenen Netz.

Nach Angaben des Unternehmens nannten in Kundengesprächen mehr als 75 % die aktuelle Netzwerkkonfiguration und den Aufwand bei Netzwerkänderungen als Hauptgrund dafür, dass bestimmte Workloads auf klassischem Compute blieben, statt auf Serverless umzuziehen.

Der Unterschied liegt in der Architektur. Klassisches Compute läuft im eigenen virtuellen Netzwerk des Kunden, der Datenzugriff ist daher über Peering mit gängigen Cloud-Bausteinen lösbar. Serverless läuft in einem von Databricks verwalteten Netzwerk. Das spart Betriebsaufwand, doch private Ressourcen brauchen dann einen expliziten Pfad.

Serverless Private Link liefert diesen Pfad und bleibt laut Databricks das richtige Werkzeug für Cloud-Dienste wie AWS S3 oder Azure Data Lake Storage. Bei selbst gehosteten Ressourcen wie Datenbanken, Kafka-Clustern oder internen APIs bedeutete die Anbindung oft einen eigenen Private Endpoint, einen Load Balancer und eine Proxy-VM pro Ressource. Hinzu kam die Abstimmung zwischen Databricks-Admin, Cloud-Admin und Netzwerksicherheitsteam. Dieser Ansatz pro Ressource werde zum Engpass, wenn ein Team auf Dutzende Datenbanken, APIs und interne Dienste über VNets, gepeerte Netzwerke und On-Premises-Umgebungen hinweg zugreifen müsse, so Databricks.

So funktioniert das Private Network Gateway

Mit PNG delegiert der Kunde ein Subnetz seines virtuellen Netzwerks an Databricks, und PNG baut von Serverless Compute aus ein verwaltetes, verschlüsseltes Gateway in dieses Subnetz auf. Konfiguriert wird das Gateway in einer Network Connectivity Configuration (NCC), dem bereits für Serverless-Netzwerke genutzten Objekt auf Account-Ebene. Die NCC wird anschließend Workspaces zugewiesen, und unterstützte Serverless-Workloads erreichen dann die privaten Ziele, die der Kunde freigibt.

Databricks erstellt und betreibt das Gateway, sodass Kunden keine Gateway-VMs bereitstellen, patchen oder skalieren müssen. Laut Unternehmen skaliert PNG nach Netzwerk, nicht nach Endpoint, und bestehende Routen, DNS- und Firewall-Regeln bestimmen, was erreichbar ist.

Databricks nennt mehrere Anwendungsfälle:

• Private Datenbank-Ingestion: Mit Lakeflow Connect auf Serverless Compute lassen sich Daten aus unterstützten Datenbanken über VNet/VPC und angebundene On-Premises-Umgebungen einlesen.
• KI-Agenten: Ein auf Databricks gebauter Agent kann einen privaten, vom Kunden gehosteten MCP-Server aufrufen.
• Private Paket-Repositories: Serverless kann Python-Bibliotheken aus einem privaten PyPI-, Artifactory- oder Nexus-Repository im Kundennetz installieren.
• Eigene Firewall für ausgehenden Verkehr: Der Traffic lässt sich über eine vorhandene Firewall oder einen Content-Inspection-Dienst leiten, sodass Egress mit den eigenen Tools gefiltert und protokolliert wird.
• Source-IP des Kunden: SaaS-Anwendungen wie Salesforce sehen eine Quell-IP, die dem Kunden gehört.

Die Kontrolle bleibt beim Kunden

Laut Databricks ist das Gateway dem Kunden exklusiv zugeordnet und keine geteilte Appliance, über die der Datenverkehr anderer Kunden läuft. Die Isolation wird durch Kapselung und Netzwerksicherheitsregeln durchgesetzt, und das Gateway erzwingt Zugriffskontrollen auf Workspace-Ebene, bevor Traffic das System verlässt. Jenseits des Subnetzes entscheiden die Routing-Tabellen, Netzwerksicherheitsgruppen, DNS-Resolver und Sicherheits-Appliances des Kunden, was Serverless erreichen darf.

Kunden können zwischen zwei Modi wählen. Der Modus specific_destinations leitet nur aufgelistete Fully Qualified Domain Names über PNG, der übrige Traffic nimmt weiter seinen normalen Weg. Der Modus all_traffic führt ausgehenden Verkehr über das Kundennetz, mit Ausnahme von allem, was zu einem spezifischeren Private-Link- oder Service-Endpoint-Pfad passt und seine native Route behält. Databricks empfiehlt diesen Modus, um breiten Egress über eine Firewall zu prüfen oder über eigene IP-Adressen des Kunden auszuleiten.

PNG ist laut Databricks additiv. Es steht neben bestehender privater Konnektivität und Egress-Kontrollen, ohne sie zu verändern, und lässt sich daher aktivieren oder entfernen, ohne die vorhandene Konfiguration zu beeinträchtigen.

Fabiano Seki von Banco Bradesco sagte, mit dem Gateway entfalle das "Aufsetzen eines Private-Link-Dienstes und Load Balancers für jede einzelne Verbindung". Auch Primož Gale von NLB und Michel Schwandner von Julius Blum GmbH äußerten sich in der Ankündigung positiv.

Verfügbarkeit und Einordnung

PNG ist auf Azure als Public Preview verfügbar, die Dokumentation stellt Databricks bereit. Auf AWS läuft es als Private Preview, Kunden sollten für eine Teilnahme ihr Databricks-Account-Team kontaktieren. Die Unterstützung für Google Cloud ist in Entwicklung.

Für Teams, die Workloads wegen der Netzwerkkomplexität auf klassischem Compute gelassen haben, zielt die Neuerung genau auf diese Hürde. Da es sich noch um eine Preview handelt, müssen Unternehmen sie anhand ihrer eigenen Netzwerk- und Sicherheitsanforderungen prüfen.