Cloud-native ohne Cloud: Architekturmuster für regulierte Branchen

Problemstellung zuerst: In vielen Industrien ist die Cloud nicht nur „schwierig“, sie ist schlicht keine Option. Ob Bahn, Verteidigung, Fertigung oder kritische Infrastruktur – Daten dürfen das Werk, die Flotte oder das Rechenzentrum nicht verlassen. Gleichzeitig erwarten Entwicklungsteams und Fachbereiche die Geschwindigkeit, Elastizität und Betriebszuverlässigkeit moderner Plattformen. Genau hier scheitern viele Initiativen: Sie kopieren Cloud-Blueprints 1:1, laufen dann an Air-Gap, DSGVO, Change-Control und Offline-Betrieb zerschellt auf. Das Ergebnis ist entweder ein „Cloud in der Fabrik“-Spielzeug ohne Compliance oder ein monolithischer Maschinenpark ohne jede Automatisierung.

Aus unserer Praxis mit Vermessungsplattformen, Fleet-Intelligence und Trainingssystemen lautet die nüchterne Erkenntnis: Cloud-native ist kein Ort, sondern eine Arbeitsweise. Container, Immutability, deklarative Zustände, saubere Telemetrie und automatisierte Deployments funktionieren exzellent On-Premise – wenn man sie an die Randbedingungen regulierter Umgebungen anpasst. Dieser Artikel beschreibt die Muster, die sich bewährt haben, die Anti-Pattern, die wir konsequent vermeiden, und eine Referenzarchitektur, die sich in Air-Gap-, Werk- und Rechenzentrumsumgebungen wiederverwenden lässt.

Was „cloud-native“ on-premise bedeutet – und was nicht

Cloud-native bedeutet aus unserer Sicht:

  • Deploybare Einheiten sind unveränderliche Artefakte (Container/Images), die reproduzierbar gebaut und signiert werden.

  • Zustände und Konfigurationen sind deklarativ beschrieben, versioniert und überprüfbar ausgerollt (Pull statt Push).

  • Telemetrie ist standardisiert, aggregierbar und ohne Seiteneffekte nutzbar.

  • Isolation und Identität sind standardisiert (mTLS, kurzlebige Credentials), nicht IP- oder VLAN-gebunden.

  • Updates sind inkrementell, rückrollbar und auditierbar.

Worauf Sie explizit verzichten müssen:

  • Permanente Outbound-Verbindungen zu SaaS-Diensten in der heißen Produktionspfad.

  • Spontanes „Nachladen“ von Abhängigkeiten zur Laufzeit.

  • Service-Split in dutzende Chatty-Microservices, die WAN-Latenz und Packet Loss ignorieren.

  • Automatische, unkontrollierte Updates von Basisimages, Treibern oder Operatoren.

Randbedingungen als Architektur-Input, nicht als Hindernis

Planen Sie mit den realen Zwängen:

  • Datenhoheit und Verbleib: Klare Domänen, klare Zonen. Persönliche Daten, Betriebsgeheimnisse und sicherheitskritische Telemetrie verlassen die Site nicht.

  • Änderungsmanagement: Jede Änderung ist nachvollziehbar, testbar und rückrollbar. Nightly-Updates sind keine Errungenschaft, sondern ein Produktionsrisiko.

  • Offline-/Intermittent-Betrieb: Verbindungen zwischen Edge, Werk und Zentrale sind stoßweise, nicht garantiert. Store-and-Forward statt Request/Response über WAN.

  • Lieferkette: Artefakte, Base-Images, Bibliotheken – alles potenzielle Einfallstore. Reproduzierbarkeit, Signaturen, SBOMs, geprüfte Upstream-Spiegel.

Architekturmuster, die on-prem funktionieren

1) Topologie und Datenpfade: Zonen, Events, Store-and-Forward

  • Dreiteilung der Welt:

  • Field/Edge: Geräte, Sensorik, Kameras, Inferenz nahe an der Maschine. Starke lokale Konsistenz, harte Echtzeit nur lokal.

  • Werk/Standort: Aggregation, Visualisierung, Workflows, lokale Datenhaltung, Operator-Interaktion.

  • Zentrale/Datacenter: Flottenweite Auswertung, Trainingspipelines, Modellvalidierung, regulatorische Berichte.

  • Datenfluss-Muster:
  • Ereignisgetriebene Kopplung statt synchroner RPC über Zonen hinweg. Idempotente Events mit stabilen Schlüsseln und Replays.
  • Dauerhafte Queues/Logs als Puffer (Append-Only). Zwischen Zonen wird repliziert, nicht „nachgefragt“.
  • Starke Konsistenz nur dort, wo physikalisch nötig (z. B. Safety-Schaltkreise). Ansonsten Eventual Consistency mit fachlicher Konfliktauflösung.
  • Beispiel Vision-Inspektion:
  • Frame-Inferenz am Edge mit Sofortentscheidungen. Nur erkannte Defekte und stichprobenartige Frames wandern als Events ins Werk, Bilder batchweise über einen freigegebenen Kanal. Keine Live-Streams über die WAN-Grenze.

2) GitOps in air-gapped Netzen: Pull, Signaturen, Bundles

  • Pull statt Push: Jede Site betreibt einen Agenten, der deklarative Zustände (Manifeste) aus einem internen Git zieht. Ingress aus dem Internet ist nie Voraussetzung.

  • Lieferkette:

  • Build in hermetischen Pipelines mit gepinnten Abhängigkeiten; deterministische Builds, reproduzierbare Container.

  • Für jedes Artefakt: SBOM erzeugen, Scans mit offline-spiegelten CVE-Datenbanken, Artefakt signieren.

  • Veröffentlichung in ein internes Registry; Promotion in Stages via Git-Merge mit Vier-Augen-Prinzip.

  • Air-Gap-Variante:
  • „Release-Bundles“ als signierte, versionierte Tarballs: Container-Images, Helm/Manifeste, Policies, Trust-Roots, Migrationsskripte. Einweg-Import in die Site über kontrollierte Medien. Verifizierung von Signaturen ist Teil des Import-Prozesses.

3) Identität, Geheimnisse, Verschlüsselung: mTLS by default

  • Interne PKI/CA: Service-Identitäten über kurzlebige Zertifikate; kein Shared Secret in Konfig-Files. Rotation automatisiert, Offline-Rotation möglich.

  • Mandantenschlüssel und Datenverschlüsselung: Envelope-Encryption, Schlüsselschutz in HSM oder zumindest mit gesichertem Key-Material, Trennung von Daten- und Metadatenzugriffen.

  • Menschliche Zugriffe: Ephemere Accounts, Just-in-Time, Session-Recording über Bastion; keine statischen Admin-Konten auf Dauer.

4) Observability ohne SaaS: Sammler an den Rändern, Retention zentral

  • Telemetrie-Pipeline:

  • An jedem Knoten lokale Collector/Agenten, die Metriken, Logs und Traces bündeln, drosseln und weiterleiten. Keine direkte App-zu-Backend-Telemetrie über Zonen hinweg.

  • Site-lokale Time-Series- und Log-Speicher für operative Analysen; zentrale, konsolidierte Instanzen für Flotten-Trends.

  • Sampling-Budgets: Trace-Sampling adaptiv, High-Cardinality-Labels begrenzen. Audit-Logs getrennt und manipulationssicher (WORM-Storage, Write-Once-Strategien).

5) Daten-Governance und LLM on-prem: Audit vor Magie

  • RAG und Wissensgrundlagen:

  • Indizes und Vektorspeicher je Site; domänenbasiertes Sharding. Replikation als genehmigter Exportprozess, nicht als stilles Sync.

  • PII-Redaktion als dedizierter Preprozessor vor Indizierung; explizite Opt-Out-Regeln für sensible Dokumente.

  • Agenten-Governance:
  • Werkzeug-Whitelisting: Welche externen Tools ein Agent nutzen darf, ist deklarativ festgelegt und auditiert.
  • Prompt-/Output-Filter mit PII- und Geschäftsgeheimnis-Checks; Policy-Verstöße führen zu Block oder Human-in-the-Loop.
  • Versionierbare Prompt-/Kontextbausteine; jede Inferenz wird mit Modellversion, Datenbasis-Hash und Policy-Kontext protokolliert.