Stolperstein: Multi-Primary-Setups über unzuverlässige Verbindungen sind ein Ausfallmagnet. In der Praxis ist Primary an der Edge + asynchrone Replikation zentral oft robuster, mit expliziten Wiederabgleichsprozessen.

6) Identität und Zugriff in Air-Gap-Umgebungen

  • Lokaler Identity-Provider (IdP) mit OIDC/SAML im gesicherten Netzsegment, synchronisiert zeitversetzt mit zentralen Quellen (falls erlaubt).
  • Kurzlebige Tokens; kein “long-lived service account” ohne Rotation. Secrets als kurzlebige, bei Deployment injizierte Materialisierung.
  • Autorisierung prinzipiell “Capability-based”: Services besitzen fein granulare Berechtigungen, nicht pauschale Netzwerkfreigaben.
  • Maschinenidentitäten: mTLS mit automatischem Zertifikats-Rollover; keins dieser “selbstsignierten Testzertifikate in Produktion”.

7) Observability: Vollständig On-Prem, differenziert nach Business-Fragen

  • Metriken: Zeitreihen lokal aggregieren; für Fleet-Analysen lässt sich im Zentrum verdichten. SLOs in technischer wie fachlicher Dimension (z. B. Fehlklassifikationsrate/Charge).
  • Logs: Strukturierte Logs, kontextsicher korreliert; PII-Redaktion vor Persistenz, wenn rechtlich erforderlich.
  • Traces: Sampling bewusst gewählt: Vollständige Traces in Fehlersituationen, niedrige Rate im Normalbetrieb. Air-Gap verlangt effiziente Speicherpolitik.
  • Events: Fachliche Events separat von technischen Logs; First-Class-Bürger zur Auditierung.

Unidirektionale Brücken:

  • Falls nur Einweg-Kanal existiert, sendet Edge periodisch komprimierte Observability-Snapshots oder streamt Metrikfenster. Fehleranalyse-Pfade müssen ohne Remote-SSH funktionieren (Support-Pakete, reproduzierbare Diagnosedaten).

8) ML/LLM On-Prem betreiben – ohne Governance-Schulden

Modelle sind Software-Artefakte mit zusätzlicher Governance-Last. On-Prem bedeutet:

  • Modell-Registry im eigenen Netz: Versionen, Metadaten, Eignung für Hardware (Precision, Quantisierung), Test- und Bias-Metriken.
  • Promotion-Flow: Train -> Validate -> Staging -> Production mit reproduzierbaren Evals; Canary-Inferenz an echter Last im Werk, bevor breiter Rollout.
  • GPU/Acceleration-Planung: Durchsatz vs Latenz vs Energie. Batchgrößen und Quantisierung im Kontext messen; 4-bit spart Strom, kann aber bestimmte Fehlermodi produzieren.
  • LLM-Serving: Je nach Sicherheitslage Offline-Modelle; Prompt/Response-Audit, PII-Scrubbing und Policy-Enforcement vor Aktor-Aufrufen. Agenten bekommen nur whitelisted Tools mit Rate-Limits und strikten Schemas.
  • Observability für LLMs: Token-Metriken, Antwortzeit, Halluzinations-Indikatoren via Offline-Evals, Fehlermeldungs-Telemetrie. Für regulierte Branchen unverzichtbar: Nachvollziehbarkeit jeder Entscheidungskette.

Praxis-Punkt: Wenn Agenten reale Aktionen ausführen (Ticket anlegen, Parameter ändern), dann immer über eine Capability-Schicht mit expliziten Freigabezuständen (z. B. Simulations-Mode, Dual-Control für kritische Aktionen).

9) Update- und Rollback-Strategien, die auf dem Shopfloor funktionieren

  • Blue/Green On-Prem: Zwei vollständige Stacks, Umschaltung an einem Load-Balancer/Ingress. Downtime kurz, Rollback schnell.
  • Canary nach Schichten: Erst Diagnose-/Nicht-Produktionslinien, dann per-Linie aktivieren. Feature-Flags helfen, Risiken zu isolieren.
  • Migrationsfenster planen: Datenbankmigrationen, die Downtime erfordern, in Schichtwechsel; Pre-Migration-Validierung obligatorisch, Post-Migration-Checks automatisiert.
  • Rollback ist eine Qualitätseigenschaft: Jedes Release enthält ein getestetes Down-Migration-Skript oder ist vorwärts-/rückwärtskompatibel.

10) Sicherheits- und Lieferkettenhygiene ist kein Bonus

  • SBOM für jedes Artefakt; Vulnerability-Scan vor Promotion; Lizenzen dokumentiert.
  • Signierte Images/Manifeste; Policy am Cluster lässt nur verifizierte Artefakte zu.
  • Keine direkten Internet-Abhängigkeiten im Runtime-Pfad; Mirrors werden kuratiert und versioniert.
  • Geheimnisse nie als statische Files; kurzlebige, drehende Credentials oder Hardware-gebundene KMS.

11) Beispiel-Blueprint: “Secure Plant AI Inference Stack”

  • Edge-Schicht:
  • Sensor-Adapter (C++/Rust) mit harten Latenzgarantien
  • Preprocessing/Feature-Extraktion (Python/C++)
  • Inferenzdienste (LLM/Visionsmodelle) mit GPU- oder CPU-Beschleunigung
  • Lokales Postgres für transaktionale Zustände
  • Event-Log als Outbox zum Zentrum
  • DMZ:
  • Message-Bridge, die Events unidirektional weiterreicht
  • Gateways mit Protokoll-Übersetzung und strikten ACLs
  • Zentrales Rechenzentrum:
  • Aggregation/Dashboarding
  • Modell-Registry und CI/CD-Pipeline für Modelle
  • Observability-Stack mit Langzeitretention
  • Governance/Policy-Engine für LLM-Agenten (Audit, PII, Tooling-Policies)
  • Querschnittlich:
  • GitOps für deklarative Zustände
  • Signaturprüfung beim Deploy
  • Identity-Provider, Secrets-Rotation
  • Backup/Restore, die tatsächlich getestet sind

12) Monolith vs. Microservices im On-Prem-Kontext

Gerade in regulierten Umgebungen gewinnt der “wohlgeschnittene Monolith” häufiger, als viele glauben:

  • Betrieb: Ein Artefakt, ein Deploy, weniger Moving Parts – gut für enge Wartungsfenster.
  • Debuggability: Traces über Prozessgrenzen fallen weg; weniger Netzwerkfehler.
  • Datenkonsistenz: Weniger verteilte Transaktionen, einfachere Migrationspfade.

Microservices sind sinnvoll, wenn:

  • Teams unabhängig deployen müssen (organisatorischer Druck).

  • Skalierungspfad klar unterschiedlich ist (z. B. Inferenz skaliert GPU-lastig, UI kaum).

  • Isolation notwendig ist (z. B. Safety-zertifizierte Komponenten vs. schnelllebige KI-Komponenten).

Praxisfaustregel:

  • Services nur schneiden, wenn ein klarer betrieblicher/organisatorischer Grund existiert, nicht weil “Kubernetes da ist”.

  • Für On-Prem: Wenige, grobgranulare Services schlagen 20+ Microlithen mit Chatty-HTTP.

13) Kosten- und Kapazitätsplanung jenseits des Cloud-Rechners

  • Hardware amortisieren: Mixed-Precision/Batching kann GPUs deutlich besser auslasten; Off-Peak-Batch-Jobs in Nachtfenstern.
  • Energieprofile berücksichtigen: Thermik/Staub in Werksumgebung, Leistungsreserven einplanen.
  • Lizenz- und Updatekosten nicht unterschätzen: Jede Zusatzkomponente hat Lifecycle-Aufwand.

14) Entscheidungs-Checkliste

  • Netzwerk: Welche Segmente, Bandbreiten, Air-Gap? Einweg-Kanal?
  • SLAs: Latenz/Jitter-Ziele, Verfügbarkeit, Wiederanlaufzeiten?
  • Daten: PII? Aufbewahrungspflichten? Löschkonzepte?
  • Betrieb: Wartungsfenster, Skill-Profile des Betriebsteams, Remote-Zugriff möglich?
  • Sicherheit: Signaturen, SBOM, Geheimnisverwaltung, Identität?
  • ML/LLM: Modellgrößen, Throughput, Governance-Anforderungen, Auditierung?
  • Orchestrierung: Rechtfertigt die Workload Kubernetes? Wenn ja, minimale Komplexität definieren.
  • Rollout: Air-Gapped CI/CD-Pfad, Teststufen, Canary/Blue-Green?
  • Observability: Welche Fragen müssen in 5 Minuten beantwortbar sein? Welche in 5 Monaten?

Mini-Fallnotizen aus der Praxis