Beiträge

Wenn Daten träge werden – Data Gravity

6.1.2020 / Falk Borgmann, Strategy Consultant, Deepshore GmbH

Haben sie in der Schule Physik oder Mathematik gemocht? Wenn man in der IT arbeitet und sich den verschiedenen Konzepten rund um verteilte Systeme widmet, wird man nicht vermeiden können, sich auch mit recht formellen Axiomen oder Theoremen zu beschäftigen. Jedenfalls dann, wenn man nicht nur an der Oberfläche von Lösungen und Technologien kratzen will. Sie kennen das Phänomen der Gravitation. Können auch Daten eine Gravitation, also eine Anziehungskraft entwickeln?

Masse zieht sich gegenseitig an

Und mehr Masse, zieht andere Masse noch mehr an. Bis hin zum schwarzen Loch, das selbst Licht und ganze Sternsysteme schlucken kann. Ob das bei Daten, rein physikalisch betrachtet, auch so ist, traue ich mich, ganz sicher nicht zu bewerten. Zu mindestens funktioniert diese Metapher, also Daten mit Masse und deren physikalischen Eigenschaften zu vergleichen, ziemlich gut. Und Gravitation eignet sich hervorragend, um ein Dilemma der Digitalisierung zu erläutern. Das Phänomen mit dem Namen Data Gravity ist erstmals 2010 durch Dave McCrory, damals Cloud Architect bei Dell und zuletzt Vice President of Software Engineering bei GE Digital, in dessen Blog erwähnt worden.

Was wir heute beobachten, ist eigentlich widersprüchlich: immer mehr Daten, immer mehr virtueller Speicher, immer höhere Flexibilität und das bei hervorragender Performance. Kleinere Datenvolumen in der Kombination mit wenigen und einfachen Rechenoperationen stellen sicherlich nicht die große Herausforderung dar. Aber mit einer gewissen Masse von Daten ist es nicht mehr ganz so einfach, flexibel, schnell und effizient zu arbeiten. Und das Volumen wächst rasant. Es gibt Studien, die bis 2025 von etwa 175 Zettabyte Daten (1 Zetta = 1021 Byte) weltweit ausgehen (2018 waren es 33 Zettabyte). Ein gutes Beispiel ist der Bereich des autonomen Fahrens. Ein einziges Fahrzeug kann heute am Tag locker 40 TB Daten produzieren – das ist schon ein ganz beachtliches Volumen.

Die Latenzproblematik

Dabei werden Daten tatsächlich mit zunehmender Masse träge. Ein aktuelles Beispiel, anhand dessen sich die Kausalität gut erklären lässt, liefert eine Pressemitteilung der Onlinebörse Euronext vom Dezember 2019. Dort wird das neue hybride Cloudmodell von Euronext vorgestellt. Deren IT speichert Daten nun auch massenhaft in der AWS Cloud – mit der Einschränkung, dass nicht alle Informationen bei Amazon liegen, da man die Latenzen dort nicht in den Griff bekommen würde. Als Latenz kann man die Zeit beschreiben, die ein Befehl (Versand eines Datenpaketes) zum Durchqueren eines Netzwerkes vom Sender zum Empfänger benötigt. Oder ganz banal ausgedrückt: Man kann zwar sehr viel Volumen in der Cloud abladen, aber wenn häufige und schnelle Zugriffe erforderlich sind, dann sollten die Daten doch lieber im selben Netz, bzw. Rechenzentrum liegen, wo auch die fachliche Anwendung betrieben wird.

Die Latenzproblematik zwingt die Euronext-Börse also, ihre Daten nahe bei der fachlichen Anwendung zu verwalten. Man könnte auch sagen, dass sich Daten und Applikationen anziehen. Eine naheliegende Lösung wäre es, die Applikationen einfach in der Cloud zu betreiben und so dem Latenzproblem zu entgehen. Aber wer kann schon genau sagen, wo diese Informationen in dieser virtuellen Umgebung wirklich liegen? Wo am Ende der physikalische Storage bzw. auch die Applikation wirklich laufen, wird wohl das Geheimnis der Cloudanbieter bleiben. Dabei stellt auch die Auswahl von „Regionen“ bei der Konfiguration von Cloudservices keineswegs eine zugesicherte physische Lokation dar. Zudem würde sich die Abhängigkeit von einzelnen Serviceprovidern derart erhöhen, dass eine technische Infrastruktur dann nur unter größten Schmerzen überhaupt gewechselt werden könnte.

Allein dieser nahe liegende Gedankengang, man könne die Applikation einfach in die Cloud umziehen, zeigt aber, dass intuitiv angenommen wird, wer hier die größere Trägheit besitzt. Und die Intuition hat vollkommen recht. Große Datenvolumen ziehen tendenziell Applikationen und Services an und nicht umgekehrt. Denn neben dem Latenzproblem gibt es eine zweite Dimension in diesem Spannungsfeld – den Durchsatz.

Nehmen wir einmal an, ein Unternehmen speichert große Menge an Daten bei einem Clouddienstleister. Dieser Dienstleister kündigt dann nach einigen Jahren der fruchtbaren Zusammenarbeit einfach seinen Service. Dann räumt dieser Serviceprovider seinem Kunden noch großzügig eine Übergangsfrist zur Migration ein – gegen einen geringen Obolus von 50 Prozent Mehrkosten. Was tun? Einfach schnell die Daten aus der Cloud holen und woanders speichern? Aber befindet man sich erst einmal im Bereich von mehreren Hunderten Terabyte Volumen, dann wird neben der Latenz auch der reine Durchsatz zu einem Problem. Wurden über Jahre die Leitungen in die Cloud beim Schreiben voll ausgelastet und so ein riesiger Datenbestand aufgebaut, ist es relativ unwahrscheinlich, dass das so entstandene Volumen innerhalb weniger Monate durch dieselbe Leistung migriert werden kann. Daten werden also mit zunehmender Menge auch noch träge. Genau wie Masse in der Physik. Sofern man sich zusätzlich noch in einem Umfeld wie zum Beispiel rechtlicher Compliance-Anforderungen befindet, kann die Herausforderung einer zügigen Migration schnell zum kostenintensiven Albtraum werden, wenn bei solchen Volumina auch noch on top, die Integrität und Vollständigkeit beim Datentransfer sichergestellt werden müssen.

Fazit

Große Datenmengen ziehen also Applikationen und Services an, da diese meist deutlich flexibler bewegt werden können. Je mehr Daten an einem Ort persistiert sind, desto träger werden sie. Mit wachsendem Volumen machen es Latenzen und ein begrenzter Durchsatz immer schwerer, flexibel und verteilt zu arbeiten oder große Datenmengen einfach zu verschieben. Dieses Phänomen verführt natürlich dazu, einfach alles zusammen einem Cloudprovider anzuvertrauen und die Applikation gleichermaßen in dessen Infrastruktur zu betreiben. Aber erstens werden dadurch nicht alle Probleme automatisch gelöst (Latenzen) und zweitens begibt man sich in eine massive Abhängigkeit von diesem Cloudprovider. Hybride oder Multicloud-Modelle mit Storage-Klassen, die Geolokationen berücksichtigen, sind anscheinend deshalb derzeit die einzig sinnvolle Antwort auf solche Herausforderungen bei hochvolumigen Systemen. Denken Sie also auch an übermorgen, wenn Sie heute ihre Cloudstrategie von morgen definieren.

Aus unserem Special
»BLOCKCHAIN: COMPLIANCE FÜR DIE BUSINESS CLOUD«
Beitrag 21/21
Teilen: