Thought Leadership
Mit fortschreitender Digitalisierung werden auch die Cloud-Modelle komplexer. Neue Ansätze sind gefragt, um hier den Überblick zu behalten und Sicherheitsstandards zu gewährleisten. Das französische Unternehmen Reportlinker hat im März dieses Jahres seinen Distributed Cloud Global Market Report 2023 veröffentlicht und die Zahlen zeigen: Die Wolken werden größer.
Der Distributed Cloud Markt wuchs von 3,38 Milliarden US-Dollar in 2022 auf 4,01 Milliarden in 2023, was einer jährlichen Wachstumsrate (CAGR) von 18,6 Prozent entspricht. Bis 2027 sagen die Experten eine CAGR von 17,8 Prozent, respektive ein Wachstum auf 7,73 Milliarden US-Dollar voraus.
Diese Zahlen dürften nicht überraschen, denn Fakt ist, dass durch die fortschreitende Digitalisierung immer mehr Anwendungsszenarien in die Cloud ziehen und entsprechende Modernisierungen angegangen werden müssen – auch solche, die bisher bewusst außen vor gelassen wurden. Zu nennen sind hier sicherlich der harte Kern an Java oder .NET Applikationen auf Servern und Datenbanken, die nur aufwändig modernisiert werden können, für den reibungslosen Betrieb vieler Unternehmen jedoch unverzichtbar sind.
Geht man dieses Thema an, so werden Workloads auf Infrastruktur-Clouds (IaaS) und Plattformen (PaaS) verteilt, nicht selten aber auch mit SaaS Lösungen substituiert. Damit erreicht man zwar die Ziele, die man durch die Modernisierung anstrebt, wie Skalierbarkeit, verbrauchsabhängige Kosten und reduzierte Administrationsaufwände, aber man erkauft sich dieses durch eine deutlich komplexere Landschaft: die Distributed Cloud.
Übersicht erschwert
So weit, so gut. Die Crux an den Distributed Cloud Modellen ist jedoch, dass oftmals die Übersichtlichkeit genauso leidet wie die Verwaltbarkeit vormals einfacher Anwendungen. Fatal dabei ist, dass vor allem mangels übergreifender Monitoring- und Steuerungs-Tools die Komplexität der Administration überproportional mit der Anzahl der administrierten Workloads steigt. Economy of Scale Effekte z. B. durch Automatisierung der Administration sind schwerer zu erzielen als bei zentralen und homogenen „Single-Cloud-Services“.
Und noch ein häufig gesehenes Trade-off wollen wir hier beschreiben: Die Distributed Cloud hilft dabei, Latenz-sensitive Workloads trotz ihrer besonderen Anforderungen in der Cloud zu betreiben. Die Methodik hierbei ist, dass die Applikation entsprechend modularisiert wird, um z. B. die Daten nach wie vor zentral zu halten, jedoch jene Applikations-Module, welche im direkten Kontakt zum Servicenutzer stehen, geographisch nahe an den Nutzer zu bringen und somit Bandbreiten und vor allem Latenz-Probleme zu eliminieren.
Der Datenaustausch zwischen zentralen und dezentralen Komponenten kann hierbei über verschiedene Wege wie z. B. das Internet erfolgen, da die Hyperscaler ein zentrales API-Management (Application Programming Interface, i.W. eine gemanagte Datenschnittstelle) als Service zur Verfügung stellen.
Wenn dann aber beispielsweise eine Kommunikation mit einem Bluetooth-Gerät außerhalb der Cloud erforderlich wird, entsteht eine neue Schnittstelle, die entsprechen nach einer API außerhalb der eigenen Cloud-Umgebung verlangt, um das Endgerät des Nutzers zu erreichen. Und letztendlich heißt das immer erneute Kontrolle, um Funktionalität und Qualität im gewünschten Maß zu gewährleisten.
Eine Frage der Skalierung
Die Nutzung von Distributed Cloud Lösungen ist für hoch skalierbare Workloads oft die einzige Möglichkeit, mit dem Bedarf mitzuhalten. Ein schönes Beispiel ist hierbei 5G mit seinen zahlreichen Netz- und Service Providern mit unterschiedlichen Services und unzähligen Usern mit unterschiedlichsten Endgeräten. APIs müssen hierbei lokal aufgerufen werden und die Daten laufen dabei in die Basisstation des 5G-Netzes und nicht erst in ein zentrales Rechenzentrum oder in das Gebiet des Cloud-Anbieters. Durch dieses Verfahren wird die Leistung erheblich verbessert und die Latenzzeiten verringert.
Allerdings sorgen die diversen APIs und Funktionalitäten einer dezentralen Multi-Cloud eben auch für eine erhöhte Komplexität, was ihr ordnungsgemäßes Management und damit das Gewährleisten eines gewissen Sicherheitsniveaus erschwert. Bestes Beispiel: Es gibt mehrere Nutzer mit unterschiedlichen Geräten, die in einer Umgebung tätig sind, allerdings ihre Standorte und damit ihre URLs wechseln. Es ist nicht trivial, hierbei sicherzustellen, dass Angreifer keine Chance haben, sich hier dazwischenzuschalten.
Distributed Cloud Konzepte auswürfeln
Zwar gibt es bereits Beispiele aus dem Kubernetes-Umfeld, bei denen Container-Instanzen und Funktionalitäten je nach Einsatzszenario entsprechend verwaltet werden. Sie greifen bei einigen Benutzerszenarien jedoch noch eindeutig zu kurz. Für IT-Designer, -Architekten und -Entwickler besteht die wesentliche Aufgabe deshalb darin, zunächst mentale Modelle wie den Multicloud-Würfel zu entwerfen und diese dann entsprechend umzusetzen.
Die Herausforderung liegt aktuell noch in der wenig feinen Granularität der Multicloud-Würfel. Hier braucht es künftig deutlich erweiterte Spezifikationen, um den konkreten Anforderungen gerecht zu werden – also beispielsweise detailliertere Punkte auf den verschiedenen Achsen des Würfels, die einbezogen werden können. Das heißt, die Würfel müssen vor allem bedarfsgerecht weiterentwickelt und präzisiert werden, damit auf den jeweiligen Achsen auch die verschiedenen Dimensionen enthalten sind, welche die Bedürfnisse der Nutzer erfüllen. Dies würde bereits dazu beitragen, ein besseres Verständnis dafür zu bekommen, was für Dimensionen tatsächlich enthalten sind und was zusätzlich ergänzt werden sollte. Daher ist der Multicloud-Würfel ein wichtiges Modell zur Unterstützung und Hilfe, damit ein Gedankenmodell überhaupt richtig funktioniert.
Abstand gewinnen
Betrachtet man einen Anwendungsfall aus der Ferne, so sieht man die verschiedenen APIs oder Abhängigkeiten, die für eine Anwendung wichtig sind. Denken wir zum Beispiel an eine Wetterapplikation, die Wetterdaten herunterlädt und Daten abfragt. Dafür braucht sie entweder den Standort des Nutzers oder den gewünschten Ort, für den das Wetter angezeigt werden soll. Die anschließende Anzeige erfolgt nun entweder über das Gerät des Nutzers oder über eine Anwendungslogik. In diesem einfachen Fall werden die Informationen noch zentral bereitgehalten. Komplexer wird es, wenn eine solche Abfrage etwa von einem Landwirt direkt auf dem Feld erfolgt, wo zusätzlich auch andere Informationen wie beispielsweise Sensordaten zur Bodenbeschaffenheit einfließen und an die Steuerung von landwirtschaftlichen Geräten zurückgespielt werden sollen. In diesem Fall muss auf die lokale API des Geräts, etwa des Traktors, zurückgegriffen werden. Ähnliche Anwendungsfälle finden sich in der produzierenden Industrie, wo vor allem Datenschutz und lokale Datenverarbeitung eine wichtige Rolle spielen – oder aufgrund von Latenzen der Steuersysteme gar nichts anderes möglich ist.
Deshalb kommuniziert ein Teil solcher Anwendungen auch nicht mehr ausschließlich mit einer zentralen Cloud, sondern tauscht Daten auch auf lokaler Ebene mit Maschinen in der Fabrik selbst oder in kleineren Rechenzentren mit lokalen APIs aus.
Distributed Multicloud als Zukunftsmodell der Cloud
Und hier fügt sich das Bild dann in Form des Multicloud-Würfels, respektive eines Distributed-Multicloud-Modells zusammen, weil so Zusammenhänge und dezentrale Cloud-Anwendungen nicht nur verstanden, sondern vor allem abgebildet und überwacht werden können.
Die Art des Einsatzes eines Distributed-Multicloud-Modells hängt dabei von der zu lösenden Aufgabe ab. Bedarf findet man bereits heute in der Logistik, der Medizintechnik, der Produktion, dem Maschinenbau und sogar im Einzelhandel. Das Distributed-Multicloud-Modell ist vor allem für Anwendungen von Bedeutung, die ein gewisses Maß an Echtzeitverarbeitung oder geografische Lokalität erfordern, da es Daten in Millisekunden verarbeiten kann, während eine zentrale, eventuell weit entfernte Cloud dafür mehrere Sekunden braucht. Das Modell unterstreicht allerdings auch, dass die leistungsfähigen APIs direkt vor Ort benötigt werden – mit all den damit einhergehenden Herausforderungen.
Silvio Kleesattel, Technology und Innovation Lead bei Skaylink, www.skaylink.com
Helmut Weiss, Enterprise Cloud Architect bei Skaylink, www.skaylink.com
