Edge vs. Cloud: Wann On-Premise die einzige Option ist – und wie man es richtig baut

Problemstellung

Cloud ist heute der Default. In vielen IIoT-Projekten höre ich früh den Satz “Das machen wir in der Cloud, ist doch skalierbar.” Das kann stimmen – aber in Industrien mit kritischen Anlagen, strengem IP-Schutz oder nationaler Sicherheitsrelevanz ist das oft die falsche Startannahme. Die zentrale Frage ist nicht “Wie kommen die Daten in die Cloud?”, sondern “Welcher Workload darf das Perimeter verlassen – und welcher nie?”. Wenn Datensouveränität nicht verhandelbar ist, gewinnt die Edge. Punkt.

In diesem Beitrag gehe ich technisch konkret durch:

  • Welche Randbedingungen Edge vs. Cloud entscheiden (Souveränität, Latenz, Verfügbarkeit)

  • Architektur-Patterns für strikt on-prem, für hybride Setups und für Flottenbetrieb

  • Protokollwahl in der Praxis: OPC UA, MQTT, Kafka – wofür, wo, warum

  • Wie man Modelle an der Edge betreibt, auditierbar aktualisiert und trotzdem im großen Stil trainiert

  • Was 100 ms in einer Fertigung wirklich bedeuten – und wie man Budget und Jitter kontrolliert

Mein Blickwinkel: Ich habe eine Cloud-Plattform für Pilotenausbildung gebaut (wo Skalierung und globale Verfügbarkeit zählen) und ein Fleet-Intelligence-System für Bahnnetze (wo intermittente Konnektivität, harte Latenzbudgets und Souveränität die Architektur bestimmen). Genau diese Spannungsfelder adressiert der Artikel.

Die drei harten Constraints: Souveränität, Latenz, Verfügbarkeit

1) Datensouveränität und Regulatorik

  • Nicht verhandelbare Daten: Konstruktions-Know-how, Sensordaten mit militärischer oder kritischer Infrastruktur-Relevanz, personenbezogene Daten aus sensiblen Umfeldern. Solche Daten verlassen das Perimeter nicht. Weder Rohdaten noch hochgranulare abgeleitete Merkmale.

  • Juristische Durchsetzbarkeit: “EU-Region” eines Hyperscalers ist keine magische Lösung, wenn rechtliche Zugriffsszenarien außerhalb Ihrer Kontrolle liegen. Souveränität heißt: technische, organisatorische und rechtliche Kontrolle in Ihrer Hand.

  • Governance-Anforderungen: Auditierbare Modelle, reproduzierbare Builds, Nachvollziehbarkeit von Entscheidungen (auch für LLM-gestützte Agenten) – das ist on-prem einfacher zu härten, weil Sie den gesamten Pfad kontrollieren.

2) Latenz und Jitter

  • Es gibt Workloads, bei denen 100 ms ein Unterschied zwischen “Fehler erkannt und stopp ausgelöst” und “Ausschuss produziert” sind. In der Praxis ist nicht nur die mittlere Latenz kritisch, sondern vor allem der Jitter (Varianz). Unvorhersehbare Cloud-Pfade oder Internet-Konnektivität zerstören deterministische Latenzbudgets.

  • Faustregel aus der Praxis: Alles, was in die Nähe von Steuerungslayern kommt (Kamera-Trigger bis Aktor-Reaktion, Kollisionsvermeidung, Zustandsüberwachung mit unmittelbarer Aktion), gehört auf die Edge. Data Lakes und Batch-Analysen dürfen zentriert sein – wenn Souveränität es erlaubt.

3) Verfügbarkeit und Konnektivität

  • Flotten in Zügen oder Baumaschinen haben Löcher in der Konnektivität. Produktionshallen haben Wartungsfenster, VLAN-Umbauten, Netzwerksegmentierung. Ihre Architektur muss bei 0 Mbit/s weiterarbeiten. Store-and-forward, lokale Puffer, idempotente Replays – Edge-first ist hier das einzige robuste Muster.

Der Entscheidungsrahmen: Bringt den Compute zur Datenquelle, wenn …

  • … der Datenklassifizierungsprozess die Quelle als “kritisch/nicht zu exportieren” einstuft.
  • … das Latenzbudget eng ist und Jitter killt.
  • … die Verbindung nicht garantiert ist (Air-Gap, intermittente Mobilfunknetze).
  • … Audit- und Forensik-Pflichten Reproduzierbarkeit auf Artefakt- und Log-Ebene fordern.
  • … der TCO von Datentransport (Egress, Speicherung, Compliance) höher ist als Edge-Compute.

Architektur-Patterns für striktes On-Prem und Hybrid

Pattern A: Strikt on-prem (Defense, kritische Infrastruktur)

  • Netzwerk: Segmentierte Zonen (OT/IT/DMZ), keine ausgehenden Verbindungen ins Internet. Software- und Modellartefakte via kontrollierten Transfer (signierte Offline-Medien oder dedizierte, gehärtete Update-Gates).

  • Compute: Kubernetes on-prem (vollständig), oft mit k3s/microk8s auf Edge-Nodes und einem zentralen Cluster am Standort für Aggregation und Management. Nodes mit TPM, Secure Boot, Image-Signing.

  • Storage: Objekt-Storage S3-kompatibel (z. B. MinIO oder Ceph RGW), getrennte Buckets für Rohdaten, Features, Modelle, Artefakte. Versionierung und WORM-Policies, um Audit-Anforderungen zu erfüllen.

  • Messaging: OPC UA für Maschinenanbindung; MQTT als leichtgewichtige Telemetrie-Schicht an der Edge; Kafka als robuste Backbone-Schicht auf Standortebene (Replays, Compaction, Time-Travel). Keine Topics verlassen das Perimeter; externe Schnittstellen liefern nur abgeleitete, aggregierte Metriken.

  • MLOps: Model Registry on-prem; Reproduzierbare Builds, SBOM, Signaturen (cosign o. ä.). Canary-Rollouts an der Edge via GitOps (Argo CD/Flux) in air-gapped Betriebsmodi (interne Registry-Spiegel).

  • Observability: OpenTelemetry-Kollektoren am Edge, lokales Sampling/Throttling, zentrale Korrelation on-prem. Ringpuffer-Logs für forensische Zeitreisen ohne Dauer-Upload.

Pattern B: Hybrid (Edge-Inferenz, zentrales Training)

  • Datenfluss: An der Edge wird inferiert, nur anonymisierte oder aggregierte Trainingsschnipsel (oder synthetische Daten) verlassen das Perimeter periodisch. Wenn echte Rohdaten gebraucht werden, per Datendiät: kurze Fenster, selektiv, rechtssicher freigegeben.

  • Training: Zentral auf einem sovereignen Compute-Cluster (on-prem oder europäische Jurisdiktion, vertraglich und technisch abgesichert). Modelle und Feature Pipelines werden als Artefakte zurückgespielt, signiert und versioniert.

  • Steuerung: Auditierbare Experimente; Feature Store, der Partitionen pro Standort kennt; Offline-Evaluationssuiten, die an der Edge vor Ausrollung laufen, damit keine Überraschungen entstehen.

  • Vorteil: Sie behalten Entscheidungslogik dort, wo die Konsequenzen entstehen (Edge), bekommen aber Aggregationsvorteile für Lernkurven und Verbesserungen.

Pattern C: Cloud-first (nur wenn Souveränität und Latenz es zulassen)

  • Das ist sinnvoll für globale, nicht-sensible Aggregation, Simulationen oder Trainings mit öffentlichen Datensätzen. In Industrien mit strenger Souveränität ist das eher die Ausnahme als die Regel.

Protokollwahl ohne Dogma: OPC UA, MQTT, Kafka