Cloud-native vs On-Premise in regulierten Branchen: Architekturmuster für echte Souveränität

Problem zuerst: In vielen Industrien ist der Datenabfluss in eine US‑Cloud nicht verhandelbar. Gleichzeitig erwarten Fachbereiche eine Entwicklungs- und Liefergeschwindigkeit, die sich an Cloud‑Maßstäben misst: kurze Release‑Zyklen, Observability, reproduzierbare Deployments, automatisierte Qualitätssicherung. Der scheinbare Zielkonflikt “Cloud‑native vs On‑Premise” löst sich erst auf, wenn man die tatsächlichen Randbedingungen adressiert: strikte Netzsegmente, teils wochenlange Offline‑Phasen, Audit‑ und Nachvollziehbarkeitspflichten, zehn Jahre+ Lebensdauer, begrenzte Betriebs- und SRE‑Ressourcen beim Kunden.

In Plattformen für Vermessungssysteme, Flotten‑Intelligenz und Trainingsumgebungen haben wir ein wiederkehrendes Muster gesehen: Man will die Entwicklungs‑ und Betriebsmuster der Cloud (Deklarativität, GitOps, Observability, Automatisierung) in ein on‑prem, häufig air‑gapped Umfeld übersetzen. Wer versucht, Public‑Cloud‑Blueprints 1:1 zu “lift‑and‑shift‑en”, scheitert an der Lieferkette (Container‑Images, Abhängigkeiten), der Netzwerkrealität (kein Egress oder nur über strikte Diode) und am Betriebsmodell (kleine Teams, starre Wartungsfenster).

Das Ziel dieses Beitrags: konkrete, erprobte Architekturmuster für regulierte Umgebungen, die echte Souveränität sicherstellen, ohne bei Engineering‑Produktivität kapitulieren zu müssen.

Designprinzipien für souveräne On‑Prem‑Plattformen

  • Souveränität zuerst: Kontrolle über Datenflüsse, Build‑ und Lieferkette, Identität, Kryptographie. Keine externe Abhängigkeit, die im Audit nicht erklärt oder ersetzt werden kann.
  • Reversibilität: Komponenten so wählen und integrieren, dass Austausch möglich bleibt. Datenformate und Protokolle bevorzugen, die nicht proprietär einsperren.
  • Operationale Einfachheit: Minimale bewegliche Teile. Was nicht notwendig ist, fliegt raus. “Fancy” verteilt schlägt “robust lokal” nur mit klar belegtem Mehrwert.
  • Offline‑first: Alles – CI/CD, Observability, Lizenzierung, Secrets, Zeit‑ und Zertifikatsmanagement – muss ohne Internet verlässlich funktionieren.
  • Governance by design: Audit‑fähige Protokollierung, Policies als Code, reproduzierbare Builds, SBOM/Signaturen – nicht als später Aufsatz, sondern im Pfad.
  • Grenzflächen bewusst gestalten: Harte Trennung zwischen Domänen, klare Datenverträge, wohldefinierte asynchrone Kopplung über Ereignisse oder Replikation.

Drei Referenz-Deploymentmodelle

1) Verbunden, aber souverän (kontrollierter Egress, keine US‑Cloud)

Typischer Kontext: Produktionsnetz hat einen streng kontrollierten Ausgang in ein EU‑Netz (z. B. Unternehmens‑Rechenzentrum), direkte US‑SaaS ist ausgeschlossen. Ziel: Moderne Delivery‑Pipelines und Telemetrie, ohne Datenhoheit zu verlieren.

Kernmuster:

  • On‑Prem‑Kubernetes oder eine schlanke Orchestrierung, die Air‑Gap unterstützt. Nicht das Feature‑feuerwerk zählt, sondern: stabile Upgrades, Offline‑Registries, reproduzierbare Control‑Plane.

  • GitOps mit internem Mirror: Es gibt ein “inneres” Git, das der einzige Autoritäts‑Punkt für die Runtime ist. Synchronisation aus dem “äußeren” Git erfolgt über Pull in einen Staging‑Mirror, mit Kontrollpunkten (Signaturprüfung, Policy Gate).

  • Artefakt‑Kette im Haus: Interner Container‑Registry‑Mirror, internes Paket‑Repository (C/C++, Python, OS‑Pakete). Outbound geht nur über Artefakt‑Fähren mit Whitelisting und Content‑Scanning.

  • Zwei‑stufige Perimeter‑Topologie:

  • Externe DMZ mit API‑Gateway/Reverse‑Proxy, der ausschließlich wohldefinierte, versionierte Schnittstellen publiziert.

  • Interne Servicezone mit Ost‑West‑Kontrollen (NetworkPolicies, mTLS). Keine Service‑zu‑Service‑Kommunikation über die DMZ.

  • Identität:

  • Menschliche Identität über das vorhandene IAM (AD/LDAP), föderiert in die Plattform.

  • Workload‑Identität separat gemanagt (kurzlebige Zertifikate/Tokens), keine statischen, langlebigen Secrets in Deployments.

  • Datenpfade: Ausleitung nur für Telemetrie‑Metadaten und nicht‑sensible Artefakte; Nutzdaten verbleiben im Segment. Wenn Training/Analytics zentral erfolgen sollen: dedizierter Anonymisierungs‑/Synthetik‑Pfad mit expliziten Verträgen.

  • Observability on‑prem: Logs, Metriken, Traces im eigenen TSDB/Log‑Store mit Retentions‑ und Redaktions‑Policies. Optional export in der EU, aber niemals personenbezogene Rohdaten.

Praxis‑Hinweise:

  • Trenne klar “Build‑Welt” und “Run‑Welt”. CI kann in einer verbundenen, aber separaten Zone laufen; der Weg ins Produktionsnetz ist ein einseitiger, signaturgeprüfter Promote‑Schritt.

  • Definiere SLOs, die zur Netzrealität passen. Wenn Egress nur stundenweise möglich ist, plant Pipelines für diese Fenster (Batches, Delta‑Synchronisation).

2) Intermittente Konnektivität (wochenweise Offline)

Kontext: Vermessungsteams im Feld, Züge in Regionen mit geringer Abdeckung, Werke mit geplanten Netzabschaltungen. Cluster laufen wochenlang autonom, Synchronisation erfolgt in “Kontaktfenstern”.

Kernmuster:

  • Staging‑Harbor: Eine dedizierte Zwischenzone, in der Updates, Policies und Modelle gesammelt, validiert und in ein Offline‑Paket geschnitten werden.

  • Store‑and‑Forward:

  • Ereignisse werden lokal in einer robusten Warteschlange/Log gehalten.

  • Bei Konnektivität erfolgt ein kontrollierter, idempotenter Abgleich.

  • Konfliktmanagement:

  • Für Metadaten und Konfiguration CRDT‑ oder versionsbasierte Merges (last‑writer‑wins reicht selten).

  • Für Domänendaten domänenspezifische Reconciliation‑Strategien (z. B. Sensor‑Messreihen: append‑only mit Kompression).

  • Zeit und Vertrauensanker:

  • Verlasse dich nicht auf externes NTP. Interne Zeitquellen mit präzisem Drift‑Management.

  • PKI‑Kette und Zertifikatsrotation so planen, dass sie keine Internetabhängigkeit hat.

  • Telemetrie‑Retention:

  • Lange lokale Retention, rollierende Kompaktion.

  • “Black‑box”-Modus für forensische Sicherung nach Vorfällen.

Praxis‑Hinweise:

  • Updates als immutable Bundles mit Manifest, Prüfsummen und Signaturen. Kein “pip install im Feld”.

  • Benutzerführung: Sichtbare “Sync‑Fenster” und Konfliktresolution dem Betriebsteam erklären, nicht verstecken.

3) Vollständige Air‑Gap (keine eingehenden/ausgehenden Verbindungen)

Kontext: Verteidigung, sicherheitskritische Produktionslinien. Kein Egress, keine Fernwartung, Artefakt‑Transfers nur über bewachte Kanäle.