Fazit

Grosse Herausforderungen ergeben sich, wenn man versucht, von einer monolithischen Architektur zu einer Microservice-Architektur zu migrieren und dabei ausser Acht lässt, dass Micro­services nicht automatisch deshalb besser sind, weil die Dienste physisch voneinander getrennt sind. Damit das Vorgehen sein wahres Potenzial ausspielen kann, müssen der orga­nisatorische Überbau und eine erhebliche Menge an Wissen für den Betrieb der Software aufgebaut werden. Nimmt das Unternehmen diese organisatorische Umstrukturierung nicht zeitgleich in Angriff, wird es nicht von den Vorteilen profitieren können. Ganz im Gegenteil, organisatorische Schwächen können sich in dieser Architekturform noch schwerwiegender auswirken, als es bei Monolithen der Fall ist. Ob sich der Aufwand also lohnt, ist nicht zuletzt davon abhängig, wie skalierbar die Software sein muss und wie viele Entwickler zeitgleich daran arbeiten sollen.

Mit dem Modulithen gibt es ­eine Architekturform, die einen Wechsel zwischen beiden Systemvarianten erlaubt und häufig auch als Zwischenstufe bei der Migration von der einen zur anderen genutzt wird. Die lose gekoppelten Strukturen eines Modulithen und die damit notwendige Infrastruktur verursachen aber einen gewissen Mehraufwand, der gerade bei kleineren Softwareprojekten als zu gross empfunden wird. Es sollte daher bereits vor der Entwicklung einer Software geprüft werden, wie umfangreich diese in Zukunft werden könnte, um dann von Beginn an entscheiden zu können, wie stark sie modularisiert werden sollte. Entscheidet man sich zu spät für ­eine Modularisierung, ist dies mit einem sehr hohen Restrukturierungsaufwand verbunden.

In jedem Fall muss aber noch einmal festgehalten werden, dass jede Form von Architekturmustern zu schlechten Ergebnissen führt, wenn sie falsch angewendet wird.