Microservices [1] [2] sind kein fest definierter Begriff. Die ISA-Prinzipien stellen deswegen Regeln für Microservices auf:

Das Gegenteil zu einem Microservices-System ist ein Deployment-Monolith, bei dem alle Module gemeinsam in Produktion gebracht werden. Das ist genauso wie Microservices ein Architektur-Ansatz mit Vor- und Nachteilen. Es ist also keinesfalls sinnvoll, Deployment Monolithen als Architektur-Ansatz von vorneherein auszuschließen.

Vorteile

Wie jede Architektur haben Microservices Vor- und Nachteile. Zunächst gibt es einige technologischen Vorteile:

Auf organisatorischer Ebene ergeben sich ebenfalls Vorteile:

Herausforderungen

Natürlich gibt es auch Herausforderungen:

Gemeinsames Datenmodell

Für das Scheitern von Microservices gibt es unterschiedliche Gründe. Ein Grund kann ein gemeinsames Datenmodell sein. Das gemeinsame Datenmodell muss nicht unbedingt zur Speicherung der Daten dienen, sondern es kann beispielsweise auch nur zu Kommunikation genutzt werden.

Beispielsweise können der Bestellprozess, der Lieferprozess und der Rechnungsprozess alle ein gemeinsames Datenmodell für Kunden oder Waren nutzen (Abb. 1). Um Aufwand zu sparen, kann man das Modell als Library implementieren, die alle Microservices nutzen. Wenn alle Microservices aus Kompatibilitätsgründen immer die neuste Version der Library nutzen müssen, hat man einen Deployment Monolithen implementiert. Die Container können nicht getrennt deployt werden, wenn es eine Änderung am Datenmodell gibt, sondern alle müssen gemeinsam aktualisiert und dann deployt werden. So können die Vorteile von Microservices wie getrenntes Deployment und genau genommen auch die getrennte Entwicklung nicht mehr ausgenutzt werden.

Abb. 1: Gemeinsames Datenmodell für mehrere Microservices
Abb. 1: Gemeinsames Datenmodell für mehrere Microservices

Ein gemeinsames Datenmodell kann Ergebnis moderner Architektur-Ansätze sein. Wenn Microservices über Events miteinander kommunizieren, dann nutzen alle dasselbe Event-Datenmodell. Mit Event Sourcing kann der Zustand eines Microservice aus den Events wieder erzeugt werden. Dazu müssen die Events beispielsweise mit einem Messaging-System wie Kafka gespeichert werden. Wenn nun alle Daten des Rechnungs-Microservice gelöscht werden und dann alle Bestellungen noch einmal bearbeitet werden, dann sollte der Microservice wieder im selben Zustand sein. Das bedeutet, dass der Zustand der Microservices eigentlich nicht relevant ist. Er kann aus den Events wieder ermittelt werden. Also haben die Microservices kein echtes eigenes Datenmodell. Schließlich kann das Datenmodell der Microservices aus dem gemeinsamen Event-Datenmodell erzeugt werden.

Ein solches Datenmodell nutzen alle Microservices. Es stellt daher ein Abhängigkeitsschwerpunkt dar und ist schwer änderbar. Ein Attribut aus dem Datenmodell zu entfernen ist besonders schwierig, weil nicht klar ist, welcher Microservice das jeweilige Attribut nutzt. Dann wird das Datenmodell immer weiter wachsen, da es sicher irgendwann neue Attribute aufnehmen muss, aber alten Attribute nicht so ohne weiteres entfernt werden können.

Events, die in einem Microservices verarbeitet werden müssen und sich für Event Sourcing eignen, haben außerdem eine andere Granularität als Events, die über Microservices hinweg verwendet werden. Eine Vermischung dieser beiden Granularitätsebenen führt dazu, dass Microservices zu viele Abhängigkeiten bekommen.

Die Lösung ist es, konsequent auf lokale Datenmodelle zu setzen. Das Event-Modell für Event Sourcing sollte außerhalb des Microservices nicht bekannt sein. Ein globales Datenmodell sollte man für Kommunikation vermeiden. So kann beispielsweise für die Kommunikation zwischen jeweils zwei Microservices ein eigenes Datenmodell dienen. Das kann zu einer Vielzahl von Modellen führen. Hier gilt es abzuwägen: Ist die Unabhängigkeit wichtiger als eine geringe Anzahl an Modellen? Können alle Anforderungen über einen Kamm geschert werden? Für den Lieferprozess sind Gewicht oder Größe der Waren interessant, für die Rechnungserstellung die Besteuerung und der Preis. Man sollte diese sehr unterschiedlichen Belange eher nicht mit einem einzigen Modell ausdrücken.

Unzuverlässigkeit

In einem Microservices-System kann viel mehr schief gehen. Es gibt mehr Server, die Microservices kommunizieren über ein unzuverlässiges Netzwerk und es gibt viel mehr Services als bei einem Deployment Monolithen. Microservices sind Module und hängen daher voneinander ab. Wenn der Ausfall eines Microservice andere Microservices ebenfalls zum Ausfall bringt, dann führt das zu einem Domino-Effekt, bei dem der Ausfall eines einzigen Microservices am Ende das gesamte System zum Ausfall bringt. Da bei der Anzahl Microservices die Wahrscheinlichkeit für den Ausfall eines Microservice hoch ist, ist die Katastrophe vorprogrammiert.

Die Lösung ist Resilienz. Wenn ein Microservice diesem Design-Ansatz entspricht, funktioniert er auch dann, wenn andere Microservices ausfallen. Wahrscheinlich kann der Microservice dann nur eine eingeschränkte Leistung erbringen. So könnte der Bestellprozess beispielsweise vielleicht nur Bestellungen bis zu einer Obergrenze bearbeitet, wenn die Prüfung der Kreditwürdigkeit ausgefallen ist. Im Extremfall kann der Microservice sogar nur eine Fehlermeldung zurückgeben. Auf keinen Fall darf er bei einem Request blockieren. Dann würden die aufrufenden Microservices ebenfalls ausfallen, weil sie blockiert werden und nach einiger Zeit alle Kapazitäten durch Warten blockiert sind.

Resilienz kann durch asynchrone Kommunikation erreicht werden. Dann werden Nachrichten später bearbeitet. Der Aufrufer wartet nicht auf das Ende der Bearbeitung. Wenn ein Microservice ausfällt, werden Nachrichten eben erst bearbeitet, wenn der Microservice wieder zur Verfügung steht. Aber der aufrufende Microservice fällt nicht aus.

Resilienz hat aber auch seine Grenzen. Wenn beispielsweise der Service für die Authentifizierung ausfällt, können Benutzer sich nicht mehr einloggen. Die einzige resiliente Alternative wäre es, Zugriff ohne Authentifizierung zuzulassen. Das ist aber wohl kaum sinnvoll.

Synchrone Aufrufe

Kaskadierende synchrone Aufrufe sind ein Konzept, dass beispielsweise Netflix umgesetzt hat. Zweifellos können so also auch große Systeme erfolgreich implementiert werden. Zudem sind Entwickler synchrone Aufrufe von imperativer Programmierung gewohnt. Bei kaskadierenden synchronen Aufrufen führt ein Aufruf dazu, dass andere Microservices aufgerufen werden, die wiederum andere Microservices aufrufen können.

Aber dieser Ansatz hat einige Nachteile:

Dementsprechend ist es sinnvoll, Microservices asynchron aufzubauen. Wenn die Microservices relativ unabhängige Teile der Domäne implementieren, dann ist eine asynchrone Kommunikation recht einfach umsetzbar. Trotzdem gibt es erfolgreiche synchrone Microservices-System wie beispielsweise Netflix, die aber nicht als Vorbild für eigenen Implementierungen dienen sollten. Ganz wird sich die synchrone Kommunikation nicht verhindern lassen.

Entity Service

Ein Microservice, der ein Domänenobjekt wie Kunden oder Waren verwaltet, scheint zunächst eine gute Idee (Abb. 2). Allerdings ist es offensichtlich ein zentrales Domänenmodell, das wie schon diskutiert viele Nachteile hat. Praktisch jede Funktionalität wie beispielsweise ein Bestellprozess braucht Zugriff auf Waren oder Kunden. Der Zugriff ist eigentlich nur mit synchroner Kommunikation umsetzbar. Ein Aufruf an den Bestellprozess-Microservice ruft den Kunden-Microservice und den Waren-Microservice mindestens einmal auf. Das führt zu schlechter Performance und höherer Latenz. Außerdem wird das System unzuverlässig, weil bei einem Ausfall eines Entity Service kaum Resilienz umgesetzt werden kann.

Abbildung 2: Entity Services
Abbildung 2: Entity Services

Statt der Entity Services kann eine gemeinsame Datenbank verwendet werden. Dann hat das System immer noch ein gemeinsames Datenmodell, aber die Probleme im Bereich Performance, Latenz oder Zuverlässigkeit sind gelöst. Das Datenmodell in der Datenbank wird für die interne Repräsentation der Daten im Microservice genutzt, was Änderungen des Datenmodell ohne Beeinflussung der anderen Microservices praktisch unmöglich macht und zu starken Abhängigkeiten zwischen den Microservice führt. Das gilt natürlich nur, wenn die Microservice sich ein Datenbank-Schema teilen. Nutzen die Microservices eine gemeinsame Datenbank aber getrennte Schemata, dann sind sie architektonisch unabhängig. Ein Ausfall der Datenbank führt dann allerdings zu einem Ausfall aller Microservices, was aber bei einer genügend hohen Verfügbarkeit der Datenbank akzeptabel sein kann.

Die Lösung ist es, Domänenobjekte in jedem Microservice zu modellieren. Das ist auch sinnvoll, weil beispielsweise für die Lieferung andere Informationen der Ware (Gewicht, Größe) als für die Rechnung (Preis, Steuer) notwendig sind (Abb. 3). Domain-driven Design [5] bezeichnet diese unterschiedlichen Modelle als Bounded Context, also einen abgeschlossenen Kontext wie Lieferung oder Rechnungslegung, in dem ein eigenes Domänenmodell sinnvoll ist.

Abbildung 3: Datenmodell pro Microservice
Abbildung 3: Datenmodell pro Microservice

Betrieb

Um Microservices umzusetzen, muss der Betrieb die Vielzahl an Microservices deployen und betreiben. Dazu ist meistens der Einsatz neuer Technologien notwendig. Die existierenden Technologien, Prozesse und Teams unterstützen oft den Wandel hin zu Microservices nicht ausreichend.

Das Problem des zusätzlichen Aufwandes im Betrieb stand von Anfang an im Zentrum der Microservices-Diskussion und ist daher recht offensichtlich. Ob ein Betriebs-Team dieses Problem lösen kann, ist meistens auch einfach zu erkennen. Gegebenenfalls kann dieses Problem dazu führen, dass man Abstand von der Microservices-Architektur nehmen muss. Das ist sicher besser als mit einem fertig entwickelten Microservices-System an Problemen im Betrieb zu scheitern.

Eine Lösung können neue Technologien wie Kubernetes bringen, die den Betrieb von Microservices deutlich vereinfachen. Für den ersten Microservice ist es allerdings sicher noch nicht notwendig, eine komplett neue Umgebung zu etablieren. Ein einzelner Microservice kann sicher auch in einer klassischen Umgebung betrieben werden.

Ein Platform as a Service (PaaS) wie Cloud Foundry oder OpenShift kann eine technologische Lösung für dieses oft eher soziale Problem sein. Nachdem der Betrieb das PaaS installiert hat, steht eine Plattform zur Verfügung, auf der beliebige Microservices installiert werden können. Dazu muss der Betrieb nicht mehr beteiligt werden. Diese „Agilisierung“ des Betriebs wird oft als Hauptvorteil eines PaaS dargestellt.

Eine Alternative ist die öffentliche Cloud. Sie bietet eine Vielzahl an Technologien, die ohne weitere Installation zur Verfügung stehen. Dazu gehören PaaS, Kubernetes aber auch beispielsweise Datenbanken. Bestimmte Betriebsprozesse wie das Booten eines Servers beim Ausfall können dabei automatisiert werden, so dass der Betrieb entlastet wird.

Schlechte Struktur

Oft werden Microservices genutzt, um Systeme leichter wartbar und änderbar zu machen. Die Wartbarkeit eines Systems hängt von der Aufteilung in Module ab. Microservices implementieren die Module nur anders. Wenn die Aufteilung in Module schlecht ist, ändert eine Implementierung als Microservices daran auch nichts.

Ein schlecht strukturiertes Microservices-System führt sogar zu größeren Problemen als ein schlecht strukturierter Deployment Monolith. Bei einem schlecht strukturierten Deployment Monolithen müssen zwar mehrere Module geändert werden, wenn eine Anforderung implementiert werden soll. Danach kann das System als Ganzes aber einfach deployt werden.

Wenn eine Änderung wegen der schlechten Strukturierung mehrere Microservice betrifft, dann muss das Deployment der verschiedenen Microservices koordiniert werden. Außerdem kommunizieren die Microservice in einem schlechten strukturierten System auch viel miteinander, was Latenz, Performance und Resilienz negativ beeinflusst. Und die Architektur-Firewalls erschweren es zusätzlich, die Struktur des Microservices-System zu verbessern.

Die Verbesserung der Struktur kann durch das Entkoppeln der Logik beispielsweise mit Domain-driven Design und Bounded Context erreicht werden. Daher ist es nicht sinnvoll, ein schlecht strukturierten Deployment Monolithen unter Beibehaltung der Struktur in ein Microservices-System zu migrieren. Stattdessen sollte ein Bounded Context nach dem anderen aus dem System herausgeschnitten werden, um so auch die Struktur zu verbessern.

Organisation

Microservices ermöglichen unabhängige Teams, da die Microservices technisch und fachlich unabhängig sind. Wenn jedes Team an einem Microservice arbeitet, muss es sich kaum mit anderen Teams koordinieren. Wenn aber eine Gruppe von Architekten alle wesentlichen Entscheidungen für alle Teams trifft, wird dieser Vorteil nicht ausgenutzt.

Die Lösung ist es, Verantwortung zu delegieren. Das erfordert Vertrauen in die Teams und Mut. Durch das Delegieren verhalten sich Teams allerdings auch anders. Wenn Änderungen direkt in Produktion gehen und nicht erst noch durch ein Test-Team bewertet werden, wird sich das Verhalten der Entwickler auch entsprechend ändern.

  1. Eric Evans: Domain-driven Design Referenz, kostenlos unter http://ddd-referenz.de/  ↩

  2. Eberhard Wolff: Microservices - Ein Überblick, kostenlos unter https://microservices-buch.de/ueberblick.html  ↩

  3. Eberhard Wolff: Das Microservices-Praxisbuch: Grundlagen, Konzepte und Rezepte, dpunkt, 2018, ISBN 978–3864905261  ↩

  4. Eberhard Wolff: Microservices Rezepte - Technologien im Überblick, kostenlos unter https://microservices-praxisbuch.de/rezepte.html  ↩

  5. Eric Evans: Domain-driven Design Referenz, kostenlos unter http://ddd-referenz.de/  ↩

Fazit

Microservices haben zwar viele Vorteile, aber es lohnt sich, auch die Nachteile zu bewerten und die typischen Fehler zu vermeiden. Überhaupt sollten Architekturen die jeweiligen Probleme lösen und nicht einfach nur unreflektiert der letzten Mode nacheifern. Es gibt bizarre Situationen, in denen Projekte zwar Microservices nutzen, aber nur einmal pro Quartal deployen und dann auch alle Microservices gemeinsam. Sie nutzen einen gemeinsamen Technologie-Stack, treffen Entscheidungen zentral und delegieren keine Verantwortung in die Teams. Solche Projekte müssen zwar mit dem komplexen Deployment der Microservices leben, erreichen weder den Vorteil des schnellen, unabhängigen Deployment noch der Entkopplung bei den Technologien und Fachlichkeiten oder der unabhängigen Teams. Solche Projekte sollten die Entscheidung für Microservices noch einmal auf den Prüfstand stellen oder aber das Projekt so umstrukturieren, dass es die Vorteile der Microservices auch tatsächlich ausnutzt. Denn darum geht es bei der Architektur: Die Lösungen mit den meisten Vorteilen für das jeweilige Problem identifizieren und umsetzen.