Microservices-Architekturen und monolithische Architekturen im Vergleich

Microservices-Architekturen sind ein wichtiger Software-Trend, der nicht nur tiefgründige Auswirkungen auf die Unternehmens-IT, sondern auch auf die digitale Transformation des gesamten Unternehmens haben kann.

Doch worin bestehen die Unterschiede zwischen einer Microservices-Architektur und einer monolithischen Architektur? Tech-Giganten wie Netflix, Google und Amazon setzen auf Microservices-Architekturen. Da stellt sich die Frage, welche Vorteile eine solche Architektur bietet.

Vergleichen wir Microservices- und monolithische Architekturen zunächst einmal miteinander. Eine monolithische Anwendung wird als einzelne Einheit entwickelt. Unternehmensanwendungen bestehen aus drei Komponenten:

• Datenbank – Sie besteht aus vielen Tabellen, in der Regel in einem relationalen Datenbanksystem.
• Clientseitige Benutzerschnittstelle – Sie besteht aus HTML-Seiten und/oder JavaScript, die in einem Browser ausgeführt werden.
• Serverseitige Anwendung – Sie wickelt HTTP-Anfragen ab, führt die domänenspezifische Logik aus, ruft Daten aus der Datenbank ab und aktualisiert diese. Außerdem füllt sie die HTML-Ansichten, die an den Browser gesendet werden sollen.

Genau deshalb ist diese Architektur monolithisch – es handelt sich um eine einzige logische ausführbare Datei. Für Änderungen am System müssen Entwickler:innen eine aktualisierte Version der serverseitigen Anwendung erstellen und deployen.

Im Gegensatz zu einer monolithischen Architektur werden Microservices-Funktionen formal durch Business-orientierte APIs angeboten. Sie umfassen eine zentrale Business-Funktion. Die Implementierung des Service umfasst mitunter Integrationen mit Datensystemen und ist komplett verborgen, da die Schnittstelle gänzlich aus geschäftlicher Sicht definiert wird.

Da Services als wertvolle Business-Assets aufgestellt sind, gelten sie implizit als anpassungsfähig für den Einsatz in verschiedenen Zusammenhängen. Die Funktionen eines Services sind für mehrere Business-Prozesse und über verschiedene Business-Kanäle oder digitale Touchpoints hinweg wiederverwendbar.

Abhängigkeiten zwischen Services und deren Nutzer:innen werden durch das Prinzips der losen Kopplung minimiert. Durch die Standardisierung von Kontrakten in Form Business-orientierter APIs werden Nutzer:innen nicht durch Änderungen am Service selbst beeinträchtigt. So können die Service-Verantwortlichen die Implementierung sowie die eventuell hinter der Schnittstelle liegenden Aufzeichnungssysteme oder Dienstekompositionen verändern und ohne Auswirkungen auf nachgelagerte Prozesse ersetzen.

Traditionelle Software-Entwicklungsprozesse (Wasserfall, Agile etc.) erfordern in der Regel, dass relativ große Teams an einem einzelnen, monolithischen Deployment-Artefakt arbeiten. Projektmanager:innen, Entwickler:innen und betriebliche Mitarbeitende sind in der Lage, mit diesen Modellen verschiedene Erfolge zu erzielen und Anwendungskandidaten zu bestimmen, die vom Unternehmen getestet werden können. Dies gilt insbesondere dann, wenn die Erfahrung mit einer bestimmten Software oder einem Deployment Stack zunimmt. Diese traditionellen Ansätze bergen jedoch einige grundlegende Probleme:

• Monolithische Anwendungen können sich zu einem „Big Ball of Mud“ entwickeln; eine Situation, in der unter den Entwickler:innen (oder einer Gruppe von Entwickler:innen) niemand die Gesamtheit der Anwendung versteht.
• Bei monolithischen Anwendungen gibt es nur sehr begrenzte Wiederverwendungsmöglichkeiten.
• Das Skalieren monolithischer Anwendungen kann eine Herausforderung sein.
• Betriebliche Agilität ist bei der wiederholten Implementierung monolithischer Anwendungsartefakte nur schwer erreichbar.
• Definitionsgemäß erfolgt die Implementierung monolithischer Anwendungen mithilfe eines einzelnen Entwicklungsstacks (zum Beispiel JEE oder .NET). Dies kann die Verfügbarkeit des passenden Tools für die jeweilige Aufgabe einschränken.

Microservice-Architekturen bieten in Kombination mit Cloud-Deployment-Technologien, API-Management und Integrationstechnologien eine alternative Methode für die Software-Entwicklung. Der Monolith wird stattdessen in eine Reihe von eigenständigen Services aufgeteilt, die unabhängig voneinander entwickelt, implementiert und verwaltet werden. Dies hat folgende Vorteile:

• Services werden im Idealfall von einer Handvoll Entwickler:innen konzipiert und haben im Normalfall einen geringen Umfang.
• Durch Sprachanbindungen und gemeinsame Bibliotheken ist es möglich, Services von anderen Services und Anwendungen ohne direkte Kopplung zu nutzen und wiederzuverwenden.
• Services bestehen als unabhängige Implementierungsartefakte und können unabhängig von anderen Services skaliert werden.
• Da Services separat entwickelt werden, können Entwickler:innen das passende Framework für die jeweilige Aufgabe nutzen.

Der Nachteil dieser Flexibilität ist die erhöhte Komplexität. Die skalierte Verwaltung mehrerer dezentraler Services ist insbesondere aus den folgenden zwei Gründen schwierig:

1. Projektteams müssen potenzielle Services für die Wiederverwendung problemlos finden können. Diese Services sollten Dokumentation, Testkonsolen usw. enthalten, denn dadurch wird Wiederverwendung statt Neuentwicklung zu einer attraktiveren Option.
2. Abhängigkeiten zwischen Services müssen genau überwacht werden. Ausfälle, Upgrades und andere Unterbrechungen der Services können Kettenreaktionen auslösen, die proaktiv analysiert werden sollten.

Es ist wichtig, dass Sie die Einführung Ihrer Microservices sorgfältig verwalten und den SDLC in größtmöglichem Umfang automatisieren. Eine mangelnde Teamkoordinierung und Automatisierung im DevOps-Stil führen dazu, dass Ihnen Ihre Microservices-Initiative mehr Sorgen als Vorteile bringen wird.

Möchten Sie Microservices einführen? Lesen Sie unseren Leitfaden zu den Best Practices für die Entwicklung von Microservices.