Microservices – ein Ansatz zur Softwaremodularisierung
Der Artikel zeigt, wie mit Hilfe von Microservices Applikationen modular und abteilungsübergreifend entwickelt werden können.
Modularisierung ist nichts Neues. Schon lange werden grosse Systeme in kleine Module unterteilt, um Software einfacher zu erstellen, zu verstehen und weiterzuentwickeln. Was ist also neu an Microservices?
Was ist neu?
Microservices nutzen als Module einzelne Programme, die als eigene Prozesse laufen. Der Ansatz basiert auf der UNIX-Philosophie. Sie lässt sich auf drei Aspekte reduzieren:
- Ein Programm soll nur eine Aufgabe erledigen und diese soll es gut machen
- Programme sollen zusammenarbeiten können
- Es soll eine universelle Schnittstelle genutzt werden. In UNIX sind das Textströme
Beispiel Kreditorenprozess
Dieser Artikel zeigt die einzelnen Schritte, um einen Prozess mittels Microservices zu modernisieren. Dazu haben wir uns den Kreditorenprozess ausgesucht, weil den die meisten von uns kennen.
Wir gehen von folgender Ausgangslage aus:
- Die ERP-Fachanwendung ist in die Jahre gekommen und die Fachabteilungen machen Druck, weil der ganze Prozess zur Freigabe von Kreditorenrechnungen zu langwierig und zu wenig intuitiv ist.
- Die ERP-Entwickler würden gerne an neuen Ideen arbeiten, sind aber mit der Wartung der Software voll und ganz ausgelastet.
- Ein neues Team von Webentwicklern, das in der Firma in den letzten Jahren entstanden ist, hätte Ideen für die Umsetzung und freie Kapazitäten.
- Das Management muss eine Entscheidung fällen, hat aber zu wenig Fakten, um grössere Investitionen zu bewilligen.
Bei dieser Ausgangslage bieten sich Microservices aufgrund folgender Vorteile an:
- Starke Modularisierung
- Konzepte zur Erweiterung von Lecacy-Anwendungen
- Unabhängige Entwicklung der Microservices
- Technologiefreiheit
- Schnellere Time-to-Market durch einzelne Entwicklung und Übergabe in die Produktion
Anhand der Ausgangslage, haben wir uns nicht wie üblich entweder für eine technische oder für eine fachliche Aufteilung der Teams entschieden, sondern für eine Kombination der beiden:
Die obige Abbildung zeigt die Aufteilung und die Schnittstellen der Teams. Für die Implementierung der Schnittstellen verwenden wir das REST Paradigma basierend auf dem http-Protokoll.
Nachdem Teams und grobe Schnittstellen geklärt sind, können die Arbeiten an den Microservices beginnen.
Als Erstes startet das Fach-Team mit der Modellierung des Prozesses. Das Fach-Team kennt sich bereits mit der BPM-Notation zur Modellierung von Prozessen aus. Als Produkte haben sie sich für den BPM-Modeler und die BPM-Engine aus dem Hause Camunda entschieden.
Stark vereinfacht sieht der Kreditorenprozess so aus:
Der Einsatz von BPM bzw. einer BPM-Engine bietet mehrere Vorteile:
- Einsatz eines Modellierungsstandards
- Prototyp des Prozesses ohne Programmierung möglich
- Und für uns am wichtigsten: Anbindung und Orchestrierung der Microservices möglich
Ausserdem steht die BPM-Engine als Docker Container zur Verfügung und kann bei entsprechender Umgebung sofort eingesetzt werden.
| Grösse von Microservices: Die Aufteilung der Microservices nach fachlichen Gesichtspunkten hat einen grösseren Stellenwert als die effektive Grösse eines Microservices. So ist es nicht unüblich, eine bestehende Applikation als Microservice zu verpacken. |
Als Zweites startet das Web-Team mit dem Microservice «Web-Frontend», um den Kreditorenprozess zu starten.
Die stark vereinfachte Web-Oberfläche, um den Kreditorenprozess zu starten, könnte wie folgt aussehen:
Anstatt mittels Web-Frontend den Kreditorenprozess zu starten, kann zu einem späteren Zeitpunkt der Prozess automatisch, z.B. durch das Einscannen einer Kreditorenrechnung, durch den Erhalt einer E-Rechnung o.Ä. gestartet werden. Einfach durch die Implementierung und den Austausch eines Microservices. Statt den Microservices einfach auszutauschen, wären auch mehrere Microservices möglich, die parallel Prozesse starten.
Die Kommunikation zum Starten des Prozesses erfolgt mittels REST- bzw. http-Aufrufen. Der Microservice «Web-Frontend» befindet sich auf github.
Parallel zum Web-Team ist das ERP-Team gestartet. Es implementiert den Microservice «Rechnung zahlen». Der Entscheid für das ERP-Team bzw. dessen Lecacy-Lösung ist gefallen, weil dort die ganzen Abhandlungen Verbuchung der Rechnung, Auslösen von Zahlungen usw. bereits implementiert sind.
Der Microservice «Rechnung zahlen» wird als «Antikorruptionsschicht»-Muster implementiert, um eine möglichst grosse Unabhängigkeit von der ERP-Applikation zu gewährleisten.
| Antikorruptionsschicht (anticorruption layer): Die Antikorruptionsschicht ist eine architekturelle Schicht, die das Domänenmodell von anderen Modellen trennt. Dabei werden die eigenen Konzepte und Sprachelemente auf die des fremden Modells übersetzt, das eigene Domänenmodell wird so nicht durch das fremde Modell beeinflusst. |
Der Aufruf des Microservices «Rechnung zahlen» wird aus dem Microservice «BPM-Engine» aufgerufen, wie folgendes Beispiel zeigt:
Fazit
Mittels Microservices können einzelne Teams unabhängig voneinander Software entwickeln. Dabei muss das Rad nicht neu erfunden werden, sondern es können bestehende Legacy-Applikationen einfach eingebunden werden. Durch den Einsatz neuer Modellierungskonzepte wie BPMN rücken die Fachabteilungen näher an die Entwicklung, was wiederum die Abstimmung vereinfacht.
Ich habe im Artikel aus Übersichtsgründen bewusst auf Container und Produkte wie Docker/Kubernetes verzichtet. Diese würden es erlauben, neben der Fachabteilung auch die IT-Operations in die Entwicklung einzubinden. Auf dem Beispiel auf github sind diese Konzepte bereits angedacht.