26. Juni 2019
In der Softwareentwicklung gilt im Grunde dasselbe wie überall sonst auch: Mit dem Abschluss von Ausbildung oder Studium hört das Lernen nicht auf.
Wo lernen unsere Softwareentwickler? Natürlich bietet jedes Kundenprojekt eine neue und willkommene Gelegenheit, vorhandenes Wissen zu vertiefen und sich weiterzuentwickeln. Wenn es aber darum geht, die ersten (und zweiten) Schritte in einer neuen Technologie oder einem neuen Framework zu tun, ist ein echtes Kundenprojekt definitiv nicht der geeignete Ort dafür.
Vor einiger Zeit haben wir bei EsPresto für die Weiterbildung speziell unserer Junior-Entwickler ein internes Projekt gestartet, in dem sie sich in für sie neue Technologien einarbeiten und mit ihnen herumexperimentieren können. Gleichzeitig sollte das Projekt aber auch einen praktischen Nutzen besitzen, und so kamen wir auf die Idee, unsere internen Prozesse mit Microservices abzubilden und die Junioren mit der Entwicklung der einzelnen Services zu beauftragen.
Microservices sind zunächst einmal auch „nur“ Softwareanwendungen, die jedoch im Unterschied zu den großen monolithischen Anwendungen dafür ausgelegt sind, genau eine Aufgabe zu erfüllen. Für den Kunden hat das den Vorteil, dass Microservices relativ schnell nutzbar sind, man sie aber bei Bedarf auch beinahe ebenso schnell wieder durch eine andere Anwendung ersetzen kann.
Mit anderen Anwendungen (egal ob Microservice oder Monolith) kommunizieren sie über Schnittstellen. Das bedeutet, dass mehrere Teams parallel mehrere Microservices gleichzeitig, unabhängig voneinander und in verschiedenen Programmiersprachen entwickeln können. Auch das Deployment kann für jeden Microservice individuell durchgeführt werden, ohne die anderen in ihrer Funktionsweise zu beeinträchtigen. Das gilt auch für Versions-Updates: Während Microservice A schon auf die neueste Java-/PHP-/Docker-/Was-auch-immer-Version aktualisiert wurde, kann Microservice B noch problemlos auf der älteren Version laufen. Auf die Leistung des Gesamtsystems hat das keinerlei Einfluss.
Das alles sind gute Argumente für Microservices im Allgemeinen und besonders für die Verwendung in unserem internen Weiterbildungsprojekt. Wir haben sowohl PHP- als auch Java-Junioren, die alle daran mitarbeiten können. Zum Projektstart haben sie gemeinsam überlegt, für welche Anforderungen welche Sprache besser geeignet ist als die andere und welches Framework zum Einsatz kommen soll. Davon ausgehend haben sie dann die verschiedenen Microservices untereinander aufgeteilt und angefangen zu entwickeln.
Zugegeben: Es geht nicht ganz so schnell voran, wie es nach allen in der Softwarewelt kursierenden Microservice-Definitionen „erlaubt“ wäre, aber das ist okay. Denn erstens entwickeln die Kollegen mit für sie neuen Frameworks, in die sie sich erst einarbeiten müssen. Sonst wäre es ja keine Weiterbildung. Und zweitens räumen wir ihnen dazu zwar gerne Arbeitszeit ein, dennoch haben die Projekte für unsere Kunden natürlich immer oberste Priorität. Dadurch gibt es immer wieder längere Phasen, in denen sie so gut wie gar nicht an ihren Microservices arbeiten können.
Wir benutzen schon einige sehr gute Tools, mit denen wir uns organisieren. Die wichtigsten davon sind JIRA und die von uns selbst entwickelte Zeiterfassung, die wir mit JIRA integriert haben, so dass wir unsere Zeiten direkt auf einzelne Tickets buchen können. Außerdem zeigt es uns an, wie viele Überstunden (oder Unterstunden) jede*r einzelne von uns angesammelt hat (uns hat das EuGH-Urteil zur Arbeitszeiterfassung daher nicht kalt erwischt). Das funktioniert hervorragend und soll darum auch so bleiben. Doch Aufgaben wie beispielsweise eine wöchentliche Übersicht der in den einzelnen Projekten angefallenen Aufwände (Weeklys), die Rechnungserstellung oder die Ressourcenplanung wollen wir zukünftig in Microservices abbilden. (Ein Tool, das uns alle an die fällige Entkalkung unserer Kaffeemaschine erinnert, wäre auch nicht schlecht, hat zum großen Bedauern der Kaffeemaschine aktuell aber keine besonders hohe Prio.)
Was aus der Aufzählung allein dieser Tools schon deutlich wird: Sie hängen alle irgendwie zusammen. Damit wir in unsere Rechnungen die korrekten Beträge schreiben können, müssen wir wissen, wie viele Stunden zu welchen Stundensätzen im jeweiligen Rechnungszeitraum angefallen sind. Sprich: Wir brauchen dazu die Weeklys. Um wiederum ein korrektes Weekly zu erstellen, muss das Tool auf unser Zeiterfassungssystem zugreifen können.
Damit ist unser internes Projekt im Kleinen das gleiche, was wir im Großen für unsere Kunden leisten: Für bestimmte Aufgaben und Prozesse individuell entwickelte Anwendungen, die wir nahtlos in die bestehende IT-Landschaft integrieren.
Zunächst einmal haben wir Ideen für verschiedene Anwendungen gesammelt und diese dann priorisiert: Was brauchen wir unbedingt, was ist mäßig wichtig und auf was können wir noch eine Weile verzichten? Davon ausgehend haben wir unsere Microservice-Architektur entworfen. Unsere Grafik zeigt den aktuellen Stand dessen, was wir bereits haben und was zumindest schon mal halb fertig ist sowie einen Teil dessen, was zu einem späteren Zeitpunkt noch kommen soll (gestrichelte Linien):
Alle Microservices sind durch ein gemeinsames API-Gateway erreichbar, das zum einen den Datenaustausch zwischen ihnen allen herstellt und zum anderen dafür sorgt, dass nur wir von EsPresto auf die Anwendungen zugreifen können. Für die API war JHipster die Technologie der Wahl, weil es im Hinblick auf die für das API-Gateway quasi ein „Rundum-Sorglos“-Paket mit allen benötigten Funktionalitäten beinhaltet. Gleichzeitig hatte die Entscheidung für JHipster aber auch eine große Auswirkung auf die Microservice-Architektur als Ganzes, denn es verlangt, die Microservices jeweils in Frontend und Backend aufzusplitten. Das mag sich auf den ersten Blick wie ein Nachteil anhören, ist aber keiner. Denn so können wir alle Microservices in einem gemeinsamen Frontend und in einem einheitlichen Design abbilden (zur großen Freude unseres Marketings; Stichwort: Corporate Design). Dieses Frontend haben wir in Angular entwickelt, weil es den aktuellen State of the Art in Sachen Frontend-Entwicklung darstellt. Außerdem fordert JHipster diese Technologie quasi ein.
Das Frontend besteht im Wesentlichen aus einem Dashboard, in das die einzelnen Microservices als Module integriert sind. Ein Nutzer kann sich die für ihn relevanten Microservices in diesem Dashboard anzeigen lassen oder sie auch wieder rausnehmen.
Im Hintergrund ist das Gateway mit mit unserem LDAP verknüpft, so dass sich a) nur wir EsPresto-Mitarbeiter in den Microservices anmelden können und b) wir für die Anmeldung dieselben Zugangsdaten verwenden können wie für die anderen Dienste, die wir nutzen (Confluence und JIRA zum Beispiel).
Im Backend läuft die Kommunikation der einzelnen Microservices untereinander über das Gateway (mit freundlicher Unterstützung durch die Service Registry). Es gibt jedoch eine – vorläufige – Ausnahme: Das OMG-Tool mussten wir in der Architektur zunächst einmal anderweitig “verdrahten”, weil die für seine Funktionalitäten erforderlichen Websockets noch nicht von JHipster unterstützt werden. Nichtsdestotrotz wird wird es jetzt schon vom gemeinsamen Dashboard aus angesprochen und in der Zukunft soll das Backend genau wie bei den anderen Anwendungen auch an das Gateway angeschlossen sein. (Was das OMG-Tool ist, wie sein Name zustande gekommen ist und was sich hinter den Kürzeln der beiden nachgeordneten Microservices verbirgt, erklären wir demnächst in einem eigenen Beitrag. Versprochen!*)
Die Microservices schicken ihre Daten also aus dem Backend grundsätzlich an das Gateway, das diese Daten dann im Frontend anzeigt. Teilweise kommunizieren sie jedoch zusätzlich im Backend direkt miteinander, z.B. das Weekly-Tool, das auf die Datenbank unseres Timetrackers zugreift, oder das Invoicing-Tool, das Daten aus dem Weekly-Tool abfragt. Die Kommunikation zwischen den Microservices und dem Gateway und den Anwendungen untereinander läuft über HTTP und REST.
URST, unser Universal-Resources-Tool (= Ressourcenplanung), hat zum aktuellen Zeitpunkt streng genommen noch gar kein eigenes Backend. Was der Nutzer im Frontend zu sehen bekommt, ist erst einmal eine Art Platzhalter aus Kibana. Kibana ist eine Open-Source-Plattform, die Daten zu Analysezwecken visualisiert. Im Falle von URST sind das die Daten aus unserem Timetracker. Dazu haben wir einen Exporter geschrieben, der die benötigten Daten zunächst in Elasticsearch überträgt. Dort hat Kibana Zugriff auf diese Daten und kann so dem Nutzer z.B. anzeigen, wie viele Stunden im Zeitraum X insgesamt und wie viele an Projekt Y gearbeitet wurde. Diese Auswertung ist gar nicht schlecht, soll aber noch granularer werden, und das soll das noch im Entstehen begriffene Backend später leisten.
Trotzdem zeigt dieses Beispiel noch einmal sehr schön einen der großen Vorteile von Microservices: Der Kunde kann die Software bereits nutzen, auch wenn ein (großer oder kleiner) Teil der gewünschten Funktionalitäten noch Softwarebaustelle ist.
* Update, 21.08.2019: Versprechen soll man bekanntlich halten – hier geht es zum Artikel über das OMG.