• On-Prem-Modellbetrieb:
  • GPU-Zuordnung und Prozessisolation pro Workload; Treiber und Runtimes als signierte Artefakte in der Lieferkette.
  • Update-Muster: Shadow-Deployments mit rekonstruierter Produktionslast (Aufzeichnungen), anschließend kontrollierte Promotion mit Rollback-Pfad.

Hinweis aus eigener Produktpraxis: Genau für diese Einsehbarkeit und Policy-Durchsetzung bauen wir mit Alpi-M eine LLM-Agent-Observability- und Governance-Schicht, die on-prem läuft, Prompt-/Output-Flüsse nachvollziehbar macht und technische Policies erzwingt, ohne Daten außer Haus zu geben.

6) Netzwerk und Segmentierung: Zero Egress als Default

  • Egress-Policy: Perimeter-Default-Deny. Ausnahmen explizit, meist nur zu Registry/Git/Update-Spiegeln. Alle Outbound-Verbindungen über einen prüfbaren Proxy.

  • Mikrosegmentierung: Sicherheitszonen und Workload-Identität statt VLAN-Spaghetti. Service-Mesh nur dort, wo es echten Mehrwert bietet (mTLS/Traffic-Policy), nicht als Selbstzweck.

  • Remote-Support: Kein dauerhaftes VPN. Stattdessen zeitbegrenzte, genehmigte Sessions über bastionisierte Sprungpunkte mit vollständigem Audit.

7) Zustand und Datenbanken: Konflikte in die Domäne, nicht in die Replikation

  • Lokale Transaktionen, globale Auswertung: Vor-Ort-DBs für Steuerung und Workflows; zentrale Warehouses/Data Lakes für Fleet-Analysen.

  • Replikationsmuster:

  • Append-Only-Events als Quelle der Wahrheit, fachliche Projizierer bauen Materialized Views.

  • Bei Zwei-Wege-Sync: Explizite Domänenregeln zur Konfliktlösung (z. B. Last-Write-Wins nur, wenn IDs kollisionsfrei; sonst Merge-Strategien).

  • Backups: Unveränderliche Snapshots mit Offline-Export. Restore-Tests sind Pflicht, nicht Kür.

8) Testen und Qualitätssicherung: Parität, Chaos und Latenz

  • Umgebungsparität: Dieselbe Orchestrierungs- und Paketierungsebene in Dev/Staging/Prod, auch on-prem. Keine Sonderwege im Werk.

  • Repräsentative Daten: Anonymisierung/Maskierung, die Verteilungen erhält. Keine Mickey-Mouse-Datensätze.

  • Realitätsnahe Tests:

  • WAN-Emulation: Latenz, Jitter, Packet Loss, limitiertes Bandbreite-Budget.

  • Chaos im „Perimeter“: Link-Ausfälle, Registry/Git nicht verfügbar, Zertifikat-Expiry, Clock-Drift.

9) Upgrade- und Rollback-Strategien: Release-Züge statt Dauerfeuer

  • Release-Trains: Quartalsweise gebündelte, geprüfte Releases schlagen Einzel-Hotfixe als Dauerzustand. Sicherheitsupdates als Out-of-Band, aber via selben Lieferweg.

  • Mehrstufige Freigabe: Site-Canaries, manuelle Gates, Telemetrie-basierte Freigaben. Rollbacks sind geübt, nicht nur theoretisch möglich.

Antipatterns, die regelmäßig teuer werden

  • „Managed Service“-Denke on-prem: Eine Architektur, die Dutzende Cloud-Managed-Services voraussetzt, bricht on-prem entweder in Eigenbau-Chaos aus oder verliert ihre Vorteile. Wählen Sie bewusst wenige, robuste Kernbausteine.

  • Chatty-Microservices über Zonen: 20 Services, die synchron über eine unzuverlässige Leitung sprechen, sind Produktionsausfälle mit Ansage. Zusammenschneiden oder fachlich neu schneiden (Domänenentkopplung).

  • Auto-Update überall: Produktionsumgebungen sind keine Smartphone-Apps. Automatisieren ja, automatisches Updaten nein.

  • „Security später“: Supply-Chain-Signaturen, SBOMs, PKI – das nachzurüsten ist teurer, als es von Anfang an vorzusehen.

Eine minimale Referenzarchitektur für regulierte On-Prem-Umgebungen

Kernkomponenten pro Zentrale/Site:

  • Container-Orchestrator mit definiertem Ingress/Egress.

  • Internes Container-Registry mit Content-Trust und Quotas.

  • Git-Server für Manifeste und Applikationen; Pull-basierte Deployment-Controller je Site.

  • CI-Pipeline mit hermetischen Workern und reproduzierbaren Builds.

  • Interne PKI/CA, Zertifikatsausgabe für Maschinen, Dienste und Menschen.

  • Secret-Management mit Audit, Rotationsprozessen und Offline-Support.

  • Message- und Event-Bus für lose Kopplung; Site-lokale Queues mit Replikationspfad zur Zentrale.

  • Telemetrie-Stack: Metriken, Logs, Traces, Alarme, WORM-Audit.

  • Zeit- und NTP-Härtung; konsistente Zeitbasis ist für Audits und Traces nicht verhandelbar.

  • Policy-Engine für Admission/Runtime (z. B. Signaturpflicht, Ressourcengrenzen, Egress-Block).

  • API-Gateway/Edge mit AuthN/AuthZ, Rate Limits und Request-Filter.

  • Identity-Provider für SSO, kurzlebige Rollen, Delegation.

Bootstrapping unter Air-Gap:

  • Vertrauensanker in Hardware (z. B. offline Root CA). Erstinbetriebnahme über signierte Install-Medien.

  • Vorbereitete Release-Bundles mit Artefakten, Manifeste, Policies, SBOMs, Trust-Store. Import über geprüfte Transfermechanismen.

  • Dokumentierte, geübte Prozedur für „Nuklear-Restore“: Rebuild der gesamten Plattform aus Bundles und Seed-Secrets.

Betriebsrhythmus:

  • Quartalsweise Release-Züge; monatliche Security-Bundle-Imports.

  • Dedizierte „Triage“-Phase für CVEs: Bewertung, Patch-Erstellung, Backport in Release-Train.

  • Regelmäßige DR- und Restore-Drills; Zertifikats-Expiry-Drills.

Entscheidungsrahmen statt Checkliste aus dem Bauch

Vor einer Technologieentscheidung sollten Sie folgende Fragen beantwortet haben:

  • Datenklassen und -standorte: Welche Daten dürfen wohin? Welche Zonen sind tabu für welche Klassen?

  • Latenz und Offline-Toleranz: Welche Workflows müssen bei Link-Ausfall weiterlaufen, welche können warten?

  • Änderungs- und Freigabemodell: Wer darf wann was promoten? Wie sieht Rollback real aus?

  • Lieferkettenvertrauen: Woher kommen Base-Images und Bibliotheken? Wie werden sie geprüft und signiert?

  • Ressourcenprofile: CPU/GPU/Storage pro Site? Drosselungs- und Priorisierungsregeln?

  • Observability-Ziele: Aufbewahrungsfristen, Audit-Anforderungen, Alarmierungswege ohne SaaS.

Ein konkretes Szenario: Fleet Intelligence im Bahn-Bereich

Edge: Jeder Zug verfügt über Sensorik und ML-Modelle für Anomalieerkennung. Inferenz läuft lokal, Ergebnisse werden als Events in eine persistente Queue geschrieben. Bei fehlender Verbindung wird lokal gepuffert.

Werk/Depots: Beim Einfahren in ein Depot synchronisiert der Zug seine Event- und ausgewählte Rohdatenpakete mit dem Standort-Broker. Wartungsplanung, Teileverfügbarkeit und Disposition laufen auf Standortsystemen, die ohne Zentrale arbeitsfähig sind.

Zentrale: Über Nacht replizieren Standort-Broker Ereignis- und Statusdaten in das zentrale Data Warehouse. Flottenweite Modelle werden offline gegen echte Lastaufzeichnungen bewertet. Neue Modellversionen gehen als signierte Bundles zurück in die Standorte, werden zuerst im Shadow-Modus gefahren und nach Telemetrie-Freigabe produktiv geschaltet.

Sicherheit: Kein direkter Zug-zu-Internet-Verkehr. Egress ist strikt auf Depot-Gateway beschränkt. Artefakt-Bundles durchlaufen Prüfpfade, Modellartefakte sind signiert und referenzieren geprüfte Runtimes.

Operativ: Telemetrie bleibt lokal detailliert für die tägliche Arbeit, während zentrale Trends und KPIs über aggregierte, anonymisierte Sichten laufen. Fällt die Zentrale aus, sind Depot-Workflows weiterhin funktionsfähig.

Fazit