Über unsMediaKontaktImpressum
Michael Schäfer 28. November 2017

Microservices vernünftig entwickeln

Die Besonderheiten des Marktes fordern, dass  Microservices vollständig autonom sein sollen. © denisismagilov / Fotolia.com
© denisismagilov / Fotolia.com

Microservices werden oft noch stoisch nach dem Netflix-Muster entwickelt. Dabei passt dieses auf Video-Streaming optimierte Muster kaum zu den mannigfaltigen Geschäftsmodellen anderer Unternehmen. Method 4D beschreibt deshalb ein Vorgehen, mit dem sich gezielt für den jeweiligen Anwendungskontext die richtige Microservice-Architektur erarbeiten lässt.

Die digitale Transformation ist in vollem Gange. Abhängig vom Disruptionsdruck befinden sich derzeit alle Unternehmen, vom Mittelstand bis zu Großunternehmen, unterschiedlich weit in diesem Prozess. Damit verbunden ist die Transformation der Gesellschaft und somit der potentiellen Kunden von morgen. Gemeint sind die Digital Natives, eine Generation, für die das Internet und die damit einhergehenden neuen Geräte wie Smartphones, Tablets oder Weareables und Apps wie Facebook, Whatsapp oder Spotify zentraler Bestandteil ihres Lebens sind. Die neue Generation von Kunden ist sehr individualisiert, ungeduldig und wechselfreudig. Um diese Kunden nicht nur zufriedenzustellen, sondern zu begeistern und somit als Fürsprecher für das eigene Unternehmen zu gewinnen, ist eine herausragende Customer Experience notwendig. Das erfordert eine kontinuierliche und schnelle Reaktion auf die Veränderungen des Marktes sowie der individuellen Anforderungen der Kunden.

Wie aber können Unternehmen schneller auf Marktveränderungen und Kundenanforderungen reagieren? Die Lösung liegt im Aufbau einer Fast IT. Während Unternehmen wie Uber oder Airbnb eine solche IT von Anfang an geplant und aufgebaut haben, müssen Großunternehmen diese erst etablieren.

Microservice-Architektur für Fast IT   

Der Aufbau einer Fast IT im Unternehmen erfordert neben einer organisatorischen Transformation ebenso eine technische Transformation, hin zu neuen Systemen, Technologien und Methoden, die den Marktveränderungen und Kundenanforderungen gerecht werden. Dazu zählen unter anderem neue Systemklassen wie Systems of Engagement (SoE), vielversprechende Konzepte wie User Experience, moderne Methoden wie DevOps oder Agile und neue Technologien wie Cloud Computing oder Microservices.

Besonderes Augenmerk fällt dabei auf die Microservices, die monolithische Architekturen aufsprengen und Unternehmen zu hoch flexiblen sowie potenten Systemen verhelfen. IT-Architekten stehen nun vor der Herausforderung, Microservice-Architekturen im Unternehmen aufzubauen. Wie aber lassen sich gute, tragfähige und unternehmenskompatible Microservice-Architekturen aufziehen?

Sieht man sich den Gartner Hype Cycle an, wird man feststellen, dass Microservices sich dort noch auf dem Gipfel der überzogenen Erwartungen befinden. Bevor das Plateau der Produktivität kommt, muss das Tal der Enttäuschungen und der Pfad der Erleuchtung noch durchlaufen werden. Das heißt im Klartext: Es ist gar nicht möglich, alle Fragen zum Thema Microservices zufriedenstellend zu beantworten, noch Best Practice oder Blueprints aufzuschreiben. Denn hier fehlt uns einfach die Erfahrung, die dazu notwendig wäre.

Es bedarf einer Methode, anhand derer sich Microservice-Architekturen iterativ und somit kostenoptimal entwickeln lassen. Sie muss nicht vollumfänglich alle Probleme lösen, sondern stattdessen eine Grundlage schaffen, die sich erweitern und optimieren lässt. Eine solche Methode ist Microservice Method 4D.

Die Grundidee der Methode

Was ist eigentlich so schwierig an der Entwicklung einer Microservice-Architektur? Die Besonderheiten des Marktes fordern, dass die einzelnen Microservices, aus denen eine Microservice-Architektur besteht, vollständig autonom sein sollen. Denn nur so lässt sich das Versprechen, dass Microservices besonders gut skalieren, auch tatsächlich erfüllen. Sam Newman, einer der Microservice-Evangelisten, schreibt die Anforderung nach Autonomie der Microservices gleich zu Beginn seines Bestsellers Building Microservices auf [1]. Diesen Sachverhalt unterstreichen auch andere namhafte Architekten wie Martin Fowler oder Adrian Cockcroft. Für Microservices bedeutet das, dass sie keine Abhängigkeiten zu anderen Microservices aufbauen dürfen, weder über die Infrastruktur, noch ihre Benutzerschnittstelle, noch ihre Daten; um nur einige Beispiele zu nennen.

Es handelt sich bei der Entwicklung einer Microservice-Architektur um ein Optimierungsproblem von Autonomie und Kosten.

Aber ist die Forderung nach einer vollständigen Autonomie überhaupt realistisch? Dazu eine Analogie aus der Tierwelt: Eine Biene hat für sich gesehen bereits herausragende Fähigkeiten. Eine Honigbiene bestäubt pro Tag ca. 4.400 Blüten und findet selbständig zurück zu ihrem Bienenstock. Allerdings ist eine Honigbiene stets Teil eines Bienenvolkes. Gemeinsam bauen sie den lebenswichtigen Bienenstock, der sie schützt sowie als Lagerstätte für den Honig und Brutkasten dient. Dazu kommunizieren Honigbienen etwa über Rund- oder Schwänzeltanz miteinander. Die Gemeinsamkeit zu Microservices? Ein Microservice für sich löst bereits ein bestimmtes Problem optimal. Aber eine sinnvolle Anwendung besteht immer aus mehreren Microservices, die untereinander kommunizieren müssen.

Microservices sind damit zu einem bestimmten Grad immer voneinander abhängig. Eine vollständige Autonomie wird es nie geben, außer es handelt sich um eine Architektur, die aus nur einem einzigen Microservice besteht. Das dürfte eher selten der Fall sein. Die Forderung nach einer vollständigen Autonomie ist also keine binäre Forderung, die entweder erfüllt ist oder nicht, sondern eher eine Forderung, die einen Lösungsraum von starker bis schwacher Autonomie zulässt. Welcher Grad an Autonomie tatsächlich notwendig ist, hängt alleine vom Anwendungskontext ab.

Eine starke Autonomie erfüllt zwar viele Versprechen einer Microservice-Architektur, ist aber mit hohen Kosten verbunden. Dabei werden die Kosten in Aufwand, Budget und technischer Komplexität gemessen. Eine schwache Autonomie verringert zwar diese Kosten, erfüllt aber auch weniger Versprechen einer Microservice-Architektur. Es handelt sich bei der Entwicklung einer Microservice-Architektur folglich um ein Optimierungsproblem von Autonomie und Kosten. An genau dieser Stelle setzt die Method 4D an. Sie beschreibt einen Weg, das Optimum zu finden. 

Die Method 4D im Überblick

Abb.1: Die Method 4D im Überblick. © Michael Schäfer
Abb.1: Die Method 4D im Überblick. © Michael Schäfer

Die Method 4D gibt einen Weg vor, um die optimale Microservice-Architektur zu entwickeln, ohne die Architekten dabei in ihrer Kreativität und Gestaltungsfreiheit einzuschränken. Daher ist die Methode nur als ein Rahmen zu verstehen, der nicht jedes Detail für jeden Schritt festlegt.

Die Method 4D besteht aus vier Dimensionen: dem Anwendungskontext, den dazugehörigen Versprechen, den jeweiligen Herausforderungen und den passenden Pattern. Die vier Dimensionen werden in genau dieser Reihenfolge durchgearbeitet (s. Abb.1). Am Ende liegt dann ein Satz von Microservice-Pattern vor, die die gewünschte Microservice-Architektur abbilden.

Im ersten Schritt definiert der Architekt den Anwendungskontext A1..An und legt damit fest, für welche Art von Anwendung die Microservice-Architektur überhaupt benötigt wird. Anschließend wählt er die für den jeweiligen Anwendungskontext zu erfüllenden Versprechen (V1..Vn)n aus. Um diese Versprechen dann erfüllen zu können, muss der Architekt die Herausforderungen H1..Hn für jedes Versprechen identifizieren. Nur so lassen sich am Ende die dafür benötigten Pattern P1.1 .. Pn.n heraussuchen. 

Schritt 1: Den Anwendungskontext finden

Ein Anwendungskontext besteht aus der eigentlichen Anwendung und denen, die diese Anwendung nutzen wollen, den Stakeholdern. Dabei hat jeder Stakeholder seine besonderen Anliegen und Erwartungen an die Anwendung. Viele Unternehmen kopieren aktuell oft bedingungslos die Microservice-Pattern sowie den gesamten Technologie-Stack von Netflix, um ihre eigene Microservice-Architektur zu entwickeln. Sicherlich ist das auch der guten Werbung geschuldet, die Netflix über ihren Architekten Adrian Cockcroft im Internet betreibt, frei nach dem Motto "Tue Gutes und rede darüber". Doch die wenigsten Unternehmen verfolgen das gleiche Geschäftsmodell wie Netflix. Ganz im Gegenteil, in aller Regel handelt es sich gar um ein gänzlich anderes Geschäftsmodell und damit auch um einen gänzlich anderen Anwendungskontext. Auf diesen kann der Netflix-Stack, der nun mal spezifisch auf den Anwendungskontext des Videostreamings zugeschnitten ist, nicht sinnvoll passen.

Es gilt also, den richtigen Anwendungskontext für das eigene Unternehmen zu finden. Dazu muss jedes Unternehmen seine Stakeholder und deren Anliegen definieren. Die Methode macht dazu lediglich einen Vorschlag, welche Stakeholder und Anliegen für Anwendung im Kontext der digitalen Transformation von besonderer Bedeutung sein könnten. Sie müssen aber nicht zwingend befolgt werden. Nachdem die Stakeholder und Anliegen definiert sind, müssen die Business-Analysten und Architekten die Anliegen noch bewerten. Die Bewertung folgt den Stufen stark, mittel und schwach. Sie hat einen entscheidenden Einfluss auf die Autonomie der Microservices und damit auf die Kosten der gesamten Microservice-Architektur.

Abb.2: Beispiel eines Anwendungskontextes für starkes und dynamisches Benutzerwachstum. © Michael Schäfer
Abb.2: Beispiel eines Anwendungskontextes für starkes und dynamisches Benutzerwachstum. © Michael Schäfer

Ein Beispiel: Die Benutzer einer Anwendung setzen sich aus bereits bekannten Benutzern – den Stammkunden – und unbekannten Benutzern – den potentiellen und somit zu gewinnenden Kunden – zusammen. Die Anzahl der Benutzer lässt sich somit nicht statisch festlegen, sondern verhält sich dynamisch. Weil das Unternehmen mit der Anwendung international auftritt, kann die Anzahl der Benutzer zudem stark ansteigen, aber auch ebenso stark abfallen. Zusammengefasst besteht der Anwendungskontext somit aus dem Stakeholder Benutzer und dem Anliegen des dynamischen Wachstums mit der Bewertung, dass ein starkes dynamisches Wachstum gefordert wird. Abb.2 zeigt den Anwendungskontext dieses Beispiels als Graph modelliert.

Schritt 2: Die Versprechen bestimmen  

Versprechen sind die Vorteile, die Unternehmen durch den Einsatz von Microservices erhalten. Jedes Unternehmen sollte für sich festlegen, welche Vorteile es sich durch den Einsatz von Microservices verspricht. Zur Orientierung hat Sam Newman bereits sieben wichtige Versprechen beschrieben [1]. Dazu gehören Technology Heterogeneity, Resilience, Scaling, Ease of Deployment, Organizational Alignment, Composability sowie Optimizing for Replicability. Es ist natürlich möglich, weitere oder ganz andere Versprechen festzuhalten.

Als nächstes stellt sich die Frage, wie die Versprechen mit dem Anwendungskontext, also den Stakeholdern, den Anliegen und Bewertungen in Verbindung gebracht werden. Aus den Anliegen an die Beispielanwendung lassen sich nichtfunktionale Anforderungen ableiten, die von den Versprechen erfüllt werden müssen. Nichtfunktionale Anforderungen sind qualitative Anforderungen an die Architektur. Dazu gehört nach ISO 9126 etwa Efficiency, unter der die in diesem Beispiel genannte Skalierung geführt wird. Der Anwendungskontext aus Schritt 1 bestand aus dem Stakeholder Benutzer und dem Anliegen, dass sich das Wachstum der Benutzer stark dynamisch verhält.

Abb.3: Beispiel für ein Versprechen; in diesem Fall Skalierung. © Michael Schäfer
Abb.3: Beispiel für ein Versprechen; in diesem Fall Skalierung. © Michael Schäfer

Daraus ergibt sich eine nichtfunktionale Anforderung an die Architektur, dass diese stark skalieren muss, s. Abb.3. Hier ist also das von Sam Newman formulierte Versprechen Scaling (dt. Skalierung) von besonderem Interesse, denn genau damit lässt sich die nichtfunktionale Anforderung realisieren. Dabei ist ersichtlich, dass die Bewertung der Anliegen gleich der Bewertung der Versprechen ist. Die Skalierung muss somit stark sein.

Schritt 3: Die Herausforderungen finden

Herausforderungen sind in diesem Kontext stets technische Herausforderungen, die gelöst werden müssen, um die festgelegten Versprechen zu erfüllen. Dabei gilt: Je größer die Versprechen, desto größer die Herausforderungen.

Um welche Herausforderungen geht es aber ganz konkret? Zunächst durchziehen die Herausforderungen alle relevanten Themenbereiche der Microservice-Architektur. Dazu gehört das Design der Microservices, die Kommunikation der Microservices untereinander oder der Zugriff der Microservices auf Daten, um nur einige Themenbereiche zu nennen.

Natürlich muss jedes Unternehmen, abhängig vom eigenen Anwendungskontext und den geforderten Versprechen, die Herausforderungen finden. Dies ist ein Prozess, in dem der Architekt darüber nachdenkt, welche technischen Probleme mit der Einhaltung der Versprechen verbunden sind. Welche Herausforderungen gefunden werden, ist dabei von der Kompetenz und der Erfahrung des Architekten abhängig. Eine Herausforderung ist beispielsweise die Verteilung der Daten über mehrere Microservices, die mit der Einhaltung der Autonomie verbunden ist. Der Beitrag "Architekturansatz mit großen Herausforderungen und gewissen Nebenwirkungen" von Ralf S. Engelschall gibt einen sehr guten Überblick über die wesentlichen Herausforderungen, die mit Microservices verbunden sind [2]

Abb.4: Beispiel für Herausforderung der Datenhaltung bei starker dynamischer Skalierung. © Michael Schäfer
Abb.4: Beispiel für Herausforderung der Datenhaltung bei starker dynamischer Skalierung. © Michael Schäfer

Bei einer Anwendung mit vielen Benutzern fallen in aller Regel auch Daten an. Mit Blick auf das Beispiel aus Schritt 1 lassen sich also beispielhaft Daten als Herausforderung an die Microservice-Architektur festlegen. Was bedeutet Forderung nach starker dynamischer Skalierung für die Daten? In aller Regel werden die Daten in einer Datenbank auf einem Datenbankserver gehalten. Steigt mit zunehmender Last die Anzahl der Microservice-Instanzen (Von einem Microservice A lassen sich mehrere Instanzen A1…An starten, um die Last auf alle Instanzen zu verteilen), so muss auch die Anzahl der Datenbankinstanzen und unter Umständen die Zahl der Datenbankserver steigen. Andernfalls würden alle Microservice-Instanzen auf dieselbe Datenbank desselben Datenbankservers zugreifen. Eine solche Architektur könnte allerdings nicht skalieren. Die Architektur muss also berücksichtigen, dass parallel zu den Microservice-Instanzen auch die Zahl der Datenbankinstanzen und gegebenenfalls der Datenbankserver steigen können muss. Das führt sehr schnell zu einer verteilten Datenbankarchitektur. Die Herausforderung, die mit dem Versprechen der starken Skalierung verbunden ist, ist also die Realisierung einer verteilten Datenbankarchitektur (s. Abb.4). Es wird somit ein Pattern benötigt, das diese Herausforderung meistert.

Schritt 4: Herausforderungen mit Pattern meistern

Mit Pattern sind ganz allgemein alle Architektur-Pattern gemeint, die gemäß ihrer Definition eine Lösung zu einem immer wiederkehrenden Architekturproblem liefern. Beispielsweise solche Architektur-Pattern, die die Probleme lösen, die mit verteilten Datenbankarchitekturen einhergehen, wie sie in Schritt 4 beschrieben sind.

In der Literatur und im Internet sind einige Pattern-Kataloge für Microservice-Architekturen zu finden, etwa die Microservice-Pattern von Chris Richardson [3]. Eröffnet sich dem Architekten ein Problem, dann müsste er im Idealfall nur noch in diesen Katalogen nachschlagen und das passende Pattern auswählen. Ganz so einfach ist es allerdings nicht.

Aus Sicht der Method 4D gibt es keine individuellen Architektur-Pattern für Microservice-Architekturen. Die Pattern, die heute in Microservice-Pattern-Katalogen auftauchen, sind in aller Regel Architektur-Pattern aus bestehenden Pattern-Katalogen, die es schon viele Jahre gibt. Beispielsweise das Circuit-Breaker-Pattern, das sich im Zusammenhang mit dem Versprechen der Resilience und den damit zusammenhängenden Herausforderungen anwenden lässt. Das Pattern ist in dem Buch Patterns for Fault Tolerant Software von Robert Hammer zu finden und ist schon viele Jahre alt [4]. Hinzu kommt, dass die bestehenden Microservice-Pattern-Kataloge nur eine begrenzte Anzahl an Problemen für einen ganz bestimmten Anwendungskontext lösen. 

Abb.5: Beispiele für Architektur-Pattern, mit denen sich die Herausforderung der verteilten Datenbanksysteme lösen lässt. © Michael Schäfer
Abb.5: Beispiele für Architektur-Pattern, mit denen sich die Herausforderung der verteilten Datenbanksysteme lösen lässt. © Michael Schäfer

Es ist daher nicht sinnvoll, sich einem der neuen Microservice-Pattern-Kataloge zu verschreiben und diesen stupide anzuwenden. Vielmehr sollte die Entscheidung stärker durch den Architekten erfolgen und auf seiner Kreativität sowie Erfahrung beruhen. Der Architekt muss selbst klären, welches der längst bekannten und bewährten Architektur-Pattern zu seinem spezifischen Problem passt und nicht den stark allgemeinen Anwendungsszenarien der Pattern-Kataloge folgen. Die Method 4D gibt daher auch keine Pattern oder gar Pattern-Kataloge für Microservice-Architekturen vor, sondern lediglich eine fundierte Quellenliste zum Thema Architektur-Pattern [5].

Zum Abschluss des Beispiels aus den vorangegangenen Kapiteln wird also ein Architektur-Pattern benötigt, das die Probleme der verteilten Daten löst (s. Abb.5). Sobald der Architekt selbst passende Pattern heraussucht, wird schnell klar: Oft existieren nicht nur ein, sondern gleich mehrere Pattern, die das Problem in Summe lösen. Im Beispielfall sind das die Pattern Domain Event, Event Sourcing, CQRS und Eventual Consistency [6].

IT-Tage 2017 - Microservices

Zusammenfassung

Bevor Architekten die Method 4D in einem Unternehmen erfolgreich einsetzen können, muss neben der technischen Transformation vor allem eine organisatorische Transformation zum Aufbau der Fast IT erfolgen. Sriram Narayan beschreibt in seinem Buch Agile IT Organization Design [7] sehr schön, wie eine Fast IT zur Umsetzung der digitalen Transformation in Großunternehmen aufgebaut werden kann. Bleibt die organisatorische Transformation dabei außen vor, werden Unternehmen bei der Umsetzung von Microservices allerdings scheitern. Conway's Law untermauert diese These [8].

Vor der Verwendung der Method 4D müssen sich Architekten aber die Frage stellen, ob die geplante Anwendung nicht auch mit anderen bekannten Technologien und Ansätzen als Microservices gelöst werden kann. Sofern die Antwort auf diese Frage eindeutig "Nein" lautet und es Microservices sein müssen, dann ist es entscheidend, bei der Entwicklung der Microservice-Architektur sinnvoll vorzugehen. Dazu ist die Method 4D bestens geeignet.

Die Method 4D muss sich in der Praxis noch bewähren und weist an der einen oder anderen Stelle noch Verbesserungspotenzial auf. Eine Vision wäre, dass sich aus der Method 4D eine Vielzahl von Lösungen entwickeln, aus denen dann typische Microservice-Architekturen mit ihren dazugehörigen Pattern abgeleitet werden könnten. Ich würde mich über Feedback und Erfahrungsberichte zur Method 4D freuen.

Quellen
  1. S. Newman, 2015: Building Microservices, O'Reilly Media; Auflage 1,
  2. R. S. Engelschall, 2016: Architekturansatz mit großen Herausforderungen und gewissen Nebenwirkungen, msg – Applied Technology Research, Auflage 1
  3. C. Richardson, 2018: Microservice Patterns, Manning Publications, Auflage 1
  4. R. Hammer, 2013: Patterns for Fault Tolerant Software, Wiley; Auflage 1
  5. M. Schäfer, 2017: Allgemeiner Pattern-Katalog, msg – Applied Technology Research, Auflage 1
  6. V. Vernon, 2013: Implementing Domain-Driven Design, Addison-Wesley Professional, Auflage 1
  7. S. Narayan, 2015: Agile IT Organization Design, Addison-Wesley Professional, Auflage 1
  8. M. E. Conway, 1968: How Do Committees Invent?
nach Oben
Autor

Michael Schäfer

Michael Schäfer ist für technologische und methodische Innovationen, Training und Publikationen bei der msg mitverantwortlich und als IT-Architekt in Spring-Projekten und Java-EE- unterwegs.
>> Weiterlesen
botMessage_toctoc_comments_929