Wir haben unseren Enterprise-Databricks-KI-Plattform-Blueprint als Open Source veröffentlicht
Eine produktionsreife Open-Source-Referenzarchitektur für Azure Databricks — Netzwerk, Sicherheit, MLOps, agentische KI und CI/CD, basierend auf dem Azure Well-Architected Framework.
Eine Enterprise-KI-Plattform von Grund auf aufzubauen ist ein mehrmonatiges Unterfangen. Sie müssen Netzwerk, Sicherheit, Data Governance, Compute, ML-Lifecycle-Management und CI/CD lösen — und alles muss zusammenarbeiten. Die meisten Teams fügen entweder Tutorials zusammen, die kritische Lücken lassen, oder bezahlen Berater, um etwas Proprietäres zu bauen, das sie nie vollständig besitzen können.
Wir haben uns entschieden, das zu ändern. Heute veröffentlichen wir unseren kompletten Enterprise-Databricks-Plattform-Blueprint als Open Source: databricks-enterprise-ai-platform.
Was das ist
Dies ist kein Quickstart oder Hello-World-Terraform-Modul. Es ist eine vollständige Produktions-Referenzarchitektur, die eine Azure-Databricks-Plattform für ML- und LLM-Workloads provisioniert, konfiguriert und betreibt. Jede Designentscheidung ist dem Azure Well-Architected Framework über alle fünf Säulen zugeordnet: Zuverlässigkeit, Sicherheit, Kostenoptimierung, operative Exzellenz und Leistungseffizienz.
Das Repository enthält:
- 9 Terraform-Module für Landing Zone, Netzwerk, Firewall, Sicherheit, Storage, Monitoring, Databricks, Compute-Integration und Container Registry
- Delta-Lake-Medallion-Architektur mit Unity-Catalog-Governance
- 3 Beispiel-ML-Projekte mit echtem Trainingscode (Umsatzprognose, Anomalieerkennung, LLM-Dokumenten-Triage)
- 3 agentische KI-Muster auf Azure Functions (Orchestrator, Multi-Agent, Monitoring-Responder)
- 4 GitHub-Actions-Workflows für Infrastruktur- und ML-CI/CD ohne gespeicherte Geheimnisse
Die Architektur
Die Plattform folgt einer Hub-Spoke-Netzwerktopologie:
Das Hub-VNet hostet gemeinsame Dienste — Azure Firewall mit erzwungenem Tunneling, Azure Bastion für sicheren Managementzugang, VPN Gateway mit Entra-ID-Authentifizierung und Private-DNS-Zonen für sieben Azure-Dienste.
Das Spoke-VNet hostet die Workloads — Databricks mit VNet-Injection und Secure Cluster Connectivity (keine öffentlichen IPs auf Compute-Knoten), Azure Functions mit VNet-Integration und Private Endpoints für Storage, Key Vault und Container Registry.
Jeglicher ausgehender Verkehr fließt durch Azure Firewall mit expliziten FQDN-Whitelists. Kein PaaS-Dienst hat einen öffentlichen Endpunkt. Drei benutzerzugewiesene Managed Identities übernehmen die Authentifizierung — keine Passwörter oder API-Keys im gesamten Stack.
Warum wir das gebaut haben
Jedes Enterprise-Engagement, das wir bei CC Conceptualise durchführen, beginnt mit derselben grundlegenden Arbeit: sicheres Netzwerk einrichten, Databricks mit privater Konnektivität konfigurieren, den Data Lake mit korrekter Verschlüsselung aufbauen und CI/CD verdrahten. Wir haben immer wieder dieselben architektonischen Probleme gelöst.
Anstatt dieses Wissen in Kundenprojekten eingeschlossen zu halten, haben wir die Muster in einen wiederverwendbaren, opinionierten Blueprint extrahiert, den jedes Team forken und anpassen kann.
Was das besonders macht
Zero-Trust standardmäßig, nicht nachträglich aufgesetzt. Private Endpoints auf jedem PaaS-Dienst. Firewall-erzwungenes Tunneling für allen ausgehenden Verkehr. OIDC-Federation für CI/CD — kein einziges Client Secret in GitHub.
WAF-Ausrichtung ist dokumentiert, nicht angenommen. Jede Terraform-Ressource enthält Kommentare, die sie spezifischen Well-Architected-Framework-Säulen mit Begründung zuordnen. Das ist audit-fertig.
End-to-End, nicht nur Infrastruktur. Die meisten Open-Source-Terraform-Repos enden bei „hier ist ein Databricks-Workspace". Unseres geht weiter durch Unity-Catalog-Setup, Medallion-Datenpipelines, ML-Modelltraining und -Promotion, agentische KI-Workflows und automatisiertes CI/CD.
Kostenkontrollen eingebaut. Konfigurierbare Budget-Alerts (Standard 1.000$), Cluster-Policies mit maximalen Workern und erzwungenem Auto-Termination, Storage-Lifecycle-Regeln und verbrauchsbasierte Functions.
Die 9 Module
| Modul | Funktion |
|---|---|
landing_zone | Ressourcengruppe + Azure-Policy-Enforcement (Tags, Standort, HTTPS, Diagnose) |
networking | Hub-Spoke-VNets, 7+ Subnetze, NSGs, Routentabellen, NAT Gateway, Private DNS Zones, VPN, Bastion |
firewall | Azure Firewall mit Application- und Network-Regelsammlungen |
security | Key Vault mit Private Endpoint, 3 Managed Identities, RBAC-Rollenzuweisungen |
storage | ADLS Gen2, 4 Container (Bronze/Silver/Gold/MLflow), CMK-Verschlüsselung, Lifecycle-Regeln |
monitoring | Log Analytics, Application Insights, Aktionsgruppen, Budget-Alerts, geplante Query-Alerts |
databricks | Premium-Workspace mit VNet-Injection, 4 Private Endpoints, Access Connector |
compute_integration | Azure Functions EP1, Service Bus Premium (3 Queues), Event Grid |
acr | Container Registry Premium mit Private Endpoint und AcrPull-RBAC |
Agentische KI-Muster
Das Repository enthält drei produktionsreife agentische KI-Muster auf Azure Functions:
Durable Orchestrator: Ein sequentieller Workflow, der Daten validiert, einen Databricks-Trainingsjob auslöst, auf Abschluss wartet, Metriken evaluiert und entscheidet, ob das Modell promoted oder abgelehnt wird.
Multi-Agent (Planner-Executor-Critic): Eine iterative Schleife, in der ein Planner-Agent eine Aufgabe zerlegt, ein Executor-Agent sie ausführt und ein Critic-Agent das Ergebnis bewertet — mit bis zu drei Wiederholungsversuchen bei Ablehnung.
Monitoring Responder: Ein ereignisgesteuerter Agent, der durch Service-Bus-Nachrichten von Monitoring-Alerts aktiviert wird. Er klassifiziert den Schweregrad, erstellt einen Incident-Eintrag und führt automatische Gegenmaßnahmen durch.
Erste Schritte
git clone https://github.com/MedGhassen/databricks-enterprise-ai-platform.git
cd databricks-enterprise-ai-platformBeginnen Sie mit dem docs/-Verzeichnis für die Architekturdokumentation und die WAF-Ausrichtungsmatrix. Überprüfen Sie dann die Terraform-Variablendefinitionen in den Modulverzeichnissen, um die Konfigurationsoptionen zu verstehen, bevor Sie terraform init und terraform plan ausführen.
Das Projekt steht unter der MIT-Lizenz. Forken Sie es, passen Sie es an, zerlegen Sie es. Wenn Sie etwas Interessantes darauf aufbauen, würden wir gerne davon hören.
Weiterführende Ressourcen
- Data-Lakehouse-Architektur auf Azure — Vertiefung des Medallion-Architekturmusters, das in dieser Plattform verwendet wird.
- MLOps auf Azure: Vom Experiment zur Produktion — Die MLOps-Praktiken, die den ML-Lifecycle in diesem Blueprint steuern.
- Infrastructure-as-Code-Strategie — Strategische Grundlagen für die Verwaltung von Terraform im Enterprise-Maßstab.
Fragen zum Deployment dieser Plattform oder zur Anpassung an Ihre Infrastruktur? Kontaktieren Sie uns — wir haben sie gebaut und helfen Teams bei der Operationalisierung.