Cloud-native vs. On-Premise in regulierten Branchen: Muster, die in der Praxis tragen

Das Grundproblem vorweg: In regulierten Industrien – Bahn, Verteidigung, Fertigung, Energie – kollidieren zwei Kräfte. Auf der einen Seite stehen moderne Cloud-native Entwicklungspraktiken, die Geschwindigkeit, Automatisierung und Skalierbarkeit versprechen. Auf der anderen Seite stehen harte Randbedingungen: Datenhoheit, Netzsegmente ohne Internetzugang, Nachvollziehbarkeit über Jahre, Auditierbarkeit und ein Betriebsumfeld, in dem Änderungsfenster kurz und Sicherheitsanforderungen lang sind.

Dieser Text beschreibt konkrete Architektur- und Betriebs-Muster, die sich in solchen Umgebungen bewährt haben. Ohne Hype, mit klaren Trade-offs. Unser Blickwinkel: Wir haben Plattformen für Vermessungssysteme, Fleet Intelligence und Trainingsplattformen gebaut und betrieben – on-premise, DSGVO-konform, ohne US-Cloud-Abhängigkeit. Ergebnis: Cloud-native Prinzipien bleiben wertvoll, aber man muss sie in on-premise Realitäten übersetzen.

Ausgangslage und Randbedingungen

Bevor man über Technologie spricht, klärt man die Systemgrenzen. Typische Rahmenbedingungen in regulierten Umgebungen:

  • Daten- und Betriebs-Souveränität: Keine Abhängigkeit von externen Cloud-Diensten im laufenden Betrieb. Updates sind möglich, aber planbar, signiert, reproduzierbar.
  • Netzwerktopologie: Air-gapped Segmente, intermittierende Verbindungen zwischen Standorten, strikte Ost-West-Segmentierung, DMZs.
  • Lebensdauer: 7–15 Jahre Laufzeit von Systemen; Ersatzteil- und Treiberprobleme sind real. API-Stabilität und Migrationspfade sind Pflicht, nicht Kür.
  • Auditierbarkeit: Änderungen müssen reproduzierbar, signiert, dokumentiert sein. SBOMs, reproduzierbare Builds, Change-Logs.
  • Echtzeit/Nahe-Echtzeit: Steuerungs- und Überwachungsaufgaben, die Latenz- und Jittergrenzen haben, oft nahe an der Maschine.

Aus diesen Nebenbedingungen ergeben sich Architekturentscheidungen. Was in einem hyper-skalierten SaaS sinnvoll ist, ist vor Ort in einem Werk, an Bord eines Fahrzeugs oder in einem Trainingszentrum oft ein Overkill – oder schlicht nicht machbar. Es geht nicht um “Cloud vs. On-Prem”, sondern um: Welche Cloud-native Ideen möchte ich behalten, und wie materialisiere ich sie on-prem?

Deployment-Modelle: Von Bare Metal bis On-Prem Kubernetes

Es gibt keine pauschale Empfehlung. Die wichtigste Entscheidung: Wie viel Orchestrierungs- und Abstraktionsaufwand steht in gesundem Verhältnis zur Betriebsumgebung?

Option 1: Systemd-Services auf Bare Metal/VMs

  • Wann: Kleine bis mittlere Deployments, deterministische Echtzeitanteile, sehr strikte Umgebungen (keine Container erlaubt).

  • Vorteile: Wenig bewegliche Teile, klare Fehlerdomänen, geringe Lernkurve im Betriebsteam.

  • Nachteile: Packaging, Isolation und Updates sind schwieriger zu standardisieren; Skalierung über mehrere Knoten braucht manuelle Arbeit oder eigene Automatisierung.

Option 2: Container ohne Cluster-Orchestrator (Docker/Podman + Compose)

  • Wann: 1–3 Knoten pro Standort, klar abgegrenzte Services, kein dynamisches Scheduling nötig.

  • Vorteile: Reproduzierbare Builds, saubere Paketierung, weniger Overhead als Kubernetes.

  • Nachteile: High Availability und Rolling Updates sind Handarbeit; Logging/Monitoring/Secrets müssen bewusst integriert werden.

Option 3: On-Prem Kubernetes (K3s, K8s-Distributionen, OpenShift)

  • Wann: Standort-Cluster mit mehreren Services, Bedarf an Isolierung, Self-Healing, deklarativer Konfiguration, GitOps.

  • Vorteile: Saubere Trennung von Anwendungs- und Betriebslogik, standardisierte Deployments, gute Grundlage für Policy/Compliance.

  • Nachteile: Komplexität. Ohne klaren SRE-Prozess und Tooling wird der Overhead zum Selbstzweck. Im Air-Gap muss alles – Images, Charts, CRDs – gespiegelt werden.

Bewährtes Muster:

  • Pro Standort ein Single-Tenant-Cluster (oder Compose-Stack). Keine mandantenübergreifende Orchestrierung über Standorte hinweg.

  • Innerhalb des Standorts so wenig Services wie nötig. Ein “modularer Monolith” oder wenige grob geschnittene Services sind oft besser als 30 Microservices, die niemand patchen kann.

  • Für harte Echtzeit: Prozess nahe an der Maschine (C++/Rust), Prozessintegration via lokale Queues oder Shared Memory, Upstream-Kommunikation asynchron.

Software-Lieferkette und Air-Gap-Delivery

Cloud-native ohne Internet? Geht – wenn die Lieferkette stimmt.

  • Build-Pipeline im Connected Zone: CI/CD baut deterministische Artefakte (Container, Pakete), erzeugt SBOM und Signaturen.
  • Staging-Repository: Alles, was das Zielsystem berührt, liegt in internen Repos (Container Registry, Helm/Chart-Repo, Paket-Repos). Keine Laufzeit-Pulls aus dem Internet.
  • Promotion: Freigaben sind ein Änderungsobjekt (Change Request) mit kryptografisch signierten Artefakten. Air-Gap-Transfer via Offline-Medien oder kontrollierten Replikationskanälen.
  • Installation vor Ort: GitOps-Spiegelung (Repo-Mirror), oder ein lokaler Installer, der signierte Bundles inkl. Abhängigkeiten entpackt und validiert.
  • Reproduzierbarkeit: Gleiche Checksummen von Build bis Deployment. Kein “apt-get update” im Feld; Basisschichten und Dependencies sind Teil des Release-Bundles.

Wichtig: Signaturvalidierung im Feld darf nicht am NTP scheitern. Zeitquellen und Zertifikatskette offline durchdenken (Offline-Root-CA, Intermediate-CAs, CRL/OCSP-Strategie).

Datenflüsse bei intermittierender Konnektivität

Zentrale Antipatterns sind synchrone Kopplung und “genau einmal” Zustellung über unzuverlässige Netze.

Bewährte Muster:

  • Event-getriebene Kernintegration: Innerhalb des Standorts ein Message-Broker als Rückgrat. Services sind Producer/Consumer mit klaren Topics.

  • Outbox-Pattern: Änderungen in der Business-Datenbank werden transaktionssicher in eine Outbox geschrieben und asynchron publiziert. Idempotente Konsumenten.

  • Store-and-Forward: Für Standort-zu-Zentrale-Replikation lokale Persistenz mit Warteschlange; Backpressure, Retry mit Exponential Backoff, Deduplizierung über Event-IDs.

  • Konsistenzmodell: Eventual Consistency by Design. Konfliktlösungs-Policy definieren (letzter Schreiber, domänenbasiert, CRDTs, Merge-Logik).

  • Schema-Evolution: Contract-first. Abwärtskompatible Änderungen (Felder nur hinzufügen, Standardwerte klar definiert). Producer und Consumer versionieren.

Trade-off:

  • Streng transaktionale, synchrone APIs zwischen Standorten erhöhen Kopplung und Ausfallraten.

  • Asynchrone, event-getriebene Replikation minimiert Latenzspitzen und erhöht Resilienz, erfordert aber Disziplin bei Idempotenz und Dublettenbehandlung.

Observability ohne SaaS

Telemetry ist kein nice-to-have. Aber ohne Internetzugang braucht es lokale Lösungen.