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

Problemstellung
Sie betreiben sicherheitskritische Anlagen, möchten visuelle Qualitätssicherung oder prädiktive Instandhaltung einführen, oder Sie denken über LLM-gestützte Assistenten für Instandhalter nach. Die Cloud verspricht Geschwindigkeit und Elastizität – aber Ihre Daten liegen in Werkshallen, Zügen, Fahrzeugen, Leitständen. Funklöcher, regulatorische Auflagen, Exportkontrollen, ITAR/EAR, Betriebsräte, NDAs, Safety-Cases. Reicht „Cloud-first“? In vielen industriellen Szenarien nicht. In Defense und kritischer Infrastruktur ist On-Premise de facto gesetzt. In der Fertigung entscheidet oft die Kombination aus Latenz, Verfügbarkeit und Datensouveränität. Die technische Frage lautet: Welche Architektur garantiert Souveränität, ohne Ihre Roadmap für Analytics, ML und Agentensysteme zu blockieren?

Aus unserer Erfahrung mit Cloud-Plattformen (Pilotenausbildung) und Fleet-Intelligence-Systemen (Eisenbahn) gilt: Souveränität ist kein „Compliance-Anhang“, sondern ein Architekturprinzip, das die Platzierung von Daten, Rechenlast und Kontrolle bestimmt. Im Folgenden skizzieren wir konkrete Muster, Anti-Patterns und Design-Entscheidungen, die sich in der Praxis bewährt haben.

Entscheidungstreiber: Was zwingt On-Premise?

  • Latenz und Jitter: Wenn ein Inferenzpfad (Sensor → Preprocessing → Modell → Aktor/Alarm) zuverlässig unter 100 ms bleiben muss, kollabiert die Luft für „Roundtrips“ in entfernte Rechenzentren. Nicht die mittlere Latenz ist kritisch, sondern die 99,9%-Perzentile und deren Varianz.

  • Verfügbarkeit am Rand: In Zügen, Werkhallen, Einsatzfahrzeugen ist Konnektivität nicht garantiert. Designen Sie mit „Offline-First“-Annahmen: Jede core-funktionale Entscheidung muss lokal möglich sein.

  • Datenklassifizierung und Exportbeschränkungen: Stücklisten, Qualitätsbilder, Telemetriedaten, Fehlerprotokolle – all das ist IP. Häufig sind Betriebsvereinbarungen oder Verträge restriktiver als gesetzliche Mindestanforderungen. „Kein Export ins Ausland“ ist häufiger als man glaubt – und schließt manche Hyperscaler-Optionen faktisch aus.

  • Sicherheit und Safety: Sicherheitsnachweise, Zulassungen und Audits verlangen deterministisches Verhalten, Reproduzierbarkeit, kontrollierte Angriffsflächen. Das spricht für schlanke, überprüfbare On-Prem-Stacks anstelle intransparenter Managed Services.

  • Kostenstruktur von Bandbreite: Hochfrequente Sensordaten (Video, Schwingungen) in Rohform in die Cloud schieben ist ökonomisch oft unsinnig. Vorverarbeitung am Rand senkt Datenvolumen und entkoppelt Kosten von der Signalrate.

Anti-Patterns, die wir wiederholt sehen

  • Naives Cloud-First: Steuerungs- und Datenebene sind fest miteinander in einem Public-Cloud-Account verdrahtet. Fällt die Leitung, fällt die Funktion. Besser: Kontroll-Ebene zentral, Datenebene lokal.

  • Ungezielte Protokollmischung: MQTT hier, proprietär dort, Kafka in der Mitte – aber ohne klare Semantik, QoS- und Retry-Strategie. Ergebnis: Backpressure-Kollaps und Ghost-Drops.

  • Edge als „Dumping Ground“: Alles wird auf Edge-Geräte gepackt – Logs, Modelle, Datenbanken – ohne Ressourcenbudgetierung. Einmalige Lastspitzen führen zu Thrashing, File-Desynchronisierung und Korruption.

  • Telemetrie-Leaks: Debugging- oder Prompt-Logs wandern in Dritttools. Bei sensiblen Daten ist das ein K.-o.-Kriterium – auch für LLM-gestützte Systeme. Observability muss on-prem beherrschbar sein.

  • OTA-Updates ohne Rollback: Ein fehlerhaftes Update bricked 500 Knoten. Ohne transaktionales Update mit Rollback, Canaries und Health-Gates wird Fleet Management zum Glücksspiel.

Referenzarchitekturen: Drei Muster, die funktionieren

1) Edge-first On-Premise (Defense, kritische Infrastruktur)

  • Datenebene

  • Feldbus/Devices → OPC UA/Industrielle Protokolle (ggf. via Gateway) → Edge Collector

  • Event-/Message-Bus lokal: MQTT (Sparkplug B für Semantik) für Geräteleben; optional lokales Kafka für hohe Bandbreiten und Replays

  • Zeitreihen lokal (z. B. TSDB) und Kurzzeit-Buffer (Ringpuffer) für Rohdaten wie Video

  • Rechenebene

  • Inferenz on-device oder on-site (CPU/GPU/TPU je nach Lastprofil)

  • Feature-Engineering lokal, Reduktion vor Speicherung

  • Jobs orchestriert via lokalem Kubernetes/Container Runtime mit Node-Affinities und Ressourcenquoten

  • Steuerungsebene

  • Lokale Orchestrierung, Policies, Secrets-Management on-prem

  • Zentraler „Directory“-Dienst (on-prem oder privater Core) nur für Metadaten, kein Sensordatenfluss

  • MLOps

  • Modell-Registry on-prem, signierte Artefakte

  • Canary-Rollouts pro Zelle/Anlage, A/B-Vergleiche offline anhand identischer Replays

  • Observability

  • Metriken/Logs lokal aggregiert; Forwarding in zentrale Instanz nur für de-identifizierte Metadaten

  • Warum: Volle Souveränität, minimale Latenz, keine Cloud-Abhängigkeit im Betriebspfad.

2) Hybrid: Edge-Inferenz, zentrale (private) Trainings- und Fleet-Services

  • Datenebene

  • Edge filtert und featuret Daten; nur verdichtete/annotierte Samples mit Freigabe landen zentral

  • Schema-evolution über Avro/Protobuf oder Sparkplug B; Versionierung strikt

  • Rechenebene

  • Inferenz und schnelle Heuristiken am Edge; Batch-Training zentral (im eigenen Rechenzentrum oder in einer europäischen Cloud-Umgebung unter klaren Datenabgrenzungen)

  • Steuerungsebene

  • Zentraler Control-Plane-Dienst (Mandanten, Richtlinien, Modelllebenszyklus)

  • Geräte bleiben funktionsfähig ohne Control-Plane (graceful degradation)

  • MLOps

  • Federated Sampling: Edge markiert „lehrreiche“ Beispiele anhand lokaler Fehler/Unsicherheit

  • Differentialer Export: Nur das Nötigste, mit Audit-Trail

  • Observability

  • Ereignis- und Metrikaggregation zentral für Flotteneinblicke; Rohdaten verbleiben lokal

3) Cloud-heavy (nur wenn Daten und Latenz es erlauben)

  • Datenebene

  • Telemetrie kontinuierlich in zentrale Streams; strikte Pseudonymisierung

  • Rechenebene

  • Skaliert zentral; Edge schlank als Forwarder und Watchdog

  • Steuerungsebene

  • Vollständig zentral; Edge als durchsetzende Policy-Agents

  • Wann sinnvoll

  • Nicht-sicherheitskritische Telemetrie, große analytische Workloads, geringe rechtliche Restriktionen