Cloud-native vs On-Premise: Praktische Patterns für regulierte Branchen

Das Problem zuerst: In regulierten Industrien (Rail, Defense, Fertigung, Aviation) sollen neue datengetriebene Funktionen live gehen – visuelle Qualitätskontrolle, Flottenintelligenz, LLM-basierte Assistenzsysteme für Instandhaltung oder Dokumentation. Gleichzeitig ist Datenabfluss in Public Clouds für geschützte Daten schlicht nicht verhandelbar. DSGVO, Exportkontrolle, interne Werkschutzauflagen, Geheimhaltungsstufen – all das führt dazu, dass “einfach ein Managed Service klicken” kein valider Pfad ist. Auf der anderen Seite sind klassische, VM-zentrierte Monolithen zu träge, um moderne Anforderungen wie Observability, reproduzierbare Deployments, beschleunigtes Rollout und GPU-Intensiv-Workloads sauber zu tragen.

Die einzige belastbare Antwort ist: Cloud-native Prinzipien ohne Public Cloud. Heißt konkret: Wir nehmen die technischen Muster aus dem Cloud-Engineering mit – Container, deklarative Konfiguration, GitOps, Observability, Zero Trust – und bauen damit eine souveräne On-Premise-Plattform, die auch unter Air-Gap- oder Semi-Connected-Bedingungen funktioniert. In diesem Beitrag skizziere ich erprobte Architektur-Patterns, die wir in Projekten in Bahn, Defense, Fertigung und Aviation genutzt haben, inklusive der harten Trade-offs.

Was “cloud-native ohne Cloud” wirklich bedeutet

Cloud-native beschreibt Architektur- und Betriebsprinzipien, nicht einen Hyperscaler. Entscheidend sind:

  • Container-Orchestrierung mit klaren Zuordnungen von Zuständigkeiten (Workload, Netzwerk, Storage, Identität).

  • Deklarativer Zustand als Quelle der Wahrheit (Infrastructure as Code, GitOps).

  • Automatisierte Software-Lieferkette mit Transparenz (SBOMs, Signaturen, Policies).

  • Dichte Observability und nachweisbare Governance (Metriken, Logs, Traces, Audit).

Die Übersetzung in On-Premise:

  • Bare-Metal- oder Virtualisierungs-Cluster als Ressourcen-Pool, häufig mit dedizierten GPU-Nodes.

  • Private Artifact-Registries und Chart-Repositories im eigenen Netz.

  • GitOps-Controller, die aus signierten Repositories desired state auf die Cluster bringen.

  • Integrierte Sicherheits- und Compliance-Kontrollen, die offline funktionieren.

Topologie-Patterns für regulierte Umgebungen

1) Air-Gapped Cluster

  • Vollständiger Netzabschluss nach außen.

  • Software-Updates kommen als signierte Bundles physisch oder via kontrollierte Einbahnstrecken.

  • Eignet sich für Defense, Prüffeldumgebungen, Werkshallen ohne Internetfreigabe.

  • Trade-off: Höchste Souveränität, aber aufwändige Update-Logistik und eingeschränkter Zugang zu Upstream-Ökosystem.

2) Semi-Connected Cluster

  • Zeitweilige oder bandbreitenbegrenzte Verbindung zu einer Staging-Zone (nicht direkt ins Internet).

  • Pull-basiertes Sync-Fenster für Artifacts und Konfigurationen, strikte Egress-Kontrollen.

  • Gut für Standorte mit definierten Wartungsfenstern oder Leitstellen-Anbindung.

  • Trade-off: Besserer Update-Durchsatz, aber Governance muss Egress-Risiken minimieren.

3) Edge-zu-Core

  • Edge-Cluster nahe an Maschinen, Zügen, Fluggeräten; zentrales Core-Cluster On-Premise im Rechenzentrum.

  • Asynchrone Replikation von Events/Telemetry (Edge -> Core), Konfigurationen und Modelle (Core -> Edge).

  • Trade-off: Lokale Latenz und Resilienz an der Edge, plus zentrale Analyse – aber Komplexität in Replikation und Konfliktauflösung.

4) Multi-Site GitOps statt k8s-Federation

  • Jede Site ist ein eigenständiger, definiert verantworteter Cluster.

  • Re-Use durch gemeinsame, versionierte Konfigurationen und Artifacts; Sites konsumieren freigegebene “Ringe” (dev, staging, prod).

  • Trade-off: Kein zentrales Global-Control-Plane-Monster, aber stärkerer Fokus auf Konfigurationsdisziplin.

Souveräne Software-Lieferkette (Supply Chain) ohne Internetabhängigkeit

  • Private Registry mit Signaturen: Container-Images, Helm-Charts und sonstige OCI-Artefakte liegen in einer internen Registry. Inhalte sind signiert; Ingress in die sichere Zone ist nur mit gültigen Signaturen möglich.
  • Vulnerability Scans und SBOM: Artefakte werden beim Eintritt gescannt; SBOMs (z. B. CycloneDX) werden mitgeliefert. Policy-Gates verbieten unbekannte/unsignierte Komponenten. Wichtig: Scans offline fähig betreiben; Datenbanken zyklisch synchronisieren.
  • Promotion-Ringe: Artifacts wandern von Integration zu Staging zu Produktion, jeweils über definierte Gates (Tests, Security-Checks, Kompatibilität).
  • Deterministische Builds: Reproduzierbare Build-Umgebungen, BuildKit oder vergleichbar, um Drift zu vermeiden; Build-Container sind selbst signiert und versioniert.
  • IaC und GitOps: Infrastruktur- und Applikationszustand sind deklarativ. Ein Merge in den freigegebenen Branch triggert eine Lieferkette, die signierte Bundles erzeugt; Deployments geschehen Pull-basiert am Ziel.

Daten-Governance und Egress-Kontrolle

  • Default-Deny fürs Netzwerk: Network Policies standardmäßig restriktiv; Egress nur über dedizierte Gateways mit Layer-7-Inspektion, falls freigegeben.
  • Datenklassifikation an der Quelle: Klare Stufen (öffentlich, intern, vertraulich, geheim). Pipelines für Pseudonymisierung/Maskierung bereits vor Persistenz sensibler Felder.
  • Verschlüsselung überall: At rest via verschlüsselte Volumes (CSI), in transit via mTLS. Schlüsselverwaltung On-Premise (HSM/KMS), Trennung von Schlüssel- und Datendomänen.
  • Event-Streaming mit Schemata: Ereignisse gehen in einen Bus (z. B. Kafka oder NATS JetStream) mit ACLs, Schema-Validierung und Retention-Strategie. Das entkoppelt Produzenten/Verbraucher und erlaubt offline Pufferung.
  • Datenabflüsse dokumentieren: Jeder exportierte Datensatz hat einen genehmigten Verwendungszweck, Zeitstempel, Verantwortliche. Auditierbarkeit ist integraler Teil, nicht Add-on.

Observability und Auditierbarkeit ohne externe Abhängigkeiten

  • Telemetrie-Standardisierung: OpenTelemetry Collector als Kante, die Metriken/Logs/Traces einsammelt, lokal persistiert und optional zeitversetzt an eine Core-Instanz repliziert.
  • Metriken und Logs lokal: Prometheus mit langlebigerem Storage (ggf. Thanos Sidecar, wenn Multi-Site gewünscht) und ein zentrales Logsystem (z. B. Loki). Traces lokal mit definierter Retention.
  • Audit-Stream neben Business-Telemetrie: Administrative Aktionen, Policy-Entscheidungen, Modellwechsel, Datenexporte – alles in getrennten, write-once-orientierten Streams mit restriktiver Zugriffskontrolle.
  • LLM-spezifische Governance: Für agentische Systeme braucht es Prompt/Output-Telemetrie, Modell- und Policy-Versionierung, sowie Reproduzierbarkeit von Entscheidungen. Eine Plattform wie Alpi-M erfüllt genau das: On-Premise integrierbar, zeichnet Interaktionen versionssicher auf, erzwingt Policies (z. B. erlaubte Tools/Datenräume) und liefert nachvollziehbare Reports für Audits. Entscheidend ist die on-prem und DSGVO-kompatible Bereitstellung ohne US-Cloud-Abhängigkeit.

Updates und Changes im Air-Gap