Alexander Serowy adesso AG

„Unternehmen sollten immer abwägen, ob ein Neubau nicht sinnvoller als eine Überführung wäre, da die Vorteile einer Überführung eher in Randfällen zum Tragen kommen.“

Microservices-Architekturen sind heute in aller Munde. Die Vorteile sind groß, die Anforderungen an die zuständigen Teams in einem Unternehmen allerdings auch. Neben der Frage nach den Grundvoraussetzungen, die ein Team mitbringen muss, um Microservices nachhaltig umsetzen und betreiben zu können, gilt es auch zu klären, ob ein Monolith in Microservices überführt werden kann und sollte.

Bei der Überführung eines Monolithen in Microservices muss man eine ganze Menge bedenken; im Folgenden soll betrachtet werden, ob eine Auslagerung überhaupt sinnvoll ist und – falls ja – wie bei der Überführung vorgegangen werden sollte. Dazu werden wir klären, nach welchen Kriterien die Reihenfolge der Services bestimmt, ob Code wiederverwendet und wie mit Abhängigkeiten umgegangen werden sollte. Der Überführungsprozess umfasst insgesamt also einen Rahmen von der Auswahl der Architektur bis zur Produktivstellung und wird in diesem Artikel anhand des Beispiels einer Verwaltungssoftware für Autowerkstätten verdeutlicht.

Was spricht für eine Microservices-Architektur?

In großen Projekten setzen Unternehmen immer häufiger mehrere Teams ein. Microservices-Architekturen bieten hier den Vorteil, dass einzelne Teams autonom einzelne Services umsetzen können. Da die Architekturen der Services spezifischer auf die geforderten Anwendungsfälle der Domäne ausgerichtet werden können, ist der Abstimmungsaufwand geringer und die Qualität der jeweiligen Projekte wird gesteigert. Darüber hinaus ermöglichen es diese in sich geschlossenen Systeme, Anforderungen einfacher umzusetzen, da Anforderungsdomänen deutlich strikter getrennt sind und so Codegröße und -komplexität deutlich kleiner und einfacher sind. Diese Anforderungen können durch Verteilung und unterstützte Updateprozesse der einzelnen Umgebungen wie Azure Service Fabric im laufenden Betrieb ausgeliefert werden. Neben den genannten Vorteilen bieten die Umgebungen darüber hinaus einfache Wege, die Applikation nicht nur vertikal, sondern auch horizontal zu skalieren. Architekten sollten neben der Architektur auch ausgelagerte externe Dienste wie Caching und Datenbanken nutzen, um eine einfache Skalierung weiter zu forcieren.

Warum auf einmal dieser Hype?

Die Fallacies of Distributed Computing beschreiben Trugschlüsse, die wesentlich bei der Betrachtung und Abgrenzung von Microservices und Monolithen sind. Die eigentliche Komplexität einer Microservices-Architektur versteckt sich nicht in, sondern neben und unter den einzelnen Services. So sorgt zum Beispiel die Kommunikation zwischen den einzelnen Services mit nicht ausfallsicheren Verbindungen, Latenz, Bandbreite, sich ändernden Standards/Topologien, Overhead und nicht homogenen Netzwerken für eine erhöhte Störanfälligkeit im Vergleich zu Monolithen. Diese Anfälligkeiten können programmatisch nur mit hohem Zeitaufwand und Expertise gemindert werden.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 10.18 - "Volle Cloud voraus?"

Alle Infos zum Heft
579857786Einen Monolithen in Microservices überführen
X
- Gib Deinen Standort ein -
- or -