Monolithen vs. Microservices
Die jüngste Ankündigung von Commerce/Magento, das Produkt vollständig neu zu entwickeln, sorgte in der Magento Community für Furore. Der Plan ist, Magento in die Adobe I/O Cloud-Plattform zu integrieren und mit dem Microservice-Ansatz fit für die Zukunft zu machen.
Das hat uns dazu veranlasst, technisch einen genauen Blick auf Microservices zu werfen. Wo hat der Ansatz seinen Ursprung und wo liegen die Hauptunterschiede zu monolithischen Gebilden? Ein Exkurs.
Anpassungsfähigkeit ist in einer sich immer wandelnden Geschäftswelt unabdingbar. Die Nutzer geben die Richtung vor und so müssen sich auch Programme und Anwendungen schnell an ihre Anforderungen anpassen können. Microservices sind ein relativ neuer Ansatz der Softwareentwicklung. Sie haben ihren historischen Ursprung im DevOps Bereich, wo sie, neben Continuous Delivery Methoden, die Grundlage bildeten.
Und genau darin liegen die Vorteile von Microservices im Vergleich zu traditionellen, monolithischen Software-Architekturmustern. Sie unterstützen nämlich lose zusammengehörige Architekturen sowie auch die unabhängige Skalierung der einzelnen Komponenten.
Monolithische Architekturen: verbinden ihre funktionalen Elemente in einem einzigen, untrennbaren sowie homogenen Gebilde.
Mikroservices: Architekturmuster, bei dem eine komplexe Anwendungssoftware aus unabhängigen Prozessen komponiert wird, die untereinander mit sprachunabhängigen Programmierschnittstellen kommunizieren.
Monolithische Einzelprozess-Architektur
Der gesamte Code befindet sich in einem "einzigen" Paket
Alle Daten befinden sich in einem einzigen Datenspeicher (Data Storage)
Modulare monolithische Architektur
Jedes Modul befindet sich in einem einzigen Paket
Die einzelnen Module nutzen dieselbe Datenbank
Die einzelnen Module sind miteinander gekoppelt
Verteilter Monolith
Vorteile:
Teilt die Logik auf die einzelnen Module auf
Verschiedene Module können von verschiedenen Teams entwickelt werden
Hält die Codebasis unter dem gleichen Technologie-Stack
Nachteile:
Die Einheiten könnte nicht separat entwickelt werden
Eine Einheit kann nicht eigenständig bereitgestellt und/oder verteilt werden (ohne Hauptanwendung)
Änderungen in einer Einheit erfordern die Änderung anderer abhängiger Einheiten oder sogar die Änderung der Hauptanwendung
Es fallen hohe Kosten für Änderungen an
Größerer Umfang des Einsatzes
Allgemeiner Monolith
Vorteile
Das Entwicklerteam kann sich nur auf einen Technologie-Stack konzentrieren, was den anfänglichen Entwicklungsprozess beschleunigen kann
Die Entwickler kennen das gesamte System, seine Funktionsweise, Architektur/Struktur
Er ist einfacher zu implementieren
Er besitzt durch das einfache Klonen der Code-Basis eine horizontale Skalierbarkeit
Kann von einem kleinen Team entwickelt werden
Einfachere Anwendung
Leichtere Fehlerbehebung und leichteres Debugging
Nachteile
Es ist kein Upgrade/Deployment einer einzelnen Einheit möglich, der gesamte Monolith muss auf einer Vielzahl von Knoten (im Falle einer verteilten Anwendung) bereitgestellt werden
Schwerer zu verstehen, wenn die monolithische Anwendung hochskaliert ist
Die Änderungen an der einzelnen Unit könnten die Änderung vieler anderer hochgekoppelter Teile erfordern.
Barrieren für neue Technologien, somit ist es schwierig, eine neue Technologie auf einen bereits bestehenden Monolithen-Technologie-Stack anzuwenden
Mikrodienste
Vorteile:
Das User Interface umfasst getrennte Einheiten, die eine bestimmte Geschäftsdomäne, ihr Objekt und ihre Verantwortlichkeiten erfüllen
Jede Einheit kann separat gebaut, getestet und gewartet werden
Jede Einheit kann einen Technologie-Stack verwenden, der für den aktuellen Fall / das Geschäftsziel am besten geeignet ist
Jede Einheit kann horizontal und dynamisch skaliert werden, so kann auch die Nutzlast besser gehandhabt werden
Kontinuierliche Lieferung (Sie können nur einen Dienst aktualisieren)
Domänenorientierter Entwurf
Leichteres und besseres Verständnis einer einzelnen Domäne/Einheit
Nachteile
Zusätzliche Komplexität, welches ein hochqualifiziertes Team erfordert, um das Geschäft global in die unabhängigen Domänen aufzuteilen und eine angemessene Architekturlösung zu erstellen
Die Verteilung erweist sich als schwierig, da das System viele einzelne Komponenten mit eigenen Datenbanken hat, wobei alle Verbindungen gehandhabt werden müssen
Übergreifende Konflikte/Sorgen- das Team muss sich um die ausgelagerte Konfiguration, Protokollierung, Zustandsprüfung usw. kümmern.
Kompliziertes Testen, da es sich als schwierig erweist, alle Einheiten zusammen zu testen
Microservices stehen in der Gunst der Software-Entwickler zurzeit weit oben und so setzen viele Technologieanbieter wie Adobe bei ihren Produkten vermehrt auf diesen Ansatz. Nicht überraschend, punktet er doch mit vielen überzeugenden Vorteilen.
Zusammenfassend kann man sagen, dass Microservices sich dann eignen, wenn das Produkt eine schnellere und unabhängige Service-Bereitstellung erfordert. Mithilfe von Microservices lassen sich innerhalb eines größeren Systems rasch unabhängige Teilsysteme integrieren. Insbesondere wenn eine Komponente äußerst gut performen muss und deshalb in einer effizienten Programmiersprache gebaut werden sollte, kann man dort den Microservice-Ansatz verfolgen. Außerdem sind kleine, separate Services einfach skalierbar. Wenn das Team/Produkt wächst, erhöht sich nicht zwingend die Komplexität, da die Teams von Beginn an durch Service-Grenzen separiert voneinander arbeiten.
Im Gegensatz dazu macht eine monolithische Architektur Sinn, wenn das Team sehr klein ist bzw. sich noch in der Gründungsphase befindet – also praktisch nicht in der Lage ist, eine komplexe Microservice-Architektur zu managen. Wenn das Team noch über keinerlei Erfahrung mit diesem Muster verfügt, ist es auch besser beraten, bei einem Monolith zu bleiben. Ferner eignet sich das monolithische Architekturmuster insbesondere für den Verprobung von neuen Produkten (Proof of Concept), wo der Lerneffekt an oberster Stelle steht.
Bei beiden Ansätzen gibt es Vor-und Nachteile. Für welchen Weg sich ein Unternehmen letztlich entscheidet, sollte jedoch immer vom eigenen Unternehmenskontext- und Nutzen abhängen. Außerdem müssen Microservices und Monolithen einander nicht zwingend ausschließen.