• Daten-Gravity und Egress: Wenn 90 % der Rohdaten vor Ort verwertbar sind, kostet ihr Transport mehr als ihr Nutzen.
  • Hardware-Lifecycle: Edge-Hardware ist CAPEX, aber kalkulierbar und wiederverwendbar. Cloud-Compute ist OPEX mit schwer prognostizierbaren Peaks.
  • Betriebsautomatisierung: GitOps, deklarative Zustände, SBOMs, SLO-Monitoring – egal ob Cloud oder Edge. Wer hier investiert, reduziert Betriebskosten in beiden Welten.
  • Vendor-Lock-in: Proprietäre Cloud-Dienste sparen anfänglich Zeit, erschweren aber Souveränität und Portabilität. Offene Protokolle und self-hosted Alternativen (z. B. S3-kompatibler Storage, Kafka-kompatible Streams) halten Optionen offen.

12. Praktische Muster und Bausteine

  • Orchestrierung: k3s/Kubernetes auf Edge-Knoten, containerd als Runtime, restriktive PodSecurity.
  • Messaging:
  • Feld: OPC UA/TSN.
  • Edge: MQTT (QoS 1/2 für Kritisches), Retained Messages für Zustände.
  • Aggregation: Kafka mit Schema-Registry; Connectors für Bridges.
  • Storage:
  • Lokal: RocksDB/SQLite pro Service; Zeitreihen lokal (z. B. VictoriaMetrics/Prometheus TSDB) für Kurzspeicher.
  • Objektspeicher on-prem: S3-kompatibel (MinIO/Ceph RGW) für Artefakte, Binaries, Snapshots.
  • Zeit:
  • PTP für harte Latenzpfade; NTP nur als Fallback. Zeitstempel immer am Entstehungsort setzen.
  • Sicherheit:
  • mTLS überall, mutual Auth über kurzlebige Zertifikate; Secret-Verteilung via lokaler Secret-Engine.
  • Signierte Images/Modelle; Policy-Check vor dem Start (Admission Controller).
  • Updates:
  • Canary/Blue-Green, Health-Probes, automatische Rollbacks bei SLO-Verletzung.
  • Air-Gap: Offline-Repo-Mirrors, signierte Update-Bundles, Vier-Augen-Freigabe.

Fazit

Die Frage „Edge vs. Cloud“ ist falsch gestellt. Richtig ist: „Welche Teile meines Systems dürfen nie eine Remote-Abhängigkeit haben – und wie gestalte ich den Rest so, dass ich Souveränität behalte?“ Wer Latenz, Verfügbarkeit, Souveränität und Daten-Gravity ernst nimmt, landet automatisch bei einer Edge-first-Architektur mit klar definierten Brücken in zentrale Dienste. Cloud ist dann ein Verstärker – für Fleet Analytics, Fleet-Management, Trainingspipelines –, aber kein Single Point of Failure.

Souveränität ermöglicht Intelligenz: Wer die Kontrolle über Daten, Schlüssel, Modelle und Prozesse behält, kann mutig automatisieren, sicher skalieren und regulatorisch sauber liefern. Alles andere ist Hyperscaler-Hoffnung – und die skaliert selten auf dem Shopfloor.

FAQ – technische Kurzantworten

  • Wie verteile ich Updates in Air-Gap-Umgebungen sicher?
  • Artefakte signieren, SBOM beilegen, offline Container-Registry spiegeln. Update-Bundles auf Wechseldatenträgern mit separater Signatur transportieren. Auf der Zielseite: Verifikation gegen lokale PKI, Vier-Augen-Freigabe, transaktionale Aktivierung und automatischer Rollback bei Health-Check-Fehlschlag.
  • Welche Kombination aus OPC UA, MQTT und Kafka empfiehlt sich bei 1.000+ Geräten?
  • OPC UA dort, wo PLC-Semantik gebraucht wird. MQTT als leichtgewichtiges Edge-Pub/Sub zwischen Geräten und Edge-Services. Werksaggregation via Kafka mit Schema-Registry. Bridges: OPC UA → MQTT Mapper am Edge; MQTT → Kafka Bridge auf der Aggregationsebene mit Schema-Enrichment.
  • Wie stelle ich deterministische Inferenzzeiten sicher?
  • Modelloptimierung (z. B. Quantisierung), Fixierung von Thread-/Batch-Parametern, Pinning auf isolierte CPU-Cores, vorhersagbare GPU-Scheduler, Warmup-Phasen. Keine Netzwerkabhängigkeiten im kritischen Pfad; lokale Pre-/Post-Processing-Schritte. Jitter-Budgets pro Stufe definieren und durchsetzen.
  • Wie betreibe ich ein Modell-Governance-System on-prem?
  • On-Prem Model Registry mit Versionierung und Signaturen, Policies für Freigaben (zonen-, geräte- und use-case-spezifisch), Audit-Trail über alle Promotions. Shadow/Canary-Mechanismen lokal, SLO-Monitoring und automatische Rollbacks. Artefakte über lokales KMS signieren; Deployments nur nach Policy-Check.
  • Wie gehe ich mit Feature-Drift um, ohne Rohdaten zu exportieren?
  • Edge-seitige Drift-Detektoren messen Verteilungen/Statistiken. Exporte enthalten nur Aggregatwerte und beschriebene Schemas. Stichproben-Rohdaten nur nach technischem Freigabeprozess und Zweckbindung; standardmäßig nicht notwendig. Retraining nutzt aggregierte Features und lokal vergebene Labels.

Wenn Sie eine konkrete Produktionslinie, ein Flotten-Szenario oder eine Defense-Umgebung diskutieren wollen: Der erste Schritt ist immer die Latenz-/Verfügbarkeitsmatrix und die Datenflussanalyse. Daraus ergibt sich, was zwingend vor Ort bleiben muss – und wo zentrale Dienste Sinn stiften, ohne Souveränität zu opfern.