Dieser Blogartikel bezieht sich auf den Vortrag „Es muss nicht immer Mikroservices sein“ von Thomas Ruhroth und Kai Schmidt, gehalten auf der JavaLand 2024.
Wenn man einen Kunden fragt, was ihm wichtig ist, dann kommt selten die Forderung nach Mikroservices. Viel wichtiger ist, dass die Anwendung funktional vollständig und korrekt ist. Eine Softwarearchitektur, wie z.B. Mikroservices, ist dabei nur ein Werkzeug, um die gewünschten Anforderungen bestmöglich zu erfüllen. In diesem Artikel geht es darum, wie man Architekturen dokumentieren kann und welchen Unterschied es zwischen Mikroservices und Monolithen gibt.
Eine gute Softwarearchitektur startet mit ihrer Dokumentation. Im deutschen Raum ist Arc42 ein bekanntes Werkzeug für diesen Zweck. Es ist eine Gliederungsvorlage mit insgesamt 12 Hauptkapiteln und gibt vor, welche Punkte ausgearbeitet und schriftlich festgehalten werden sollten. Seit 2005 entwickelten Peter Hruschka und Gernot Starke Arc42 und haben 2022 mittlerweile die 8. Version veröffentlicht. Besonderes Augenmerk legen sie unter anderem auf die Formulierung funktionaler und nicht-funktionaler Anforderungen. Denn bei der Formulierung solcher Anforderungen sollten zum einen die konkreten Wünsche möglichst präzise formuliert, aber vor allem auch schon deren spätere Umsetzbarkeit berücksichtigt werden. Außerdem legen sie in ihren Architekturrichtlinien Wert auf die korrekte und möglichst abschließende Erfassung von nicht-technischen Randbedingungen. Dazu zählen beispielsweise das Budget, rechtliche Bestimmungen oder auch die Verfügbarkeit von Internet während der Verwendung des Produkts. Denn auch solche Randbedingungen können einen entscheidenden Einfluss auf die finale Softwarearchitektur haben.
Mit Arc42 versuchen Hruschka und Starke die Schwächen in der Spezifikation ISO 25010 zu korrigieren. ISO 25010 ist genau wie Arc42 eine Richtlinie zur standardisierten Dokumentation einer Softwarearchitektur, die allerdings in ihren Grundzügen laut Hruschka und Starke nicht ausreichend die Betriebspraxis eines Softwareproduktes berücksichtigt. Es fehlen unter anderem Konzepte, wie Time-to-Market, Deploybarkeit oder Skalierbarkeit.
Folgende Grafik zeigt die acht Top-Level Konzepte von ISO 25010. Diese sind wiederum in jeweilige Unterkategorien unterteilt.
Skalierbarkeit ist keines der Top-Level Konzepte und wird auch in keiner Unterkategorie behandelt. Sie ist allerdings der entscheidende Punkte bei der Entscheidung zwischen einer monolithischen Architektur und Mikroservices.
Mikroservices zeichnen sich dadurch aus, dass unabhängige Funktionalitäten in unabhängig voneinander deploybare Services gekapselt werden. Monolithische Architekturen dagegen nehmen keine solche Trennung vor, sondern vereinen die gesamte Funktionalität in einer einzelnen Komponente.
Der entscheidende Vorteil von Mikroservices ist, dass einzelne Services horizontal gut skaliert werden können. So kann auf unterschiedliche Lastanforderungen einzelner Services ressourceneffizient und schnell reagiert werden. Allerdings geht diese Zerteilung mit einem erhöhten Overhead in der Kommunikation innerhalb des Systems einher. Da jeder Service eine eigenständige API bereitstellt, die über das Netzwerk angesprochen werden muss, ist eine Kommunikation zwischen einzelnen Services immer langsamer als die Kommunikation verschiedener Komponenten innerhalb eines Monolithen.
Auch die Betriebskosten einer Mikroservicearchitektur können die Betriebskosten eines Monolithen erheblich übersteigen. Ein sehr prominentes Beispiel lieferte Amazon Prime mit ihrem in 2023 veröffentlichtem Artikel „Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%“ (https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90). Darin schildern sie, dass sie erhebliche Effizienzprobleme in ihrer Microservice-Architektur hatten, weshalb sie begannen, Services zu größeren Komponenten zusammenzufassen. Infolgedessen stellte sich aber heraus, dass die Microservice-Architektur als solche überhaupt nur geringe Vorteile in ihrem Anwendungsfall brachte. Deshalb entschieden sie sich dazu, vollständig zu einer monolithischen Architektur zu wechseln und konnten letztlich sogar ihre Betriebskosten um 90% reduzieren.
Eine weitere Kritik an Mikroservices ist, dass es in der Praxis nicht sehr leicht ist, die Funktionalität tatsächlich so zu schneiden, dass sich die Abhängigkeiten zwischen den einzelnen Services sauber trennen lassen. Wird die Funktionalität nicht korrekt getrennt, kann es schnell zu inneren Abhängigkeiten zwischen Mikroservices kommen, wodurch das System letztlich doch nur ein Monolith „auf vielen Füßen“ ist.
Abschließend lässt sich sagen, dass Mikroservices nicht die Lösung für jedes Problem sind. Die horizontale Skalierbarkeit ist ein großer Vorteil dieser Architektur, wird aber durch Nachteile in anderen Gebieten erkauft. Daher sollte die Entscheidung zu Mikroservices trotz ihrer Popularität immer eine wohl überlegte Entscheidung sein.
