Microservice-Infrastruktur: Hybrid-Design

Die Verwaltung großer Rechnerplattformen wie IBM System z erfolgt oft Out-of-Band, d.h. ein Großteil der Systems Management Software läuft auf dedizierten Servern. Dies führt zu erheblichen zusätzlichen Hardwarekosten und einer niedrigen Auslastung der Server. Die aktuelle Infrastruktur ist aufwändig und teuer. Redundante Hardwarekomponenten führen zu einer niedrigen Gesamt-Auslastung der Ressourcen. Aus ökonomischer Sicht stellt sich die Frage, ob die gleiche Zuverlässigkeit und Stabilität mit weniger Hardware erreicht werden kann. Eine heterogene Rechnerlandschaft (Out-of-Band-Server und interne Prozessormodule) mit unterschiedlichen Prozessorarchitekturen (z.B. amd64 und s390x) erschwert die zuverlässige Ausführung und Verwaltung einer großen Anzahl kritischer Services. Die Verbesserung der Ressourcenauslastung und die Senkung der Hardwarekosten stehen im Mittelpunkt der Überlegungen.

Ein Ansatz zur Kostensenkung besteht darin, einen Großteil der Systems Management Software (Firmware) von externen Komponenten auf die Plattform selbst zu verlagern. Durch die Aufteilung von System Management Anwendungen in kleinere Services und deren Verteilung über die Plattform kann die Auslastung der internen Ressourcen erhöht und der Bedarf an externer Serverhardware gesenkt werden. Das Ziel ist die Reduzierung der zusätzlichen Kosten durch die Eliminierung oder zumindest teilweise Reduzierung der Out-of-Band-Server. Diese interne Verlagerung der System Management Aufgaben soll, unter Beibehaltung der Verfügbarkeitsgarantien des Mainframes, zu einer höheren Gesamtauslastung der Ressourcen und der Obsoleszenz der zusätzlichen Out-of-Band-Server führen. Die Abbildung 1.2 veranschaulicht dieses Konzept. Trotz der potenziellen Einsparungen birgt die Umsetzung als Microservices auch Herausforderungen in Bezug auf die Verwaltung und den erhöhten Betriebsaufwand für eine große Anzahl unabhängiger und verteilter Prozesse. Die Komplexität der Verwaltung wächst exponentiell mit der Anzahl der Anwendungen, weshalb eine automatisierte Management-Infrastruktur unerlässlich wird.

Die Migration der System Management Software zu einer Microservice-Architektur erfordert die Bewältigung der Komplexität verteilter Systeme. Asynchrone Kommunikationsprotokolle müssen eingesetzt werden, um Performance-Probleme zu mindern. Netzwerklatenzen und Ausfälle stellen Herausforderungen dar. Die Entwicklung erfordert ein verteiltes Denkmodell der Softwareentwickler. Die Notwendigkeit einer Infrastruktur zur Microservice-Orchestrierung ist essentiell für die Verwaltung der großen Anzahl von Services. Die Arbeit betont die Wiederverwendung bestehender Open-Source-Projekte und -Tools, anstatt eine kundenspezifische Lösung von Grund auf neu zu entwickeln. Die Wahl von Apache Mesos als Basis für den Prototyp wird begründet durch dessen hohe Verfügbarkeit, Skalierbarkeit und die Möglichkeit, mehrere Frameworks auf einem Cluster auszuführen. Die Anwendung-spezifische Scheduling-Funktionalität von Mesos soll die Auslastung der Hardwareressourcen optimieren, auch unter Berücksichtigung der unterschiedlichen Anforderungen der Firmware-Anwendungen. Die Umstellung auf Microservices könnte zudem eine modularere und dezentralere Softwarearchitektur erzwingen und so die Codequalität verbessern.

Der Abschnitt vergleicht die etablierte monolithische Architektur von System Management Software mit dem modernen Microservice-Ansatz. Monolithische Systeme, oft mit einer einzigen SQL-Datenbank verbunden, zeichnen sich durch sequentielle und transaktionale Datenbankupdates aus, die starke Konsistenzgarantien bieten, aber die Performance beeinträchtigen können. Im Gegensatz dazu bevorzugen Microservices die Verwaltung eigener Datenbanken und ermöglichen den Einsatz verschiedener Speichertechnologien ("Polyglot Persistence"). Die Konsistenzgarantien werden zugunsten von "eventual consistency" gelockert, was bedeutet, dass die Aktualisierungsübertragung im System Zeit benötigt und kurzzeitig inkonsistente Zustände auftreten können. Die Vorteile der Microservice-Architektur liegen in ihrer Skalierbarkeit, Flexibilität und höheren Verfügbarkeit. Der Vergleich mit klassischen Unix-Kommandozeilen-Tools veranschaulicht das Konzept von "Smart Endpoints and Dumb Pipes", bei dem die Geschäftslogik in den einzelnen Services liegt und die Kommunikation über leichtgewichtige Protokolle wie REST über HTTP erfolgt, im Gegensatz zu komplexeren Ansätzen wie dem Enterprise Service Bus (ESB).

Die Umstellung auf Microservices bringt jedoch auch Nachteile mit sich. Die verteilte Natur von Microservices führt zu erhöhter Komplexität, da Remote-Aufrufe langsamer sind als In-Memory-Aufrufe und anfällig für Netzwerkfehler und Prozessabstürze. Die Verwendung asynchroner Kommunikationsprotokolle erhöht die Komplexität der Entwicklung. Die Entwickler müssen ein verteiltes Denkmodell adaptieren. Neben der erhöhten Komplexität, ist auch die Implementierung von Sicherheitsmechanismen wie Authentifizierung und Autorisierung entscheidend. Der Schutz vor Angriffen, die auf Cluster-Mitgliedschaften abzielen (z.B. durch TLS-Zertifikate), ist wichtig. Das Prinzip des geringsten Privilegs sollte eingehalten werden, um die Zugriffsrechte auf ein Minimum zu beschränken. Ein weiterer wichtiger Aspekt ist die Handhabung von persistenten Daten. Der kurzlebige Zustand von Containern stellt eine Herausforderung dar, da Daten bei Containerabstürzen verloren gehen können, was bei zustandsbehafteten Services zu Problemen führt. Eine ideale Microservice-Infrastruktur bietet entweder Shared Persistent Storage oder APIs zur Integration mit Drittanbieter-Lösungen.

Die Anforderungen an eine Microservice-Infrastruktur für System Management werden in kritische und weniger dringliche Anforderungen unterteilt. Zu den kritischen Anforderungen zählt die Funktionalität des Prototyps. Weniger dringliche Anforderungen sind Sicherheits- und Monitoring-Aspekte, die für den Betrieb von Microservices unabdingbar sind, aber im Rahmen der Arbeit zunächst zurückgestellt wurden, um sich auf die zentralen Herausforderungen hybrider Cluster zu konzentrieren. Die Wahl von Apache Mesos als Grundlage der Infrastruktur wird in diesem Zusammenhang als besonders vielversprechend dargestellt, da es eine hohe Flexibilität bietet und verschiedene Aufgabenarten (lange laufende Dienste, Cron-Jobs, Batch-Jobs) unterstützt. Mesos' dezentrale Scheduling-Philosophie im Gegensatz zu zentralisierten Ansätzen wie bei Docker Swarm oder Kubernetes wird als großer Vorteil hervorgehoben, da sie eine Anwendung-spezifische Optimierung ermöglicht und besser auf zukünftige Entwicklungen reagieren kann.

Apache Mesos wird als Cluster-Management-Lösung für die hybride Umgebung gewählt, da es eine hochverfügbare und skalierbare Ressourcenabstraktionsschicht bietet. Mesos konsolidiert eine beliebige Anzahl von Maschinen zu einem einzigen Pool an Rechenressourcen, ermöglicht das Ausführen mehrerer Frameworks auf einem einzigen Cluster und unterstützt somit ein Application-Aware Scheduling, das die unterschiedlichen Anforderungen von Firmware-Anwendungen berücksichtigt und die Auslastung der verfügbaren Hardware maximiert. Im Gegensatz zu Lösungen wie Docker Swarm oder Kubernetes verfolgt Mesos eine dezentrale Scheduling-Philosophie. Dies erlaubt es, das Scheduling-Verhalten exakt an die jeweilige Anwendung anzupassen, im Gegensatz zu globalen Schedulern, die zwar eine optimale Gesamtauslastung anstreben, aber unter Umständen zu einer schlechten Datenlokalität führen können, etwa bei mehreren Jobs auf demselben Datensatz. Die Architektur von Mesos basiert auf der Beobachtung, dass Cluster zunehmend von verschiedenen Frameworks genutzt werden, die jeweils auf bestimmte Anwendungstypen (z.B. Webanwendungen, datenintensive wissenschaftliche Anwendungen) zugeschnitten sind. Mesos ermöglicht "Cluster Multiplexing" und effizientes Ressourcen-Sharing zwischen diesen Frameworks. Die Fähigkeit, benutzerdefiniertes Scheduling-Verhalten zu implementieren, ist ein entscheidender Vorteil.

Für die Koordinierung und hohe Verfügbarkeit von Mesos wird Apache ZooKeeper integriert. ZooKeeper nutzt verschiedene Techniken zur Performance-Optimierung, wie z.B. die Optimierung für lese-dominante Workloads und Client-seitige Caches. Die Arbeit erläutert auch die Verwendung von Linux Containern und deren Vorteile für die Workload-Isolation. Der Linux-Kernel bietet Namespaces und cgroups (Control Groups), die es ermöglichen, Container von der zugrundeliegenden Host-Umgebung zu isolieren und Ressourcenbeschränkungen für einzelne Prozesse festzulegen. Docker wird als User-Friendly API zur Nutzung dieser Kernel-Features erwähnt. Die Verwendung von Docker Images, die effektiv schreibgeschützt sind und auf dem Prinzip von Copy-on-Write (CoW) basieren, um Speicherplatz zu sparen und die Wiederverwendbarkeit zu erhöhen, wird ebenfalls beschrieben. Mesos kann verschiedene Containertechnologien (z.B. Docker, LXC) verwenden und bietet auch eigene Container-Tools an. Die Integration von Drittanbieter-Lösungen, wie z.B. Docker, erfordert die Installation des Docker Engine auf jedem Host, der einen Mesos Agenten ausführt. Frameworks können Container auch selbstständig starten, wie z.B. Marathon, das eine JSON-basierte Abstraktion für die Definition von Tasks als Docker-Container bereitstellt.

Die Arbeit beschreibt die Verwendung der Mesos Frameworks Marathon und Aurora. Beide Frameworks abstrahieren Jobs als Sammlung identischer Tasks, da Mesos nur mit Tasks arbeitet. Marathon und Aurora sind vor allem für lang laufende Services konzipiert. Aurora unterstützt Cron-Jobs (periodische Ausführung), während Marathon Funktionen für Job-Abhängigkeiten bietet. Die Kombination beider Frameworks auf einem Mesos-Deployment wird als Möglichkeit zur Abdeckung eines breiteren Spektrums von Job-Typen vorgeschlagen. Beide Frameworks ermöglichen die Definition von Scheduling-Constraints, um Jobs auf bestimmte Agenten mit spezifischen Labeln (z.B. CPU-Architektur) zu beschränken. Marathon bietet dabei mächtigere Constraint-Möglichkeiten als Aurora. Die Koordinierung von Mesos mit Apache ZooKeeper ist essentiell für die Zuverlässigkeit und Hochverfügbarkeit des Systems, da alle Agenten und Frameworks von einem funktionierenden Leader-Master abhängig sind. ZooKeeper verwaltet den dynamischen Zustand von Mesos, einschließlich der Master-Leader-Election. Die Verwendung des Mesos Replicated Log, basierend auf dem Multi-Paxos Konsensus-Algorithmus, gewährleistet einen robusten Zustand auch bei Master-Ausfällen.

Die praktische Umsetzung der Microservice-Infrastruktur basiert auf Apache Mesos. Theoretisch bietet Mesos die Flexibilität für spezielle Umgebungen wie IBM System z, jedoch ist die praktische Implementierung im Vergleich zu integrierten Lösungen wie Kubernetes oder Docker Swarm aufwändiger. Zusätzliche Abhängigkeiten für Koordination, Scheduling und Netzwerk müssen installiert werden. Die Migration von Mesos auf die s390x Architektur von IBM System z erweist sich als nicht trivial. Der Aufbau einer funktionsfähigen Umgebung erfordert die Installation und Konfiguration verschiedener Komponenten. Der Abschnitt beschreibt die Herausforderungen bei der Bereitstellung der Infrastruktur und die Notwendigkeit zusätzlicher Abhängigkeiten. Die Wahl von Mesos wird trotz des höheren Implementierungsaufwands begründet durch die gewünschte Flexibilität und Skalierbarkeit, welche durch die Bereitstellung eigener Container-Tools untermauert wird und die Abhängigkeit von externen Diensten wie Docker reduziert.

Die manuelle Installation von Docker auf CentOS wird kurz beschrieben. Es wird auf die Funktionsweise von Docker Images und Storage Drivern eingegangen. Docker Images bestehen aus mehreren schreibgeschützten Layern und einem zusätzlichen beschreibbaren Layer (Copy-on-Write). Die Einrichtung eines ZooKeeper Ensembles auf drei amd64-basierten VMs wird als unkomplizierter Prozess dargestellt. Ein Fokus liegt auf einer neuen Funktion in der ZooKeeper Version 3.5 (alpha), die dynamische Änderungen am Quorum ermöglicht, ohne einen Neustart des gesamten Setups. Die Konfiguration eines Docker Registry Servers für den Netzwerkzugriff wird erläutert, inklusive der Verwendung von TLS-Zertifikaten zur Sicherstellung der Sicherheit und der Notwendigkeit der regelmäßigen Überprüfung von Ablaufdaten. Die Verwendung von selbstsignierten Zertifikaten für Testumgebungen wird als Alternative erwähnt. Die Implementierung des Thermos Executors und Observers in einem einzigen Docker Image wird erklärt; dieser Ansatz wird gewählt, um eine reibungslose Interoperabilität mit dem Marathon Framework zu gewährleisten.

Die Erweiterung der Infrastruktur auf eine hybride Umgebung mit IBM System z (amd64 und s390x Prozessoren) stellt eine wesentliche Herausforderung dar. Die Unterstützung von Open-Source-Software auf weniger verbreiteten Plattformen wie Mainframes erfordert oft die manuelle Kompilierung und Erstellung von Paketen, was erheblichen Aufwand verursacht, der stark von der Programmiersprache abhängt. Die Arbeit beschreibt die Erfahrungen und Probleme beim Portieren der Komponenten (Docker, ZooKeeper, Mesos, Marathon, Aurora) auf die s390x Architektur. Die fehlende Verfügbarkeit von s390x Paketen für Mesos führte zur Notwendigkeit des Kompilierens aus dem Quellcode. Für Marathon musste ein angepasstes Base Image mit s390x-kompatiblen Binärdateien erstellt werden, da es die libmesos.so Shared Library benötigt, um über die Java Native Interface (JNI) mit dem Mesos Master zu kommunizieren. Die Abhängigkeit von der libmesos.so wird als starr und inflexibel bezeichnet, mit der Erwartung, dass Marathon zukünftig die Mesos RESTful API verwenden wird. Die Arbeit erwähnt auch die Komplikationen beim Umgang mit spezifischen OS-nativen Features, die nur in neueren Versionen des Linux-Kernels verfügbar sind, insbesondere im Kontext von IBM System z mit kundenspezifischen Kerneln.

Dieser Abschnitt beginnt mit der Unterscheidung zwischen homogenen und heterogenen Jobs in Multi-Architektur-Umgebungen. Homogene Jobs laufen auf Maschinen mit der gleichen Architektur, während heterogene Jobs auf verschiedenen Architekturen ausgeführt werden. Die Herausforderung besteht darin, die Mesos-Infrastruktur so zu nutzen, dass beide Jobtypen effizient gemanagt werden können. Mesos selbst bietet einfache Mechanismen wie Agenten-Node-Labeling, aber die Implementierung eines ausgefeilten Scheduling-Verhaltens liegt in der Verantwortung der Mesos-Frameworks. Der Fokus liegt hier auf der Nutzung des Marathon Frameworks, da die Scheduling-Möglichkeiten von Aurora noch nicht ausgereift genug sind. Der Abschnitt legt den Grundstein für die Beschreibung der praktischen Umsetzung des Job Schedulings auf einer hybriden Plattform.

Die Implementierung des Job Schedulings wird anhand des Marathon Frameworks beschrieben. Es wird erklärt, wie die Konzepte von homogenen und heterogenen Jobs mithilfe der vorhandenen Primitiven und APIs von Marathon umgesetzt wurden. Die Verwendung von Agenten-Node-Labeling und Scheduling Constraints, um Jobs auf Maschinen mit der gleichen CPU-Architektur zu platzieren, wird detailliert erläutert. Der Abschnitt befasst sich mit der Herausforderung, dass die Docker Registry zunächst nur 1:1 Beziehungen zwischen Identifikatoren (Namen) und Images zulässt. Für die gleiche Anwendung auf verschiedenen Architekturen (z.B. amd64 und s390x) müssten daher unterschiedliche Image-Namen verwendet werden, was die Transparenz für Plattformnutzer verringert. Die Architektur-abhängigen Image-Namen müssen den Nutzern bekannt sein. Der Abschnitt zeigt, wie mehrere Images unter einem einzigen Identifikator in einer Registry gespeichert werden können, um mehr Transparenz zu erreichen.

Die Verwendung identischer Image-Namen für Container auf verschiedenen Architekturen (SEs und LPAR Hosts) wird als wünschenswert, aber aufwändig dargestellt, da die Images manuell auf jeder Maschine separat erstellt werden müssten. Das Einrichten von zwei separaten Registries (eine für s390x und eine für amd64 Images) wird als keine Option betrachtet, da der Registry-Name Teil des Image-Namens ist. Die Verwaltung einer Registry pro Host wird ebenfalls als zu aufwendig verworfen. Der Abschnitt beleuchtet die Herausforderungen bei der Sicherstellung von Transparenz und einfachem Handling von Docker Images auf einer heterogenen Plattform. Es wird deutlich, dass der gewählte Ansatz der Infrastruktur die Architektur-spezifische Auswahl von ausführbaren Dateien übernehmen soll, um die Komplexität für den Benutzer zu reduzieren. Der Abschnitt führt zu der Schlussfolgerung, dass effizientes Job Scheduling auf hybriden Clustern mit Marathon eine sorgfältige Berücksichtigung der Architekturunterschiede und der Möglichkeiten der Docker Registry erfordert. Die beschriebenen Ansätze zielen auf maximale Transparenz für die Plattformbenutzer ab, ohne dass diese sich mit architekturspezifischen Details auseinandersetzen müssen.

Die Zuverlässigkeit der implementierten Microservice-Infrastruktur wurde durch verschiedene Tests evaluiert. Die Tests konzentrierten sich auf das Verhalten des Systems unter verschiedenen Fehlerbedingungen. Die Testumgebung bestand aus einer Infrastruktur, die unter anderem Apache Mesos, ZooKeeper, Marathon und Docker beinhaltete. Die Tests simulierten verschiedene Fehler, um die Robustheit des Systems zu überprüfen. Als Grundlage für die Simulationen diente ein minimaler, statisch kompilierter Go-Web-Server in einem Docker Image, der eine einfache, aber funktionsfähige Webanwendung darstellte, um den Ressourcenbedarf für die Tests gering zu halten. Die Last wurde dabei gleichmäßig auf drei Agenten verteilt. Die Testmethodik bestand darin, bestimmte Komponenten gezielt auszufallen zu lassen und das Verhalten des Systems zu beobachten. Die Ergebnisse sollten Aufschluss über die Robustheit und Fehlertoleranz der implementierten Architektur geben.

Der erste Test simulierte den Ausfall eines ZooKeeper Follower-Prozesses. Erwartungsgemäß sollte dies keine Leader-Election auslösen und keine Auswirkungen auf andere Infrastrukturkomponenten haben. Frameworks und deren Tasks sollten ohne Unterbrechung weiterlaufen. Aktive Sessions sollten nach einem Timeout zu einem anderen ZooKeeper-Node umgeschaltet werden. Diese Erwartung setzt voraus, dass nach dem Ausfall eines Followers ein Quorum (z.B. 2 von 3 Knoten) weiterhin verfügbar ist. Ist dies nicht der Fall, stoppen die verbleibenden ZooKeeper Server. Der Test diente der Überprüfung der Fehlertoleranz von ZooKeeper und dessen Auswirkungen auf die Gesamtsystemstabilität. Die Ergebnisse bestätigten die Erwartungen und zeigten eine robuste Reaktion des Systems auf den Ausfall.

Der zweite Test simulierte den Ausfall eines Mesos Agents. Erwartet wurde, dass die Tasks des Agents weiterlaufen und das Framework Ersatz-Tasks auf verbleibenden Agents plant. Dies wurde bestätigt. Es zeigte sich jedoch ein unerwartetes Verhalten: Der ausgefallene Agent bereinigte seine redundanten Tasks nach der Wiederherstellung nicht, wie in der Dokumentation beschrieben. Dies liegt daran, dass beim Beenden des Mesos Agenten-Containers auch die Task-Executors beendet werden. Ein wiederhergestellter Agent kennt die vorherigen Tasks nicht und kann sie nicht entfernen, was zu einer manuellen Intervention zwingt. Der dritte Test simulierte den Ausfall eines Standby Masters. Erwartet wurde, dass dies keine Auswirkungen hat, was sich bestätigte, außer wenn alle Standby-Master ausgefallen waren. In diesem Fall verweigerte Aurora Read- und Write-Requests, da Aurora das Mesos Replicated Log für die Zustandssicherung nutzt. Ohne Mesos-Quorum werden Write-Operationen zum Log abgelehnt. Die korrekte Einstellung der Mesos-Quorum-Größe für Mesos und Aurora ist entscheidend für das korrekte Verhalten des replicated logs. Die Tests zeigten unterschiedliche Reaktionen von Marathon ("fail fast") und Aurora beim Mesos Master-Failover.

Der letzte Test simulierte den Ausfall des führenden Mesos Masters. Die verbleibenden Master-Knoten sollten einen neuen Leader wählen, zu dem sich Agenten und Frameworks wieder verbinden können. Die Untersuchungen bestätigten dies, zeigten aber auch einen erheblichen Unterschied zwischen Marathon und Aurora im Umgang mit dem Mesos Master-Failover. Marathon verwendet eine "fail fast" Strategie, der führende Scheduler beendet sich sofort nach dem Verbindungsverlust. Aurora wartet hingegen auf ein Timeout, bevor es sich beendet. Diese unterschiedlichen Strategien zielen darauf ab, Inkonsistenzen im Clusterzustand zu vermeiden. Der automatische Neustart von beendeten Scheduler-Prozessen könnte beispielsweise über das OS-native Init-System (z.B. systemd) erfolgen. Die Ergebnisse unterstreichen die Bedeutung der korrekten Konfiguration und der Wahl geeigneter Frameworks für die gewünschte Fehlertoleranz und Reaktionszeit.

Die Arbeit präsentiert eine Referenzimplementierung einer Microservice-Infrastruktur für hybride Rechenumgebungen, wobei IBM System z als Beispielplattform dient. Die Motivation lag in der Verlagerung von System Management Anwendungen von externen Servern auf den Mainframe selbst, um Hardwarekosten zu senken und die interne Ressourcennutzung zu erhöhen. Dies führte zu einer verteilten Microservice-basierten Architektur. Eine zentrale Herausforderung war das Lifecycle-Management einer großen Anzahl von Services auf einer Multi-Architektur-Plattform (amd64/s390x). Ein Prototyp wurde entwickelt, der generische Workloads auf einer Umgebung mit zwei amd64 SEs und einem s390x LPAR verwalten kann. Es wurde gezeigt, dass durch die Kombination von Apache Mesos, Containern und OS-nativen Isolationsmechanismen eine zuverlässige und flexible Microservice-Plattform für homogene und heterogene Jobs aufgebaut werden kann. Die Lösung basiert auf existierenden Features wie Node-Labeling und Docker Image Fat Manifests, ohne neue Features in Open-Source-Projekten hinzuzufügen. Die Architektur ermöglicht transparente Deployments und abstrahiert plattformspezifische Details von Docker Images.

Zukünftige Arbeiten konzentrieren sich auf die Verbesserung der Fehlerbehandlung, insbesondere im Zusammenhang mit Mesos Agenten-Ausfällen. Ein konkretes Beispiel ist die Implementierung eines Startup Hooks, der beim Neustart eines Mesos Agenten-Containers alle darin laufenden Tasks löscht, um das Problem der nicht bereinigten Tasks nach einem Ausfall zu beheben. Weitere Forschungsarbeiten könnten die Erweiterung der Funktionalität der Infrastruktur, z.B. durch die Einbindung von Sicherheits- und Monitoring-Aspekten, umfassen. Die vollständige Integration des Aurora Frameworks in die hybride Umgebung ist ein weiteres Ziel. Die Optimierung des Job Schedulings und die Verbesserung der Transparenz für Plattformnutzer bleiben ebenfalls wichtige Aufgaben für zukünftige Entwicklungen. Weitere Untersuchungen könnten sich auf die Optimierung der Ressourcennutzung und die Skalierbarkeit der Infrastruktur konzentrieren.