Ist eine Microservice-Architektur am Stand der Technik? Teil 1 (Bedingungen)

Noch vor wenigen Jahren waren Microservices in aller Munde. Microservice-Architekturen versprechen jede Menge Vorteile: Verteil- und skalierbarer, verfügbarer, wartbarer, paralleler entwickelbar, schneller und öfter ausrollbar, ... sollten sie sein. Doch stimmt das auch tatsächlich und macht das Microservice-Architekturen zum Stand der Technik?

Zweifelsohne kann man Software mit einer Microservice-Architektur umsetzen. Es gibt schon seit vielen Jahren erfolgreich mit einer Microservice-Architektur umgesetzte Projekte. Vorreiter war Netflix 2009, inzwischen hat Netflix tausende Microservices die teilweise hunderte Male täglich ausgerollt werden.
→ Damit ist die Funktionstüchtigkeit von Microservice-Architekturen als erprobt und erwiesen anzusehen - eine der Bedingungen für die Erfüllung des Standes der Technik.

Die zweite Bedingung für die Erfüllung des Standes der Technik ist, ob das geprüfte Verfahren (also eine Microservice-Architektur) auf wissenschaftlichen Erkenntnissen beruht. Zu allen in der Softwareentwicklung breit verwendeten Verfahren gibt es wissenschaftliche Erkenntnisse. Bei Microservice-Architekturen wird man aber bei einer einfachen Internetsuche nach wissenschaftlichen Erkenntnissen rasch fündig.¹
→ Auch diese Bedingung wird somit durch Microservice-Architekturen erfüllt.

Bleibt die dritte, letzte, und am schwierigsten zu erfüllende Bedingung: Ist das geprüfte Verfahren fortschrittlicher als alternative Verfahren. "Fortschrittlichkeit" ist nicht generell, sondern speziell für die jeweilige Aufgabenstellung zu prüfen: Ist die Verhältnismäßigkeit zwischen Kosten und Nutzen geringer als bei alternativen Verfahren?

Es gilt also alle Vor- und Nachteile einer Microservice-Architektur speziell für den jeweiligen Anwendungsfall abzuwägen. Dieser Punkt wird beinahe immer von den Softwarearchitekten vernachlässigt. Man verlässt sich darauf, dass die proklamierten Vorteile jedenfalls eintreffen werden und recherchiert meist nicht einmal nach den Nachteilen.

Dabei muss für eine akzeptable Software nicht nur geprüft werden, ob die Vor- die Nachteile überwiegen, sondern auch ob die Verhältnismäßigkeit besser als bei alternativen Verfahren ist. Im nächsten Blogpost schauen wir uns diese Vor- und Nachteile im Vergleich zu der typischerweise alternativ eingesetzten Architektur eines Modulithen an.¹

Fazit: Hinsichtlich zwei der drei Bedingungen für den Stand der Technik kann generell gesagt werden, dass eine Microservice-Architektur dem Stand der Technik entspricht. Ob sie aber auch hinsichtlich der dritten Bedingung (der "Fortschrittlichkeit") am Stand der Technik ist, wird meist ignoriert, muss aber für jedes Projekt einzeln geklärt werden - siehe nächster Blogpost.

___

1. siehe beispielsweise die ca. 100 wissenschaftlichen Arbeiten dazu bei ResearchGate. ↩

2. Mit dem Aufkommen von Web- und Microservices haben Monolithen den Stempel einer unwartbaren, riesigen, Big-Ball-of-Mud Architektur aufgedrückt bekommen. Darum verwenden wir den Begriff "Modulith" (= ein gut strukturierter Monolith = das was immer das Ziel einer monolithischen Architektur war), um klar zu machen, dass wir eine Microstervice-Architektur nicht mit einer schlecht gelungenen Umsetzung einer ansonsten vielleicht guten Architektur vergleichen. ↩