Trendanalyse von Microservices, Node, Orchestrierung und Co

Makrotrends in der Technologiebranche
Keine Kommentare

Die Technologiebranche ist bunt, da fällt es schwer den Überblick zu behalten. Zweimal im Jahr führt das Unternehmen ThoughtWorks eine Analyse der aktuellen Entwicklungen in der Softwarebranche durch und veröffentlicht die Ergebnisse im Technology Radar. Aktuelle Trends aus diversen Bereichen – beispielsweise Microservices, Node und Orchestrierung – werden hier unter die Lupe genommen.

Buy now, pay later

In den letzten Jahren wurde zunehmend auf die Developer Experience der Tools und Plattformen Wert gelegt. Dass Entwickler z. B. eine integrierte Entwicklungsumgebung (IDE), Open-Source-Bibliothek oder Cloud-Plattform völlig problemlos nutzen und übernehmen können, gewinnt an Bedeutung. Das ist gut so und oft auch die treibende Kraft für Innovationen. Entwickler als Kunden eines Produkts zu behandeln, kann durchaus Vorteile bringen.

Problematisch wird es jedoch, wenn die Benutzerfreundlichkeit eines Tools in einer bestimmten Situation zu einem falschen Paradigma in einem anderen Anwendungsfall führt. Beispielsweise raten wir aktuell von der Verwendung von Jupyter Notebooks zur Entwicklung von Produktivcode ab. Jupyter eignet sich hervorragend, um Daten zu analysieren und daraus Schlussfolgerungen zu ziehen und Einblicke zu gewinnen. Wenn man Jupyter jedoch direkt für Produktivcode verwendet (anstatt den Code in eine für die Produktion geeignetere Programmiersprache wie Python zu portieren), kann dies schnell zu Problemen führen.

Ebenso ist es einfach, eine Datei in einen Amazon S3-Bucket hochzuladen, mit dem Simple Notification Service (SNS) zu verknüpfen und den Inhalt mit einer Lambda-Funktion zu verarbeiten. Allerdings könnte eine solche verworrene Infrastruktur mehr schaden als nutzen.

Dies sind Beispiele für die 80-Prozent-Regel, die in diesem Zusammenhang eine wichtige Rolle spielt. Viele Tools bieten für 80 Prozent der Anwendungsfälle eine große Zeitersparnis. Bei den nächsten 10 Prozent lassen sich mit dem Tool jedoch nur noch zufriedenstellende Ergebnisse erzielen. Bei den letzten 10 Prozent gerät man in eine Sackgasse, aus der man nur mit zusätzlichem Aufwand wieder herauskommt („Pay later“). Wer kann die Komplexität wirklich überschauen und die letzten 10 Prozent bewältigen? An diesem Punkt sollten sich Teams besser die Frage stellen, ob sich der Aufwand lohnt oder ein anderes Tool für den Anwendungsfall geeigneter wäre.

Das Betriebsmodell der Microservices

Microservices können als erste wahre „cloud-native“ Architektur bezeichnet werden, und sie sind durchaus eine vernünftige Wahl für moderne Systeme. Teams sollten jedoch eine übertriebene Vorliebe für Microservices vermeiden und verstehen, dass Microservices zwar die Entwicklung einfacher gestalten, dafür aber die operative Komplexität erhöhen. Während die Services für sich genommen einfacher sind, ist für das Zusammenspiel dieser Services eine viel komplexere Choreografie erforderlich als bei einer monolithischen Architektur.

Angesichts der wachsenden Beliebtheit von Microservices lässt sich beobachten, dass sie zunehmend mit einem „richtigen“ Servicemanagement betrieben werden. Bestehende Betriebsmethoden wurden unter neuem Namen, wie z. B. „Error budgets“, neu erfunden. Service-Level-Ziele (SLOs) liefern Teams eindeutige Kennzahlen bei der Entscheidung, ob das Konzept „you build it, you run it“ funktioniert. Service Meshes wie Istio unterstützen diese Servicemanagementkonzepte unmittelbar. Observability ist in aller Munde, und Teams arbeiten hart daran, dass der Zustand ihrer Systeme für die Überwachungstools angemessen sichtbar ist.

Ein echtes „Betriebsmodell für Microservices“ umfasst auch Änderungen am Aufbau und an den Zuständigkeiten von Teams sowie die damit verbundenen organisatorischen Auswirkungen. Als Grundlage dieser aufkommenden Modelle sollten verschiedene Betriebs- und Plattformfunktionen bestimmt werden. Anschließend sollten erfahrene Teams darauf ausgerichtet werden, zur Bereitstellung dieser Funktionen Produkte zu planen, zu entwickeln und auszuführen. Es sei nachdrücklich davor gewarnt, ein monolithisches „Plattformteam“ aufzustellen oder einfach darauf zu hoffen, dass sich gemeinsame Betriebsfunktionen von allein ergeben werden und sich verbreiten.

Kontinuierliche Verbesserung

Im Gegensatz zu „guten“ Technologen zeichnen sich „hervorragende“ Technologen (unabhängig von ihrem Fachgebiet) dadurch aus, dass sie mit der aktuellen Lösung nie zufrieden sind, sondern immer versuchen, es noch besser zu machen. Als Branche verbessern wir unsere bestehenden Entwicklungen kontinuierlich.

Dafür gibt es unzählige Beispiele. Taiko ist eine Node-Bibliothek zur Automatisierung von Chrome, die auf eine klare und schlanke API abzielt. Wir haben zwar schon früher im Browser Tests durchgeführt, aber mit jedem Schritt verbessern wir uns. Deno, eine sichere, serverseitige JavaScript- und TypeScript-Engine, stammt vom Erfinder von Node.js als unmittelbare Reaktion auf die seiner Ansicht nach größten Problembereiche von Node. Gremlin ist eine Sprache für die Suche in Graphen, die gegenüber ihren Vorgängern mit Verbesserungen aufwartet. Immer.js wurde für seine Fortschritte in der Entwicklung der Immutable State Trees mit dem Titel „Breakthrough of the Year“ ausgezeichnet. Micronaut ist ein Framework zur Erstellung von Microservice- und serverlosen Anwendungen, das uns auf diesem Gebiet einen großen Schritt weiterbringt.

Jeder Schritt, den wir heute unternehmen, fördert künftige Innovationen, die – wie bereits erwähnt – grundsätzlich unvorhersehbar sind (einem zentralen Grundsatz der evolutionären Architektur zufolge erstellen wir Systeme in dem Wissen, dass wir diese Veränderungen nicht wirksam voraussagen können).

Konfiguration zu weit getrieben

Im Rahmen unserer Technology-Radar-Ausgaben haben wir uns intensiv mit dem Problem der „Configuration as code“ und den negativen Auswirkungen beschäftigt, die sich offenbar ergeben, wenn eine einfache Konfigurationssprache immer komplexer wird und man schließlich „Turing-vollständiges XML“ erhält, das schwer zu testen und zu erfassen ist. Dafür gibt es zahlreiche Beispiele, die von Build-Dateien bis hin zu Terraform-Konfigurationsdateien mit Vorlagen reichen. Oft stellen die Teams fest, dass es einfacher ist, testbaren Code in einer Programmiersprache zu schreiben als ein Tool zu verwenden, das wir durch Konfigurationsdateien programmierbar gemacht haben.

Kief Morris, der Autor von Infrastructure as Code, sieht das grundlegende Problem darin, dass wir keine klare Grenze zwischen Konfiguration und Logik ziehen. Seiner Ansicht nach sollten wir keine Konfigurationsdateien testen und einen Zielzustand nicht mit programmierbarer Logik definieren. Wer dennoch eines von beidem tut, hat keine klare Unterscheidung zwischen Konfiguration und Logik gemacht. Morris ist der Auffassung, dass deklarative Sprachen leichter erweiterbar sein sollten, indem zu gesonderten, testbaren Komponenten Logik hinzugefügt wird.

Zunehmende Komplexität der Orchestrierung

In der Technologielandschaft zeichnet sich als allgemeiner Trend eine zunehmende generelle Komplexität ab und damit verbunden ein steigender Aufwand, die einzelnen Komponenten miteinander zu kombinieren. Luigi ist ein neues Tool im Datenbereich, mit dem sich komplexe Batch-Job-Pipelines erstellen lassen. Mit Apache Airflow kann man Workflows programmatisch erstellen, planen und überwachen. Systeme werden laufend um neue Dinge erweitert: Functions-as-a-Service, Workflows, Python-Prozesse usw.

Orchestrierung an sich ist keine schlechte Sache, da sie Dinge verbindet. Nur wenn Services flexibel kombiniert werden, kann ein System funktionieren und Mehrwert erzeugen. Ob sich Orchestrierung negativ auswirkt, hängt davon ab, wie verbreitet sie in einer Anwendung und im gesamten System ist.

Diffusion der Businesslogik

Probleme durch übertriebene Konfiguration und die Komplexität der Orchestrierung sind Symptome eines größeren Trends: Die Businesslogik ist nicht mehr auf kleine Codeblöcke beschränkt, sondern de facto auf ein ganzes System verteilt. Sie zeigt sich in der Art, wie wir Kubernetes-Pods konfigurieren und unsere Lambda-Funktionen kombinieren. Es gibt die altmodische Vorstellung von einer ‚Workload‘, die sich an verschiedene Orte verschieben lässt. Für das Schreiben und Hosten der Workload sind jeweils Zuständigkeiten festgelegt, und die Steuerungsebene und die Anwendung sind klar voneinander getrennt. Diese Vorstellung trifft heute nicht mehr zu.

Genau genommen hat die Businesslogik wohl nur die Aufgabe, Berechnungen vorzunehmen. Allerdings müssen erfolgsrelevante Entscheidungen getroffen werden. Wie sollten wir bei einem bestimmten Skalierungsbedarf vorgehen? Welche Beeinträchtigung ist unter Belastung hinnehmbar? Diese Fragen stellt sich ein Product Owner. Sie sind Teil der Businesslogik, allerdings nicht im traditionellen Sinn. Wir haben uns für den Begriff „Businessverhalten“ entschieden, um Fragen dieser Art abzudecken.

Wir empfehlen den Teams, zunächst einmal anzuerkennen, dass diese Verteilung stattgefunden hat. In einer klassischen Architektur hätte sich alles Wesentliche im Business Domain Layer befunden. Diese Schicht gibt es jedoch nicht mehr, und die entsprechende Logik verteilt sich auf eine Kombination aus Infrastruktur, Konfiguration, Microservices und Integrationen. Ereignisgesteuerte, serverlose Funktionen, Dateien in einem S3-Bucket, der einen Lambda-Dienst auslöst – in einem solchen System lässt sich der Ablauf der Logik nur schwer nachvollziehen. Die Teams sollten nach Möglichkeit Muster verwenden, die das Systemverhalten leichter verständlich machen. Vielleicht sollten sie hierzu sogar die Anzahl der Technologien im System verringern.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -