Application-Edge-Integration: Eine Studie zur Evolution

Ken Arora

Flugfähigkeit: Konvergente Evolution in der Praxis

Die meisten von uns haben schon einmal davon geträumt, fliegen zu können – und wie sich herausstellt, gilt das gewissermaßen auch für die Evolution. Die Fähigkeit zu fliegen – sei es, um Fressfeinden zu entkommen, effizienter nach Nahrung zu suchen oder weite Strecken zurückzulegen – hat sich für eine Vielzahl von Tieren immer wieder als äußerst nützlich erwiesen. Tatsächlich ist dies so häufig der Fall, dass die Evolution immer wieder neue Wege findet, das Ziel des Fliegens zu erreichen. Heute kennen wir drei verschiedene Tiergruppen, die unabhängig voneinander die Fähigkeit zu fliegen entwickelt haben: Insekten, Vögel und Säugetiere (Fledermäuse). Jede dieser drei Gruppen hat einen anderen evolutionären Weg zum Flug eingeschlagen, wobei ihre heutige Art des Fliegens die jeweilige Gestalt ihrer nicht flugfähigen Vorfahren widerspiegelt. Betrachten wir die Insekten: Ihre Vorfahren besaßen außen liegende Exoskelette, die sich durch eine geringe Dichte und einen schichtartigen Aufbau auszeichneten, was je nach Richtung zu unterschiedlichen Zugfestigkeiten führte. Auf dem Weg zum Flug machte sich die Evolution der Insekten daher verformbare Flügel zunutze – ein Ansatz, der auf dem vorhandenen Grundbaustein mit geringer Dichte und variabler Zugfestigkeit aufbaute. Bei den Vögeln hingegen war die Entwicklung von Federn die entscheidende „Technologie“ auf ihrem Weg zum Flug. In diesem Fall waren die Federn ein glücklicher Zufall: Sie entstanden aufgrund der Bedürfnisse einer Gruppe warmblütiger Dinosaurier, die ein fellähnliches Material benötigten, um Wärme zu speichern. Erst später erwiesen sich die Federn als glückliche „Technologie“, die das Fliegen ermöglichte. Fledermäuse schließlich sind die jüngste Gruppe, die das Fliegen entwickelt hat. Ihr Ansatz beruht auf einer schrittweisen Evolution aus gleitenden Säugetieren, doch sie konnten bislang noch nicht von Jahrmillionen evolutionärer Anpassung profitieren.

Eine interessante und bemerkenswerte Ergänzung zu dieser Geschichte ist die Beobachtung, dass die Menschen, als ihnen mithilfe von Maschinen schließlich das Fliegen in der Praxis gelang, völlig andere Ansätze verfolgten: entweder Auftrieb durch Gase, die leichter als Luft sind, oder schnell bewegte Tragflächen, die von benzinbetriebenen Motoren angetrieben werden.

Das war interessant, aber was hat das mit Edge Computing zu tun?

Aus evolutionsgeschichtlicher Sicht erzählen auch die Wege, die die Anwendungsbereitstellung in den vergangenen 20 Jahren eingeschlagen hat, eine Geschichte konvergenter Evolution. Genauer gesagt wurden in diesen Jahren verschiedene Bereitstellungstechnologien entwickelt, die sich rückblickend allesamt als erste, noch junge Evolutionsschritte hin zu dem erweisen, was sich heute zur Application Edge entwickelt.

Vorläufer vieler dieser ursprünglichen Technologien waren Content Delivery Networks (CDNs). Der Antrieb für diese Technologie – gewissermaßen ihre „evolutionäre Nische“ – war die Notwendigkeit, große Mengen relativ statischer Daten, typischerweise große Bilder sowie Audio- und Video-Streams, für eine umfangreiche Gruppe von Endkunden bereitzustellen. Die Lösung bestand darin, zwischengespeicherte Kopien der großen Datendateien an mehreren geografisch verteilten Standorten näher an den Clientgeräten abzulegen. Auf diese Weise ließ sich die Auslieferungslast sowohl hinsichtlich der Rechenleistung als auch der Bandbreite von einem einzigen zentralen Rechenzentrum weg verteilen und zugleich eine geringere und besser vorhersehbare Latenz erzielen.

Da Anwendungen heute immer ausgereifter und fester in unseren Alltag integriert sind, wächst weiterhin der Bedarf, die Anwendungserfahrung der Kunden durch geringere Latenzzeiten und zusätzliche Bandbreite zu verbessern. Allerdings haben sich die Rahmenbedingungen verändert und weiterentwickelt. So wie Klima und Geografie in der Natur fortwährend Anpassungen bewirken, führen veränderte Anforderungen an die Anwendungsbereitstellung zu Veränderungen bei den erforderlichen Lösungen. Die Anforderungen moderner Anwendungen gehen weit über das grundlegende CDN-Szenario hinaus. Die anspruchsvolleren Anwendungsfälle von heute müssen mehr leisten als lediglich einfache statische Inhalte bereitzustellen; sie stellen auch Anforderungen an Rechenleistung und Interaktivität. Beispiele für Anwendungen mit höheren Anforderungen sind Videokonferenzen und der elektronische Handel. Allgemeiner betrachtet erfordert der Trend zum Single-Page-Application-Paradigma (SPA), bei dem eine Anwendung aus einer Vielzahl unterschiedlicher Webdienste zusammengesetzt ist, robustere verteilte Ressourcen als lediglich statischen Speicher, um ein hochwertiges Benutzererlebnis zu gewährleisten. Da sich die Umgebung hin zu diesen neuen Anwendungsfällen „weiterentwickelt“ hat, beobachten wir eine entsprechende Konvergenz mehrerer etablierter Marktlösungen, die sich anpassen, um diese neue und lukrative „evolutionäre Nische“ besser zu besetzen – das technologische Gegenstück zum Konzept der „konvergenten Evolution“.

Die erste dieser bereits bestehenden Lösungen sind die zuvor erwähnten CDNs. Ihre evolutionäre „Stärke“ als etablierte Anbieter liegt in ihrer umfangreichen vorhandenen Infrastruktur mit einer großen Zahl bestehender CDN-Knoten. Ihr „evolutionärer“ Weg besteht darin, diese Knoten, die bislang ausschließlich auf cacheähnliche Speicherung ausgerichtet waren, so weiterzuentwickeln, dass sie einen ausgewogeneren Mix verschiedener Speichertechnologien – Dateien, Datenbanken und Objektspeicher – in Verbindung mit Rechenressourcen bereitstellen, die diese Speicher nutzen können.

Die zweite etablierte Lösung auf dem Markt sind Public-Cloud-Anbieter. Ihre „Stärke“ liegt in ihrem robusten Ökosystem aus Rechen-, Speicher- und Bandbreitenressourcen sowie den entsprechenden flexiblen Nutzungsmodellen für diese Ressourcen. AWS bietet beispielsweise verschiedene Datenbanktechnologien an, stellt Rechenleistung entweder serverbasiert oder serverlos bereit, verfügt über ein umfangreiches Technologieangebot für die Identitäts- und Authentifizierungsverwaltung und bietet vielfältige ergänzende Dienste wie Protokollierung und Berichterstellung, Visualisierung, Datenmodellierung und vieles mehr. Ihre „evolutionäre Lücke“ besteht jedoch darin, dass sie nicht über so viele Präsenzpunkte wie die etablierten CDN-Anbieter verfügen und daher nicht dieselbe Verteilungsbreite erreichen.

Am anderen Ende der Skala hinsichtlich der Anzahl von Präsenzpunkten stehen die Mobilfunkanbieter (Mobile Service Providers, MSPs), insbesondere im Zuge des Ausbaus ihrer 5G-Infrastrukturen. Die großen MSPs planen Zehntausende von Mobilfunkzugangspunkten, von denen jeder einen Zugang zum Kernnetz darstellt. Neben ihrer „Stärke“ in Bezug auf Verteilung und Skalierung verfügen sie an diesen Zugangspunkten über Rechenkapazität und begrenzte Speicherkapazität. Bis vor Kurzem waren diese Ressourcen jedoch in ihrem Umfang begrenzt und primär auf den eigenen Infrastrukturbedarf der MSPs ausgerichtet. Die zu schließende „Lücke“ besteht daher im Übergang zu einem Computing-Paradigma, das die Recheninfrastruktur für externe Anwendungen zugänglich macht, sowie in der Erweiterung um zusätzliche Speicherkapazitäten.

Zurück zum Fliegen – und warum Menschen einen anderen Ansatz verfolgten

Die soeben skizzierte Entwicklung lässt sich als natürlicher, schrittweiser Evolutionsprozess beschreiben. Manchmal gibt es jedoch evolutionäre „Gamechanger^[1]“ – etwas, das die Evolution aus der Bahn wirft und dazu führt, dass der lineare Verlauf neu bewertet wird. Bei der Entwicklung des Fliegens durch den Menschen ermöglichten Systeme, die schnell große Energiemengen bereitstellen können (z. B. benzinbetriebene Motoren), in Verbindung mit Werkstoff- und Konstruktionstechnologien zur Herstellung stabiler Leichtmetalllegierungen, die Herausforderung des Fliegens völlig neu zu denken. Damit änderten wir gegenüber der Art und Weise, wie die Natur das Fliegen hervorgebracht hat, gewissermaßen „die Spielregeln“.

Überträgt man diese Geschichte auf das Edge-Konzept, so konzentrierte sich die bisherige Entwicklung der Anwendungsbereitstellung auf die Auslagerung serverseitiger Aufgaben – also jenes Teils der Bereitstellungskette, der damit beginnt, dass der Server eine Anfrage empfängt. Aufgrund der „evolutionären Prägung“ der bereits vorhandenen Lösungen, deren Nutzen darin bestand, den Anwendungsserver zu entlasten, lag der Schwerpunkt insbesondere implizit auf der Auslagerung und Verteilung von Rechenprozessen und der Bereitstellung von Inhalten als Reaktion auf die Anfrage eines „Client“-Kunden.

Betrachten wir nun jedoch, was geschieht, wenn wir diese geografisch verteilten Präsenzpunkte nicht nur als Rechenknoten und Caches zur Entlastung des Servers – „Anwendungs-Proxys“ – verstehen, sondern zusätzlich als Kontrollpunkte, die eingehende Client-Anfragen gleichermaßen berücksichtigen und sie den Infrastrukturen sowie Rechen- und Cache-Knoten zuordnen, die den Anforderungen der jeweiligen Anwendung entsprechen. So könnte beispielsweise eine latenzunempfindliche, aber bandbreitenintensive Anwendung wie die Cloud-Dateisicherung anders geroutet werden als eine Anwendung mit geringem Bandbreitenbedarf, die empfindlich auf Latenzen reagiert, etwa Online-Gaming. Bankanwendungen, die eine zentrale Datenclearingstelle benötigen, könnten an ein zentrales Rechenzentrum weitergeleitet werden. Dieses Konzept, das ich als „Anwendungsorchestrator“ bezeichne, ergibt sich ganz natürlich, sobald man den Edge nicht mehr als etwas betrachtet, das lediglich den Server entlastet, sondern als ein Element, dessen Aufgabe darin besteht, den Zugang zur allgemeinen Server-/Zugangsknotenumgebung bereitzustellen.

Bauen wir ein Flugzeug, keinen Ornithopter

So wie der Mensch den praxistauglichen Flug letztlich nicht mit einem mechanisierten, vogelähnlichen Ansatz (da Vincis berühmtem „Ornithopter“) verwirklichte, sondern indem er überlegte, wie sich die am besten geeigneten verfügbaren Technologien – mit benzinbetriebenen Motoren gekoppelte Tragflächen – effektiver nutzen ließen, sollten auch wir darüber nachdenken, wie sich die Anwendungsinfrastruktur mit dem Aufkommen einer allgegenwärtigen, verteilten und dienstereichen Edge neu gestalten lässt. Je deutlicher das Potenzial dieser neuen Fähigkeit zutage tritt und je einfacher sie nutzbar wird, desto eher werden Anwendungseigentümer und -betreiber den nächsten Schritt auf dem Weg der Anwendungsevolution gehen. Das daraus resultierende bahnbrechende Ereignis – die disruptive Weiterentwicklung der Edge von einem bloßen Proxy für den Anwendungsserver oder einem überdimensionierten Anwendungscache hin zu einem vollwertigen Anwendungsorchestrator – wird dem Anwendungsökosystem eine Fülle neuer Möglichkeiten eröffnen, die Gegenstand künftiger Artikel sein werden.

Mit Blick auf den weiteren Weg möchte ich eine Vision davon vermitteln, wie die Nutzung des Edge als Anwendungsorchestrator eine stärker deklarative, absichtsgesteuerte Spezifikation des gewünschten Verhaltens jeder Anwendung ermöglichen und dadurch sowohl die Anwendungsinfrastruktur als auch das Kundenerlebnis bei der Nutzung der Anwendung optimieren wird. So könnte beispielsweise eine Anwendung, die etwa auf Augmented-Reality-Technologie setzt, eine Richtlinie festlegen, die Latenz und Bandbreite priorisiert, während eine Finanzanwendung möglicherweise Zuverlässigkeit oder Zentralisierung in den Vordergrund stellt und eine andere IoT-Anwendung für Verbraucher sich auf das OpEx-Management konzentriert. Allgemeiner betrachtet führt eine Denkweise, die die Rolle des Edge erweitert und ihn als Anwendungsorchestrator nutzt, auch dazu, dass der Edge zum logischen Ort für die Umsetzung von Sicherheitsrichtlinien und Transparenz wird. Damit erfüllt sich ein weiterer Wunsch vieler Anwendungsverantwortlicher: eine von der Infrastruktur unabhängige Anwendungssteuerung.

^[1] Die Entwicklung des sauerstoffbasierten Stoffwechsels ist ein gutes Beispiel, aber diese Geschichte muss ich ein andermal erzählen.

Über den Autor

Ken Arora

Weitere Blogbeiträge von Ken Arora