Cloud-native vs. On-Premise in regulierten Branchen: Architektur-Patterns, die unter echten Auflagen funktionieren

Wer Software für regulierte Industrien baut, stellt fest: Die spannendste Entscheidung ist nicht „Kubernetes ja/nein“ oder „AWS vs. Azure“, sondern wie man harte Randbedingungen in eine robuste Architektur überführt. In Defense, Fertigung, Bahn, Luftfahrt und Bau begegnen uns immer wieder dieselben Fragen: Wie halte ich Daten im Haus, ohne auf moderne Entwicklungspraktiken zu verzichten? Wie betreibe ich Systeme ohne Internetzugang? Wie wäge ich Latenz, Betriebskosten und Auditierbarkeit gegeneinander ab? Dieser Artikel liefert kein Glaubensbekenntnis, sondern praxisnahe Patterns – mit ihren Trade-offs.

Ausgangspunkt: Die echten Constraints in regulierten Umgebungen

In unseren Projekten kristallisieren sich typisch fünf Cluster von Anforderungen heraus:

  • Datenhoheit und -lokalität: Bestimmte Daten dürfen physisch das Gelände oder Netzwerksegment nicht verlassen. Anonymisierung ist oft nicht ausreichend, weil Metadaten bereits kritisch sind.
  • Netzwerkrestriktionen: Egress ist dicht oder gar nicht vorhanden. Air-Gap ist kein Marketingbegriff, sondern Kabel raus – inklusive fehlender Zeitserver, Paketquellen und Container-Registry.
  • Nachvollziehbarkeit und Audit: Jede Ausführung, jedes Modell, jedes Artefakt muss reproduzierbar, versionierbar und rückführbar sein – Jahre später.
  • Determinismus und Latenz: Entscheidungen im Millisekundenbereich (z. B. visuelle Inspektion am Band) dulden keine Cloud-Roundtrips. Auch nicht „nur für die Lizenzprüfung“.
  • Betriebsrealität: Wartungsfenster sind knapp, Security-Updates sind verpflichtend, und ein Ein-Knoten-Sonderling wird später niemand mehr patchen.

Mit diesen Constraints im Hinterkopf lassen sich tragfähige Architekturen aufbauen – ob on-prem, hybrid oder mit Cloud-Anteil. Das Folgende ist ein Werkzeugkasten; die Auswahl hängt vom Problem, nicht vom Hype ab.

Architekturgrundsatz: Plane entlang der Ebenen Daten, Kontrolle, Identität

Stabile Architekturen separieren drei Ebenen:

1) Datenebene: Wo die sensiblen Daten entstehen, verarbeitet und gespeichert werden (z. B. Werkhalle, Fahrzeug, Leitzentrale).
2) Kontrollebene: Wo Konfiguration, Rollouts, Policies, Observability gesteuert werden.
3) Identitätsebene: Wer darf was? Workload-Identität, Maschinenzertifikate, Secrets, Schlüsselmaterial.

Praxisregel:

  • Datenebene so nah wie möglich an der Sensorik/Aktion – meist on-prem oder edge-nah.

  • Kontrollebene minimal-invasiv ins Zielnetz – idealerweise mit Pull-Mechanismen aus dem gesicherten Netz heraus, nicht mit Cloud-Push.

  • Identitätsebene unter eigener Hoheit – interne PKI/CA, kein externer KMS-Zwangsanker.

Cloud-native ohne Internet: Geht – aber bewusst anders

„Cloud-native“ ist ein Set an Praktiken (Container, deklarative Deployments, Automatisierung, Observability). Nichts davon verlangt per se Public Cloud. Was sich ändert, ist der Pfad der Artefakte und die Vertrauensanker.

Kernbausteine on-prem und air-gapped:

  • Interne Container-Registry mit Content-Trust: Images werden signiert und offline verifiziert. Artefaktfluss: Build-Pipeline in einem Netz A, Signatur, Export als Bundle, Import in Netz B. Kein „docker pull“ ins Blaue.

  • Hermetische Builds: Reproduzierbarkeit durch gepinnte Baselines, lokale Paketmirror, SBOM (Software Bill of Materials) und Sigstore-ähnliche Verifikation. Ohne das wird Compliance im Audit zur Zitterpartie.

  • Interne PKI und mTLS by default: Maschinen- und Workload-Identitäten sind Pflicht. Entweder via Service-Mesh oder schlank mit Sidecars/Init-Containern, die Zertifikate ausrollen. Wichtig ist nicht das Tooling, sondern rotierende, kurzlebige Zertifikate und klare Zuständigkeiten.

  • Policy as Code offline: Admission-Kontrolle (z. B. via OPA/Gatekeeper-ähnlichem Pattern) nutzt signierte Policy-Bundles. Kein „Policy aus dem Internet nachladen“.

  • Observability ohne SaaS: Metrik-, Log- und Trace-Pipelines lokal. Export erfolgt, wenn gewünscht, nur via genehmigtem, gepacktem Exportkanal. Sampling und Aufbewahrungsfristen sind bewusst zu wählen, sonst erschlägt die Kardinalität die Storage-Schicht.

  • Rollout-Strategien ohne externen „Traffic Splitter“: Blau/Grün oder Canary innerhalb der on-prem-Domäne. Bei Echtzeitsystemen bewährt sich ein Shadow-Deployment (Spiegeln von Live-Ereignissen an ein zweites System, ohne dessen Output zu aktivieren).

  • Daten-Domänen strikt entkoppeln: Keine „nebenbei“ verbauten Rückkanäle (z. B. Lizenzcheck-Calls, Telemetrie-Beacons). Alles, was egress braucht, ist ein potenzieller Ausfallverursacher und ein Audit-Risiko.

Wann On-Premise die bessere Antwort ist

  • Harte Latenzbudgets im einstelligen Millisekundenbereich: Visuelle Fehlererkennung, Sicherheitsfunktionen, Steuerungen. Jeder externe Hop erhöht Varianz; deterministische Latenz gewinnt gegen durchschnittlich niedrige Latenz.
  • Daten, die nie das Segment verlassen dürfen: Personenbezug, Betriebsgeheimnisse, Sensorik mit Rückschlüssen auf Prozesse. Pseudonymisierung reicht oft nicht, weil Muster reichen, um Prozesse zu rekonstruieren.
  • Langfristige Auditierbarkeit: Wenn Sie in fünf Jahren nachvollziehen müssen, welche Modellversion mit welchen Parametern auf welcher Hardware welche Entscheidung traf, ist vollständige Kontrolle über Artefakte und Laufzeit Gold wert.
  • Abhängigkeiten auf Zulieferketten: Wenn der Anlagenstillstand Millionen kostet, ist „SaaS hat gerade Störung“ kein akzeptabler Grund.

Wann die Cloud sinnvoll ist

  • Elastische, nicht-sensible Workloads: Simulationen mit synthetischen Daten, CI/CD-Pipelines, Rendering von Dashboards für Management-Ebenen ohne Rohdatenzugriff.
  • Internationale Kollaboration: Pre-Production-Umgebungen mit Mock-Daten, gemeinsamer Review von Pipelines, asynchrones Prototyping.
  • Heavy Compute on demand: Große Trainingsläufe, sofern die Datenlage das erlaubt, oder mit generierten/abgeleiteten Datensätzen, deren Leakage-Risiko tragbar ist.

Das Entscheidungsraster ist simpel: Datenhoheit + Latenz + Auditierbarkeit + Betriebsrisiko gegen Elastizität + Time-to-Market + Betriebskosten rechnen. Es gibt selten den „einen“ Ort – oft ist eine klare Trennung der Ebenen zielführend.

Konkret: Deployment-Patterns, die sich bewährt haben

1) Pull-basierte Steuerung statt Push

  • In abgeschotteten Netzen funktioniert „Zentrale pusht Update“ schlecht. Stabiler ist ein Agent im Zielnetz, der in festen Intervallen signierte Release-Manifeste aus einem transferierten Artefakt-Store liest.

  • Artefakte kommen als physisch oder logisch transferierte Bundles (z. B. signierte OCI-Image-Tarballs plus Manifeste). Validierung erfolgt vor Rollout.

Trade-off: Höhere Latenz bis zum Update vs. deterministischer, auditierbarer Pfad.