Cloud-native ohne Cloud: Architektur-Patterns für On-Prem in regulierten Branchen

Das eigentliche Problem ist selten “Cloud oder nicht?”, sondern: Wie baue ich ein System, das unter echten Restriktionen zuverlässig läuft – Daten dürfen das Werksgelände nicht verlassen, es gibt Air-Gap-Zonen, Software muss 10+ Jahre wartbar bleiben, Updates haben Wartungsfenster von 2 Stunden im Quartal, und dennoch sollen ML/LLM-Funktionen mit Governance, Observability und klaren SLAs bereitgestellt werden. In Verteidigung, Bahn, Fertigung oder Aviation ist diese Kombinatorik der Normalfall. Die “Cloud-native”-Debatte hilft nur, wenn wir sie entmystifizieren: Cloud-native ist ein Architekturstil, kein Ort. Die Muster – Container, deklarative Deployments, immutables Infrastruktur-Artefakt, Observability, Zero-Trust – funktionieren On-Prem genauso, wenn man die richtigen Trade-offs zieht.

Dieser Artikel beschreibt, welche Muster sich in der Praxis bewährt haben, wo die Fallstricke liegen und wie man KI-Funktionalität (inkl. LLMs) souverän On-Prem betreibt, ohne sich in Betriebs- und Compliance-Schulden zu manövrieren.

1) Restriktionen explizit machen: Was dominiert die Architektur?

Bevor Technologieentscheidungen diskutiert werden, müssen die harten Constraints klar sein. In regulierten Umgebungen sehen wir wiederkehrende Muster:

  • Datenhoheit und DSGVO: Personen- oder Betriebsdaten dürfen das Gelände nicht verlassen; Audit-Pflichten und Aufbewahrungsfristen gelten, “Delete on request” muss nachweisbar sein.
  • Air-Gap und Netzwerksegmentierung: Physisch getrennte Netze, Diode/Unidirektional-Verbindungen, DMZs. Kein “mal eben in die Cloud pushen”.
  • Lebensdauer: 10–20 Jahre Betrieb, aber Libraries haben 1–3 Jahre Lifecycle. Upgrades müssen reproduzierbar und rückrollbar sein.
  • Betriebsfenster: Strikte Wartungsfenster, Schichtbetrieb, Safety-Kopplung (z. B. nur in Stillstandsphasen).
  • Vorhersagbarkeit: Latenz-Jitter ist teurer als 5% mehr Hardware. “Best effort” ist wertlos, wenn Sicherheitsketten dranhängen.
  • Zulieferkette: Software muss lieferbar sein ohne US-Cloud-Abhängigkeit, mit attestierter Provenienz, signierten Artefakten und SBOM.

Diese Randbedingungen prägen jedes Architekturdetail stärker als “welches Orchestrierungstool” oder “welche Programmiersprache”.

2) Cloud-native als Muster, nicht als Standort

Die folgenden Prinzipien sind im Rechenzentrum genauso wertvoll wie in der Public Cloud:

  • Immutables Deployable: Build einmal, signieren, ausrollen. Keine “SSH auf Prod und Fix einspielen”.
  • Deklarative Zustände: Der gewünschte Systemzustand als Code (Kubernetes-Manifeste, Systemkonfiguration, Policies). Drift-Erkennung und Korrektur automatisch.
  • Service-Isolation via Container: Reproduzierbare Laufzeit, klare Ressourcenbudgets, Security-Boundaries.
  • Zero-Trust-Identität: Dienste sprechen nur mit mTLS/OIDC-Identität, keine impliziten Vertrauenszonen.
  • Observability by default: Metriken, Logs, Traces als First-Class-Citizens, mit Langzeitaufbewahrung on-prem.
  • Event-First-Integration: Lose Kopplung und robuste Replays statt Chatty RPC zwischen Segmenten.

Wichtig: Diese Muster sind unabhängig vom Hyperscaler. Die Herausforderung ist die Umsetzung unter Air-Gap, mit eingeschränkten Betriebsfenstern und Compliance-Anforderungen.

3) Topologien, die in der Praxis funktionieren

a) Edge-Cluster + Zentrales Rechenzentrum + DMZ

  • Edge: Kleine Cluster (2–3 Nodes, ggf. k3s/microk8s oder schlicht Container mit systemd), dicht an Sensorik/Aktoren. Verantwortlich für Ingestion, Vorverarbeitung, lokale ML-Inferenz.
  • Zentrale: Stärkerer Cluster im Werksrechenzentrum für Aggregation, Fleet-Model-Training, Dashboards, Datenhaltung, Governance.
  • DMZ: Nachrichtenzwischenpuffer mit strikten Firewall-Regeln. Unidirektionale Replikation ins Zentrum (Pull aus Zentrum oder Push via Diode-kompatible Mechanik).

Trade-offs:

  • Pro: Lokale Resilienz bei WAN-Ausfall, deterministische Latenzen, Datenhoheit.

  • Contra: Höhere Komplexität im Update- und Schlüsselmanagement; sorgfältige Versionierung für Edge und Zentrum notwendig.

b) Single-Node plus Replikationsknoten für einfache Standorte

  • Ein robuster Single-Node (z. B. mit Container Runtime + systemd) genügt, wenn HA-Anforderungen moderat sind und Wartungsfenster verfügbar.
  • Replikation zeitversetzt ins Zentrum; Write-Ahead-Logs/Ereignis-Streams werden gepuffert.

Trade-offs:

  • Pro: Deutlich weniger Moving Parts als Kubernetes; einfachere Diagnose.

  • Contra: Kein automatisches Failover; Recovery-Prozesse müssen geübt sein.

c) Air-Gapped Update-Pipeline mit signierten Bundles

  • Artefakte im zentralen, internen OCI-Registry gespiegelt (kein Internetzugang am Zielsystem).
  • Promotionsstufen: dev -> int -> preprod -> site-X; jedes Artefakt signiert, Provenienz attestiert, SBOM angehängt.
  • Physischer Transport via überprüfbares Medium oder Diode-taugliche Übertragung; Policy am Ziel prüft Signaturen und Gate-Kriterien (Tests, Vulnerability-Gates, Lizenzauflagen).

Trade-offs:

  • Pro: Prüfbare Lieferkette, Compliance-freundlich.

  • Contra: Lead Time erhöht sich; Testqualität in Preprod muss deutlich höher sein.

4) Orchestrierung: Kubernetes, k3s oder gar kein Orchestrator?

Kontext ist entscheidend:

  • Volatile Workloads, Multi-Tenant, GPU-Sharing, Rolling-Updates ohne Downtime? Dann lohnt sich ein kleiner, gut gehärteter Kubernetes-Stack on-prem (z. B. 3 Control-Plane Nodes ohne exotischen Zusatz).
  • Statischer Workload, wenige Services, klare Wartungsfenster? Dann reichen containerisierte Systemd-Units mit Health-Checks und Watchdogs.
  • Air-Gap + Minimal-Tooling? Komplexität runter: keine Service Meshes, keine exotischen CRDs, keine Pflicht zu Sidecars, wenn nicht nötig.

Bewährtes Minimum für On-Prem-K8s:

  • Ein Ingress-Controller, ein internes Registry-Mirror, ein Observability-Stack, ein GitOps-Operator (der mit offline Mirrors umgehen kann).

  • Netz wird so einfach wie möglich gehalten: Layer-7-Policies, mTLS auf Service-Ebene, aber kein Full-Blown Mesh, solange nicht messbar nötig.

5) Datenhaltung: CAP im Werk, nicht im Whitepaper

  • Transaktionale Workloads: Eine robuste, replizierte SQL-Instanz (z. B. Postgres-HA) deckt 80% der Anforderungen ab. Write-Konsistenz ist oft wichtiger als verteilte, globale Verfügbarkeit.
  • Verteilte Konsistenz: Nur dann zu einer verteilten SQL/Key-Value-DB greifen, wenn tatsächlich Partitionstoleranz bei Schreiblast erforderlich ist. Sonst zahlt man Operabilitätszinsen.
  • Ereignisprotokolle: Ereignis-Streams mit Retention und Replays sind der Integrationsanker zwischen Segmenten (Edge -> Zentrum). Sie entkoppeln Takt und erlauben robuste Recovery.
  • Lokale-First-Synchronisation: Bei intermittierenden Verbindungen können CRDT-/Delta-basierte Replikationsmuster an Endpunkten Konflikte minimieren. Für “Mensch im Loop”-Systeme hilft Soft-Lock + Merge-Regeln.