Rainer Stropek Selbstständig

„Die Herausforderung bei Microservices ist, dass die wesentlichen Anforderungen trotz verteilter Datenspeicherung erfüllt, die sprichwörtlichen alten Zöpfe aber abgeschnitten werden.“

Es gibt im Moment nur wenige Themen, die auf Konferenzen, in Magazinen und in Softwarearchitekturworkshops so präsent sind wie Microservices. In diesem Artikel nehmen wir die Coding-Brille ab und sehen uns die Grundprinzipien dieses Architekturansatzes an. Welche Probleme lösen Microservices? Was sind die Stärken und Schwächen? Welche organisatorischen und technischen Voraussetzungen sind notwendig? Ich versuche in diesem Artikel, Antworten auf Fragen wie diese zu entwickeln.

Starten wir mit einer Beschreibung dessen, was Microservices sind: kleine, autonome Dienste, die erst im Zusammenspiel größere, nutzbringende Aufgaben für Benutzer erfüllen. In diesem Satz stecken einige Aussagen, die einen genaueren Blick wert sind. Was bedeutet zum Beispiel klein?

Es gibt keine eindeutige Definition dafür, wie klein Services sein sollten, damit sie als Microservices durchgehen. Aussagen wie „nicht mehr als 1 000 Codezeilen“ werden der Vielfalt an grundlegend unterschiedlichen Aufgabenstellungen, die man in der Praxis findet, nicht gerecht. Ich mache die Kleinheit daran fest, wie viele Personen wie lange brauchen würden, um den Microservice neu zu bauen. Eine Kernidee von Microservices ist es schließlich, technische und organisatorische Abhängigkeiten in den Griff zu bekommen. Wir wollen große Haufen an Spaghetticode vermeiden, in denen sich niemand mehr fundamentale Änderungen vorzunehmen traut, weil die Auswirkungen und Risiken nicht abschätzbar wären. Ein Gesamtsystem aus Microservices, die jeweils klein genug sind, dass sie von einem kompetenten Scrum-Team beispielsweise in einem Monat auf Basis einer neuen Technologie neu erstellt werden könnten, ermöglicht kontinuierliche, schrittweise Verbesserung. Das ist ein großer Wert für nachhaltig denkende Unternehmen, die nicht das schnelle Geld suchen, sondern Software bauen wollen, die lange auf dem aktuellen Stand der Technik gehalten werden soll.

Wer eine allgemeingültige, exakte Definition der Größe von Microservices sucht, den muss ich enttäuschen. Eine solche Aussage wäre meiner Ansicht nach nicht seriös. Jede Organisation muss für ihre Projekte eine individuelle Balance aus verkraftbarer Größe und Koordinationsaufwand durch zu viele, zu kleine Einzelservices finden.

Nur eine Aufgabe pro Microservice

Für die Größe eines Microservice sollte man meiner Ansicht nach nicht nur technische Metriken wie Anzahl Codezeilen oder Codekomplexität betrachten. Es gibt auch eine inhaltliche Perspektive. Jeder Microservice hat eine einzelne, klar definierte Aufgabe. Funktionen und Daten, die in engem, inhaltlichen Zusammenhang stehen, weil sie beispielsweise immer gemeinsam in Geschäftsprozessen verwendet werden, sind Kandidaten für eine Zusammenfassung in einem Microservice. Idealerweise muss ein Endbenutzer, der eine Änderung an der Umsetzung eines wichtigen Geschäftsprozesses möchte, mit genau einem Microservices-Team sprechen. Das unerwünschte Gegenteil wäre, wenn der Endbenutzer mit mehreren Teams sprechen und die Rolle der Koordinatorin übernehmen müsste.

Natürlich stehen in der Praxis Geschäftsprozesse zueinander in Beziehung. Auf die Produktpräsentation im Onlineshop folgt hoffentlich die Bestellung, darauf die Auslieferung und anschließend die Verrechnung. Die Details der Teilprozesse sind jedoch für die nach- und vorgelagerten Aufgaben nicht relevant. Nur die Ergebnisse (z. B. Bestellung) und Ereignisse (z. B. Ware wurde versendet) werden ausgetauscht. Aus ihnen ergeben sich die Schnittstellen zwischen Microservices.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 2.18 - "Microservices"

Alle Infos zum Heft
579824460Was ist dran am Microservices-Hype?
X
- Gib Deinen Standort ein -
- or -