Cloud-native ohne Cloud: Architektur-Patterns für regulierte Branchen (On-Premise-first, ohne Illusionen)

Das eigentliche Problem ist nicht „Wie bekommen wir Kubernetes in die Fabrikhalle?“. Das Problem ist meist nüchterner: Sie müssen ein verteiltes, langlebiges System bauen, das unter lückenhafter Konnektivität, strengen Datenschutzauflagen und Auditpflichten funktioniert – und das über 10+ Jahre erweiterbar bleibt. Gleichzeitig erwarten Fachbereiche moderne Produktqualitäten: Near-Real-Time-Daten, ML-gestützte Assistenz, sichere Remote-Updates, reproduzierbare Deployments, Observability. Cloud-native verspricht diese Qualitäten – aber viele Branchen (Bahn, Defense, Fertigung, Energie) dürfen oder wollen die US-Public-Cloud nicht nutzen.

In diesem Artikel geht es nicht um Glaubensfragen, sondern um praxistaugliche Architektur-Entscheidungen. Cloud-native ist ein Satz von Prinzipien (Automatisierung, deklarative Zustände, lose Kopplung, resiliente Datenpfade) – kein Ort. Wir übertragen diese Prinzipien auf On-Premise- und Edge-Setups mit folgenden Leitplanken:

  • Datenhoheit und DSGVO sind nicht verhandelbar.

  • Netzwerke sind unzuverlässig, Latenzen schwanken, Air-Gaps existieren.

  • Betriebsteams sind klein; Komplexität muss sich rechnen.

  • Lebensdauer der Lösung überdauert Technologiemoden.

Im Folgenden zeige ich erprobte Patterns, Anti-Patterns und konkrete Technologiebausteine, inklusive Trade-offs. Beispiele stammen aus realen Projekten in Bahn, Defense, Fertigung und Vermessung.

1) Control-Plane vs. Data-Plane konsequent trennen

Ziel: Updates und Governance zentral steuern, aber Daten- und Rechenpfade lokal halten.

  • Control-Plane (zentral, selbstgehostet):
  • GitOps-Operator (z. B. Argo CD oder Flux) als Quell-der-Wahrheit für Deployments quer über Standorte.
  • Eigene Container- und Artefakt-Registry mit Signierung (Cosign, Notation) und Policy-Checks vor Freigabe.
  • Identitätsprovider (z. B. Keycloak) und Policy-Engine (z. B. OPA/Rego) für Rollen, Tenants, Compliance.
  • Observability-Metadaten-Zentrale (Federation statt zentraler Metrik-Sammlung) und Audit-Trail.
  • Data-Plane (Edge/Standorte):
  • Verarbeitung von Telemetrie, ML-Inferenz, Benutzerinteraktion lokal – ohne Cloud-Abhängigkeit.
  • Store-and-Forward für Ereignisse und Logs bei Netzwerkunterbrechungen.
  • Lokal betriebene Storage-Systeme (z. B. S3-kompatibles Object Storage, Timeseries-DB).
  • Feingranulare Policies: Welche Daten dürfen wohin repliziert werden, wann und in welcher Form.

Trade-offs:

  • Vorteil: Minimierter Datenabfluss, planbarer Rollout, robust gegen WAN-Probleme.

  • Nachteil: Mehr Inhouse-Responsibility für CI/CD, PKI und Artefakte. Ohne Disziplin degeneriert GitOps zum „ManuOps“.

2) Event-getriebene Backbones, die Partitionen aushalten

Nahezu jedes Industrie-Setup profitiert von Event-Driven Architecture. Der Knackpunkt in regulierten, verteilten Umgebungen ist nicht „welcher Bus ist schneller“, sondern „wie gut funktioniert das unter Partition und Backpressure“.

  • Typische Optionen:
  • NATS (JetStream) für leichtgewichtige, standortnahe Kommunikation, flexible Subjekträume, gutes Handling von temporären Ausfällen.
  • MQTT 5 für Geräteschichten und stark beschränkte Endpunkte.
  • Kafka für hohe Durchsätze, geordnete Streams, Replays und robuste Pipeline-Entkopplung; bei Bedarf mit externem Object Storage für längere Aufbewahrung.
  • Muster:
  • Store-and-Forward Gateways als Puffer zwischen Edge und Zentrale.
  • Quoten und Backpressure-Signale, damit Sensorik/ML nicht das Netzwerk füllt, wenn WAN weg ist.
  • Ereignisse sind kanonisch versioniert; Schema-Evolution via Schema-Registry (z. B. Avro/Protobuf).

Trade-offs:

  • NATS/MQTT: Einfacher zu betreiben, sehr gut für Edge, aber weniger stark in „dicken“ Analytik-Pipelines.

  • Kafka: Mächtige Semantik und Replays, aber höherer Betriebs- und Persistenzaufwand.

Praxis-Tipp:

  • Für Flotten-Telemetrie (Bahn, Fahrzeuge) mit Bursty-Lasten und vielen Partitionen: NATS/JetStream + Timeseries nahe am Edge, periodische Batches in die Zentrale.

  • Für Video/Inspection-Streams und Feature-Pipelines: Kafka + Object Storage für Warm/Cold-Data.

3) State-Management am Edge: Lokal-first, deterministische Synchronisation

Wer echte Offline-Fähigkeit will, muss State lokal ernst nehmen.

  • Timeseries-Layer (z. B. Timescale/Influx) pro Standort; Replikation als geplante Aufgabe, nicht „permanent live“.

  • Logische Replikation oder exportierbare Change-Feeds; Konfliktregeln deterministisch definieren (Zentrale gewinnt, oder edge-präferiert je Domäne).

  • Für Konfiguration: deklarativ (CRDs, JSON-Schemas), Versionierung im Git, Rollbacks jederzeit.

Trade-offs:

  • Vollständige Multi-Master-Synchronisation ist oft Overkill. Besser: klare Ownership je Datenkategorie (z. B. „Messdaten sind edge-owned bis Export-Task erfolgreich; Stammdaten sind central-owned mit Caches“).

4) Monolith vs. Microservices: Der Monolith gewinnt öfter am Edge

Microservices sind kein Selbstzweck. Gerade On-Prem- und Edge-Deployments mit kleinen Teams profitieren häufig von einem modularem Monolithen:

  • Wann der Monolith gewinnt:

  • Harte Latenzanforderungen zwischen UI, Echtzeitsensorik und Inferenz.

  • Team < 10 Entwickler, ein gemeinsamer Release-Takt, hohe Notwendigkeit deterministischer End-to-End-Tests.

  • Offline-Installationen mit knappen Ressourcen; Prozess-Orchestrierung soll minimal bleiben.

  • Wie man den Monolithen skaliert:
  • Klare Modulgrenzen, interne Contracts, saubere ABI/API-Stabilität; Plugin-Architektur (z. B. C++/Qt-Plugins, Python-Plugins mit strikter Schnittstelle).
  • Nebenläufigkeit über Worker-Pools und Message-Queues im Prozess; Shared-Nothing-Module, die per Ereignis kommunizieren.
  • Prozess-Supervision (systemd) und Watchdogs, Crash-only-Design, Recoverability.
  • Wann Microservices sinnvoll sind:
  • Heterogene Workloads, die unterschiedlich skalieren (z. B. ML-Inferenz getrennt vom Backend und UI).
  • Unterschiedliche Technologiestacks berechtigt (z. B. C++ für Vision, Python für Training, Go für Datenverteilung).
  • Zentrale Analytik, die von Replays und Stateful-Streams profitiert.

Betriebsaspekt:

  • Wenn Microservices on-prem, dann klein anfangen: K3s/MicroK8s oder Nomad, kein Service Mesh, solange nicht zwingend (jedes Mesh bringt Debug- und Zertifikatskomplexität). Erst wenn Traffic-Management, mTLS‑Rotation und Telemetrie skalieren müssen, lohnt ein Mesh.

5) Identität und Zugriff ohne Cloud-IdP

Ohne externen Identity-Provider braucht es eine robuste, selbstgehostete I&A-Story:

  • IdP selbst hosten (z. B. Keycloak) mit:

  • Kurzen Token-Laufzeiten, Refresh nur lokal.

  • Mandantenfähige Realms und Rollen für Standorte/Kunden.

  • Geräte- und Dienstidentitäten via mTLS; für saubere Automatisierung: SPIFFE/SPIRE oder alternativ statische mTLS mit Kurzlebigkeit.

  • PKI-On-Prem: Root in HSM offline; Zwischenzertifikate mit definierten Roll-over-Fenstern; CRLs/OCSP stapelbar für Air-Gaps.