Ist eine Microservice-Architektur Stand der Technik (Teil 4 - Voraussetzungen)

In den letzten Blogposts wurden die Vor- und Nachteile einer Microservice-Architektur herausgearbeitet und einander gegenübergestellt. Dabei hat sich herausgestellt, dass vielen der Vorteile auch nicht zu vernachlässigende Nachteile gegenüberstehen.

Dieser Blogpost soll nun klären, unter welchen Voraussetzungen eine Microservice-Architektur Stand der Technik ist. D.h. (zumindest im Vergleich zu einer modulithischen Architektur) effektiver (also nur so die Ziele erreichend) oder zumindest effizienter (also die Ziele produktiver erreichend) ist:

• Skalierung: Microservices sind effektiver, wenn eine vertikale Skalierung (mehr CPUs, Arbeitsspeicher, Netzwerkbandbreite, ...) nicht ausreicht, um die Anforderungen an die Gesamtsoftware zu stemmen¹ und es Teile gibt, die sich nicht (horizontal) skalieren lassen und sich durch eine "Auslagerung" dieser Teile in Microservices das Gesamtsystem realisieren lässt.
  Ansonsten aber sind sie finanziell und organisatorisch ineffizienter, wenn sie auf unterschiedlichen Nodes laufen. 
  → Skalierbarkeit ist nur in Ausnahmefällen ein Entscheidungsgrund für Microservices, ansonsten eher ein Nachteil
• Performance: Performance ist bei Microservices generell geringer. Hinsichtlich performancekritischen Anwendungen und solchen, wo damit zu rechnen ist, dass die geforderte Performance nur schwer zu erreichen ist, gilt eine Microservice-Architektur somit als ineffizient.
  → Performance ist in bestimmten Anwendungen ein Entscheidungsgrund gegen Microservices
• Technische Qualität: Die Möglichkeit Microservices unabhängig voneinander zu entwickeln, ist hinsichtlich technischer Qualität nur dann von Vorteil, wenn die tatsächlich jeweils geeigneteren Technologien verwendet werden und mit organisatorischen Maßnahmen ein Wildwuchs vermieden wird und damit die für Microservices nötige technische Komplexität und der für architekturelle Änderungen drastisch höhere Aufwand kompensiert wird.
  → In den meisten Fällen führt eine Microservice-Architektur zu einer insgesamt technisch schlechteren Lösung
• Umsetzungsproduktivität: Microservices lassen sich aufgrund der Unabhängigkeit produktiver umsetzen und testen. Dennoch ist die gesamte Produktivität aufgrund der genannten organisatorischen Maßnahmen und technischen Komplexität, und der Problematik, dass Architekturrefactorings sowie das Microservice-übergreifende Testen und Debuggen nur ineffizient umsetzbar sind, teils deutlich geringer
  → Die Umsetzungsproduktivität ist bei Microservice-Architekturen geringer, für Software, die eine geringe Fehlerdichte aufweisen muss (z.B. sichere Software und Standardsoftware) teils sogar deutlich geringer
• Weitere Punkte: Hinsichtlich weiterer Punkte wurden in den vorangehenden Blogposts die Vor- und Nachteile als ausgewogen (Deployment) bzw. weniger effizient (Konsistenz, Infrastruktur) beurteilt.
  → Hinsichtlich Deployment kann kein allgemeiner Vor- oder Nachteil festgestellt werden, fehlende Konsistenz und höhere Infrastrukturkosten sind jedoch als Nachteil zu werten

Fazit: Wenn die oben genannten Ausnahmefälle hinsichtlich Skalierung und technischer Qualität nicht zutreffen, so gilt eine Microservice-Architektur in den allermeisten Fällen nicht als Stand der Technik und ihr Einsatz ist somit technisch (und juristisch) dringend zu hinterfragen.

___

1. AWS r8g.metal-48xl schafft derzeit  (12/2024) 192 vCPUs, 1,5 TB RAM und 50 GBit/s. Die Kosten pro vCPU, GB, GBit steigen wie schon erwähnt etwas weniger als linear. . ↩