Replatforming: Mit Microservice-Architektur zu mehr Wettbewerbsfähigkeit in digitalen Märkten

Unter Replatforming verstehen wir unterschiedliche Formen der Modernisierung von Softwaresystemen. Eine besonders wichtige und derzeit angesagte Variante des Replatforming ist die Überführung in Microservice-Architekturen. Zu den Vorteilen einer solchen Architektur gehören Merkmale wie Flexibilität, Skalierbarkeit, Technologieunabhängigkeit und Ausfallsicherheit. Vorteile, die eine entscheidende Rolle für die Wettbewerbsfähigkeit in digitalisierten Märkten spielen.

In der Theorie sind Technologien und Methoden für die Entwicklung Microservice-basierter Softwaresysteme ausführlich beschrieben. Wir zeigen Ihnen anhand eines einfachen praxisnahen Anwendungsbeispiels, wie die Vorteile einer Microservice-Architektur realisiert werden.

Einfache Modularisierung durch Microservice-Architekturen

Bei unserem Anwendungsbeispiel handelt es sich um eine Webanwendung für eine fiktive Bibliothek. Eine Modularisierung der Anwendung kann z. B. gemäß ihrer Fachlichkeit (bounded contexts) erfolgen: Kundenverwaltung, Bestandsverwaltung, Ausleihe und Mahnwesen.

Kurze Release-Zyklen = hohe Flexibilität

Die Module werden durch Microservices realisiert. Bereits hier wird deutlich, wie sich dieser Ansatz vorteilhaft für den Entwicklungsprozess auswirkt: Es wird eine agile, parallele Entwicklung mit kurzen Release-Zyklen ermöglicht (siehe Abbildung). Sowohl in Bezug auf neue Releases als auch Fehlerbehebungen verkürzt sich die Time-to-Market und die Kundenakzeptanz steigt.

Gleichzeitig erlauben die kurzen Release-Zyklen eine hohe Flexibilität bei der Organisation des Entwicklungsprozesses: Je schneller und häufiger Releases erfolgen, desto öfter können weitere Features und Verbesserungen veröffentlicht werden. Diese Dynamik wird von engagierten Entwicklerteams sehr geschätzt. Durch stetige Revision des gesamten Systems verlangsamt sich der Alterungsprozess der Software und es entstehen weniger technische Schulden.

Mehr Autonomie erreichen

In unserem Beispiel der fiktiven Bibliothek ist es möglich, große Teile der Microservices für die Kunden- und Bestandsverwaltung unabhängig von Ausleihe und Mahnwesen in Betrieb zu nehmen. Was daran liegt, dass wichtige Anwendungsfälle der Kunden- und Bestandsverwaltung weitgehend unabhängig von Ausleihe und Mahnwesen sind. So können beispielsweise Bücher inventarisiert oder Kundinnen und Kunden angelegt werden, ohne dass das Mahnwesen involviert ist. Domain Driven Design fokussiert auf diese Aspekte.

Ein weit verbreitetes Muster, um größtmögliche Autonomie von Microservices sicherzustellen, ist die lose Kopplung. Erreicht wird dies unter anderem durch asynchronen Austausch von Nachrichten (Events) über sogenannte Topics. Man spricht hier auch von Event-Driven Architecture. Vereinfacht kann man darunter die Veröffentlichung und den Empfang von Nachrichten zwischen Microservices verstehen. Sender und Empfänger sind nur über ein Topic miteinander verbunden, direkte Aufrufe von Methoden der Microservices erfolgen nicht.

Wurde in der Beispielanwendung ein Buch in der Bestandsverwaltung inventarisiert, veröffentlicht der Microservice eine entsprechende Nachricht in dem dafür vorgesehenen Topic. Da die Bestandsänderung für den Microservice „Ausleihe“ relevant ist, abonniert die Ausleihe Nachrichten von diesem Topic.

Ausfallsicherheit als Vorteil von microservicebasierten Systemen

Asynchrone Kommunikation ermöglicht einen weiteren wichtigen Vorteil microservicebasierter Systeme: die Ausfallsicherheit. In verteilten Systemen kommt es im Betrieb immer wieder zum Ausfall von Komponenten. Bei der asynchronen Kommunikation über Topics ist dagegen sichergestellt, dass Nachrichten, die ein Topic erreichen, an registrierte Empfänger zugestellt werden, auch wenn diese zeitweise nicht verfügbar sind. Hierbei ist entscheidend, dass die Infrastruktur für den Nachrichtenaustausch hochverfügbar ist. Moderne Systeme wie Kafka stellen Ausfallsicherheit durch Redundanz und Verteilung her.

Ist die Verfügbarkeit der Infrastruktur sichergestellt, verzögert sich bei einem Ausfall eines Microservice zwar die Verarbeitung von Nachrichten, es kommt aber nicht zu einem Nachrichtenverlust. Durch die asynchrone Kommunikation über Topics ist es daher auch möglich, einzelne Microservices im Produktivbetrieb ohne Ausfallzeit zu ersetzen. Was ein bedeutender Vorteil gegenüber monolithischen Systemen darstellt, die in der Regel nur als Ganzes ausgetauscht werden können.

Bei der Verwendung von Kafka-Topics erhält ein Empfänger erst dann Nachrichten, wenn er dazu bereit ist (pull Prinzip). Ein Push, was einen bereits ausgelasteten Microservice überlasten könnte, erfolgt nicht. Werden Nachrichten insgesamt zu langsam verarbeitet, wird dies automatisch erkannt und durch Aktivierung von zusätzlichen Instanzen der betroffenen Microservices beschleunigt.

Lastverteilung schafft Skalierbarkeit und senkt Betriebskosten

Bei dynamisch veränderlichen Lastanforderungen kommt es häufig vor, dass Softwaresysteme an ihre Belastungsgrenze kommen und die anfallenden Nachrichtenmengen kaum mehr bewältigen können. Microservicebasierte Systeme sind besonders gut skalierbar: Treten für einzelne Komponenten Lastspitzen auf, wird dies von modernen Container-Managementsystemen wie Kubernetes automatisch erkannt. Weitere Microservice-Instanzen werden dann gezielt zusätzlich aktiviert, um die Last effizienter zu verteilen. Analog werden Instanzen bei zu geringer Auslastung wieder deaktiviert.

Durch den automatisierten und bedarfsgerechten Einsatz von Ressourcen werden so hochdynamisch veränderliche Lastanforderungen zuverlässig bedient und gleichzeitig signifikant Betriebskosten gespart.

Feel free – Technologieunabhängigkeit bei Microservices

Als letzter Aspekt soll noch die Technologieunabhängigkeit von Microservices betrachtet werden. Für die Entwicklung von Microservices ist aus technischer Sicht die Wahl der zum Einsatz kommenden Technologien frei: Hier können unterschiedliche Programmiersprachen, Frameworks, Persistenzlösungen usw. zum Einsatz kommen.

In unserem Anwendungsbeispiel „Bibliothek“ hat sich herausgestellt, dass die Persistenzanforderungen von Microservice zu Microservice sehr unterschiedlich sind. Die zu verwaltenden Datenmengen und -strukturen sind in der Kundenverwaltung recht einfach, was ebenso für die Kriterien bei Suchanfragen gilt. Entsprechend haben wir uns hier für eine leichtgewichtige dokumentenorientierte Lösung entschieden. In anderen Microservices wie „Ausleihe“ und „Bestandsführung“ wird hingegen mit relationalen Datenbanken gearbeitet. Eine vergleichbar große Freiheit, für individuelle Anforderungen jeweils die passende Technologie auszuwählen, ist in monolithischen Systemarchitekturen nicht möglich.

Fazit: erfolgreiches Replatforming mit microservicebasierten Architekturen

Mircoservicebasierte Architekturen im Replatforming liegen derzeit zurecht im Trend. Die Vorteile sind zahlreich – sowohl auf Entwicklerseite als auch auf Anwenderseite – und zahlen sich schnell aus.