Monolithen vs. Microservices

Ein Überblick zu Vor-und Nachteilen

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.

Monolithen vs. Microservices

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.