Die Datenverarbeitung in Cloud und Edge wird meist in Form von leichtgewichtigen Containern verfügbar gemacht. Die reduzierte Größe von Containern im Vergleich zu virtuellen Maschinen (VM) ermöglicht eine flexible Bereitstellung auf verschiedenen Ebenen der Cloud-Edge/Edge-IoT Architektur. Hierbei gilt es eine effiziente Verteilung der containerisierten Applikation zu erreichen, um:

• dem (oft limitierten) Angebot an Ressourcen der Geräte (z. B. Raspberry Pi oder andere Embedded-Geräte) im Edge-Layer gerecht zu werden und den Energieverbrauch durch effiziente Verteilung zu minimieren
• die Anforderungen an die benötigte Latenz der Applikation und der verfügbaren Bandbreite zu erfüllen
• alle Abhängigkeiten zu anderen Services und weiteren Ressourcen entsprechend in annehmbarer Distanz zum eigentlichen Service bereitzustellen.

Für die Frage der Verteilung von containerisierten Applikationen spricht man von der sog. Cloud-Edge Orchestration, die sich diesen Herausforderungen annimmt. Die Orchestration einer solchen mehrschichtigen Architektur umfasst die Auswahl von Edge-Knoten für das Deployment, Monitoring und die autonome und dynamische Ausführung von Containern unter Einhaltung der geforderten Quality-of-Service (QoS), wie z.B. die maximal zulässige durchschnittliche Verarbeitungszeit einer Anfrage. Neben populären Frameworks wie Kubernetes gibt es zahlreiche weitere, nicht-threshold basierte Algorithmen und Policies zur Umsetzung komplexer autonomer Orchestrationen mit unterschiedlichen Techniken z. B. aus dem Bereich des maschinellen Lernens.

Ziel ist es, basierend auf dem Leistungsanforderungsprofil von Applikationen (z.B. CPU- oder I/O-intensiv) und Infrastrukturleistungsdaten, wie z.B. Art und Anzahl der Knotenpunkte, einen Algorithmus für eine autonome Orchestration auszuwählen. Die Orchestration wird dabei in eine plattform-unabhängige Orchestrationstopologie umgesetzt und von einer Container-Runtime (z. B. Docker) ausgeführt und anschließend auf Knoten in der Cloud-, Edge- und IoT-Ebene verteilt. Die Knotenpunkte melden dabei stets QoS-Daten an den Autonomen Controller zurück, welcher unter Anwendung des MAPE-K-Loop reagiert und die Orchestration laufend anpasst (Abb. 2). Anhand der gewonnenen Daten kann mit Hilfe statistischer Auswertungen eine Empfehlung für die zukünftige Bereitstellung von neuen Applikationen ausgesprochen werden.

Aus diesem universalen Architekturvorschlag ergeben sich folgende Fragestellungen, welche im Kernbereich unserer Forschung stehen: