• Logs, Metriken, Traces site-lokal sammeln und aggregieren. Retention nach lokaler Speicherkapazität, ggf. Kompression und Rolling.
  • Dashboards vor Ort; Exportfenster in ein zentrales Datensicherheitsnetz nur nach Freigabe. Kein Dauerstream in die Cloud.
  • SLOs und Budgetierung: Fehlerbudgets auch on-prem definieren. Alert-Routing in die lokalen Betriebsprozesse integrieren (nicht aufs Handy eines Engineers in einer anderen Zeitzone).
  • LLM/ML-Governance: Für generative und prädiktive Komponenten Telemetrie über Prompt-/Kontextgrößen, Antwortlatenz, Modell-/Datenversion, Ausnahmepfade. Ein Observability/Governance-Layer (z. B. wie wir ihn mit Alpi-M bauen) gehört zum System, nicht als später Aufsatz.

Ziel: Ein Betreiber kann lokal diagnostizieren, ein Auditor kann rückwirkend prüfen, und ein Entwickler kann reproduzieren – ohne externe Dienste.

Secrets, Identität und interne Zero-Trust

“Innerhalb des Werks ist alles vertrauenswürdig” ist gefährlich.

  • Interne PKI: X.509-basierte Identitäten für Services und Maschinen. mTLS standardisieren. Kurzlebige Zertifikate mit automatisierter Erneuerung innerhalb des Standorts.
  • Secret-Storage vor Ort: Verschlüsselung at rest, auditierte Zugriffe, Trennung von Root-of-Trust (HSM oder abgesicherte Offline-CA).
  • RBAC: Rollen- und mandantenspezifische Rechte lokal abbilden; kein externer IdP zur Laufzeit notwendig. Optional: Synchronisation in Wartungsfenstern.
  • Administrative Pfade härten: Break-glass Accounts, Just-in-Time-Zugriff, Bastion Hosts. Jede Admin-Aktion ist nachvollziehbar.

Trade-off: Komplexe Federated-Identity-Lösungen sparen wenig in vollständig isolierten Segmenten. Lieber ein robustes lokales Identitäts- und Zertifikats-Management.

ML/LLM on-prem: Modell- und Datensouveränität praktisch

Für prädiktive Wartung, Sichtprüfungen oder LLM-gestützte Assistenzsysteme gelten zusätzliche Anforderungen.

  • Offline-Registry: Modelle, Tokenizer, Konfigurationen, Schwellenwerte – versioniert, signiert, reproduzierbar. Kein Runtime-Fetch aus externen Repos.
  • Hardware-Pfade: GPU-Treiber und Runtimes als Teil der Lieferkette paketieren und testen. Fallback-Pfade (CPU-Modus) definieren.
  • Reproduzierbarkeit: Trainingsläufe dokumentiert (Seeds, Datasets, Hyperparameter), Golden Datasets für Akzeptanztests im Feld.
  • Drift-Erkennung: On-prem Statistiken über Eingabedaten und Modelloutput. Alarme auf Datenverteilungsänderungen, nicht nur auf Fehlerraten.
  • Datenschutz: Kontext- und Promptdaten verbleiben im Standort. Keine Telemetrie mit personenbezogenen Inhalten außer explizit freigegebenen, anonymisierten Stichproben.

Governance: Ohne Sicht auf Kontext, Modellversion und Entscheidungen ist ein LLM im Feld ein blindes Risiko. Ein Observability- und Policy-Layer ist nicht “nice-to-have”, sondern Betriebspflicht.

Update-Strategien: Sicher, rückrollbar, planbar

Updates in regulierten Umgebungen sind Change-Events, keine spontanen “Klick mal Update”.

  • Release-Trains: Planbare, gebündelte Releases mit klarer Semantik (Patch, Minor, Major).
  • Blue/Green oder A/B: Zwei Stacks parallel, Umschalten nach Health Checks. Bei Single-Node: sequentielle Services mit klaren Downtime-Fenstern.
  • Datenbank-Migrationen: Expand-Contract (vorwärtskompatible Erweiterung, später Bereinigung). Test auf N-1/N+1 Kompatibilität.
  • Rollback-Strategie: Rollback muss realistisch sein – inkl. Datenmigrationen (Down-Migrations oder Vorwärts-Rollbacks mit Feature-Flags).
  • Infrastruktur-Patching: OS- und Runtime-Patches als Teil des Release-Bundles. Keine “driftenden” Basissysteme im Feld.
  • Backup/Restore-Drills: Mindestens halbjährlich echte Restore-Übungen aus Offline-Backups.

Trade-off: Canary-Pattern sind im Air-Gap nur stan­dort-intern sinnvoll. Breite Flottenverteilung ist eher ein abgestuftes Rollout nach Standorten.

Sicherheitsarchitektur: Segmentierung, Scans, SBOM

  • Netzwerk: Strikte Segmentierung, minimaler Ost-West-Datenverkehr, zulässige Ports/Protokolle whitelisten. Service Mesh nur, wenn Management kompetent abgebildet ist.
  • Artefakt-Integrität: SBOMs liefern, offline verwalten, bei Updates verifizieren. Signaturketten sind Teil der Audit-Trails.
  • Vulnerability-Scanning: Offline-Spiegel der CVE-Datenbasis bzw. periodische Aktualisierung über kontrollierte Kanäle. Scans sind Build- und Pre-Deploy-Gates.
  • Härtung der Operator-UIs: Kiosk-Modus, minimale Rechte, physische Zugriffskontrollen.

Wichtig: Sicherheit ist ein Systemattribut. Ein “sicheres” Modul in einer unsicheren Integrationsarchitektur ist wertlos.

API-Design für Langlebigkeit

Schnittstellen überdauern Teams und Hardwaregenerationen. Stabilität schlägt modische Eleganz.

  • Vertrag zuerst: Strikte IDL (z. B. Protobuf/gRPC, OpenAPI). Generierte Clients/Server, keine “magische” Reflection.
  • Versionierung: Keine “Breaking Changes” ohne Major-Version. Parallelbetrieb von N und N-1 Versionen über einen klar definierten Zeitraum.
  • Evolutionsregeln: Nur additive Felder, sinnvolle Defaults, klare Deprecation-Policies. Fehlermeldungen maschinenlesbar (Fehlercodes, nicht nur Texte).
  • Datenmodelle entkoppeln: Interne Repräsentationen nicht 1:1 exponieren. Domain-API vor Infrastruktur-API.

Trade-off: GraphQL kann intern nützlich sein, aber für langlebige, bandbreiten-sensible Feldgeräte ist ein stabiles, binär serialisiertes Protokoll mit hartem Vertrag oft überlegen.

Monolith vs. Microservices im On-Prem-Kontext

Microservices sind kein Ziel, sondern ein Mittel. In on-prem Umgebungen ist Betriebsaufwand meist der limitierende Faktor.

  • Wenn ein Monolith gewinnt:
  • Ein Standort, wenige Funktionen, kleines Team, harte Echtzeitanteile.
  • Bedarf an einfacher Diagnose und Updates mit minimalen beweglichen Teilen.
  • Wann Services trennen:
  • Sicherheits-/Sicherheits-zertifizierte Komponenten vs. nicht-sicherheitskritische.
  • Unterschiedliche Skalierungsprofile (z. B. Videoverarbeitung vs. UI).
  • Unterschiedliche Lebenszyklen (z. B. ML-Inferenz vs. ERP-Adapter).
  • Faustregel:
  • Start mit einem modularen Monolithen. Extrahiere Services entlang stabiler, asynchroner Grenzen (Events/Queues), nicht entlang temporärer Teamgrenzen.

Ergebnis: Weniger Overhead, klarere Verantwortlichkeiten, bessere Wartbarkeit über Jahre.

Beispiel-Blueprint: Standort-Architektur