Vom Monolithen zu Microservices – (k)eine Selbstverständlichkeit Wann ist eine Microservice-Architektur sinnvoll?

Microservices sind aktuell State of the art, wenn es um Architekturentscheidungen geht. Doch löst der Einsatz von Microservices alle Probleme? Und welche Herausforderungen birgt der Schwenk vom Monolithen auf eine Microservice-Architektur?

Die einschlägige Literatur verspricht viele Vorteile von Microservices, wenn diese richtig eingesetzt werden. Der Weg zu einem funktionierenden Geflecht aus Microservices kann jedoch ein sehr beschwerlicher sein. Soll eine bereits bestehende monolithische Altapplikation durch eine neue, auf Microservices basierende Applikation abgelöst werden, gilt es viele Herausforderungen zu meistern.

Hierbei sind nicht nur technische Aspekte zu beachten – wie die Auswahl einer tragfähigen zukunftssicheren Architektur für die neue Applikation – sondern auch, dass die bestehende Applikation nicht in einem „Big-Bang“ abgelöst werden kann. Vielmehr ist meistens nur eine schrittweise Ablösung von zusammenhängenden Funktionen oder Teilmodulen der Altapplikation durch eine Neuimplementierung möglich.

Dies hat zur Folge, dass der Umstieg einen Parallelbetrieb von Alt- und Neuapplikation beinhaltet – und damit erhöhte Kosten für Betrieb, Infrastruktur und so weiter. Darüber hinaus gilt es, organisatorische Aspekte und kulturelle Themen zu berücksichtigen. Daher ist im Vorfeld gut abzuwägen, in welchen Bereichen sich der Einsatz von Microservices wirklich lohnt.

Insbesondere bei der Ablösung einer bestehenden monolithischen Applikation will dieser Schritt gut überlegt und geplant sein. Dieser Beitrag beleuchtet die Herausforderungen, die ein Umstieg von einem Monolithen zu einer Microservice-basierten Architektur mit sich bringt. Zuerst werden die beiden unterschiedlichen Architekturansätze beschrieben und anschließend aufgezeigt, in welchen Szenarien sie am besten geeignet sind.

Auch Monolithen haben ihre Vorteile

Monolithen zeichnen sich dadurch aus, dass die gesamte Applikation beziehungsweise das System einem einzigen Deployment unterliegt. Dazu müssen alle Komponenten des Monolithen zusammengefasst und gleichzeitig bereitgestellt werden.

Das Ergebnis ist eine Applikation, die als ein Prozess ausgeführt wird. Dabei kann sich die zugrundeliegende Code-Basis dahingehend unterscheiden, dass überhaupt keine Trennung der Business-Logik vorhanden ist oder einzelne Logikblöcke in Module getrennt sind. Die Trennung (beziehungsweise Dekomposition) kann im letzten Fall unterschiedlich stark ausgeprägt sein.

Im Zuge der Service-orientierten Architektur wurde begonnen, die einzelnen Module als Services zu betreiben. Allerdings war weiterhin ein gemeinsames Deployment erforderlich. Unter technischen Gesichtspunkten zeichnen sich Monolithen dadurch aus, dass ihnen eine strikte Trennung auf Code-Basis fehlt.

Das hat zum einen zur Folge, dass der einer Funktionalität zugrundeliegende Code an vielen Stellen aufgerufen und damit von vielen unterschiedlichen Entwicklern bearbeitet wird. Zum anderen kann es passieren, dass kein Entwickler sich für eine bestimmte Funktionalität beziehungsweise den dazugehörenden Code verantwortlich fühlt.

Trotz der genannten Nachteile haben Monolithen auch Vorteile: Der Deployment-Prozess ist in der Regel deutlich einfacher und beinhaltet weniger Fallstricke als bei verteilten Systemen. Für die Überwachung und Fehlerverfolgung trifft das gleiche zu. Auch ein Ende-zu-Ende-Test lässt sich einfacher realisieren, wenn nur eine Komponente beteiligt ist. Eine Wiederverwendung von Code ist ohne großen technischen Aufwand möglich.

Microservice-basierte Architekturen können hohe Komplexität beinhalten

Im Gegensatz zu Monolithen besteht eine auf Microservices basierende Architektur aus unabhängig voneinander deploybaren Services, die sich rund um Geschäftsfelder und -bereiche entwickeln lassen. Die Kommunikation zwischen den einzelnen Services erfolgt über das Netzwerk. Die gesamte Applikations- und Systemlogik entsteht durch das Zusammenspiel der einzelnen Microservices.

Microservices zeichnen sich darüber hinaus im Wesentlichen durch die folgenden Punkte aus:

• Technologische Unabhängigkeit

• Unabhängige Deploybarkeit

• Geschäftsbereichsorientierung

• Kontrolle über die eigenen Daten

• Verantwortlichkeit für den Code

Insbesondere die Kommunikation über das Netzwerk zwischen den einzelnen Microservices kann schnell zu einer Herausforderung werden. Latenzzeiten verlangsamen die Kommunikation und können bis hin zu Netzwerkausfällen führen. Dies erfordert eine zusätzliche Absicherung der einzelnen Microservices in puncto Transaktionssicherheit und trägt somit maßgeblich zur Erhöhung der Komplexität bei.

Die größten Vorteile entstehen durch die Aufteilung der Funktionalitäten in unabhängige Einheiten. An diesen können unterschiedliche Teams parallel arbeiten, es ist für sie eine zur Funktionslogik passende Technologie wählbar und sie lassen sich zu unterschiedlichen Zeitpunkten veröffentlichen.

Fragen und Entscheidungen im Vorfeld

Wie alle Vorhaben sollte auch hier mit einer Frage begonnen werden. Doch die Frage lautet nicht: „Warum wollen wir Microservices einsetzen?“ Diese Frage würde nämlich bereits die Lösung vorwegnehmen und die Prämisse setzen, dass Microservices das „Allheilmittel“ sind – mit dessen Hilfe sich alle Probleme, Defizite und sonstige widrige Umstände beheben lassen.

Der Einstieg in das Thema sollte so lange wie möglich technologieneutral bleiben. Die erste Frage sollte also lauten: „Was wollen wir in Zukunft erreichen, welches Ziel haben wir?“ Um nicht bereits in der Anfangsphase auf einen Holzweg zu gelangen, schließt sich die folgende Frage an: „Welche Alternativen zu Microservices gibt es – und wurden diese ausreichend berücksichtigt?“ Jedes Unternehmen ist unterschiedlich und verfolgt andere Ziele. Daher gibt es auch nicht die „eine“ Lösung.

Für die Entscheidungsfindung bei der Architektur sind insbesondere die folgenden Kriterien relevant:

Ziele, die sich gut mit Microservices erreichen lassen:

• Verbesserung der Teamskalierbarkeit und -autonomie

• Verkürzung der Entwicklungszyklen

• Bessere Skalierbarkeit einzelner „Module“ und Microservices

• Verbesserung der Robustheit und Reduzierung von Ausfällen

• Nutzung neuer Technologien und Modernisierung des Systems

Gründe, die gegen den Einsatz von Microservices sprechen:

• Kleine Systeme mit geringer Komplexität

• Zusammenhängende Funktionen und Daten

• Performanz-kritische Systeme

• Lange Änderungszyklen

• Unklare Geschäftsbereichsgrenzen und -zuständigkeiten

Bei einem genaueren Blick auf die Gründe, die für oder gegen eine Transition von einem Monolithen zu einer Microservice-basierten Architektur sprechen, wird deutlich, dass sich diese in zwei Kategorien einteilen lassen: Organisationsbezogene und technikbezogene Faktoren. Nur wenn beide Kategorien berücksichtigt werden, kann eine Transition funktionieren und nachhaltig erfolgen.

Sowohl organisations- als auch technikbezogene Faktoren sind entscheidend

Im Zusammenhang mit den organisationsbezogenen Gründen lohnt es sich, einen Blick auf Conways Gesetz zu werfen, das immer noch Gültigkeit besitzt. Demnach wird jede Organisation, die ein System entwirft, ein System erzeugen, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation entspricht. Im Zusammenhang mit der Eigenschaft, dass sich Microservices an den Geschäftsbereichen der Organisation orientieren, wird schnell klar, dass eine monolithische Organisation sich schwer tun wird, eine Microservice-basierte Architektur ins Leben zu rufen.

Ist die Entscheidung für eine Transition gefallen, sollte berücksichtigt werden, dass diese nicht – wie bereits anfangs erwähnt – in einem großen Schritt, sondern iterativ angegangen werden sollte. Das ermöglicht es, aus vorangegangenen Schritten zu lernen und die Vorgehensweise anzupassen.

Das weitere Vorgehen aus technologischer Sicht hängt davon ab, ob der zu überführende Monolith verändert werden kann. Eine Änderung kann zum Beispiel nicht möglich sein, wenn:

• Es sich um ein Kaufprodukt handelt, für das kein Sourcecode vorliegt;

• die einsetzte Technologie nicht mehr in der Organisation beherrscht wird;

• der Monolith in so schlechtem Zustand ist, dass eine Änderung viel zu teuer werden würde.

Ist die Prämisse gegeben, dass der Sourcecode vorliegt und mit diesem gearbeitet werden kann, gibt es grundsätzlich drei Möglichkeiten:

• Den Code umziehen

• Den Code kopieren

• Die Funktion neu implementieren

Generell ist es sinnvoll, die vorhandene Funktionalität und den damit verbundenen Code im Monolithen in einem ersten Schritt bestehen zu lassen, um eine Fall-back-Alternative zu haben oder beide Implementierungen parallel nutzen zu können.

Eine weitere Herausforderung ergibt sich dadurch, dass monolithischer Code in den meisten Fällen technisch organisiert ist und sich nicht an Geschäftsbereichen orientiert, wie es bei Microservices angestrebt wird. Daher kann es schwierig sein, die richtigen Codestellen zu identifizieren. Dies erfordert eine Neustrukturierung. In einigen Fälle ist es an dieser Stelle sogar ausreichend, den Monolithen neu zu strukturieren, in einzelne Module zu zerlegen und diese entwicklungs- sowie deployment-seitig zu entkoppeln.

Im Falle einer Transition sollte der betroffene Code aus dem Monolithen in einen Microservice überführt werden. Nach Überführung stehen beide Implementierungen parallel zur Verfügung. Durch ein Umleiten lässt sich der Aufruf dieser Funktionslogik dahingehend steuern, ob wahlweise der Funktionsblock im Monolithen oder der Microservice genutzt wird.

Bevor die Umsetzung beginnt, ist es wichtig, nicht nur die Gründe und die damit verbundenen Ziele einer Migration auf eine microservice-basierten Architektur zu betrachten, sondern auch eine Priorisierung der Ziele vorzunehmen. Die Migration an sich ist in der Regel zu komplex, um Kapazitäten auf unnötig zu „verschwenden“.

Fazit: Der Schritt hin zu Microservices will gut überlegt sein

Die Migration von einem Monolithen zu einer Microservice-basierten Architektur ist eine große Herausforderung. Sie sollte daher gut überlegt und geplant werden. Nicht in jedem Fall sind Microservices sinnvoll oder können die bestehenden Defizite eines Monolithen beheben.

Es kann sehr wohl angezeigt sein, sich auf die wesentlichen Defizite – wie fehlende Modularisierung – innerhalb der bestehenden Applikation zu konzentrieren und jene anzugehen. Microservices bringen Komplexität und Geschäftsbereichsorientierung mit sich, für die nicht jedes Unternehmen richtig aufgestellt ist.

* Dr. Lothar Grünz ist seit 2015 als Programm Manager und SCRUM Master bei der AUSY Technologies Germany AG tätig. Seine Schwerpunkte liegen unter anderem in den Bereichen Softwareentwicklung, Anforderungsmanagement und IT-Prozessmanagement.

(ID:47267457)