Microservices ersetzen den Monolithen
Ameisenprinzip
Microservices erfreuen sich enormer Beliebtheit und haben sich über die Jahre weit verbreitet. Mittlerweile gelten sie häufig schon als Standardarchitekturansatz. Dieser Artikel wirft einen Blick auf den aktuellen Stand der Technik.
Microservices [1, 2] sind ein Ansatz für die Modularisierung von Softwaresystemen. Statt die Module nur im Sourcecode zu trennen, ist jedes Modul zur Entwicklungszeit ein eigenes Deployment-Artefakt und zur Laufzeit ein eigener Prozess. Zur besseren Isolation der einzelnen Module haben sich mittlerweile Docker-Container durchgesetzt. Sie versehen die Prozesse mit eigenen Dateisystemen. Das ermöglicht zum Beispiel, auf einem Red-Hat-Linux-System einen Docker-Container laufen zu lassen, der eine Ubuntu-Linux-Distribution enthält. Außerdem lassen sich Konfiguration und Bibliotheken der Microservices konsequent voneinander trennen. Daneben hat jeder Docker-Container eine eigene IP-Adresse, sodass er von anderen auch in Bezug auf das Netzwerk separiert ist.
Independent Systems Architecture
Aus dieser anderen Umsetzung von Modulen ergeben sich zahlreiche Vorteile. Die Independent-Systems-Architecture-Prinzipien (ISA, siehe ix.de/ix1904042, [6]) zeigen auf, wie einige Best Practices erlauben, den maximalen Nutzen aus Microservices zu ziehen. Als Motiv für Microservices sieht ISA die stärkere Entkopplung der Systemkomponenten. Der Entwickler kann viele technische Entscheidungen für jedes Modul einzeln treffen. Es ist beispielsweise denkbar, für jeden Microservice die am besten passende Programmiersprache zu verwenden. Die Makroarchitektur enthält alle Entscheidungen, die alle Module betreffen. Die Mikroarchitektur umfasst Entscheidungen, die sich in jedem Microservice anders treffen lassen. Wesentliche Bestandteile der Makroarchitektur sind etwa die Mechanismen zur Integration und Kommunikation, wie REST, über die Module erst ein Gesamtsystem bilden.
Unabhängige Continuous-Delivery-Pipelines sind ein wichtiges Konzept, um tatsächlich jeden Microservice unabhängig von den anderen in Produktion bringen zu können. Ein Feature lässt sich in einem Microservice implementieren und anschließend ohne große Koordination produktiv bringen.
Microservices in der Praxis
Inzwischen sind Microservices im Architekturalltag angekommen. Oft sind sie der Ansatz, mit dem man heute eben Systeme baut. Das weißt auch gleich auf ein Problem hin: Jede Architektur ist ein Trade-off zwischen Vor- und Nachteilen. Das gilt auch für Microservices. So steht der stärkeren Entkopplung ein höherer Aufwand im Betrieb gegenüber, weil viel mehr Prozesse laufen und überwacht werden müssen. Andererseits gibt es eine breite Auswahl an Literatur, Beratung und Trainings, die Microservices-Konzepte vermitteln. Erfahrungsberichte zu Projekten helfen, Fallen zu vermeiden. Viele ausgereifte Methoden sowie kommerzielle und Open-Source-Software dienen als zusätzliche Unterstützung.
Microservices kommen heute in zahlreichen neuen Projekten von Anfang an als Architekturmuster zum Einsatz und stellen eine langfristige Modularität und Evolutionsfähigkeit sicher. Ob es grundsätzlich sinnvoller ist, direkt mit Microservices zu starten oder besser zunächst einen Monolithen zu entwickeln, ist umstritten [6].
Wie groß sind Microservices?
In vielen Projekten lösen Microservices einen bereits bestehenden, zu komplizierten und schwerfälligen Deployment-Monolithen ab. Häufig passiert das in vielen einzelnen Schritten. Bei einer solchen Migration entstehen zahlreiche Herausforderungen, die oft erst über mehrere Jahre hinweg adressiert werden können.