Microservices vs. Monolithische Architekturen: ein Leitfaden

Monolithische Software-Architekturen waren – und sind bis heute – die bevorzugte Basis bei der Entwicklung von Anwendungen und Services. Mit der digitalen Evolution im Hinterkopf erscheint das einigermaßen paradox: Monolithen sind wichtige Pfeiler der heutigen Geschäftsprozesse und erweisen sich gleichzeitig schon jetzt als enormes Hindernis, um den Anforderungen von morgen gerecht zu werden.

Was Microservices von monolithischen Systemen unterscheidet

Microservices sind kleine, einzeln lauffähige, voneinander unabhängige Services mit jeweils beschränktem Leistungsumfang. Das bringt Vorteile mit sich: Jeder Service kann einzeln deployed, implementiert, upgegradet, skaliert oder neu gestartet werden, ohne dass das große Ganze neu ausgerollt werden muss. Die Services können so schneller entwickelt, Funktionen verbessert und zur Verfügung gestellt werden. Im Zuge der Continuous-Delivery-Anforderungen sowie der Einführung agiler Entwicklungsmethoden beinahe ein Muss. Doch nicht immer gelingt das und die Einführung von Microservices erfordert einige Anstrengung.

Der direkte Vergleich zwischen monolithischen und Microservice-Ansatz zeigt folgende, wichtige Unterschiede:
Der Fokus: Während monolithische Systeme zahlreiche Funktionen für ganz unterschiedliche Business-Cases zur Verfügung stellen, konzentriert sich ein Microservice auf ein spezifisches Problem und bezieht dafür genau die Daten mit ein, die benötigt werden.

Die Integration: Traditionell bestehen Systeme aus mehreren voneinander abhängigen Komponenten, bei Deployments und ähnlichem sind diese Abhängigkeiten zu beachten und machen den Prozess aufwendig sowie langwierig. Microservices hingegen funktionieren so autark wie möglich, feste Referenzen zu anderen Services werden weitgehend vermieden.

Der Delivery-Zyklus: Updates von Applikationen werden an Terminen veröffentlicht, die in einem eher langfristigen Plan festgelegt sind, oft vierteljährlich oder noch seltener – ein typisches Merkmal monolithischer Architekturen. Microservices wollen Änderungen so schnell wie möglich an den Markt bringen. Continuous Delivery ist das Ziel – ideal für Anwendungen, deren Anforderungen sich ständig ändern.

Die Arbeit im Team: An der Entwicklung, der Pflege und dem Betrieb monolithischer Systeme sind zumeist mehrere Teams beteiligt. Programmierer schreiben den Code, Software-Tester prüfen das Ergebnis und Operations sorgt für Wartung und Betrieb. Dem stehen unabhängige Teams mit jeweils nur der Verantwortung für einen Microservice gegenüber. Die Team-Strukturen sind grundverschieden.
Das Umfeld: Monolithische Software ist etwas großes, umfassendes. Siloartige Entwicklung mit einem bestimmten Set an Tools und eigens geschaffenen Prozessen sind typisch. Eine Microservices-Architektur hängt von einer Vielzahl an Umgebungsvariablen ab: flexible Allround-Tools, skalierbare Infrastruktur, Failure-Detection-Prozesse und einiges mehr.

Einfach umswitchen geht nicht

In einem Satz: Microservices sind das genaue Gegenteil von traditioneller, monolithischer Software. Einfach zwischen beiden Ansätzen zu wechseln ist praktisch unmöglich. Unternehmen, die künftig mit Microservices arbeiten wollen, sollten zunächst mit einigen wenigen, geschäftsunkritischen Services beginnen. Denn die Veränderungen sind vielschichtig. Microservices einzuführen heißt eben nicht, eine neue Programmiersprache zu benutzen. Vielmehr ist es ein Paradigmenwechsel, der teamstrukturelle und technische Neuerungen mit sich bringt.

Sollen monolithische Strukturen aufgebrochen werden, entstehen dutzende verschiedene Services, die zwar ab sofort voneinander unabhängig entwickelt, aber ja doch irgendwie koordiniert werden müssen. Betrachtet man den gesamten bisherigen Software-Lebenszyklus – von Development über Performance- und Acceptance-Testing bis hin zu Roll-out und Betrieb – entstehen, ehe man sich versieht, zahllose Microservices, die das Operations Team kaum mehr in den Griff bekommt. Virtual Machines (VM) müssen provisioniert und gemanagt werden, das Monitoring gestaltet sich kompliziert und Ressourcen müssen den Entwicklern schnell zur Verfügung gestellt werden können. Traditionelle, gewachsene Prozesse sind dafür ungeeignet.

Wann ist ein Unternehmen bereit für Microservices?

Welche organisatorischen Herausforderungen bringt das mit sich? Der Weg hin zu einer Microservice-Architektur bringt eher organisatorische als technische Veränderungen mit sich. Vor allem die Teams müssen dazu bereit sein: Serviceorientierte, automatisierte Continuous Delivery funktioniert anders als traditionelle Ansätze. Autarke Arbeiten ohne zwingende funktionale Zusammenhänge und ein Management-Team, was dies unterstützt, sind essentiell.

Wie sollen die Services koordiniert werden? Weil Microservices nur lose miteinander gekoppelt sind, muss die Plattform dahinter einiges an Koordination leisten. Aktuelle Versionen müssen auffindbar sein, die elastische Anzahl von Service-Instanzen gemanagt werden. Datentransfer, Load Balancing und ähnliches sind nun deutlich dynamischer.

Wie lässt sich die komplexer werdende Umgebung operativ managen? Mit der wachsenden Anzahl von Microservices steigen auch die operativen Risiken. Bereits bevor sich zahllose Services auf hunderten Servern verteilen, sollten Unternehmen ein schlüssiges Konzept für die darunterliegende Infrastruktur haben: die Wahl der Plattform und der Laufumgebung, Patch- und Upgrade-Zyklen, Tracking von Abhängigkeiten und Monitoring der Aktivitäten.

Ab jetzt nur noch Microservices? Nicht jede Anwendung lässt sich in Microservices aufspalten und muss es auch nicht. Gerade Applikationen, die sich nur wenig ändern, sollten monolithisch bleiben. Microservices bringen mehr Agilität in die Entwicklung, auf Kosten einer erhöhten Komplexität. Bereits zu Beginn der Einführungsphase sollten Unternehmen deshalb ihre Applikationen danach beurteilen, wie viel Microservicing gut tut.

2013 gegründet, wird das Enterprise-Software-Start-up Pivotal heute mit 2,8 Milliarden US-Dollar evaluiert. Über 2.300 Beschäftigte und eine globale Entwickler-Community arbeiten an Pivotals Cloud-nativen Technologien. Neben dem Hauptsitz in San Francisco zählen zu den 20 Standorten in sieben Ländern Berlin und München. Unter den Kunden in Deutschland sind BMW, VW, Mercedes und die Deutsche Bank.