Monolith vs. Microservices

In der Softwarearchitektur gibt es im Grunde zwei verschiedene Design Ansätze, Monolith und Microservices. Beide Architekturstile haben ihre Daseinsberechtigung. Welcher Ansatz der Passende ist, sollte von Projekt zu Projekt neu entschieden werden. Um einen ersten Überblick über das Thema Architektur zu bekommen, werden in diesem Blogartikel beide Ansätze kurz vorgestellt und deren Unterschiede aufgezeigt.

Monolith

Eine monolithische Anwendung besteht aus einer Einheit. Sowohl die horizontalen Ebenen, wie Benutzeroberfläche, Anwendungslogik oder Datenbankzugriff, als auch die vertikalen Ebenen, wie die Umsetzung der einzelnen Funktionalitäten, werden innerhalb eines Programms entwickelt. Während diese Art der Anwendungsentwicklung früher gebräuchlich war, verbreitete sich in den letzten Jahren, vor allem im Bereich der Webentwicklung, ein neuer Architekturstil, die sogenannte Microservices-Architektur.

Microservice

Eine einheitliche Definition des Begriffes Microservice gibt es in der Literatur nicht. Ein Microservice ist ein kleines, eigenständiges Programm, welches genau eine Aufgabe hat bzw. sich mit genau einem Problem beschäftigt. Dabei ist nicht vorgegeben, was „klein“ bedeutet. Anstatt ein Projekt in einem einzigen, großen Monolithen umzusetzen, werden mehrere, kleinere Services entwickelt, die sich gegenseitig zuarbeiten. Sam Newman beschreibt diesen Architekturstil als einen Ansatz für verteilte Systeme.

Unterschiede

Die Idee von Microservices ist, bestimmte Anwendungen in kleinere Stücke zu unterteilen. Diese können voneinander unabhängig entwickelt werden. Die Microservices-Architektur bietet eine Reihe von Vorteilen gegenüber dem monolithischen Ansatz. Microservices sind leichter zu entwickeln und zu warten. Jedes Team ist für seinen Service selbst verantwortlich und es gibt keine gemeinsame Codebasis. Das bringt auch den Vorteil, dass die Microservices mit unterschiedlichen Technologien arbeiten können. Außerdem läuft das Deployment von Microservices einzeln, sodass bei Änderungen in einem bestimmten Teilbereich nicht die komplette Anwendung neu auf dem Server eingerichtet werden muss. Das sind zum Großteil die Vorteile, die verteilte Systeme mit sich bringen. Allerdings gibt es bei diesem Architekturstil auch einen Nachteil. Durch die Verteilung der Ressourcen entsteht eine höhere Komplexität. Für einen Datenaustausch zwischen den Microservices ist Kommunikation über das Netzwerk notwendig.

Verbreitung und Nutzung

Die Idee, ein Projekt in Teilprojekte aufzuspalten, ist nicht neu. Früher gab es mit der serviceorientierten Architektur (SOA) bereits einen ersten Ansatz für verteilte Systeme. Dieser Ansatz konnte sich allerdings nicht durchsetzen, denn es fehlte am allgemeinen Verständnis, wie SOA anzuwenden ist. Dass sich das Konzept von Microservices in den letzten Jahren durchsetzen konnte, liegt an der Vielzahl vorangegangener Entwicklungen. Kleine, eigenständige Teams die jeweils ein eigenes Teilprojekt entwickeln, Continious Delivery für eine schnellere Bereitstellung neuer Funktionalitäten und die Notwendigkeit von skalierbaren Systemen haben die rasante Entwicklung und Verbreitung von Microservices unterstützt.

Martin Fowler beschreibt in einem Artikel den monolithischen Ansatz als den natürlichen Weg der Entwicklung. Jede neue Anwendung sollte erst einmal als Monolith geplant und entwickelt werden. Bei ausreichend Komplexität des Systems kann später durch Aufspalten des Monolithen in eine Microservices-Architektur übergegangen werden. Bei einer Neuentwicklung ist die Software klein, übersichtlich und gut zu warten. Erst beim weiteren Entwickeln erhöht sich die Komplexität, sodass über eine Aufspaltung des Monolithen nachgedacht werden kann.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.