Cloud-native vs On-Premise in regulierten Branchen: Muster statt Meinungen

Die Diskussion „Cloud-native oder On-Premise?“ ist im öffentlichen Web schnell beendet: alles in die Cloud, DevEx maximieren, elastisch skalieren. In regulierten Industrien ist die Frage anders gestellt. Dort geht es nicht um Bequemlichkeit, sondern um Souveränität: Wer kontrolliert Daten, Modelle, Lieferketten und Betriebsprozesse? Wie halten wir Systeme auditierbar, upgradefähig und deterministisch – auch ohne Internetverbindung?

Aus unseren Projekten (Vermessungssysteme, Fleet Intelligence im Bahnsektor, cloudbasierte Trainingsplattformen, visuelle Qualitätskontrolle in der Fertigung) ist die nüchterne Erkenntnis: Es gibt keine binäre Entscheidung. Erfolgreiche Architekturen kombinieren Cloud-Prinzipien (Deklarativität, Automatisierung, Isolierung, Observability) mit souveränen Infrastrukturen (Rechenzentrum des Kunden, Edge, Air-Gap). In diesem Beitrag geht es nicht um Hype, sondern um Muster und Trade-offs, die in sicherheitskritischen und datensouveränen Umgebungen funktionieren.

Problemraum sauber aufspannen

Bevor Technologien ausgewählt werden, lohnt ein Constraint-Matrix. Typische Dimensionen in regulierten Branchen:

  • Latenz und Determinismus: Entscheidungen im Millisekundenbereich (z. B. Inferenz am Band) vs. Batch-Verarbeitung über Nacht (z. B. Flottenauswertung).
  • Konnektivität: Volle Offline-Fähigkeit, sporadische Synchronisation, Air-Gap mit manueller Freigabe. Internet oft nicht verfügbar oder nicht erlaubt.
  • Rechtliche Vorgaben: DSGVO, Exportkontrollen, Geheimhaltungsstufen, Datenlokalisierung. Audit-Pflichten und Aufbewahrungsfristen.
  • Lieferkettensicherheit: Keine US-Cloud-Abhängigkeit, überprüfbare Artefakte, signierte Deployments, Reproduzierbarkeit.
  • Operator-Modell: Betrieb durch interne IT/OT, restriktive Change-Fenster, Schichtbetrieb, begrenzte personelle Kapazitäten.
  • Lebensdauer: 10+ Jahre; Ersatzteile wechseln, Software muss evolvierbar bleiben.

Antipatterns, die wir vermeiden

  • Cloud-SaaS „lift-and-shift“ ins Rechenzentrum kopieren: gleiche Komplexität, aber ohne die SRE-Teams, die es täglich betreiben. Ergebnis: fragiles System.
  • Air-Gap ignorieren, bis kurz vor Go-Live: Dann fehlen Artifaktkette, Signierung und Offline-Update-Prozess – und es gibt Delay um Monate.
  • Monolith reflexhaft in Dutzende Microservices zerschneiden: Für kleine Teams führt das schneller zu Betriebsrisiko als zu Flexibilität.
  • Sicherheit als „Perimeter“ definieren: In modernen Netzen sind Identitäten und Workload-Isolation robuster als Firewallschichten.

Stattdessen: Architekturmuster, die sich bewähren

Muster 1: Deklarativer Steuerungspfad mit Git als Herz

  • Ziel: Gewünschter Zustand des Systems (Infrastruktur, Applikationen, Policies) ist deklarativ versioniert und auditierbar. Keine „ClickOps“ in der Produktion.
  • Umsetzung:
  • Ein zentrales Repository pro Domäne (z. B. Infrastruktur, Plattform, Geschäftslogik).
  • Build-Pipeline erzeugt signierte Artefakte (Container-Images, Pakete), inklusive SBOM und Provenienznachweis.
  • Ein „GitOps“-Kontrollprozess im Zielnetz (ohne Internet) reconciliert gewünschten und aktuellen Zustand. Pull statt Push ist im Air-Gap robuster.
  • Changes gehen durch Freigabe-Workflows mit Vier-Augen-Prinzip; für Notfälle gibt es „Break-Glass“-Prozeduren mit vollständigem Audit-Log.
  • Trade-off:
  • Vorteile: Reproduzierbarkeit, Nachvollziehbarkeit, Trennung von Build- und Run-Umgebung.
  • Kosten: Initiale Einrichtung (Signierung, Artefakt-Registry, Policies) ist nicht trivial. Diese Kosten zahlen sich über die Lebensdauer aus.

Muster 2: Identitäten vor Geheimnissen

  • Ziel: Kurzlebige, überprüfbare Workload-Identitäten ersetzen langlebige statische Secrets. Maschinenauthentifizierung ist Kern statt Beigabe.
  • Umsetzung:
  • Private PKI/CA im Kundennetz; alle Services, Nutzer, Maschinen haben X.509- oder vergleichbare Identitäten.
  • Service-zu-Service-Authentifizierung basiert auf mTLS mit rollenbasierten Policies.
  • Token sind kurzlebig; Rotation automatisiert. Secrets liegen nicht in Images, nicht in Git.
  • HSM-Integration für Root-Keys; CA-Rollovers sind geprobt und dokumentiert.
  • Trade-off:
  • Vorteile: Minimiert Blast-Radius, vereinfacht Audit.
  • Kosten: Betrieb einer PKI, Schulung des Teams. Aber ohne das wird On-Premise schnell zu einem Zoo aus statischen Passwörtern.

Muster 3: Datenflüsse als erste Bürger, Netze als unzuverlässig behandeln

  • Ziel: Auch bei Paketverlust, intermittierender Konnektivität und Reboots bleiben Datenkonsistenz und Prozessfortschritt gewährleistet.
  • Umsetzung:
  • Ereignisorientierte Architektur mit klaren Domänen-Events. Persistente Queues vor langsameren Downstream-Systemen (Outbox-Pattern).
  • At-least-once-Delivery mit Idempotenz-Strategien auf Konsumentenseite. Exactly-once wird schnell zur Falle.
  • Replikation zwischen Standorten als asynchroner Strom; Konfliktlösung und Merge-Strategien sind explizit definiert.
  • Große Binärdaten (z. B. Bilder) aus Event-Payloads auslagern; referenzieren über Content-Addressing (Checksummen).
  • Trade-off:
  • Vorteile: Robust unter realen Netzbedingungen, klare Backpressure-Punkte.
  • Kosten: Höhere Designdisziplin (Event-Schemata, Idempotenz, Reprocessing).

Muster 4: Observability ohne Datenabfluss

  • Ziel: Vollständige Nachvollziehbarkeit von Verhalten und Leistungsdaten, ohne Telemetrie unkontrolliert nach außen zu senden.
  • Umsetzung:
  • Zentrale Telemetrie-Speicherung im Kundennetz: Logs, Metriken, Traces, plus Audit-Events. Retentions- und Redaktionsregeln sind Teil der Policies.
  • Sampling-Strategien für Traces; Event-Korrelation über Request- und Domain-IDs.
  • Für KI/LLM-Komponenten: Prompt-, Kontext- und Output-Logging mit PII-Redaktion; Evaluationsmetriken lokal. Agentenaktionen werden als Events modelliert und mit Ein- und Ausgaben verknüpft. So entsteht Governance, ohne die Souveränität aufzugeben.
  • Trade-off:
  • Vorteile: Audits werden möglich, Fehleranalyse beschleunigt.
  • Kosten: Mehr Storage und striktes Schema-Management; dafür keine Diskussionen über Datenabfluss.

Muster 5: Update- und Lieferkette zuerst bauen, nicht zuletzt

  • Ziel: Kein Artefakt betritt die Produktionsdomäne ohne Herkunftsnachweis und Signatur; Upgrades sind plan- und reversierbar – auch offline.
  • Umsetzung:
  • Build in einer isolierten CI-Umgebung. Ergebnisse: Image, SBOM, Provenienzdokument, Signatur.
  • Transfer in die Zielumgebung über einen kontrollierten Pfad (z. B. Wechseldatenträger, DMZ-Proxy), inklusive Anti-Malware-Scan.
  • Lokale Registry/Repository spiegelt freigegebene Artefakte. Der GitOps-Controller holt nur signierte Artefakte.
  • Rollouts: gestaffelt (Canary, Stages), mit Health-Gates; Rollbacks sind erster Klasse Bürger.
  • Trade-off:
  • Vorteile: Verteidigt gegen Supply-Chain-Angriffe, minimiert „Snowflakes“.
  • Kosten: Anfangsinvest in Werkzeuge und Prozesse; dafür weniger nächtliche Feuerwehreinsätze.