9 Minutes
Jede Technologie ist nur so gut wie das Problem, das sie löst
Ein heiß diskutiertes Thema in jeder Softwareentwicklung ist der aktuell verwendete Tech Stack. Sollte nicht doch das neuste JavaScript- oder Microservice-Framework eingesetzt werden? Schließlich wird es zur Zeit auf jeder Konferenz vorgestellt! Sollte nicht jetzt sofort auf eine neue Technologie gewechselt werden, damit wir auch in Zukunft noch anschlussfähig sind? Nicht selten bildet sich hier eine Front zwischen alten Hasen, welche die bestehenden Technologien verteidigen und neuen Kollegen die Probleme gerne anderes angehen würden.
Das Dilemma, vor dem wir stehen lässt sich wie folgt zusammenfassen: Sollte eine neue Technologie eingeführt werden, um von neuen und spannenden Technologien, sprich der Weiterentwicklung des State of the Art, zu profitieren oder sollen wir bei Bewährtem bleiben, um die hohen Migrationskosten zu sparen.
Technologieentscheidungen beeinflussen den Alltag der Entwickler und Nutzer jedes System nachhaltig und sollten daher mit großer Sorgfalt getroffen werden. In diesem Artikel soll unaufgeregt betrachtet werden, welche Kriterien für eine richtige Entscheidung relevant sind.
Was spricht für einen Technologiewechsel?
Es gibt oft viele kleine detaillierte Gründe, die diskutiert werden, aber langfristig gesehen sind die folgenden zwei Aspekte bei jedem Technologiewechsel die wichtigsten Faktoren:
Bei alten Technologien kann es passieren, dass die Community wegbricht
Es gibt sehr viele Technologien, die vor zehn Jahren als neu und innovativ galten und heute kaum noch verwendet werden. Auch wenn die Community am Anfang noch groß war, so ist sie mit der Zeit schnell kleiner geworden. Neue Features werden kaum noch entwickelt. Tritt jetzt ein Problem auf, müssen sich die Entwickler:innen die Lösungen selbst erarbeiten und können nicht darauf hoffen Antworten auf den bekannten Plattformen im Netz zu finden. An diesem Punkt sollte ein Technologiewechsel diskutiert werden.
Dabei ist Größe der Community für Auswahl einer Technologie aber deutlich entscheidender als das Alter. Ein gutes Beispiel, um die Thematik zu erläutern, ist Java selbst. Die Community von Java ist schlichtweg riesig. Die Alternative Kotlin verspricht neue Sprachfeatures, welche das Fehlerpotenzial reduzieren und die Produktivität erhöhen sollen. Allerdings werden die wichtigsten neuen Features auch mittlerweile in Java übernommen. Außerhalb des Android-Marktes ist die Kotlin Community außerdem deutlich kleiner.
Ähnliches gilt auch für die JavaEE (bzw. JakartaEE) Welt. Noch vor wenigen Jahren war JavaEE der unangefochtene Standard. Heute übernimmt Spring Boot an vielen Stellen diese Rolle [1]. Ein Wechsel von JavaEE zu SpringBoot bringt viele Vorteile, aber mit MicroProfile ist auch für JavaEE Umgebungen ein wesentlicher Teil der nützlichsten Features von SpringBoot zugänglich gemacht worden.
Diese beiden Beispiele zeigen, dass eine große und starke Community den State of the Art auch bei lange bestehenden Technologien vorantreibt. Das bringt uns zum ersten entscheidenden Punkt bei der Technologieauswahl: Der Community. Ist Community hinter einer Technologie groß und aktiv und hat auch schon in der Vergangenheit gezeigt, dass sie den State of the Art halten kann, ist das ein starkes Argument auf diese Technologie zu setzen. Ganz neue Technologien müssen aber erst beweisen, dass sie langfristig eine starke Community aufbauen können, damit sie auch in zehn Jahren noch konkurrenzfähig sind.
Alte Technologien entfernen sich immer mehr vom State of the Art
Je länger eine Technologie existiert und genutzt wird, desto weiter entfernt sie sich vom aktuellen State of the Art. Das ist natürlich nicht immer der Fall (wenn man z.B. an das Java Beispiel denkt) aber doch sehr oft. Ein typisches Beispiel sind Frontend-Technolgien, die vor der Mobil-Revolution (ca. 2007) entwickelt wurden. Hier fehlen oft elementare Werkzeuge, die ein gutes Design auf mobilen Endgeräten möglich machen. Es ist also auch wichtig den State of the Art zu beobachten und zu entscheiden, ob Weiterentwicklungen für die eigene Anwendung relevant sind.
Der State of the Art ändert sich laufend. Wie kann man also erkennen, welche Änderungen für die eigene Anwendung relevant sind? Ein Beispiel aus unserer eigenen Erfahrung: Viele SaaS-Anbieter haben in den letzten Jahren zum Beispiel neue Javascript Frameworks wie Vue, React oder Angular eingeführt, da diese die Erstellung und Wartung von inaktiven Seiten deutlich vereinfachen. Ein Kombinationen mit bestehenden Templating-Engines ist relativ einfach möglich, so dass auch SEO Inhalte weiterhin ausgespielt werden können. Die Entscheidung zum Einsatz einer solchen Technologie sollte immer vom Problem abgeleitet werden: Wer keine oder nur sehr wenig dynamischen Inhalt benötigt, kann natürlich auf diese Technologien verzichten oder sie sehr gezielt einsetzen.
Was spricht gegen einen Technologiewechsel?
Die Migration auf eine neue Technologie dauert sehr lange und ist teuer
Soll eine Kernkomponente getauscht werden, wie z.B. ein Appliktionsserver oder eine Datenbank, so kann dies Jahre in Anspruch nehmen. Das neue System parallel zu entwickeln und dann einfach umzuschalten, scheitert meist daran, dass das Altsystem weiterentwickelt werden muss. Alle Änderungen, die während der Migration gemacht werden, müssen dann auch im neuen System nachgezogen werden. Im schlimmsten Fall wird das neue System dann nie fertig. Daher ist eine Migration in kleinen Schritten die bekanntermaßen sinnvollste Vorgehensweise. Aber auch hier gilt: Erst wenn wirklich die letzte Komponente und der letzte Service umgestellt ist, kann ein Team die alte Technologie gedanklich streichen. Solange jede Woche noch mehrmals im alten Tech-Stack gearbeitet werden muss, hat ein Team keinen großen Vorteil von der Umstellung. Für den Zeitraum der Migration hat das Team sogar gravierende Nachteile: Es muss mit der doppelten kognitiven Last leben, da beide Technologien weiterhin beherrscht werden müssen. An dieses Problem schließt der folgende Punkt direkt an.
Der Einsatz zu vieler Technologien gleichzeitig kann ein Team schnell überfordern
Auch wenn die Grundlagen schnell erarbeitet sind, ist viel Wissen und Erfahrung notwendig, um eine Technologie langfristig zu betreiben. Es ist ein großer Unterschied, ob eine Technologie nur für ein kleines Bastelprojekt mal ausprobiert wird oder ob unter Zeitdruck schwerwiegende Probleme auf einem Produktionssystem gelöst werden müssen. Jede Technologie kostet Einarbeitungsaufwand und benötigt spezielle Kenntnisse. Wer gedankenlos zu viele Technologien einsetzt, trägt unabsichtlich zur Verlangsamung der Softwareentwicklung bei, weil sich Entwickler:innen in allen Stacks auskennen und mit deren Eigenheiten im Betrieb auseinandersetzen müssen.
Um einen “Technologiezoo” zu vermeiden, muss genau definiert werden, welches Problem eine Technologie eigentlich löst. In der Regel gibt es Problembereiche bzw. Aufgabengebiete die sich relativ klar benennen lassen. Zum Beispiel fallen Oracle, Postgres und MariaDB alle in den Bereich der relationalen Datenbanken und lösen die gleichen Probleme. Angular, React und Vue haben i.d.R. ein Aufgabengebiet. Über MicroProfile, Spring Boot und Micronaut lässt sich das Gleiche sagen. Eigentlich ist es offensichtlich, dass es nicht sinnvoll ist, mehrere Technologien einzusetzen, die sich einen Aufgabenbereich teilen, wenn keine sehr speziellen Anforderungen vorliegen. Dennoch weiß jeder aus der Praxis, das dies in vielen Firmen genau so vorkommt.
Fazit
Bei der Auswahl von Technologien muss immer zuerst genau verstanden werden, welche Herausforderungen und Probleme zu lösen sind. Erst dann sollte über passende Werkzeuge diskutiert werden. Dabei wird es immer den Entwickler geben, der jedes Problem, unabhängig vom Zusammenhang, mit Apache Kafka lösen will. Auf der anderen Seite gibt auch immer den alten Hasen, der alle Innovationen am Markt schlecht redet, damit im Unternehmen alles so bleiben kann wie es ist. Wenn aber aus der Sicht der konkreten Anforderungen diskutiert wird, ist es am wahrscheinlichsten die beste Entscheidung zu treffen.
