Komplexität in der IT

Drei Ereignisse der letzten Tage haben mich bewogen diesen Beitrag zu schreiben, der mir schon länger im Kopf herumschwirrt. Mir wurde der Link zu einem Blogbeitrag von Eugene Yan mit dem Titel Simplicity is An Advantage but Sadly Complexity Sells Better geschickt, auf Hacker News bin ich über den Blogbeitrag von Bert Hubert gestolpert (Cyber Security: A Pre-War Reality Check) und zusätzlich hatte ich auch wieder einmal Probleme mit einer MongoDB. Aber der Reihe nach.

Inhalt:

• Einleitung
• Falsche Anreize
• Die MongoDB-Herausforderung
• Fazit

Einleitung

Die großen Techunternehmen müssen Probleme lösen, die die meisten anderen Unternehmen wahrscheinlich komplett überfordern würden. Weil diese Unternehmen allerdings die finanzielle Ausstattung und damit genügend Personen mit einhergehendem Know-How haben, können sie auch sehr komplexe Probleme lösen. Und geben mit ihren Lösungen auch den Takt ein wenig vor. Viele Projekte und Unternehmen orientieren sich an den Lösungen. Schon vor Jahren wurde von Oz Nove in einem (mittlerweile bekannten) Artikel You Are Not Google beschrieben, dass man selten ähnliche Probleme hat, wie die großen Techunternehmen. Trotzdem gibt es eine Versuchung sich mit den ganzen neuen Technologien und Tools zu umgeben. Komplexität ist etwas, worauf die Leute stolz sind und auch belohnt wird. Vor allem wenn auch neue Dinge eingeführt werden. Denn das wird gerne als Innovation verkauft.

In Readings in Database Systems wird es auch folgendermaßen beschrieben:

The community of programmers has a love affair with “the next shiny object”. This is likely to create “churn” in your organization, as the “half-life” of shiny objects may be quite short.

Falsche Anreize

Eugene Yan hat es in seinem Artikel beschrieben, dass es falsche Anreize gibt, da es nur Anerkennung gibt, wenn man komplexe Dinge gemacht bzw. gelöst hat. Ein meiner Meinung nach sehr gutes Beispiel dafür schildere ich dann noch im Abschnitt Die MongoDB-Herausforderung. Wenn man die Dinge komplex macht, dann kann man auch ganz gut mit den Tools der großen Firmen spielen und sich als innovativ hervortun.

Beispielsweise beschreibt Jordan Tigani in seinem Artikel Big Data is Dead, natürlich nicht ganz uneigennützig, warum die wenigsten wirklich mit riesigen Datenmengen umgehen müssen. Dennoch werden komplexe Lösungen bevorzugt. Denn es könnte ja sein, man gehört zu den oberen paar %, die wirklich komplexe Probleme lösen müssen. Ich denke, es zeigt dann auch, wie gut und wichtig man selbst ist, da man die Dinge so komplex gemacht hat und damit eine "perfekte" Lösung. Diese Wichtigkeit wird dann auch gerne von Vorgesetzten und Kunden honoriert.

Ein ganz gutes Beispiel für mich war da ein Besuch im Jahr 2016 auf der DotScale-Konferenz. Damals war ich durchaus auch sehr angetan von diesem ganzen Big Data-Hype und welche Möglichkeiten es gibt.

Eine der ersten Fragen in den Gesprächen hat sich meist um die Datenmenge, die man in seinen Datenbanken hatte, gedreht. Hatte etwas von einem Weitpinkelwettbewerb für Data Engineers. Vor der Konferenz war ich etwas zurückhaltend, weil wir nur, eine meines Erachtens, kleine Datenbank mit damals ungefähr 2 TB hatten.

Allerdings hat sich sehr schnell herausgestellt, die meisten anderen hatten bei wesentlich geringeren Datenmengen, wesentlich komplexere Lösungen. Sicherlich ist die Größe einer Datenmenge nur ein Teil der Entscheidungsfindung, aber schon damals hatte ich das Gefühl, für das Ego vieler ist es wichtig, die Dinge möglichst komplex zu halten. Was sich dann auch im weiteren Gesprächsverlauf immer wieder gezeigt hat. Oftmals konnte mir auch nicht erklärt werden, warum man eine gewisse Lösung genommen hat. Also im Detail und abseits von irgendeinem Marketing-Bullshit.

In den Gesprächen mit Sponsoren der Veranstaltungen und Teilnehmer:innen habe ich sehr schnell festgestellt, es gibt auch so etwas wie eine gegenseitige Abhängigkeit. Sponsoren möchten ihre Produkte verkaufen und mit höherer Komplexität kann man höhere Preise verlangen. Die Teilnehmer:innen können die Reise zu einer Konferenz auch ganz gut rechtfertigen, wenn sie vermeintliche Lösungen für vermeintliche Probleme von ihrem Trip mitgebracht haben.

Gerade wenn Personen, die die Entscheidung für eine Lösung treffen, nicht lange in einer Firma bleiben, müssen oftmals andere die Entscheidungen dann ausbaden. Daher möchte ich nicht wissen, wie viele Firmen durch solche Veranstaltungen Produkte eingeführt haben, die sie nie gebraucht haben und die es mittlerweile nicht mehr wirklich gibt. Ich denke da beispielsweise an Riak, die damals auf der DotScale ein gewisses Thema waren.

So hat man als Firma einen doppelten Schaden. Einerseits investiert man Geld, um ein Produkt einzuführen. Das umfasst das Produkt selbst, aber natürlich braucht man auch ein gewisses Know-How, um mit dem Produkt umgehen zu können. Und wenn es dann kein Hauptprodukt ist, dann ist es wahrscheinlich noch schwieriger das entsprechende Wissen auf eine entsprechende Anzahl an Leuten zu verteilen. Später, wenn sich herausstellt, die Lösung war nicht optimal, dann hat man wiederum die Kosten, die entstehen, wenn man davon zu einem anderen Produkt migrieren möchte.

In unserem Unternehmen mit rund 500 Mitarbeiter:innen gibt es auch jemanden, der in seiner Leistungsbeschreibung als oberster "IT-Stratege" es als seine Aufgabe sieht, ständig neue Tools einzuführen, deren Halbwertszeit äußerst gering ist.

So entstehen einem Unternehmen hohe Kosten und vor allem auch Probleme mit den Daten und damit geht Wissen verloren. Denn jedes dieser Tools, hat natürlich wieder ein eigenes Datenmodell und Inhalte, die man in dem einen Tool teilt, sind dann in einem Nachfolgetool nicht mehr vorhanden. So kommt es, dass Produktivitätstools durch den ständigen Wechsel eigentlich das Gegenteil von ihrem Versprechen auslösen. Aber zumindest ist für die Nutzer:innen alles komplizierter geworden.

Die MongoDB-Herausforderung

Wie Bert Hubert in seinem Artikel ausgeführt hat, kann es durchaus zum Problem werden, wenn Nicht-Techniker Entscheidungen treffen. In diesem Fall waren es Ökonomen. Oder besser gesagt, sie haben sich Dinge aufschwatzen lassen. Voller Stolz hat mir der damalige Projektleiter erklärt:

Unsere Applikation und Daten sind so komplex, das lässt sich nicht mit einer SQL-Datenbank abbilden.

Bis heute habe ich noch nicht verstanden, was an der Applikation so komplex ist, dass es dafür eine MongoDB braucht. Zumal es damals schon den JSON(B)-Datentyp in Postgres gegeben hat.

Was ich auch dem damaligen Entwickler mitgeteilt habe, aber es dieser leider nicht gewusst hatte. Man sieht, auch Techniker können für eine Organisation nachteilige Entscheidungen treffen, da es natürlich sehr schwer ist bei jedem System über die neuesten Entwicklungen Bescheid zu wissen.

Zumal der (vermeintliche) Vorteil der MongoDB, bessere Skalierbarkeit, überhaupt nicht benötigt wird.

Nach der Entwicklung der Applikation ging es dann darum die Applikation weiter zu hosten. Damit begannen die Herausforderungen, denn wir hatten bisher hauptsächlich RDBMs im Einsatz. Das umfasste vorwiegend Postgres, aber auch MySQL und Microsoft SQL Server Datenbanken. In der Woche 9 habe ich schon ein Zitat vom Blog-Beitrag How we built our customer data warehouse all on Postgres gebracht, das auch hier ganz gut passt:

Every time we bring in a new technology into the ecosystem, it becomes a piece of software that needs to be learned, mastered and maintained. This becomes a huge cost in the form of cognitive overhead for the team in addition to the time and resources it takes to set up, manage and maintain it. The system also gets expensive and much harder to debug due to the sheer number of tools involved. Many software systems today consist of far too many tools and technologies for any human to keep in their head. Some engineers at Uber spoke briefly about this recently.

Die Datenmenge der Applikation bewegte sich bei rund einem Gigabyte, d.h. es sollte eigentlich keinerlei Performanceprobleme geben. Aber natürlich war es am Ende des Tages, wie es im Lehrbuch stand.

Man musste Daten auf Applikationsebene joinen, was auf viele Arten einfach schlecht ist. Einerseits haben Datenbanken unterschiedlichste Join-Algorithmen (Nested Loops, Hash Join oder Sort Merge), die anhand der Datenmenge und den Join-Kriterien die beste Methode auswählen.

Auf Applikationsebene werden im Normalfall am ehesten Nested Loops implementiert, da es die einfachste Methode ist. Zusätzlich werden ja in einem ersten Schritt alle Daten in die Applikation geladen, um sie dann zu filtern. Ein Prozess, den die Datenbank natürlich wesentlich besser und effizienter machen kann.

So wurden alleine durch die Tatsache Collections (ich würde sagen es entspricht in einer SQL-Datenbank einer Tabelle) verknüpfen zu müssen, zwei Operationen, die eine Datenbank eigentlich mitbringen sollte, extra implementiert. Tatsachen, die auch heute, einige Jahre später, dafür sorgen, dass gewisse Abfragen zu einer ungeahnten Auslastung der CPUs führen können.

Auch fehlende Möglichkeiten zur data virtualization führen dann zu herausfordernden Architekturen, wie der Abfrage von unzähligen API-Endpunkten, um Daten zu synchronisieren. (Anmerkung: Wer sich jemand mit dem Thema data virtualization auseinandersetzen will, kann das mit meinem Beitrag Data virtualization mit Postgres).

Aber und das ist meines Erachtens das größte Problem an der Geschichte, es kennt sich bis heute niemand wirklich mit der MongoDB aus. Es wird in keiner anderen Applikation verwendet. Das hat eigentlich nur zu einer erhöhten Komplexität im Betrieb geführt, die auch zu wenig Unterstützung für das Entwicklungsteam geführt hat. Bei SQL-Datenbanken gibt es, trotz unterschiedlicher Syntax und Befehle, einfach eine gemeinsame Basis, wo man sich mit Know-How aus Datenbank X auch in anderen Systemen zurechtfinden kann.

Fazit

Entscheidungsträger:innen sind zu oft versucht komplexe Lösungen einzuführen, da es Karrierevorteile bringt. Eigentlich sollte genau das Gegenteil der Fall sein. Lösungen sollten nur so komplex sein, wie es unbedingt notwendig ist und nicht vom Start weg so komplex, als ob man Probleme der großen Techunternhemen lösen möchte.

Neue Lösungen bedeuten auch Aufwand für die Nutzer:innen und es sollte daher überlegt werden, ob man etwas einsetzt und wie lange die Halbwertszeit einer Lösung wohl sein wird. Schnelle Wechsel von Produkten sind kein Zeichen von Agilität, sondern nur Geldvernichtung.

Wichtig ist meiner Ansicht nach auch zu beachten, ob es in einem Unternehmen schon Know-How zu einem gewissen Produkt gibt. Ich kenne kaum Unternehmen, die genüg Engineers haben, um wirklich eine breite Palette an Systemen ohne Problem abdecken zu können. Wenn man etwas einführt, dann sollte es kein kleiner Nebenschauplatz sein, denn dann gibt es dahingehend auch kaum einen Know-How-Aufbau und man ist bei Problemen sehr schnell mit seinem Latein am Ende.

Außerdem sollte man vorsichtig vor Leuten sein, die sich nur hinter Marketing-Bullshit-Bingo-Begriffen verstecken und nicht erklären können, warum sie etwas gemacht haben.

Zum Abschluss sei erwähnt, man sollte auch keine Angst haben, neue Produkte einzuführen, allerdings sich hinterfragen, wenn die Lösungen wesentlich schneller komplexer werden, als es die Probleme werden.