Um eines gleich vorweg zu nehmen: Microservices sind kein Allheilmittel und nicht pauschal der richtige Weg für jedes Softwareprojekt.

Grundlagen

Modularisierung ist in der Entwicklung von Software nichts Neues. Die meisten Ansätze in der Vergangenheit beschäftigten sich damit, Software in kleinere Module zu schneiden und Code zu strukturieren. Denkt man beispielsweise an Schichtenarchitekturen, ist die Software zwar technisch gut gegliedert, fachliche Belange lassen sich daraus aber nicht ableiten. In der Welt des objektorientierten Designs spielen Klassenbibliotheken eine große Rolle. Diese ermöglichen es auch, unter Umständen fachliche Belange gut zu trennen. Wird in diesem klassischen Ansatz ein fachliches Modul in Form einer Klassenbibliothek aktualisiert, ist ein komplettes Deployment der Applikation erforderlich. Deswegen handelt es sich bei diesem Ansatz um sogenannte Deployment-Monolithen.

Zudem hat sich in der Praxis gezeigt, dass das Einhalten von Modulgrenzen bei monolithischen Anwendungen sehr schwierig ist, da aus Zeitgründen, oft schnell Klassen aus anderen Java-Packages oder .NET-Projekten genutzt werden. Abhängigkeiten können somit ungewollt recht schnell entstehen.

Modularisierung im Sinne von Microservices bedeutet, dass unabhängig deploybare Module entstehen. Microservices besitzen eigene Sourcecode-Projekte. Die Schnittstellen zwischen den Microservices sind als REST-Schnittstellen implementiert. Dies verhindert, dass sich Abhängigkeiten nicht so einfach einschleichen. Das Einhalten der Modulgrenzen wird demnach durch die Architektur erzwungen, ohne dass zusätzliche Tools dafür notwendig sind.

Microservices führen zu einer erhöhten Komplexität im Betrieb und ggf. bei Tests. Dieser zusätzlichen Komplexität stehen die im nachfolgenden Kapitel beschriebenen Vorteile, wie die bessere Modularisierung, die stärkere Entkopplung und das unabhängige Deployment, gegenüber.

Was sind Microservices?

Microservices sind ein Architekturmuster, das eine Anwendung als eine Sammlung kleiner, lose gekoppelter Services strukturiert, die zusammenarbeiten, um ein gemeinsames Ziel zu erreichen. Sie ergeben quasi gemeinsam eine Gesamtapplikation.

Jeder Teil dieser Applikation -also jeder Microservice- ist unabhängig deploybar und skalierbar. Sie arbeiten unabhängig voneinander und können deshalb auch hinzugefügt, entfernt oder aktualisiert werden, ohne andere Services der Applikation zu beeinträchtigen.

Die einzelnen Services können durch unterschiedliche Teams in unterschiedlichen Sprachen/ Technologien entwickelt bzw. getestet werden.

Dieser Architekturansatz bietet zahlreiche Vorteile, wie z. B. einfachere Bereitstellung und Tests, verbesserte Produktivität, Flexibilität und Skalierbarkeit, bringt aber auch einige Nachteile mit sich.

Monolithen

Bei einem monolithischen System gehören alle Module zu einer Applikation, die einen Lifecycle durchläuft. Üblicherweise besteht eine Anwendung aus einer Datenbank und unterschiedlichen Komponenten, die im besten Falle als fachliche Module geschnitten sind. In der Praxis sieht es meist so aus, dass die Businesslogik ordentlich in fachliche Module getrennt wird, aber um Redundanzen zu vermeiden, alle Module dasselbe Datenmodell verwenden. Technisch gesehen muss bei einer Änderungen in einem Modul die gesamte Anwendung ausgerollt werden.

Oft scheint es so, als wäre der Deployment-Monolith die bessere und unkompliziertere Wahl. Auf der einen Seite, weil nur ein System muss betrieben und ausgeliefert werden muss und auf der anderen Seite, weil man sich als Entwickler auf vertrauten Terrain bewegt.

Übliche Nachteile monolithischer Architekturen:

ausschließlich über Load Balancing skalierbar
meist schwer wartbar (viel Know-How erforderlich)
unterbrechungsfreie Deployments schwierig möglich (ggf. für dieses Vorhaben nicht entscheidend!)
Entwicklung mit mehreren Teams ist ineffizient
hohen Abstimmungsbedarf

Microservices

Es gilt zu beachten, dass der Microservices Architekturansatz entstanden ist, um reale Probleme in der Softwareentwicklung zu lösen. Dieser Architekturansatz ist nicht theoretischer Natur. Aus meiner Erfahrung heraus haben Microservices folgende Vorteile:

einfaches und schnelles Deployment
Risikominimierung (Änderungen betreffen nur ein Modul)
ggf. Verringerung des Testaufwandes
Technologiefreiheit (vor allem wichtig, wenn das System langfristig weiterentwickelt werden soll; bei Monolithen hat sich fast immer gezeigt, dass die Umstellung auf eine aktuellere Technologie/Framework unmöglich ist und dann nur eine gesamte Neuentwicklung in Frage kommt; Microservices lassen sich hingegen einzeln migrieren)
neue Features können bei Ressourcenknappheit auch leichter an neue Mitarbeiter übergeben oder externe Dienstleister beauftragt werden (Komplexität des Gesamtsystems etc. muss nicht bekannt sein)
autonomes Arbeiten möglich
technische Koordination auf ein Mindestmaß reduziert
unabhängiges Skalieren der Dienste

Für und Wider

Argumente für eine monolithische Anwendung sind dann gegeben, wenn zu erwarten ist, dass die Anwendung eher klein bleiben wird und zukünftig wenig Änderungen und Erweiterungen zu erwarten sind. Ist das Gegenteil der Fall, dann spricht das eher für verschiedene Microservices.

Ist also davon auszugehen, dass es sich um eine komplexe Anwendung handeln wird, die stetig neuen oder geänderten Anforderungen ausgesetzt sein wird, sollte eine nähere Prüfung stattfinden, ob eine Microservices Architektur geeignet ist.

Subscribe now

INUVEON

Microservices Architekturen