In den letzten Jahren haben sich einige Hype-Themen angesammelt, über die ich an dieser Stelle ein paar Gedanken notieren will. Hinter jeder Technologie steckt natürlich ein gültiger Anwendungsfall, allerdings ist dieser bei Hypes in der Regel wesentlich kleiner als der dann gewählte Einsatzbereich. Damit setzen viele Firmen suboptimale Lösungen ein, nur weil ein Thema gerade heiß ist.

Big Data

Schon seit einigen Jahren verfolt uns das Thema Big Data. Jede Firma macht Big Data, auch wenn es lediglich 1GB an Daten sind. Und weil alle Big Data machen, brauchen natürlich auch alle eine Software-Lösung, um Big Data zu betreiben. Getrieben wird dieser Hype meines Erachtens vor allem von den Consulting-Firmen, die Big-Data-Lösungen oder Beratung zu Big Data an Firmen verkaufen.

Als Enterprise-Standard hat sich hier Apache Hadoop etabliert, wobei neuerdings Apache Spark interessanter wird (welches aber bis vor kurzem ohne Hadoop nicht funktioniert).

Natürlich haben Hadoop und Spark ihre Daseinsberechtigung, allerdings werden sie oft eingesetzt, auch wenn sie gar nicht nötig wären oder gar nicht das richtige Tool sind. Also welche Probleme lösen Apache Hadoop und Apache Spark?

Hadoop mit HDFS löst letztlich das Problem, dass man Daten server-lokal verarbeitet bei Daten, die zu groß für einen einzelnen Rechner sind. Das heißt eine Datei sollte idealerweise größer als mehrere Terabytes sein. Allerdings kann man auch bei kleineren Dateien durch Parallelisierung Geschwindigkeit gewinnen. Nur sollte man sich dann bereits kritisch fragen, ob Hadoop die notwendige Lösung ist, oder ob man die Dateien (die dann offensichtlich wieder komplett auf einem Rechner gespeichert werden können) nicht besser mit anderen Programmen verteilt berechnen kann.

Der Vorteil von Spark liegt darin, dass es verteilt auf Daten im RAM rechnen kann. Hier ist die Limitierung also schon etwa bei 1TB pro Server, so viel RAM kann ein Server durchaus haben. Wenn man also mehr als 1TB im RAM verarbeiten muss, wird Spark das Mittel der Wahl.

Ein Vorteil, den beide Tools gemeinsam mitbringen, ist die Fehlertoleranz gegen Ausfälle von einzelnen Servern. Diesen Punkt sollte man dann genauer betrachten, wenn man damit rechnet, dass realistischerweise ein Rechner ausfällt, während man Berechnungen ausführt. Das wird in der Regel dann der Fall sein, wenn man mehr als 1000 Rechner verwendet und die Berechnungen trotzdem noch längere Zeit dauern. Rechnet man hingegen beispielsweise nur mit einem Ausfall pro Jahr, der dann eine 1h-Berechnung zum Absturz bringt, kann die Ausfalltoleranz ignoriert werden.

Der Nachteil, den man sich mit beiden Technologien einhandelt, ist natürlich, dass man die Systeme verwalten muss. Das heißt, dass man einen kompletten Cluster verwalten muss. Außerdem muss man das Debugging der Berechnungen ebenfalls auf dem Cluster durchführen, was ebenfalls komplizierter ist als lokal auf einem Rechner.

Aus diesen Gründen brauchen meines Erachtens fast alle Berechnungen in Firmen kein Apache Hadoop oder Apache Spark und sollten lieber simplere Lösungen zur parallelisierten Verarbeitung suchen. Im einfachsten Fall kann es eventuell schon reichen, das bisherige Programm auf zwei oder drei Rechnern gleichzeitig laufen zu lassen und die Eingangsdaten einfach aufzuteilen. Das Ergebnis muss dann natürlich noch zusammengeführt werden. Dieser Aufwand kann sich jedoch gegenüber dem teuren Management eines Hadoop- oder Spark-Clusters sehr häufig lohnen.

Serverless

Ein neuerer Hype, seitdem Amazon Lambda eingeführt hat, ist Serverless. Dieser Hype wird speziell von den Cloud-Anbietern getrieben, allen voran natürlich von Amazon, weil sie von den großen Cloud-Anbietern die ersten mit einem Serverless-Dienst waren. Serverless bedeutet natürlich nicht, dass es keinen Server mehr gibt. Lediglich, dass der Programmierer diesen nicht mehr sieht, sondern er vom Hosting-Anbieter transparent verwaltet wird.

Serverless löst meines Erachtens zwei Probleme: für sehr selten laufenden Code muss man nicht mehr einen ganzen Server auf Amazon EC2 starten, der dann für eine Stunde berechnet wird. Stattdessen wird nur die Ausführung der Funktion berechnet. Ein zweiter Vorteil ist, dass die Funktionen bei erhöhter Last automatisch vom Hosting-Anbieter auf mehreren Servern gestartet werden können.

Das erste Argument finde ich jedoch etwas schwach, denn es relativiert sich, sobald man mehrere selten laufende Funktionen hat. Dann könnte es sich bereits lohnen, einen Server vorzuhalten, auf dem alle diese Funktionen gespeichert sind und bei Bedarf starten.

Umgekehrt handelt man sich natürlich einige Probleme ein. Zunächst einmal ist das Debugging von Serverless-Funktionen schwieriger, weil man sich nicht auf einem Server einloggen und den Zustand am Server prüfen kann. Verwendet man Lambda bei einem der Cloud-Anbietern muss man außerdem mit einem starken Vendor-Lock-In leben, denn bei Serverless hat jeder Anbieter eine eigene Umsetzung. Wählt man dagegen ein self-hosted System, hat man natürlich wieder den Verwaltungsaufwand für dieses System.

5G

5G ist aktuell ein Hype-Thema in den deutschen Medien. Dies ist ein neuer Mobilfunk-Standard, der höhere Datenraten und vor allem sehr viel niedrigere Latenzen bringen soll. In den Medien werden damit aber allerhand Heilsversprechen verbunden, die meines Erachtens nicht haltbar sind.

Ja, die Latenz von 5G soll gering sein (mehr als 1ms schreibt Android Authority), aber das bedeutet nicht, dass die Kommunikation von einem Handy zu einem Server dann nur 1ms dauert. Die derzeitige Latenz bei kabelgebundenen Datenverbindungen von meinem Anschluss zu einem Server in Österreich oder Deutschland liegt etwa bei 20-50ms, je nach Serverstandort. Diese Latenz liegt nicht alle an meiner Kupferleitung zum Repeater, sonst wäre sie für jeden Standort gleich. Diese 20-50ms werden durch 5G nicht kürzer. Kürzer wird nur die Latenz vom Handy zum Mobilfunkmasten. Diese lag bei einem Test mit meinem Mobiltelefon bei 20ms (4G), bei einem Bekannten in Deutschland bei 150ms (2G).

Damit werden durch 5G aber auch nicht - wie man in manchen Medien liest - plötzlich medizinische Operationen über das Internet möglich. Die Latenz des Mobilfunknetzes wird lediglich auf die von Kabelnetzen gedrückt. Außerdem will man Operationen überhaupt nicht über ein Mobilfunknetz machen, sondern aus Sicherheitsgründen über ein redundant ausgelegtes Kabelnetzwerk.

Auch die Aussage, dass 5G für Autonomes Fahren gebraucht werde, ist natürlich Unsinn. Ein Autonomes Auto wird zum sicheren Fahren kein Mobilfunknetz brauchen dürfen, ansonsten fährt es bei einem Verbindungsabbruch gegen die Wand. Internetverbindung für Autos wird lediglich für Komfort-Funktionen, Verkehrsfluss-Optimierungen und Gefahrwarnungen gebracht (letzteres aber nur als Zusatz, das Fahrzeug muss auch ohne die Warnungen fahren können).

Insofern können Fahrzeuge eventuell tatsächlich von geringeren Latenzen profitieren (bei den Gefahrwarnungen), allerdings sind diese keinesfalls eine Voraussetzung für das Autonome Fahren.

Microservices

Unter Entwicklern sind Microservices gerade ein heißes Thema. Das Problem daran ist, dass Microservices von Firmen kommen, die Websites für hunderte Millionen Besucher bereitstellen. Also Größenordnungen, in die normale Websites in der Regel nie kommen. Ein schönes Zitat hierzu ist:

Programmers worrying about whether their architecture will Web Scale is like buying a lottery coupon and fretting about which yacht to buy.

Deshalb stellt sich für normale Websites eigentlich nie die Problematik, ob man den Einkaufskorn nun als einen vom Rest der Website unabhängigen Microservice entwickeln sollte oder nicht. Microservices bringen nämlich - wie alle anderen Technologien - nicht nur Vor-, sondern auch Nachteile. Und man sollte sich immer gut überlegen, ob sie die richtige Lösung sind und man alle Vorteile auch voll nutzen kann.

Probleme, die Microservices lösen, sind sowohl technische als auch organisatorische. Sie erlauben einerseits, dass man die einzelnen Microservices unterschiedlich stark skalieren kann. Um beim Beispiel von Amazon zu bleiben: Wenn der Einkaufswagen eine höhere Last hat als die Check-Out-Seite, dann kann man den Einkaufswagen auf 20 Servern live schalten und die Check-Out-Seite lediglich auf 3 Servern.

Organisatorisch dagegen helfen sie dabei, dass verschiedene Teams an jeweils ihrem Produkt arbeiten können. Das trifft allerdings natürlich erst dann zu, wenn wirklich mehr als 10 Leute an der Website programmieren. Außerdem ist es nun möglich, für verschiedene Aufgaben auch verschiedene Programmiersprachen zu wählen.

Probleme entstehen natürlich auch durch Microservices. Zunächst einmal können durch die Wahl von verschiedenen Programmiersprachen Synergie-Effekte verloren gehen, weil die Microservices weniger Libraries teilen können, z.B. zum Lesen von speziellen Dateiformaten. Eine ganze Reihe an technologischen Schwierigkeiten entsteht ebenfalls: Distribution der Microservices, Kommunikation zwischen ihnen, Discovery von Diensten und Health-Monitoring.

Letztlich wird auch das Debugging mit Microservices schwieriger, weil man nicht mehr in der eigenen IDE in einen Debugger springen kann, sondern Nachrichten im Netzwerk nachverfolgen muss. Das Problem ist sogar so schwer, dass Google auf der I/O ‘18 ein neues Programm vorgestellt hat, um das Debugging von Microservices zu vereinfachen: Istio

Blockchain

Das aktuelle Hype-Thema in diversen Firmen ist Blockchain. Im Moment macht gefühlt jede größere Firma etwas mit Blockchain, der Outcome scheint jedoch nicht vorhanden.

Das Problem an der Stelle dürfte sein, dass (wie bei vielen Hype-Themen) die treibende Kraft nicht von einem bestehenden Problem ausgeht, sondern vom Thema an sich. Das heißt, es gibt eine Technologie, aber kein Problem, und die Firmen meinen, diese Technologie unbedingt verwenden zu müssen. Also sucht man sich ein Problem, auf das man die Technologie anwenden kann.

Bei Firmen, die mit Blockchain-Beratung ihr Geld machen, habe ich dagegen das Gefühl, dass für sie jedes Problem nach einem Blockchain-Problem aussieht oder aussehen soll.

Schauen wir uns zunächst an, welches Problem Blockchains wirklich lösen: sich gegenseitig nicht trauende Teilnehmer wollen gemeinsam einen unveränderlichen Log erzeugen, den alle als wahr akzeptieren, ohne dafür einen Vermittler zu nutzen.

Das heißt, damit eine Blockchain überhaupt sinnvoll wird, brauchen wir zunächst einmal mehrere Teilnehmer. Außerdem darf es keinen Vermittler geben, den man einsetzen kann und dem die Teilnehmer vertrauen. Zudem brauchen wir natürlich auch Daten, die in die Blockchain gespeichert werden sollen.

Und an dieser Stelle haben meines Erachtens sehr viele Lösungen Lücken, weil sie letztlich Daten weltweit validieren wollen, aber meines Erachtens keine Lösung bereitstellen, um sicherzustellen, dass die eingetragenen Daten überhaupt wahr sind. Die Blockchain selbst stellt keinerlei Möglichkeiten bereit, um sicherzustellen, dass die enthaltenen Daten in der Kette auch wirklich gültig sind. Dies muss nochmal getrennt gelöst werden, zum Beispiel durch Signaturen (selbst dann kann aber natürlich der Signierende immer noch lügen und die Unwahrheit eintragen).

Die nächste Schwierigkeit ist der Algorithmus zum Berechnen von neuen Blöcken. Da Blockchain eine geteilte Wahrheit zwischen Teilnehmern schaffen soll, die sich nicht vertrauen, muss sichergestellt werden, dass ein Angreifer nicht die Wahrheit verändert. Dazu verwendet Bitcoin beispielsweise den sogenannten Proof-of-Work. Dazu muss hoher Rechenaufwand getätigt werden, bis ein gültiger Block gefunden wird, der in die Blockchain eingetragen werden kann. Als gültige Blockchain wird dann immer die längste Blockchain anerkannt. Und dadurch, dass es sehr lange dauert, einen neuen Block zu berechnen, wird sichergestellt, dass ein einzelner Angreifer nicht eine neue längere Blockchain mit anderen Blöcken erstellen kann und somit alte Transaktionen aus der Blockchain wieder löschen.

Diese Variante kommt jedoch in Firmen-Blockchains meines Erachtens nicht in Betracht, denn sie erfordert einen sehr hohen Rechenaufwand, den man nur betreibt, wenn man im Gegenzug wiederum einen monetären Gegenwert erhält.

Schaut man sich die Beispiele von Firmen an, die Blockchain-Technologien entwickeln, so klingen diese eher nach normalen Problemen, die auch ohne Blockchain zu bewältigen wären. Beispielsweise schreibt die chinesische Firma VeChain:

In a supply chain that consists of manufacturers, logistics, storage, retailers, distributors companies, every company operates in silos and has its own governance. VeChain uses blockchain to enhance the flow of information between each company by breaking silos yet maintaining the privacy of data owned by each company. It results in an efficient logistics process and makes room for innovative business models.

Dies klingt für mich eigentlich nur nach einem Daten-Austausch-Problem. Mehrere Firmen haben ihre Daten jeweils lokal gespeichert und wollen Teile dieser Daten an Partner weiterleiten, ohne diesen jedoch Zugriff auf die gesamte eigene Datenbank zu geben. In diesem Fall könnte man entweder eine gemeinsame Datenbank entwickeln, in die man die Informationen einträgt, oder aber einen gemeinsamen Message-Bus, auf den alle Nachrichten schicken können.

I do not maintain a comments section. If you have any questions or comments regarding my posts, please do not hesitate to send me an e-mail to blog@stefan-koch.name.