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: