Sind Monolithe besser als ihr Ruf?

Wider die Microservices: Monolithe als Fundament

Michael Thomas

© Shutterstock.com/RomboStudio

Microservices sind zur Zeit in aller Munde: Vielstimmig werden sie als optimale Lösung gefeiert, um monolithische Architekturen zu überwinden. Doch mitunter sind auch gegenteilige Meinungen zu vernehmen. Martin Fowler, Urgestein der Softwareentwicklung, hat nun – basierend auf den Überlegungen zahlreicher Kollegen – zumindest eine kleine Lanze für die Monolithen gebrochen.

Grundlage von Fowlers Argumentation sind zwei von ihm häufig beobachtete Muster. Erstens: Der Großteil der erfolgreichen Microservice-Architekturen basieren auf einem Monolithen, der zu unhandlich und deshalb zerlegt wurde. Zweitens: Systeme, die sich von Grund auf auf Microservices stützen, verursachen im Grunde ebenso viele Probleme wie sie lösen. Es biete sich deshalb, wie Fowler der Ansicht zahlreicher Kollegen folgt, an, Microservices niemals als Basis zu verwenden, selbst dann nicht, wenn es absehbar ist, dass die Größe der Anwendung dies eigentlich lohnenswert machen würde.

Pro Monolith

Fowler merkt an, dass die Einführung von Microservices zunächst einen gewissen „Aufschlag“ bedeutet: Dieser besteht aus dem Aufwand, der sich durch die Verwaltung der Services ergibt und ein Team merklich bremsen kann. Besonders kleinere Projekte können demnach nach wie vor von einer monolithischen Lösung profitieren. Gleichzeitig betrachtet Fowler diesen Umstand als gutes Argument dafür, generell mit einem Monolithen zu beginnen und die Microservices erst später hinzuzufügen.

Prinzipiell sollte man zu Beginn eines Projekts die Frage stellen, ob dieses den Usern überhaupt Vorteile bringt, es also ein Flop oder potentieller Hit wird. Um es dahingehend abzuklopfen, werden häufig zunächst vereinfachte Versionen erstellt. Besonders in dieser Phase spielt die Entwicklungsgeschwindigkeit eine Rolle, weshalb man hier laut Fowler gut und gerne auf den „Aufschlag“ der Microservices verzichten kann. Ein weiteres Problem mit Microservices ist Fowlers Ansicht nach, dass die Refaktorisierung der Funktionalität zwischen den Services sich deutlich schwieriger gestaltet als bei Monolithen. Da Microservices nur dann wirklich gut arbeiten, wenn die Grenzen zwischen den Services klar abgesteckt sind und dies laut Fowler selbst für erfahrene Architekten keine einfache Aufgabe darstellt, plädiert er auch in diesem Fall dafür, mit einem Monolithen zu beginnen.

Wie kann eine Monolith-first Strategie aussehen?

Anschließend an die vorhergehenden Überlegungen stellt sich natürlich die Frage, wie man eine Microservices-freundliche Architektur auf Basis eines Monolithen am besten gestaltet. Fowler hat auf Grundlage anekdotischer Erzählungen einige Ansätze zusammengetragen:

1) Ein umsichtiges Design des Monolithen verfolgen, das von Beginn an Wert auf die Modularität der Software legt, sowohl im Hinblick auf die API-Grenzen als auch dahingehend, wie Daten gespeichert werden.

2) Ein Monolith als Herzstück der Architektur einsetzen, von dessen Rändern aus sich die Microservices nach und nach „abschälen“. Der Monolith bleibt dabei relativ untätig und unverändert, während sich der Großteil der Neuerungen in den Microservices abspielt.

3) Einen Monolithen im Sinne der von Fowler beschriebenen „Sacrificial Architecture“ komplett austauschen.

4) Ausgehend von einigen wenigen grobkörnigen Services ein Gespür für das gleichzeitige Arbeiten mit mehreren Services gewinnen und diese nach Auslotung der Grenzen in feinkörnigere Services aufspalten.

Zwar sprach sich offenbar ein Großteil von Fowlers Kontakten ungeachtet der mitunter nicht unerheblichen Herausforderungen von Monolith-first-Ansätzen für eben jene aus. Fowler selbst jedoch möchte sich derweil noch keine abschließende Meinung zum Thema bilden dafür sei die verstrichene Zeit seit Beginn des Microservices-Zeitalter noch zu kurz.

Aufmacherbild: rock monolith at night – long exposure von Shutterstock / Urheberrecht: RomboStudio

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare
  1. Joe Broccoli2015-06-15 13:40:05

    Die von Fowler geforderte eigenständige Datenhaltung eines Microserver ist in den meisten größeren Systemen meiner Meinung nach sowieso selten zu erreichen. Aus diesem Grund verstehe ich den Ansatz Monolith-First. Dennoch sehe ich für einzelne Dienste rund um einen Monolithen immer auch die Chance diese als Microservice umzusetzen. Vielleicht ist die Mischung der Architekturen eine Lösung. Ähnlich eines Marineverbands der aus unterschiedlichen Schiffsgrößen zusammengesetzt ist. So würde eine Anwendung aus dem Monolithen und mehreren Mini- bzw. Microservices bestehen. Der Monolith greift auf eine größere Datenbasis zu, Miniservices könnten sich unabhängig von Monolithen die Datenbasis teilen und Microservices haben nur ihre persönliche Datenbasis. Mit einem solchen Strauß an Diensten kann ich die größte mögliche Unabhängigkeit erreicht ohne ein wildes Netzwerk von Kommunikation zu erzwingen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.