Distributed-Multicloud: zukunftsweisend

Autoren/Redakteur: Silvio Kleesattel, Technology Lead und Helmut Weiss, Enterprise Cloud Architect bei Skaylink/gg

Eine zentrale Datenverarbeitung kann vieles, aber nicht in Echtzeit. Da die aber immer wichtiger wird, braucht man neue Cloud-Modelle – auch in der Komplexität Herr zu werden.  

Mit Blick auf die Cloud gibt es aktuell eine Entwicklungsspirale, auf die Unternehmen Antworten finden müssen, losgetreten von einer kontinuierlichen Modernisierung – der Infrastruktur, des Betriebs und von Anwendungen. In der Konsequenz verteilen Unternehmen bereits zunehmend Anwendungen über die eigenen Rechenzentren hinaus in eine oder mehrere öffentliche Clouds oder Edge-Umgebungen. Entsprechend wird das Management mehrerer Cloud-Umgebungen für die IT zunehmend zur Regel denn zur Ausnahme – auch, weil über Multi-Cloud-Lösungen zunehmend Compliance-Bedürfnisse oder Anforderungen an die Performance abgedeckt werden können. 

Gleichzeitig sorgen „Altlasten“, also jener harte Kern an Java- oder .Net-Applikationen, dafür, dass immer mehr verteilte Umgebungen, die Distributed Cloud-Modelle, entstehen. Denn Altlasten können meist nicht auf dieselbe Art und Weise modernisiert werden, sind für den laufenden und reibungslosen Betrieb des Unternehmens jedoch oftmals unverzichtbar. Entsprechend müssen neue, kreative Wege gefunden werden, damit sie mit dem Unternehmenswachstum und der damit einhergehenden zunehmenden Komplexität des Cloud-Computings schritthalten können. 

Distributed Cloud trifft auf zentrale Verwaltung  

Diese neue Entwicklungsspirale trifft nun auf ein System der zentralen Datenverwaltung in nur einer Cloud. Das hat bisher prima funktioniert, weil die notwendigen Informationen über das Internet abgefragt und über eine zentrale, von Hyperscalern gesteuerte API verteilt werden konnten. Schwer wird es allerdings, sobald beispielsweise eine Kommunikation mit einem Bluetooth-Gerät außerhalb der Cloud erforderlich wird. Denn damit entsteht eine Schnittstelle, die eine API außerhalb der Cloud-Umgebung direkt auf dem Endgerät des Nutzers anspricht. Hier gilt es, die Kontrolle über Funktionalität und Qualität zu gewährleisten und Missbrauch und Manipulation durch Cyberkriminalität zu vermeiden. In einem kleineren Rahmen mit vergleichsweise wenig Ausstattung mag das noch ohne Komplikationen gelingen. Werden die Umgebungen spezifischer, etwa mit bis zu 1.000 Nutzern und entsprechend vielen Geräten, wird es schnell kompliziert und unübersichtlich, was die Anfälligkeit für Missbrauchsversuche entsprechend erhöht. 

Gleiches gilt für ein dezentralisiertes Umfeld mit mehreren spezifischen Cloud-Anwendungen.  Bestes Beispiel: ein 5G-Netz mit vielen Netzbetreibern und unterschiedlichen Funktionen, weswegen APIs lokal aufgerufen werden müssen. Die Daten laufen dann direkt in die Basisstation des 5G-Netzes und schaffen es nicht bis ins Rechenzentrum oder ins Gebiet des Cloud-Anbieters. Das verbessert natürlich Leistung und verringert Latenzzeiten, allerdings nicht ohne die bereits erwähnten Downsides. 

Container und Kubernetes reichen nicht  

Was so entsteht, lässt sich zunächst als eine Art Durcheinander von APIs, API-Codes und Funktionalitäten betrachten, in das es eine Ordnung zu bringen gilt. Nur so kann ein gewisses Maß an Sicherheit garantiert werden – vor allem dann, wenn viele Nutzer in unterschiedlichen Regionen tätig sind, ihre Standorte und damit auch die URLs wechseln. Denn genau die sind ein beliebtes Ziel für Hacker, um Fakes einzuschleusen. 

Nun ist die Container-Technologie ein beliebtes Mittel, Interoperabilität zwischen verschiedenen Cloud-Welten trotz hoher Abhängigkeiten zwischen Infrastruktur und Applikationen herzustellen. Sie sorgt mit zentralen Komponenten dafür, dass Anwendungen weitgehend unabhängig von der jeweiligen Umgebung funktionieren, indem sich containerisierte Applikationen auf verschiedene Cloud-Plattformen verschieben lassen. Und auch aus dem Kubernetes-Umfeld gibt es entsprechende Beispiele, die – genau wie die Container-Technologie – bei manchen Nutzerszenarien allerdings eindeutig zu kurz greifen. 

Schlüsselthema bei Distributed-Cloud-Konzepten

Für IT-Designer, -Architekten und -Entwickler heißt es deshalb zunächst: Abstand gewinnen. Denn wenn man einen Anwendungsfall aus der Ferne betrachtet, sieht man die verschiedenen APIs oder Funktionalitäten, die für eine Anwendung wichtig sind. Hierbei zeigt sich auch, dass Anwendungen immer dann Daten auf lokaler Ebene etwa mit Maschinen in der Fabrik selbst oder mit kleineren Rechenzentren mit lokalen APIs austauschen, wenn etwa lokale Sensordaten essenziell werden. Ein Beispiel findet sich in der produzierenden Industrie, wo Datenschutz und lokale Verarbeitung nicht nur sehr wichtig, sondern teilweise auch gar nicht anders möglich sind, etwa wegen der notwendigen kleinen Latenzen der Steuersysteme von Maschinen oder Produktionsprozessen. 

Genau deshalb dürfte sich die Distributed-Multicloud zum Zukunftsmodell der Cloud mausern. Sie schafft Zusammenhänge und sorgt dafür, dass 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 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.