Die blitzschnelle Anwendungsentwicklung von Portbase

Portbase ist die Spinne im Netz der niederländischen Logistik. Die 2009 gegründete gemeinnützige Organisation verbindet alle Beteiligten in den Logistikketten der niederländischen Häfen. Portbase erleichtert den Datenaustausch zwischen Unternehmen und den Informationsaustausch mit Behörden, um schneller, effizienter und kostengünstiger zu arbeiten. 

Wie bei so vielen Organisationen war auch die IT-Architektur von Portbase bis vor kurzem ein echter Monolith: ein Sammelsurium von Diensten, die gegenseitig voneinander abhängig waren. In einem solchen IT-Dschungel dauerte Development nicht nur lange, eine Vielzahl an Leuten musste gleichzeitig aktiv werden, wobei gemeinsame Releases höchstens alle vierzehn Tage stattfanden. Genau das wollte Portbase ändern, indem autonome Teams eingesetzt werden, die für bestimmte Funktionalitäten zuständig sind, ohne dabei von anderen Teams, anderer Infrastruktur und dem Monolithen abhängig zu sein. 

Als Lead Software Engineer machte sich René de Waele 2018 mit seinem Team (und später mit anderen Teams) an die Arbeit, um diese Umstellung zu realisieren. "Der Ausgangspunkt war, dass wir nicht nur die Software skalierbar machen, sondern auch, dass sich jede Abteilung auf fachliche Aspekte oder Geschäftsregeln konzentrieren kann, anstatt sich nur mit der Technik im Code zu beschäftigen. Kurz gesagt: schreibe die Dinge in deinem Code so auf, wie du sie haben willst."

Die Grundlage für die Lösung war ein Tool, das De Waele bereits zuvor entwickelt hatte: Flux Capacitor. "Einen Monolithen gegen Microservices auszutauschen ist attraktiv, aber die Kommunikation zwischen den Services ist eine ziemliche Herausforderung", erklärt er. "Dank Flux Capacitor ist es viel einfacher, Nachrichten zwischen den Anwendungen auszutauschen und neue Dienste zu starten. Sobald du einen Dienst gestartet hast, kann er mit jedem anderen angeschlossenen Dienst kommunizieren." 

Wie haben René und sein Team das erreicht? "Wenn man zu den Grundlagen zurückgeht und sich ansieht, was eine Anwendung eigentlich macht, kann man zwischen drei Dingen unterscheiden. Commands sind Anfragen an die Anwendung, zum Beispiel: Ich möchte einen neuen Besuch eines Schiffes registrieren. Queries sind Anfragen, in diesem Fall zum Beispiel: Gib mir alle Besuche dieses einen Schiffes. Dann gibt es die Side Effects, z. B. die Benachrichtigung des Hafens oder des Zolls, dass das Schiff angemeldet wurde. In einer dynamischen Umgebung, in der solcherlei Nachrichten in großer Zahl ausgetauscht werden und wo es auf Zuverlässigkeit ankommt, ist der traditionelle Weg sehr mühsam. Zum Beispiel werden Dienste oft mehrfach aufgerufen, sodass ein Load Balancer erforderlich ist, um einen reibungslosen Ablauf zu gewährleisten. Weil es immer mehr Endpunkte gibt, wird die Infrastruktur unnötig kompliziert, und all diese Endpunkte müssen zusätzlich auch noch gesichert werden. Ein spezialisiertes Team von Cloud-Ingenieuren muss sich um diese Probleme kümmern, und dann musst du dein Produkt natürlich auch noch auf den Markt bringen." 

Dies kann vermieden werden, indem die Queries und Commands von einem zentralen Messagebroker bearbeitet werden. Die verschiedenen Microservices sind nicht miteinander verknüpft und keiner von ihnen ist direkt mit dem Internet verbunden. "Es sind keine Anwendungen, die du über deinen Browser aufrufen kannst. Das bedeutet auch, dass sie weniger anfällig für Hackerangriffe sind. Zudem versteht der Message Broker keine der Nachrichten, sondern speichert nur, welche Queries und Commands bearbeitet werden. Der Message Broker kann zudem das Load Balancing übernehmen. Außerdem können wir damit genau verfolgen, was passiert. Nicht nur die Ereignisse, sondern auch alle eingehenden API-Anfragen, alle eingehenden Nachrichten, welcher Browser verwendet wurde und so weiter. Bei Portbase haben wir inzwischen dutzende von Microservices entwickelt, die die Logs völlig unabhängig voneinander lesen." 

Auch das Testing ist jetzt viel einfacher und liefert weitaus bessere Ergebnisse. "Wenn man verschiedene Dienste testen will, ist das oft ein mühsamer Prozess. Du musst eine Testumgebung mit einer Datenbank, verschiedenen Diensten und einer Netzwerkverbindung erstellen. Weil das umständlich und fehleranfällig ist, wird in der Praxis nur selten das funktionale Verhalten der Anwendung als Ganzes getestet. Beim Testing sind wir an dem Verhalten der gesamten Anwendung interessiert. Das wollen wir ständig testen, ohne dass wir wissen müssen, wie die Anwendung es verwaltet. So haben wir alle unsere Tests geschrieben." 

Inzwischen sind die Hauptanwendungen vollständig vom Monolithen getrennt. "Die Umstellung dauerte nicht länger als sechs Monate pro Anwendung und konnte, verglichen mit dem vorherigen System, mit einem Zehntel der Codezeilen durchgeführt werden. Unterm Strich bestanden 90 Prozent der Anwendung aus reiner Technik. Anstatt zweimal im Monat mit einer neuen Version live zu gehen, können wir das jetzt fünf bis zehn Mal am Tag tun. Tatsächlich gehen wir jetzt mit verschiedenen Teams etwa hundertmal am Tag live, immer mit echten Funktionen." Obwohl wir so viele neue Dinge implementieren, gibt es viel weniger Probleme als vorher. "Bevor wir anfingen, hatte das Team einen riesigen Backlog, der schneller wuchs als er bearbeitet werden konnte. Nach der sechsmonatigen Umstellung war der Auftragsbestand fast vollständig abgearbeitet."