Constantin Budin, Cloud- und Platform-Engineer bei Pexon Consulting | 8 Min. Lesezeit | 16.09.2026
Das hier ist keine Anleitung. Es ist der Bericht aus einem Mandat, in dem Pexon Consulting einen Digital Twin Azure für die Simulationssoftware eines internationalen Pharma- und Biotech-Anbieters gebaut hat. Sechs Monate Hauptbeteiligung, Start 2023. Am Ende liefen hybride Modelle produktiv in Azure ML Studio und waren über Cloud-Endpoints für Kunden erreichbar.
| In diesem Projekt | |
|---|---|
| Was | Kundenreferenz, internationaler Pharma-/Biotech-Anbieter mit Simulationssoftware für Bioreaktoren, über 18.000 Mitarbeitende weltweit, DSGVO und Pharma-F&E-Datenschutz |
| Auftrag | Digital Twin Azure: hybride Simulationsumgebung, Feature-Pipelines, Governance, produktive Endpoints |
| Team | Pexon, Senior Cloud- und Data-Engineering |
| Dauer | sechs Monate Hauptbeteiligung, Start 2023 |
| Stack | Azure ML Studio, Azure Databricks, PostgreSQL, Microsoft Purview, Unity Catalog, Terraform, Docker, Kubernetes, Python |
| Stand | hybride Modelle und Endpoints produktiv, weiterer Ausbau derzeit beim Kunden |
Digital Twin Azure: Produkt intern, Cloud-Naht bei uns
Der Kunde entwickelt Simulationssoftware für Bioreaktoren. Ein Nischenprodukt, das den Verlauf von Bioprozessen virtuell abbildet, mit einem globalen Kundenstamm und einer wachsenden Zahl angeschlossener Laborinstrumente. Konsolidierter Umsatz rund 2,7 Mrd. USD. Die fachliche Semantik lag intern: Metabolitenmodelle, Bioprozess-Parameter, was ein Batch in der Lab-Realität bedeutet. Genau das bleibt intern. Was wir geliefert haben, ist die Fläche, auf der dieser Twin trainiert, versioniert und nach außen gegeben werden kann.
Die Software war der erste Schritt in die Cloud schon gegangen, als Lift-and-Shift. Für Head of Data und Cloud Engineering war der nächste Maßstab klar: skalierbare Simulationsleistung, reproduzierbare Trainingsläufe, Integration über Cloud-Endpoints. Nicht noch eine Kopie der Binaries.
Pexon Consulting kam als Partner für genau diese Naht. Produkt und Domain bleiben intern. Workspace-Struktur, Trainings-Orchestrierung, Feature-Pipelines, Endpoint-Lifecycle und Governance lagen bei uns. So eine Teilung ist in F&E-Mandaten oft der saubere Schnitt: die Wissenschaft bleibt im Haus, die cloud-native Fläche kommt von Leuten, die Azure ML und Databricks täglich bauen. Ohne diese Teilung landet entweder die Domain in einer Blackbox oder die Cloud-Seite als Folienarchitektur. Beides wäre in diesem Mandat falsch gewesen.
Daten kamen aus Laborinstrumenten, historischen Batch-Verläufen, metabolischen Messreihen und konfigurierbaren Reaktorparametern. Ohne klare ETL-Strecke werden Features inkonsistent und Trainingsläufe schwer vergleichbar. Parallel gelten in der Pharma-F&E Lineage, Sensitivity und Access-Controls, nicht nur performante Jobs. Microsoft Purview war der gesetzte Governance-Standard, Unity Catalog die Databricks-Seite davon. Netz und Endpoint-Härtung gehörten von Tag eins zur Architektur.
Was Digital Twin Azure konkret hieß
Wir haben die Simulationsumgebung um ein hybrides Prinzip gelegt. Das mechanistische Metabolitenmodell liefert den physikalisch-biologischen Rahmen. Machine Learning verfeinert dort, wo reine Mechanik an Datenknappheit oder nicht modellierte Effekte stößt.
Reine ML-Modelle halten in F&E-Bioprozessen oft nicht, weil die Trainingsmenge zu klein ist. Reine Mechanik allein trifft die Lab-Realität nicht immer. Die Kombination war die bewusste Entscheidung, nicht der Kompromiss. Azure ML Studio wurde zur Trainings- und Inferenz-Plattform mit Lifecycle von Dataset über Run bis Endpoint, nicht zur Experimentierfläche.
Vier Entscheidungen haben das Mandat getragen.
- Databricks für ETL und Feature-Prep, Azure ML für Training und Inferenz. Spark-Jobs, nachvollziehbare Notebooks und Unity Catalog tragen wachsende Instrument-Feeds besser als eine reine Studio-Pipeline. Die Studio-Seite bleibt der Ort, an dem Runs, Modelle und Endpoints denselben Lifecycle haben.
- PostgreSQL als persistenter Layer, Schema eng geschnitten. Hochfrequente Bioprozess-Daten brauchen klare Feature-Tabellen und kurze Query-Pfade für Training und Inferenz. Mehr Disziplin im Schema statt eines weiten Lake-Schemas. Dafür reproduzierbare Features und kürzere Debug-Zyklen.
- Hyperparameter-Suche parallel, nicht sequentiell. Die Suche läuft als Azure-ML-Sweep mit mehreren Trials gleichzeitig. Die Visualisierung der Runs ist das Werkzeug der F&E-Teams, kein einmaliger Report. Höhere Pipeline-Kosten am Anfang, dafür vergleichbare Experimente statt des letzten lokal gespeicherten Notebooks.
- Endpoints erst, wenn Lineage sitzt. Microsoft Purview und Unity Catalog dokumentieren die Datenflüsse, Access und Sensitivity folgen dem Pharma-F&E-Rahmen. Terraform und CI/CD für Workspace, Modell und Service. Der erste Spike dauert länger. Jeder Folge-Deploy und der Wissenstransfer werden kürzer.
from azure.ai.ml import command
from azure.ai.ml.sweep import Uniform, Choice
# Parallele Suche, nicht sequentiell am Laptop.
job = command(
code="./src",
command="python train.py --lr ${{inputs.lr}} --hidden ${{inputs.hidden}}",
environment="azureml:bioreactor-train:1",
compute="gpu-cluster",
inputs={"lr": 0.01, "hidden": 128},
)
sweep = job.sweep(
sampling_algorithm="random",
primary_metric="val_rmse",
goal="minimize",
)
sweep.extend_search_space(
lr=Uniform(0.0001, 0.01),
hidden=Choice([64, 128, 256]),
)
sweep.set_limits(max_total_trials=32, max_concurrent_trials=8)Managed Online Endpoints sind der Produkt-Schnitt, nicht ein internes Artefakt. Die Microsoft-Dokumentation zu Azure Machine Learning Endpoints beschreibt denselben Lifecycle, den wir hier produktiv geschaltet haben: Dataset, Run, Modell, Endpoint.
Den Rahmen, den wir sonst als Azure Beratung schneiden, haben wir hier an der ML- und Databricks-Naht umgesetzt. Das hier ist das Mandat, nicht das Produktblatt.
Sobald Kunden den Twin nutzen, nicht nur F&E
Der Sprung in diesem Mandat war nicht der erste Trainingslauf. Der Sprung war, dass derselbe Twin über Cloud-Endpoints in Kunden-Systeme geht.
Ab da gilt ein anderer Maßstab. Reproduzierbare Runs reichen nicht mehr. Lineage muss über Instrument-Feed, Feature-Tabelle, Training und Inferenz greifen. Access muss zum Pharma-F&E-Rahmen passen. Ein Endpoint, den niemand nachziehen kann, ist intern interessant und nach außen nicht freigabefähig.
Das ist nach einer Produktöffnung der normale nächste Schritt, kein Sonderfall. Die Nähte haben gehalten, weil sie schon da waren: Databricks als ETL, Azure ML als Lifecycle, Purview plus Unity Catalog als Katalog, Terraform als Wiederholbarkeit. Was dazukam, war die produktive Schaltung der Endpoints, nicht ein Plattform-Neubau unter Kundendruck.
| Dimension | Vorher | Nachher | Effekt |
|---|---|---|---|
| Simulationsbetrieb | On-Premise bzw. Lift-and-Shift ohne cloud-native Orchestrierung | Hybride Modelle produktiv in Azure ML Studio mit Cloud-Endpoints | Digital Twin als Kundenintegration statt lokaler Installation |
| Modelloptimierung | Manuelle, weitgehend sequentielle Versuche | Automatisierte Suche mit parallelen Runs und Visualisierung | Vergleichbare Experimente für F&E, kürzere Optimierungszyklen |
| Daten und Pipelines | Heterogene Quellen, hohe Modellkomplexität | Databricks ETL, engeres PostgreSQL-Schema | Reproduzierbare Features, skalierbare Bioprozess-Datenflüsse |
| Governance | Lineage nicht durchgängig über Cloud-Pipelines greifbar | Purview plus Unity Catalog, Terraform und CI/CD | Nachvollziehbare Deployments unter DSGVO und Pharma-F&E |
Was am Ende stand
Von unserer Seite war die Hauptbeteiligung nach sechs Monaten fertig. Hybride Simulationsmodelle liefen produktiv in Azure ML Studio. Cloud-Endpoints waren für die kundenseitige Nutzung geschaltet. Die Hyperparameter-Suche lief parallel. Data Lineage über die Bioprozess-Datenflüsse war in Purview dokumentiert. Der Twin ist damit Produkt, nicht nur internes F&E-Artefakt. Der weitere Plattform-Ausbau liegt derzeit beim Kunden. Das ändert nichts am übergebenen Stand: Modelle, Endpoints, Lineage und IaC sind da und vom internen Team weitertragbar.
Drei Dinge würde Pexon in einem vergleichbaren Mandat wieder so machen. Metabolitenmodell plus ML, nicht reines ML auf dünnen Batches. Databricks für Features, Azure ML für Run und Endpoint. Purview und Unity Catalog bevor der erste Kunden-Endpoint live geht.
Wer die Governance hinterherzieht, baut den Twin zweimal. Einmal als F&E-Notebook, einmal als Produkt. Die zweite Runde ist die teure.
Pexon Consulting hat das Hands-on gebaut, im Kunden-Tenant, mit Azure-Leuten die selbst im Workspace stehen. 80 Mitarbeitende in Deutschland, Microsoft Partner, ISO 27001. Der technische Stand in diesem Bericht ist der, den Pexon übergeben hat.
Wer selbst Bioprozess-Simulationen cloud-native skalieren will: Bringen Sie den Tenant mit, eine ehrliche Aussage ob das Metabolitenmodell schon steht, und ob die Endpoints Produkt für externe Kunden sind oder interne F&E bleiben. Dann können wir sagen, ob Digital Twin Azure in dieser Form passt oder ob bei Ihnen ein anderer Schnitt sitzen muss.
Nächster Schritt
Das Mandat ist in der übergebenen Form abgeschlossen. Wenn Sie vor einem ähnlichen Aufbau stehen, gehen wir die Naht an Ihrem Workspace und Ihrer Datenlage durch, nicht an dieser Story.
HTML-Tags strictly limited to: `
`, `
`, `
`, `
- `, `
- `, ``. No code fences, no markdown, no ``, ``.
* Output strictly ONLY the HTML, nothing else.7. **Final Polish of the HTML:**
Ensure valid HTML entities/characters, clean structure.
No Markdown markers (` „`html `).Netzwerk-Isolation und Zugriffsschutz
Netzwerk-Isolation und Zugriffsschutz im Pharma-Umfeld
Die Bereitstellung produktiver Inferenz-Schnittstellen für externe Kunden erfordert eine strikte Netztrennung, insbesondere wenn Forschungsdaten und geistiges Eigentum auf derselben Plattform verarbeitet werden. In diesem Projekt durften Trainingsdaten, Modellgewichte und Zwischenergebnisse zu keinem Zeitpunkt über öffentliche Schnittstellen erreichbar sein. Die Herausforderung bestand darin, Azure Machine Learning und Azure Databricks vollständig in private virtuelle Netzwerke einzubinden, ohne die Agilität der Entwicklungszyklen zu ersticken.
Wir haben die Plattform über Azure Private Link und dedizierte Private Endpoints abgesichert. Sämtliche Kommunikation zwischen den Databricks-Clustern, den Speicherkonten mit den Rohdaten der Laborinstrumente und den Compute-Instanzen in Azure ML verlief über isolierte Subnetze. Der Zugriff auf den zentralen PostgreSQL-Layer wurde über restriktive Network Security Groups und Service Endpoints an die jeweiligen Inferenz-Routinen gekoppelt. Öffentliche IP-Adressen wurden auf Workspace-Ebene deaktiviert, was zwar den initialen Einrichtungsaufwand erhöht, aber das Risiko von Datenabflüssen eliminiert.
Für die F&E-Teams brachte dieser Aufbau eine spürbare Umstellung mit sich. Lokale Werkzeuge konnten nicht mehr ohne Weiteres gegen die Cloud-Dienste geschaltet werden; der Zugriff erforderte konfigurierte VPN-Tunnel und abgesicherte Bastion-Verbindungen. Beim Entwurf solcher Architekturen ist dieser Mehraufwand früh einzuplanen:
- Private DNS Zones konsistent verwalten: Azure ML und Databricks benötigen dutzende interne DNS-Einträge für Storage, Workspace-Artefakte und Key Vaults. Fehler im Routing führen hier sofort zu schwer diagnostizierbaren Timeout-Fehlern beim Pipeline-Start.
- Egress-Traffic minimieren: Paket-Downloads über PyPI oder Conda während des Container-Starts schlagen in isolierten Netzen fehl. Basis-Images für Trainingsläufe müssen vorab kuratiert und in einer privaten Azure Container Registry abgelegt werden.
- Getrennte Kontrollpfade: Administrative Steuerung über das Azure Portal und operative Datenabfragen über Inferenz-Endpoints erfordern voneinander getrennte Identitäts- und Netzwerkpfade.
Die Betriebsfolge dieser Härtung ist ein deterministisches System. Validierungs- und Zertifizierungsprozesse im regulierten Umfeld werden deutlich vereinfacht, da Netzwerkgrenzen auditsicher nachgewiesen werden können, statt sich auf Richtlinien auf Anwendungsebene verlassen zu müssen.
Containerisierung und Release-Lifecycle der Simulationsmodelle
Ein funktionierendes Python-Skript in einem Notebook garantiert noch keinen stabilen Betrieb, wenn mehrere Kunden parallel Vorhersagen abrufen. Um den hybriden Twin verlässlich zu betreiben, mussten die Simulationsroutinen standardisiert paketiert und über automatisierte Build-Strecken versioniert werden. Das Zusammenspiel aus mechanistischem Code und trainierten Gewichten verlangte nach einem klar definierten Container-Lebenszyklus.
Wir haben den Modellcode samt aller Laufzeitabhängigkeiten in Docker-Images gekapselt, die über Azure ML Environments instanziiert werden. Mechanistische Modellteile besitzen oft Abhängigkeiten zu C-Bibliotheken oder numerischen Optimierern, die nicht mit Standard-Pip-Installationen harmonieren. Durch das Vorausbauen unveränderlicher Basis-Images wurde sichergestellt, dass jede Inferenz-Instanz exakt dieselbe mathematische Laufzeitumgebung vorfindet, unabhängig vom Bereitstellungszeitpunkt.
Der eigentliche Release-Prozess wurde über deklarative Terraform-Definitionen und CI/CD-Pipelines gesteuert. Sobald ein Hyperparameter-Sweep ein Modell hervorbrachte, das die Validierungskriterien erfüllte, erzeugte die Pipeline ein registriertes Modellartefakt in Azure ML Studio. Von dort aus erfolgte die automatische Aktualisierung der Managed Online Endpoints:
- Blue-Green-Deployments für Endpoints: Neue Modellversionen werden zunächst als sekundäres Deployment am bestehenden Endpoint ausgerollt. Ein kleiner Prozentsatz des Test-Traffics prüft Latenz und Stabilität, bevor der Produktionsverkehr vollständig umgeschaltet wird.
- Kopplung an Git-Tags: Jedes produktive Container-Image lässt sich über Metadaten auf den exakten Commit des Modell-Repositories und die Databricks-Pipeline-ID zurückführen.
- Ressourcen-Limits und Autoscaling: Bioprozess-Simulationen erzeugen punktuell hohe CPU- und Speicherlasten. Über Metriken der Inferenz-Warteschlangen skaliert die Endpoint-Infrastruktur dynamisch Instanzen hinzu und verhindert Deadlocks bei parallelen Kundenanfragen.
Für den laufenden Betrieb bedeutet dieses Vorgehen, dass Rollbacks innerhalb von Minuten möglich sind, falls ein Modell unter realen Laborparametern unerwartete Randwerte liefert. Die Trennung von Modell-Artefakt, Ausführungsumgebung und Infrastrukturdefinition verhindert driftende Konfigurationen und sichert die Wartbarkeit des Systems langfristig ab.
