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

Die eigentliche Frage ist nicht „Cloud oder On-Premise?“, sondern: Wie liefern wir ein System, das in einer regulierten Umgebung zuverlässig, auditierbar und betreibbar ist – ohne Souveränität an Dritte abzugeben? In Defense, Bahn, Fertigung oder Energie sind Datenklassifizierung, Betriebsverantwortung und Lieferkettenkontrolle keine optionalen Anforderungen. Gleichzeitig erwarten Fachbereiche die Agilität moderner Plattformen: Continuous Delivery, horizontale Skalierung, GPU-Workloads, Observability, Self-Service für Teams. Genau diese Spannungsfläche entscheidet über die Architektur.

Dieser Beitrag beschreibt, wann und wie cloud-native Muster auf On-Premise- oder Edge-Infrastruktur sinnvoll sind. Fokus sind konkrete Patterns, Trade-offs und Anti-Patterns aus realen Projekten, keine Hype-Versprechen. Es geht um reproduzierbare Deployments, Air-Gap-Fähigkeit, Supply-Chain-Sicherheit, LLM/ML-Betrieb on-prem und realistische Betriebsmodelle.

Problemrahmen: Randbedingungen in regulierten Umgebungen

  • Daten- und Betriebs-Souveränität: Keine Abhängigkeit von US-Clouds oder extern betriebenen Control-Planes. Betreiber dürfen den Betrieb nicht verlieren, nur weil ein externer Service nicht verfügbar ist.
  • Klassifizierung und Segmentierung: Unterschiedliche Schutzbedarfe (z. B. personenbezogene Daten vs. Maschinen-Telemetrie) verlangen technische und organisatorische Trennung.
  • Netzrestriktionen: Häufig gibt es nur intermittierende oder stark limitierte Verbindungen zwischen Standorten (Edge) und Zentrale, teils Air-Gap.
  • Auditierbarkeit: Jede Änderung muss rekonstruierbar sein: Artefakte, Signaturen, SBOM, Change-Logs, Zugriffspfade.
  • Lebenszyklus: Systeme leben 7–15 Jahre. Technologie-Entscheidungen müssen Update-Pfade, Migrationsoptionen und EOL-Strategien berücksichtigen.

Entscheidungskriterien: Cloud-native, On-Premise oder Hybrid

Folgende Kriterien strukturieren die Entscheidung:

  • Datenlokalität: Müssen Daten das Rechenzentrum/den Standort verlassen? Wenn nein, sind reine Public-Cloud-Ansätze raus. Hybrid ist nur tragfähig, wenn klare Datenflüsse und Whitelists existieren.
  • Latenz & Verfügbarkeit: Steuerungsnahe Systeme (z. B. Qualitätsprüfung an der Linie) benötigen lokale Inferenz und Pufferung. Cloud-only ist dafür ein Risiko.
  • Betriebsmodell & Skills: Wer betreibt Day-2 (Upgrades, Backups, Incident-Response)? On-Prem-Cloud-Native reduziert „Managed Service“-Komfort, erhöht interne Verantwortung.
  • Kostenstruktur: Cloud verlockt mit CapEx→OpEx, On-Prem mit fixen Kosten und Vorhersagbarkeit. Daten-Egress, Langzeitaufbewahrung und GPU-Skalierung kippen die Waage schnell zugunsten On-Prem, wenn kontinuierlich große Datenmengen anfallen.
  • Lieferketten- und Compliance-Risiko: Können Abhängigkeiten rechtlich und technisch sauber kontrolliert werden (Artefakte, Signaturen, Herkunft, Exportkontrollen)?
  • Update-Frequenz: Produkte mit selteneren Releases und stabilen Schnittstellen sind On-Prem einfacher. Hochfrequente SaaS-Funktionalität lässt sich in air-gapped Milieus schwer replizieren.

Empfehlung in einer Zeile: Baue cloud-native, betreibe on-prem – aber wie eine Cloud, nicht wie eine Sammlung einzelner Pets.

Kernpatterns für On-Prem Cloud-Native

1) Kubernetes, aber bewusst gewählt

  • Distribution: Wählen Sie eine Distro, die Air-Gap, Offline-Upgrades und HA im Rechenzentrum ernst nimmt. Wichtig ist nicht der Name, sondern: reproduzierbare Cluster-Bereitstellung, Upgrades ohne Internetzugang, vernünftige Lifecycle-Docs.

  • Control-Plane-HA: Drei Control-Plane-Knoten auf getrennten Racks. Kein Cross-Site etcd-Quorum über unzuverlässige Links.

  • Node-Profile: Dedizierte GPU-Knoten, Storage-Knoten mit lokaler Redundanz, Edge-Knoten mit kleinerem Footprint.

  • Netzwerk-Policies: Default-Deny, klar definierte Ost-West-Pfade. mTLS zwischen Services. Service Mesh ist optional, aber ab 20+ Services hilfreich, solange es betrieblich gemeistert wird.

2) Artefakt- und Registry-Strategie

  • Lokale Container-Registry mit Signaturprüfung. Spiegeln externer Upstream-Repositories in einen internen „Golden Repo“-Stand – mit Freigabeprozess. Keine direkten Pulls ins Produktionsnetz.

  • SBOM und Provenance: Für jedes Container-Image eine SBOM (z. B. CycloneDX) und eine signierte Herkunfts-Attestation. Build-Pipeline im eigenen CI/CD (z. B. GitLab on-prem).

  • Distroless/Minimal-Images, um Angriffsfläche zu reduzieren. Klare Baseline-Images, seltene Wechsel.

3) GitOps im Air-Gap

  • Pull-basiert: Ein GitOps-Operator (z. B. Argo CD-ähnliches Pattern) zieht deklarative Manifeste aus einem internen Git. Keine Push-Pipelines ins Prod-Netz.

  • Air-Gap-Bundles: Freigaben geschehen als versionierte, signierte Bundles: Helm-Charts, Manifeste, Images, SBOMs. Ein „Promotion“-Schritt importiert diese in das Produktionsnetz über geprüfte Transferpfade.

  • Release-Trains: Kein permanentes „rolling latest“, sondern feste Releases, die in Staging-Umgebungen exakt wie Prod getestet werden.

4) Identität, Secrets, Schlüsseldrehs

  • Interner IdP (z. B. mit LDAP/OIDC) ohne Cloud-Abhängigkeit. Kurzlebige Token, regelmäßige Rotation.

  • PKI on-prem, idealerweise Hardware-gestützt (HSM/TPM). Service-zu-Service-Auth mTLS-first.

  • Secrets-Management mit auditierbaren Zugriffen und Break-Glass-Verfahren.

5) Observability ohne Telemetrie-Leaks

  • Metriken/Logs/Traces lokal sammeln und vorhalten. Nur aggregierte, freigegebene Reports verlassen das Segment, wenn überhaupt.

  • „Daten-Diode“-Prinzipien: Falls ein Export nötig ist, dann nur unidirektional aus sicheren Segmenten heraus, über geprüfte Gateways.

  • Retentions-Strategie und Speicherplanung früh festlegen. Timeseries können schnell explodieren.

6) Datenarchitektur für Edge + Zentrale

  • Event-Driven für entkoppelte Flüsse: Telemetrie, Qualitätsdaten, Sensor-Streams als Events. Lokale Queues/Broker puffern Paketverluste und Leitungsabrisse.

  • CDC und Append-Only: Statt „Remote-Writes“ in zentrale DBs lokale Commit-Logs und periodische Replikation. Konfliktlösungen deterministisch, kein ad-hoc Merge-Chaos.

  • PII-Trennung by design: Sensible Daten in gesonderten Stores/Namensräumen/Namespaces, mit strikteren Schlüssel-Policies.

7) Sicherheitsbaseline der Plattform

  • Supply-Chain: Signierte Commits, reproduzierbare Builds dort wo praktikabel, Image-Signing, Policy Enforcement vor Deploy.

  • Minimale Angriffsfläche: Netzwerk-Policies, Read-Only RootFS, Seccomp/Capabilities reduzieren, Non-Root-Container als Standard.

  • Offline-Patching-Pipeline: Regelmäßige Synchronisierung von Security-Patches in ein internes Mirror, definierte Update-Zeitfenster.