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

Das eigentliche Problem liegt selten in „Cloud oder nicht Cloud“, sondern in einer widersprüchlichen Anforderungslage: Entwicklungsgeschwindigkeit und Betriebseffizienz wie in der Cloud, gleichzeitig Datensouveränität, Auditierbarkeit und oft vollständige Internetabkopplung. Wer Bahnfahrzeuge, Produktionslinien, Vermessungssysteme oder Trainingsplattformen in regulierten Umgebungen betreibt, kennt die Randbedingungen: kein US-Cloud-Anbieter, strenge Netztrennungen, Lebenszyklus > 10 Jahre, und Änderungen nur in geplanten Wartungsfenstern. In diesem Spannungsfeld entscheidet Architektur über Machbarkeit.

Dieser Text beschreibt Architekturmuster, die sich in der Praxis bewährt haben, um „cloud-native“ Arbeitsweisen on-premise umzusetzen, ohne Governance und Souveränität zu opfern. Er ist bewusst tool-agnostisch: Es geht um Prinzipien, Trade-offs und klare Entscheidungsfragen – nicht um Produktlisten.

Problemraum präzisieren, bevor Technologie gewählt wird

Bevor Sie über Orchestrierung, Service-Meshes oder GitOps diskutieren, modellieren Sie Ihren Problemraum entlang von sechs Achsen:

1) Konnektivität

  • Air-gapped (kein Internet, nur interne Netze, ggf. Datentransport per Wechseldatenträger)

  • Restriktiv (ausgehende Verbindungen über Proxy erlaubt, eingehend gesperrt)

  • Hybrid (standortübergreifende VPNs/Leitungen, definierte Management- und Datenkanäle)

2) Latenz-/Verfügbarkeitsziele

  • Harte Echtzeit (z. B. Steuerung): lokale Prozesse, minimaler Overhead

  • Nahe-Echtzeit (z. B. visuelle Qualitätskontrolle): Edge-Inferenz + lokale Dienste

  • Batch/Backoffice (z. B. Reporting): asynchron, tolerant ggü. Verzögerungen

3) Datenklassifizierung und -flüsse

  • Streng vertraulich (Fertigungsrezepte, Verteidigungsdaten)

  • Personenbezogen (DSGVO-relevant, Pseudonymisierung/Anonymisierung erforderlich)

  • Betriebsdaten (Maschinentelemetrie, Logdaten, Modelle)

4) Lebenszyklus und Änderungsfrequenz

  • Hohes Änderungsaufkommen (ML-Modelle, Geschäftslogik)

  • Niedriges Änderungsaufkommen (Schnittstellen zu Anlagen, Feldbus, Treiber)

5) Auditierbarkeit und Nachvollziehbarkeit

  • Vollständige Nachvollziehbarkeit von Software- und Modellständen

  • Reproduzierbare Deployments, signierte Artefakte, manipulationssichere Logs

6) Betriebsorganisation und Fähigkeiten

  • Gibt es SRE-/Plattformkompetenz?

  • Wer trägt Betrieb und Verantwortung am Standort (IT vs. OT)?

Diese Achsen bestimmen die Architektur. „Cloud-native on-prem“ ist erreichbar – aber nur, wenn die Komplexität zur Organisation und zum Risiko passt.

Drei Basis-Deploymentmodelle und ihre Trade-offs

Modell A: Air-gapped On-Premise

  • Beschreibung: Vollständige Plattform innerhalb des Standortnetzes, keine externen Verbindungen.

  • Vorteile: Maximale Souveränität, klare Sicherheitsgrenzen.

  • Nachteile: Hoher Aufwand für Artefakt-Transfer, Patching, Vulnerability-Scanning, CRL/OCSP-Handling; jede Integration muss offline-fähig sein.

  • Wann sinnvoll: Verteidigung, kritische Produktion mit strikter Netztrennung, strenge Lieferantenvorgaben.

Modell B: Restriktiv angebundenes On-Premise

  • Beschreibung: Egress via Proxy erlaubt, kein eingehender Traffic; eventuell dedizierter Managementkanal durch DMZ.

  • Vorteile: Aktualisierungen, Telemetrie-Export, Lizenzprüfung, Signatur-/Zeitstempeldienste werden handhabbar; weiterhin hohe Souveränität.

  • Nachteile: Externe Abhängigkeiten müssen whitelisted werden; strikte Egress-Policies; Ausfall externer Endpunkte darf die Produktion nicht stören.

  • Wann sinnvoll: Industrieanlagen mit sporadischer Verbindung, zentraler Governance und dezentraler Autonomie.

Modell C: Hybride Steuerung, lokale Datenebene

  • Beschreibung: Zentrales Management (Policies, Git-Repos, Artefaktkataloge) in einem souveränen Rechenzentrum, lokale Datenverarbeitung am Edge/Standort.

  • Vorteile: Einheitliche Governance, konsistente Releasesteuerung, horizontale Skalierung auf viele Standorte.

  • Nachteile: Komplexeres Betriebsmodell (Policy-Verteilung, Konsistenz); klare Isolationsmechanismen nötig, damit zentrale Störung lokale Produktion nicht blockiert.

  • Wann sinnvoll: Flottenbetrieb (Bahn/IoT), verteilte Werke, mehrstufige Organisation.

Bausteine einer „cloud-nativen“ On-Prem-Plattform

Orchestrierung – so leicht wie möglich, so mächtig wie nötig

  • Kleine bis mittlere Systeme mit klaren Latenzanforderungen profitieren oft von einem schlanken Ansatz: ein Prozess-Supervisor, saubere Service-Isolation, minimaler Netzwerk-Overhead. Ein ausgewachsener Orchestrator lohnt sich erst, wenn Sie echte Elastizität, Rolling-Updates, Self-Healing und Workload-Isolation brauchen.

  • Wenn Orchestrierung: Planen Sie deterministische Cluster-Versionen, Air-Gap-Bootstrap (lokaler Artefakt-Cache, lokaler Paketmirror), Device-Plugins für GPUs/Beschleuniger und klare Zuweisungen (kein Overcommit, wenn harte Latenzen).

  • Vermeiden Sie „Service Mesh by Default“. mTLS und Autorisierung können oft am Ingress/Egress und über eine solide PKI gelöst werden. Ein Mesh ergibt Sinn, wenn Sie viele teamübergreifende Services, Traffic-Shaping und feingranulare Policies brauchen – nicht, um „modern“ zu sein.

Storage und Snapshots

  • Objekt-Storage on-prem erleichtert Versionierung großer Artefakte (Modelle, Datensätze, Logs). Stellen Sie unveränderliche Buckets für Audit-Artefakte bereit (WORM).

  • Für Produktionsdaten: Snapshots first. Konsistente Snapshots + testbare Restore-Pfade sind wichtiger als exotische Replikationsmodi.

  • Trennen Sie kurzlebige Telemetrie (schnelle SSDs, kurze Retention) von langlebigen Artefakten (günstiger, replizierter Storage).

Private Registry und Artefaktkette

  • Eigene Container-Registry, Helm-/OCI-Chart-Store und Paketmirror sind Pflicht. Kein „docker pull“ aus dem Internet in Produktion.

  • Signieren Sie Images und Charts. Bewahren Sie SBOMs auf und scannen Sie Artefakte vor der Standortverteilung. In Air-Gap-Umgebungen erfolgt das Scanning zentral; an Standorten nur Verifikation und Policy-Enforcement.

  • Klare Promotionspfade (Dev → Staging → Preprod → Prod) mit Freigabeschritten, die auditierbar sind.

Netzwerk, PKI, mTLS

  • Interne PKI mit kurzlebigen Service-Zertifikaten, automatische Rotation, CRL-/OCSP-Handling, das auch offline funktioniert (z. B. vorverteilte CRLs; Revocation im lokalen Trust-Store).

  • East-West-Firewalling ist nicht „nice-to-have“: Mikrosegmentierung verhindert, dass ein kompromittierter Service den Standort lahmlegt.

  • Egress-Kontrolle per expliziten Allow-Listen; DNS-Firewalling gegen exfiltration via DNS.

Identity und Autorisierung

  • Ein OIDC-/SAML-fähiger IdP on-prem ist Kernbestandteil. Rollen modellieren entlang Domänen (IT/OT, Engineering, Qualitätssicherung), nicht entlang Org-Charts.

  • Maschinenidentitäten sind gleichwertige Bürger. Signierte Service-Accounts, kein „shared secret“.

  • Policy-as-Code für Autorisierungen, die auch offline evaluiert werden können.