Monolithen vs. Microservices - Whitepaper

Im eCommerce dominieren monolithische Middleware-Lösungen den Markt. Doch bei monolithischen Anwendungen nimmt der Entwicklungsumfang mit der Zeit zu. Infolgedessen wächst nicht nur die Codebasis, sondern auch die Komplexität. Eine agile Entwicklung und schnelle Bereitstellung werden so zu echten Herausforderungen. Um diese zu lösen, wandeln einige Unternehmen ihre monolithische Middleware in individuelle Microservices um. In diesem Whitepaper erhalten Sie einen umfassenden Leitfaden zu Architekturvorteilen, Migrationsstrategien, Tools und Technologien.

Im eCommerce dominieren monolithische Middleware-Lösungen den Markt. So hilft bspw. die SAP Commerce Cloud Unternehmen, Kosten zu senken, Zeit zu sparen und Komplexität zu reduzieren, um ein hervorragendes Kundenerlebnis zu generieren. Doch bei monolithischen Anwendungen nimmt der Entwicklungsumfang mit der Zeit zu. Infolgedessen wächst nicht nur die Codebasis, sondern auch die Komplexität, wodurch sich Prozesse mühsamer gestalten.

Um diese zu lösen, wandeln einige Unternehmen ihre monolithische Middleware in individuelle Microservices um. Die Microservice-Architektur lässt sich einfach testen, warten und ist eine lose gekoppelte Lösung, bei der jeder Service autonom bereitgestellt werden kann. Sie besitzt zudem den Vorteil, dass sie sich an den Business Capabilities eines Unternehmens orientiert.

Die monolithische Architektur galt jahrelang als das traditionelle Softwaredesign. Denn auch wenn beide Ansätze etwa gleichalt sind, überwogen beim Microservices-Ansatz für lange Zeit die Nachteile die Vorteile. Von potenziellen Veränderungen unabhängig wird ein Monolith häufig exhaustiv bereitgestellt. In Monolithen wird alles in einer Codebasis konstituiert. In den meisten Fällen setzen sie sich aus drei Bestandteilen zusammen:

Microservices ermöglichen als Architekturmuster den Aufbau einer Gruppe von lose gekoppelten Services. Diese sind logisch und physisch getrennt und jeder einzelne Service hält das Single-Responsibility-Prinzip ein. Das wiederum ermöglicht parallele Entwicklung, Testing und unabhängige sowie kontinuierliche Bereitstellung. Jeder einzelne Microservice lässt sich individuell skalieren. Während monolithische Anwendungen eine einzige logische Datenbank für persistente Daten verwenden, verfügen Microservice-Architekturen über ein dezentrales Datenmanagement. Die Grenzen einzelner Microservices werden von individuellen Bounded Contexts definiert.

Welche Migrationsstrategien eignen sich, um Monolithen in Microservices zu segmentieren? Diese Frage bezieht nicht nur die Codebasis ein, sondern betrifft auch die Aufteilung der Datenhaltung. Denn die dezentrale Datenhaltung ist eines der Hauptmerkmale der Microservice-Architektur und jeder einzelne Service sollte über eine eigene Datenhaltung verfügen.

Für den Erfolg des Prozesses ist entscheidend, dass die neue extrahierte Funktion genauso funktioniert wie jene im Monolithen. Es ist deshalb wichtig, die Entwicklung im Monolithen so weit wie möglich einzuschränken, bevor neue Services extrahiert werden können. Durch die Extraktion von Business Capabilities entsteht eine stabile Microservice-Architektur, in der die Services lose miteinander gekoppelt sind.

Eine alternative Möglichkeit besteht darin, Services gemäss den Subdomänen des Domain-Driven Designs zu extrahieren. Dabei wird das Domänenmodell in einzelne Subdomänen aufgeteilt. Nach dieser Strategie empfiehlt sich eine Hierarchisierung nach Änderungsnotwendigkeit. Zunächst sollten die einfachen Edge-Services entkoppelt werden. Anschliessend werden andere Services, die tiefer im Monolithen verankert sind, extrahiert.

Gegenüber der vollständigen Substitution eines Systems findet durch die Strangler-Fig-Anwendung eine inkrementelle Migration bei gleichzeitiger Nutzung des bestehenden Monolithen zur Risikominderung und schnelleren Auslieferung von Funktionalitäten statt. Die Umsetzung des Musters erfolgt in drei Schritten:

Zusätzlich wird ein parallellaufendes Muster angewandt, um Leistungsvergleiche zwischen der neuen und der monolithischen Funktionalität ziehen zu können. Ausserdem ermöglicht dies die Reaktionszeit sowie Fehlerquoten zu ermitteln. Das parallele Muster erkennt nur eine Quelle als Wahrheit an, auch wenn es beide Funktionalitäten aufruft und die Ergebnisse gegenüberstellt. Bis die neue Implementierung ihre Zuverlässigkeit beweist, wird dies die monolithische sein.

Während Unternehmen oft eine einzelne Datenbank für eine Reihe von Anwendungen bevorzugen, präferieren monolithische Anwendungen eine einzige logische Datenbank für persistente Daten. Microservices stellen einen Gegensatz dazu dar, weil hier idealerweise jeder Dienst seine eigene Datenhaltung verwaltet. Es gibt verschiedene Muster und Methoden:

Für den Aufbau von Microservices können verschiedene Technologien und Betriebsumgebungen eingesetzt werden:

Basierend auf Tests und eigenen Projekten zeigen Microservices folgende Vorteile: 1. Bereitstellung - Microservices versetzen uns in die Lage, schnell neue Werte zu liefern. Die vollständige Extraktion der am meisten genutzten Services trägt dazu bei, den Monolithen zu entlasten. 2. Skalierung - Entwickler-Teams durchdringen die Domäne substantiell und erwerben bessere Fähigkeiten im Migrationsprozess.

Die Handhabung und Durchdringung von Monolithen angesichts ihrer grossen Komplexität und die zentrale Entscheidung darüber, welche Services extrahiert werden sollen, stellen grosse Herausforderungen dar. Eng gekoppelte Domänenmodelle können zu einem hybriden Konstrukt führen, das die Nachteile beider Architekturen besitzt. Daher empfehlen wir, den Migrationsprozess nur schrittweise mit kleinen Teilen des Monolithen durchzuführen und jeden neuen Service nach dem bewährten DDD-Prinzip zu entwickeln.

Die kurze Antwort ist: Ja. Teams müssen sich mit Problemen wie Datenkonsistenz und der Synchronisierung zwischen dem Monolithen und den neu extrahierten Services beschäftigen. Je mehr Services extrahiert werden, desto komplexer wird die Kommunikation, sodass eine Latenzzeit emergiert. Tritt ein Fehler auf, ist durch den Prozessfluss bereits der Schritt herauszufinden, wo der Fehler liegt, problematisch.

Monolithen bieten klare Vorteile: 1. Einfachheit in Bereitstellung und Verwaltung - unkompliziert zu implementieren, da alle Komponenten Teil einer einzigen Plattform sind. 2. Integrierte und einheitliche Umgebung - alle Komponenten arbeiten nahtlos zusammen. 3. Kosteneffizienz (kurzfristig) - niedrigere Entwicklungs- und Bereitstellungskosten.

Vor der Entscheidung auf eine Microservice-Architektur zu migrieren, sollten Kosten und Vorteile abgewogen werden. Die Migration kann teür werden, wenn sie nicht angemessen durchgeführt wird oder unvorhergesehene Schwierigkeiten auftreten.

Anwendungen müssen so konzipiert sein, dass sie den Ausfall einzelner Services tolerieren können. Monitoring gewährleistet ein Frühwarnsystem, wenn etwas schiefläuft.

Unter dem Gesichtspunkt der Komplexität steht die Kosten-Nutzenrechnung im Zentrum. Soll ein Shop nur Produkte verkaufen, ist es einfacher, mit einem Monolithen zu starten. Die Komplexität liegt am Ende bei den Monolithen im Code, bei Microservices in der Netzwerkebene.

Die erfolgreiche Migration kann nur mit einem gut ausgebildeten Team durchgeführt werden. Die vertikale Aufteilung in funktionsübergreifende Teams analog zur Microservice-Struktur ermöglicht die Skalierung der Entwicklungskapazitäten. Die Entkopplung von Teams ist ebenso wichtig wie die Entkopplung von Softwaremodulen.

Microservices bieten eine Vielzahl an Vorteilen für Unternehmen, die auf der Suche nach Flexibilität und Effizienz sind. Letztendlich kann auch ein hybrider Ansatz, der die Stärken beider Architekturen vereint, die ideale Lösung sein. Die Wahl des richtigen Ansatzes beginnt immer mit einer gründlichen Evaluation Ihrer geschäftlichen Anforderungen und technischen Kapazitäten und sollte niemals ohne die notwendige Erfahrung getroffen werden.