Mittelstand, Finger weg von Microservices!

Seit mehr als zehn Jahren vergeht kaum eine Konferenz ohne das Thema Microservices. Fachmagazine publizieren eine hohe Anzahl von Artikeln zum Thema und externe Beratungsunternehmen verkaufen Workshops, beraten aktiv zum Wechsel zu einer Microservice-Architektur und preisen die Vorteile an. Für viele kleine und mittlere Unternehmen klingt das attraktiv – was bei den Großen so viel nützt, kann doch den kleineren nicht schaden? Ein folgenschwerer Trugschluss.

Denn Overengineering – also der Einsatz unnötig komplexer Software – kostet KMUs nicht nur viel Geld und Zeit, es nimmt ihnen auch ihren wichtigsten Wettbewerbsvorteil gegenüber den Konzernen.

So unterschiedlich KMUs sein können, also Firmen mit bis zu 250 Mitarbeitern und bis 50 Millionen Euro Umsatz – von Start-ups über Scale-ups bis zu Hidden Champions: Ihre Herausforderungen sind teils ähnlich. Das betrifft vor allem die Ressourcen. Oft haben diese Unternehmen nur ein bis zwei Dutzend Entwickler, die mitunter schnell auf veränderte Produktvisionen oder Anforderungen an das Projekt reagieren müssen. Die Architektur muss dies unterstützen, weshalb auch KMUs zunehmend über Microservices nachdenken. Aber Achtung vor Overengineering, denn damit erreicht man genau das Gegenteil.

Microservices lösen die Probleme von Konzernen …

In Großunternehmen, mit mehr als 250 Mitarbeitern, wird die Microservice-Architektur erfolgreich umgesetzt. Sie löst für diese Unternehmen die Probleme der Skalierung und Zusammenarbeit ihrer Entwicklungsteams. Es müssen Hunderte, zum Teil Tausende Entwickler an einem Produkt arbeiten. Um diese Teams autark und unabhängig arbeiten lassen zu können, ist eine Microservice-Architektur eine gute Lösung.

Netflix beschäftigt weltweit 13.000 Mitarbeiter, davon 2.500 Softwareentwickler. Mit dieser Anzahl an Softwareentwicklern ist eine Microservice-Architektur eine Möglichkeit, viele kleine Teams unabhängig arbeiten zu lassen. Im deutschsprachigen Raum gibt es ebenfalls Beispiele: Laut Linkedin geben knapp 1.000 deutschsprachige Mitarbeiter der Deutschen Bank an, über Kenntnisse in Java zu verfügen. Trivago hat über 300 Softwareentwickler. Und Check24 verzeichnet laut Linkedin mehr als 800 Mitarbeiter mit Kenntnissen über Javascript. Diese Zahlen verdeutlichen, dass die Unternehmen in anderen Dimensionen agieren als KMU. Die Herausforderungen, aber auch die Möglichkeiten sind fundamental unterschiedlich im Gegensatz zu KMUs.

… und verursachen welche in KMUs

KMUs versuchen, mit einer oder ein paar Handvoll Entwicklern das zu stemmen, wozu Großunternehmen Hunderte zur Verfügung hat. Die Teams in KMUs unterschätzen oft den Overhead in der Wartung einer Microservice-Landschaft sowie damit zusammenhängenden Kosten.

Eine Microservice-Architektur ist ein verteiltes System. Und in verteilten Systemen müssen Kompromisse zwischen Datenkonsistenz, Verarbeitungsgeschwindigkeit und Zuverlässigkeit eingegangen werden. Es kostet viel mehr Zeit, Energie und letztlich Geld, diese Merkmale im Sinne des Produktes zu erfüllen, als in einer monolithischen Anwendung.

Die Infrastruktur und deren Betreuung wird mit jeder weiteren Komponente exponentiell aufwendiger und teurer. Statt einer einzelnen Applikation müssen fünf oder zehn deployt, gewartet und überwacht werden. Es müssen automatisierte Alarmsysteme aufgebaut werden, die CI-/ und CD-Pipelines müssen komplexer sein. Und es werden umfangreichere Prozesse benötigt, um Versionierungen, API-Kompatibilitäten und Wartungsarbeiten zu koordinieren.

Als zusätzlichen Kostenfaktor ergibt sich bei genauerer Betrachtung, dass viele Entwicklungsteams von KMUs ihre Software nicht korrekt geschnitten haben. Die Software einer KMU befindet sich meistens in einer einzigen Domäne. Unter Umständen gibt es noch kleine Randdomänen – die aber selten entscheidend sind. Und diese Erkenntnis ist konsistent: Warum sollte es in einem Unternehmen mit zehn Softwareentwicklern mehrere Domänen geben, aber in Großunternehmen nicht, wo auch dort ein Team aus zehn Softwareentwicklern eine einzelne Domäne betreut?

Die Software eines KMU hat nicht den Umfang und das Featureset eines Spotify, Netflix, Check24 oder der Deutschen Bank. Und nach Domain-driven-Design sollte eine Domäne von einer einzelnen Applikation bearbeitet werden. Wenn eine einzelne Domäne fälschlicherweise auf mehrere Applikationen – vermeintliche Microservices – aufgeteilt wird, entsteht ein verteilter Monolith. Diese Architektur verbindet dann nur noch die Nachteile der Microservice-Architektur und der monolithischen Architektur.

Nicht selten führt eine zu komplizierte Softwarearchitektur zum schleichenden Scheitern des Produkts. Die Kosten steigen exponentiell mit fortschreitender Entwicklung und machen das Projekt unprofitabel. Oder die Software ist unflexibel und neue Markterkenntnisse oder strategische Anpassungen des Produkts können nicht oder nur mit hohen Kosten in die Software eingearbeitet werden.

Sprecht über Overengineering!

Microservices sind also in der Regel nicht die adäquate Lösung für die Anforderungen der KMUs. Warum werden sie trotzdem so oft in KMUs eingesetzt?

Die Survivorship Bias könnte erklären, wieso die Microservice-Architektur heute auch in KMUs die dominante Architekturform ist. Diese kognitive Verzerrung beschreibt das Phänomen, dass uns erfolgreiche Ereignisse präsenter sind als gescheiterte. Beispielsweise lesen wir eher von Erzählungen über Menschen, die mit Bitcoin über Nacht Millionär wurden, als all die Geschichten über Verluste im Kryptohandel.

Die meisten Entwicklerteams sind sich des Overengineerings nicht einmal bewusst, denn dieses Problem wird selten diskutiert. Wir sollten damit anfangen. Softwarearchitektur ist anpassbar. Sie muss und kann sich an die Gegebenheiten des Unternehmens anpassen. In der aktuellen Phase kann eine monolithische Anwendung für die KMU die beste Lösung sein. In der Zukunft kann sie an das Wachstum des Unternehmens angepasst werden und zu Microservices werden. Aber:

KMUs brauchen andere Lösungen als Großunternehmen.