Aufbau ereignisgesteuerter Microservices

Kapitel 1. Warum ereignisgesteuerte Microservices

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Das Medium ist die Botschaft.

Marshall McLuhan

McLuhan argumentiert, dass nicht der Inhalt der Medien, sondern die Auseinandersetzung mit dem Medium die Menschen beeinflusst und die Gesellschaft grundlegend verändert. Zeitungen, Radio, Fernsehen, das Internet, Instant Messaging und soziale Medien haben dank unseres kollektivenEngagements die menschliche Interaktion und die sozialen Strukturen verändert.

Das Gleiche gilt für die Architekturen von Computersystemen. Du brauchst nur einen Blick auf die Geschichte der Computererfindungen zu werfen, um zu sehen, wie Netzwerkkommunikation, relationale Datenbanken, Big-Data-Entwicklungen und Cloud Computing die Art und Weise, wie Architekturen aufgebaut werden und wie die Arbeit ausgeführt wird, erheblich verändert haben. Jede dieser Erfindungen veränderte nicht nur die Art und Weise, wie die Technologie in verschiedenen Softwareprojekten eingesetzt wurde, sondern auch die Art und Weise, wie Organisationen, Teams und Menschen miteinander kommunizierten. Von zentralisierten Mainframes bis hin zu verteilten mobilen Anwendungen hat jedes neue Medium die Beziehung der Menschen zum Computer grundlegend verändert.

Das Medium des asynchron erzeugten und konsumierten Ereignisses hat sich durch die moderne Technologie grundlegend verändert. Diese Ereignisse können jetzt unbegrenzt und in extrem großem Umfang gespeichert und von jedem Dienst so oft wie nötig konsumiert werden. Rechenressourcen können leicht erworben und auf Abruf freigegeben werden, was die Erstellung und Verwaltung von Microservices erleichtert. Microservices können ihre Daten nach ihren eigenen Bedürfnissen speichern und verwalten, und zwar in einem Umfang, der bisher auf Batch-basierte Big-Data-Lösungen beschränkt war. Diese Verbesserungen des bescheidenen und einfachen ereignisgesteuerten Mediums haben weitreichende Auswirkungen, die nicht nur Computerarchitekturen verändern, sondern auch die Art und Weise, wie Teams, Menschen und Organisationen Systeme und Unternehmen aufbauen, völlig neu gestalten.

Was sind ereignisgesteuerte Microservices?

Microservices und Microservice-Architekturen gibt es schon seit vielen Jahren, in vielen verschiedenen Formen und unter vielen verschiedenen Namen. Serviceorientierte Architekturen (SOAs) bestehen oft aus mehreren Microservices, die synchron direkt miteinander kommunizieren. Message-Passing-Architekturen verwenden konsumierbare Ereignisse, um asynchron miteinander zu kommunizieren. Die ereignisbasierte Kommunikation ist sicherlich nicht neu, aber die Notwendigkeit, große Datenmengen in großem Umfang und in Echtzeit zu verarbeiten, ist neu und erfordert eine Abkehr von den alten Architekturstilen.

In einer modernen ereignisgesteuerten Microservices-Architektur kommunizieren Systeme durch das Ausgeben und Konsumieren von Ereignissen. Diese Ereignisse werden nicht wie in Message-Passing-Systemen nach dem Konsum zerstört, sondern bleiben für andere Konsumenten verfügbar, die sie nach Bedarf lesen können. Dies ist ein wichtiger Unterschied, denn er ermöglicht die wirklich leistungsfähigen Muster, die in diesem Buch behandelt werden.

Die Dienste selbst sind klein und zweckgebunden, um die notwendigen Geschäftsziele der Organisation zu erfüllen. Eine typische Definition von "klein" ist etwas, dessen Erstellung nicht länger als zwei Wochen dauert. Nach einer anderen Definition sollte der Dienst (konzeptionell) in den eigenen Kopf passen. Diese Dienste nehmen Ereignisse aus Eingangs-Ereignisströmen auf, wenden ihre eigene Geschäftslogik an und können ihre eigenen Ausgangsereignisse ausgeben, Daten für den Anfrage-Antwort-Zugriff bereitstellen, mit einer API eines Drittanbieters kommunizieren oder andere erforderliche Aktionen durchführen. Wie in diesem Buch beschrieben, können diese Dienste zustandsbehaftet oder zustandslos, komplex oder einfach sein. Sie können als langlaufende, eigenständige Anwendungen implementiert oder als Funktion mit Functions-as-a-Service ausgeführt werden.

Diese Kombination aus Ereignisströmen und Microservices bildet einen vernetzten Graphen von Aktivitäten innerhalb einer Unternehmensorganisation. Traditionelle Computerarchitekturen, die aus Monolithen und intermonolithischer Kommunikation bestehen, haben eine ähnliche Graphstruktur. Diese beiden Graphen sind in Abbildung 1-1 dargestellt.

Abbildung 1-1. Die Graphenstrukturen von Microservices und Monolithen

Um herauszufinden, wie man diese Graphenstruktur effizient gestalten kann, muss man sich die beiden Hauptkomponenten ansehen: die Knoten und die Verbindungen. In diesem Kapitel werden wir beide Komponenten nacheinander untersuchen.

Einführung in Domain-Driven Design und Bounded Contexts

Domain-driven Design, wie es von Eric Evans in seinem gleichnamigen Buch genannt wird, stellt einige der notwendigen Konzepte für die Entwicklung ereignisgesteuerter Microservices vor. Angesichts der Fülle von Artikeln, Büchern und Blogs, die sich mit diesem Thema befassen, werde ich mich in diesem Abschnitt kurz fassen.

Die folgenden Konzepte liegen dem domänenorientierten Design zugrunde:

Domain

Der Problemraum, den ein Unternehmen einnimmt und für den es Lösungen anbietet. Er umfasst alles, womit sich das Unternehmen auseinandersetzen muss, einschließlich Regeln, Prozessen, Ideen, geschäftsspezifischer Terminologie und allem, was mit dem Problemraum zu tun hat, unabhängig davon, ob sich das Unternehmen damit beschäftigt oder nicht. Der Bereich existiert unabhängig von der Existenz des Unternehmens.

Subdomain

Eine Komponente der Hauptdomäne. Jede Subdomäne konzentriert sich auf eine bestimmte Untergruppe von Aufgaben und spiegelt in der Regel einen Teil der Organisationsstruktur des Unternehmens wider (z. B. Lager, Vertrieb und Technik). Eine Subdomäne kann als eigenständige Domäne betrachtet werden. Subdomänen gehören wie die Domäne selbst zum Problemraum.

Domänen- (und Subdomänen-) Modell

Eine Abstraktion des eigentlichen Bereichs, die für Geschäftszwecke nützlich ist. Die Teile und Eigenschaften des Bereichs, die für das Unternehmen am wichtigsten sind, werden zur Erstellung des Modells verwendet. Das wichtigste Domänenmodell eines Unternehmens lässt sich an den Produkten erkennen, die das Unternehmen seinen Kunden anbietet, an den Schnittstellen, über die die Kunden mit den Produkten interagieren, und an den verschiedenen anderen Prozessen und Funktionen, mit denen das Unternehmen seine erklärten Ziele erreicht. Modelle müssen oft verfeinert werden, wenn sich der Bereich ändert und sich die Prioritäten des Unternehmens verschieben. Ein Fachbereichsmodell ist Teil des Lösungsraums, da es ein Konstrukt ist, das das Unternehmen zur Problemlösung verwendet.

Begrenzter Kontext

Die logischen Grenzen, einschließlich der Eingaben, Ausgaben, Ereignisse, Anforderungen, Prozesse und Datenmodelle, die für die Subdomäne relevant sind. Im Idealfall stimmen ein Bounded Context und eine Subdomain vollständig überein, aber Altsysteme, technische Schulden und die Integration von Drittanbietern führen oft zu Ausnahmen. Begrenzte Kontexte sind auch eine Eigenschaft des Lösungsraums und haben einen erheblichen Einfluss darauf, wie Microservices miteinander interagieren.

Begrenzte Kontexte sollten einen hohen Grad an Kohäsion aufweisen. Die internen Vorgänge des Kontexts sollten intensiv und eng miteinander verbunden sein, wobei der Großteil der Kommunikation intern und nicht grenzüberschreitend stattfindet. Hochgradig kohärente Zuständigkeiten ermöglichen einen geringeren Gestaltungsspielraum und einfachere Implementierungen.

Die Verbindungen zwischen gebundenen Kontexten sollten lose gekoppelt sein, da Änderungen innerhalb eines gebundenen Kontexts die Auswirkungen auf benachbarte Kontexte minimieren oder eliminieren sollten. Eine lose Kopplung kann sicherstellen, dass Änderungen an den Anforderungen in einem Kontext nicht zu einer Flut von abhängigen Änderungen in benachbarten Kontexten führen.

Domänenmodelle und eingeschränkte Kontexte nutzen

Jede Organisation bildet einen einzigen Bereich zwischen sich und der Außenwelt. Jeder, der innerhalb der Organisation arbeitet, unterstützt die Bedürfnisse seines Bereichs.

Dieser Bereich ist in Unterbereiche unterteilt - zum Beispiel in einem technologieorientierten Unternehmen in eine technische Abteilung, eine Vertriebsabteilung und eine Kundendienstabteilung. Jeder Teilbereich hat seine eigenen Anforderungen und Aufgaben und kann selbst weiter unterteilt werden. Dieser Unterteilungsprozess wiederholt sich, bis die Modelle der Teilbereiche granular und umsetzbar sind und von den Implementierungsteams in kleine und unabhängige Dienste umgesetzt werden können. Um diese Subdomänen herum werden Bounded Contexts erstellt, die die Grundlage für die Erstellung von Microservices bilden.

Abgleich von begrenzten Kontexten mit Geschäftsanforderungen

Es ist üblich, dass sich die geschäftlichen Anforderungen eines Produkts während seiner Lebensdauer ändern, z. B. aufgrund von organisatorischen Änderungen oder neuen Funktionsanforderungen. Im Gegensatz dazu kommt es selten vor, dass ein Unternehmen die zugrundeliegende Implementierung eines Produkts ändern muss, ohne dass sich gleichzeitig die geschäftlichen Anforderungen ändern. Aus diesem Grund sollten gebundene Kontexte auf geschäftlichen und nicht auf technologischen Anforderungen aufbauen.

Die Ausrichtung von Bounded Contexts auf die Geschäftsanforderungen ermöglicht es den Teams, Änderungen an Microservice-Implementierungen auf eine lose gekoppelte und hochgradig kohärente Weise vorzunehmen. Es gibt einem Team die Autonomie, eine Lösung für die spezifischen Geschäftsanforderungen zu entwerfen und zu implementieren, was die Abhängigkeiten zwischen den Teams stark reduziert und es jedem Team ermöglicht, sich ausschließlich auf seine eigenen Anforderungen zu konzentrieren.

Umgekehrt ist die Ausrichtung von Microservices auf technische Anforderungen problematisch. Dieses Muster ist häufig bei unsachgemäß konzipierten synchronen Punkt-zu-Punkt-Microservices und bei traditionellen monolithischen Computersystemen zu beobachten, bei denen Teams bestimmte technische Schichten der Anwendung besitzen. Das Hauptproblem bei der technologischen Ausrichtung besteht darin, dass die Verantwortung für die Erfüllung der Geschäftsfunktion auf mehrere begrenzte Kontexte verteilt wird, an denen mehrere Teams mit unterschiedlichen Zeitplänen und Aufgaben beteiligt sein können. Da kein Team allein für die Umsetzung einer Lösung verantwortlich ist, wird jeder Dienst über Team- und API-Grenzen hinweg an einen anderen gekoppelt, was Änderungen schwierig und teuer macht. Eine scheinbar unschuldige Änderung, ein Fehler oder ein fehlgeschlagener Dienst kann schwerwiegende Auswirkungen auf die Geschäftsfähigkeit aller Dienste haben, die das technische System nutzen. Technisches Alignment wird in ereignisgesteuerten Microservice-Architekturen (EDM) nur selten eingesetzt und sollte, wann immer möglich, vollständig vermieden werden. Die Beseitigung übergreifender technologischer und teambezogener Abhängigkeiten verringert die Empfindlichkeit eines Systems gegenüber Veränderungen.

Abbildung 1-2 zeigt beide Szenarien: alleinige Eigentümerschaft auf der linken Seite und übergreifende Eigentümerschaft auf der rechten Seite. Bei der alleinigen Eigentümerschaft ist das Team vollständig nach den beiden unabhängigen Geschäftsanforderungen organisiert (Bounded Contexts) und hat die vollständige Kontrolle über seinen Anwendungscode und die Datenbankschicht. Auf der rechten Seite wurden die Teams über die technischen Anforderungen organisiert, wobei die Anwendungsschicht getrennt von der Datenschicht verwaltet wird. Dadurch entstehen explizite Abhängigkeiten zwischen den Teams sowie implizite Abhängigkeiten zwischen den Geschäftsanforderungen.

Abbildung 1-2. Ausrichtung auf geschäftliche Kontexte versus technologische Kontexte

Die Modellierung von ereignisgesteuerten Microservices-Architekturen auf der Grundlage von Geschäftsanforderungen ist zu bevorzugen, auch wenn es bei diesem Ansatz Kompromisse gibt. Der Code kann mehrmals wiederholt werden, und viele Dienste können ähnliche Datenzugriffsmuster verwenden. Produktentwickler können versuchen, Wiederholungen zu reduzieren, indem sie Datenquellen mit anderen Produkten gemeinsam nutzen oder eine Kopplung an Grenzen vornehmen. In diesen Fällen kann die anschließende enge Kopplung auf lange Sicht viel kostspieliger sein als die Wiederholung von Logik und die Speicherung ähnlicher Daten. Diese Kompromisse werden im Laufe dieses Buches genauer untersucht.

Tipp

Achte auf eine lose Kopplung zwischen gebundenen Kontexten und konzentriere dich darauf, die Abhängigkeiten zwischen den Kontexten zu minimieren. So können die Implementierungen von Bounded Contexts bei Bedarf geändert werden, ohne dass viele (oder alle) anderen Systeme zerstört werden.

Darüber hinaus muss jedes Team über die gesamte Bandbreite an Fachkenntnissen verfügen, was durch den Bedarf an speziellen Fähigkeiten und Zugangsberechtigungen erschwert werden kann. Die Organisation sollte die häufigsten Anforderungen so operationalisieren, dass diese vertikalen Teams sich selbst unterstützen können, während spezialisiertere Fähigkeiten je nach Bedarf teamübergreifend bereitgestellt werden können. Diese bewährten Methoden werden in Kapitel 14 ausführlicher behandelt.

Strukturen der Kommunikation

Die Teams, Systeme und Menschen einer Organisation müssen miteinander kommunizieren, um ihre Ziele zu erreichen. Diese Kommunikation bildet eine vernetzte Topologie von Abhängigkeiten, die als Kommunikationsstruktur bezeichnet wird. Es gibt drei Hauptkommunikationsstrukturen, und jede beeinflusst die Art und Weise, wie Unternehmen arbeiten.

Strukturen der Unternehmenskommunikation

Die Struktur der Unternehmenskommunikation(Abbildung 1-3) bestimmt die Kommunikation zwischen den Teams und Abteilungen, die sich jeweils nach den wichtigsten Anforderungen und Verantwortlichkeiten richten, die ihnen zugewiesen sind. So produziert z. B. die Technik die Softwareprodukte, der Vertrieb verkauft an die Kunden und der Support sorgt dafür, dass die Kunden und Auftraggeber zufrieden sind. Die Organisation der Teams und die Festlegung ihrer Ziele, von den großen Geschäftsbereichen bis hin zur Arbeit des einzelnen Mitarbeiters, fallen unter diese Struktur. Die Geschäftsanforderungen, ihre Zuordnung zu den Teams und die Zusammensetzung der Teams ändern sich im Laufe der Zeit, was sich stark auf die Beziehung zwischen der Kommunikationsstruktur des Unternehmens und der Kommunikationsstruktur der Implementierung auswirken kann.

Abbildung 1-3. Beispiel für die Struktur der Unternehmenskommunikation

Umsetzung Kommunikationsstrukturen

Die Kommunikationsstruktur der Implementierung(Abbildung 1-4) umfasst die Daten und die Logik des Teilbereichsmodells, wie es von der Organisation vorgegeben wird. Sie formalisiert die Geschäftsprozesse, die Datenstrukturen und das Systemdesign, damit die Geschäftsvorgänge schnell und effizient durchgeführt werden können. Dies führt zu einem Kompromiss bei der Flexibilität der Geschäftskommunikationsstruktur, da eine Neudefinition der Geschäftsanforderungen, die von der Implementierung erfüllt werden müssen, eine Neufassung der Logik erfordert. Diese Neuformulierungen sind meist iterative Änderungen am Subdomänenmodell und dem zugehörigen Code, die im Laufe der Zeit die Entwicklung der Implementierung widerspiegeln, um die neuen Geschäftsanforderungen zu erfüllen.

Das Paradebeispiel für eine Kommunikationsstruktur in der Softwareentwicklung ist die monolithische Datenbankanwendung. Die Geschäftslogik der Anwendung kommuniziert intern entweder über Funktionsaufrufe oder einen gemeinsamen Status. Diese monolithische Anwendung wird wiederum verwendet, um die von der Kommunikationsstruktur vorgegebenen Geschäftsanforderungen zu erfüllen.

Abbildung 1-4. Beispiel für die Kommunikationsstruktur der Implementierung

Datenkommunikationsstrukturen

Die Datenkommunikationsstruktur(Abbildung 1-5) ist der Prozess, über den Daten innerhalb des Unternehmens und insbesondere zwischen Implementierungen kommuniziert werden. Obwohl eine Datenkommunikationsstruktur, die E-Mail, Instant Messaging und Meetings umfasst, häufig für die Kommunikation von geschäftlichen Änderungen verwendet wird, wurde sie bei Softwareimplementierungen weitgehend vernachlässigt. Ihre Rolle wurde meist ad hoc und von System zu System erfüllt, wobei die Kommunikationsstruktur der Implementierung oft eine doppelte Aufgabe übernahm, indem sie zusätzlich zu ihren eigenen Anforderungen auch Datenkommunikationsfunktionen enthielt. Dies hat zu vielen Problemen bei der Entwicklung und Veränderung von Unternehmen geführt, deren Auswirkungen im nächsten Abschnitt untersucht werden.

Abbildung 1-5. Beispiel für eine Ad-hoc-Datenkommunikationsstruktur

Das Conway'sche Gesetz und Kommunikationsstrukturen

Organisationen, die Systeme entwerfen, sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen widerspiegeln.

Melvin Conway - Wiemachen Ausschüsse Erfindungen? (April 1968)

Dieses Zitat, bekannt als Conways Gesetz, besagt, dass ein Team Produkte entsprechend der Kommunikationsstrukturen seiner Organisation entwickelt. Die geschäftlichen Kommunikationsstrukturen organisieren die Menschen in Teams, und diese Teams produzieren in der Regel Produkte, die durch ihre Teamgrenzen abgegrenzt sind. Implementierungs-Kommunikationsstrukturen ermöglichen den Zugang zu den Datenmodellen der Teilbereiche eines bestimmten Produkts, schränken aber auch den Zugang zu anderen Produkten ein, da die Datenkommunikation schwach ist.

Da Domänenkonzepte unternehmensübergreifend sind, werden Domänendaten oft von anderen Kontexten innerhalb einer Organisation benötigt. Die Kommunikationsstrukturen der Implementierung sind in der Regel schlecht geeignet, um diesen Kommunikationsmechanismus bereitzustellen, obwohl sie die Bedürfnisse ihres eigenen begrenzten Kontexts hervorragend erfüllen. Sie beeinflussen die Gestaltung von Produkten auf zweierlei Weise. Erstens halten sie von der Entwicklung neuer, logisch getrennter Produkte ab, weil die Kommunikation der erforderlichen Domänendaten innerhalb des Unternehmens ineffizient ist. Zweitens bieten sie einen einfachen Zugang zu den bestehenden Daten des Fachgebiets, auch auf die Gefahr hin, dass das Fachgebiet ständig erweitert werden muss, um die neuen Geschäftsanforderungen zu erfüllen. Dieses besondere Muster wird durch monolithische Designs verkörpert.

Datenkommunikationsstrukturen spielen eine zentrale Rolle bei der Entwicklung und Herstellung von Produkten, aber in vielen Unternehmen fehlt diese Struktur schon lange. Wie bereits erwähnt, spielen die Kommunikationsstrukturen für die Umsetzung häufig diese Rolle zusätzlich zu ihrer eigenen.

Einige Unternehmen versuchen, die Unmöglichkeit des Zugriffs auf Domänendaten von anderen Implementierungen aus abzumildern, aber diese Bemühungen haben ihre eigenen Nachteile. So werden beispielsweise häufig gemeinsam genutzte Datenbanken verwendet, die jedoch häufig Anti-Patterns fördern und oft nicht ausreichend skalierbar sind, um allen Leistungsanforderungen gerecht zu werden. Datenbanken können schreibgeschützte Replikate bereitstellen, was jedoch ihre inneren Datenmodelle unnötig offenlegen kann. Batch-Prozesse können Daten in einem Dateispeicher ablegen, damit sie von anderen Prozessen gelesen werden können, aber dieser Ansatz kann zu Problemen mit der Datenkonsistenz und mehreren Wahrheitsquellen führen. Schließlich führen all diese Lösungen zu einer starken Kopplung zwischen den Implementierungen und verfestigen eine Architektur mit direktenPunkt-zu-Punkt-Beziehungen.

Vorsicht

Wenn du feststellst, dass der Zugriff auf Daten in deinem Unternehmen zu schwierig ist oder dass deine Produkte den Anwendungsbereich einschränken, weil alle Daten in einer einzigen Implementierung gespeichert sind, hast du wahrscheinlich mit den Auswirkungen schlechter Datenkommunikationsstrukturen zu kämpfen. Dieses Problem wird sich verstärken, wenn das Unternehmen wächst, neue Produkte entwickelt und zunehmend auf häufig verwendete Domaindaten zugreifen muss.

Kommunikationsstrukturen im traditionellen Computing

Die Kommunikationsstrukturen eines Unternehmens haben einen großen Einfluss darauf, wie technische Implementierungen erstellt werden. Das gilt auch für die Teamebene: Die Kommunikationsstrukturen des Teams wirken sich auf die Lösungen aus, die es für die ihm zugewiesenen spezifischen Geschäftsanforderungen erstellt. Schauen wir uns an, wie das in der Praxis funktioniert.

Stell dir das folgende Szenario vor. Ein einzelnes Team hat einen einzigen Dienst, der von einem einzigen Datenspeicher unterstützt wird. Das Team ist mit der Erfüllung seiner Aufgaben zufrieden und alles ist gut. Eines Tages kommt der Teamleiter mit einer neuen Geschäftsanforderung herein. Sie hat etwas mit dem zu tun, was das Team bereits tut, und könnte möglicherweise einfach zu ihrem bestehenden Dienst hinzugefügt werden. Sie ist aber auch so anders, dass sie in einen eigenen neuen Dienst integriert werden könnte.

Das Team steht am Scheideweg: Sollen sie die neue Geschäftsanforderung in einem neuen Dienst umsetzen oder sie einfach zu ihrem bestehenden Dienst hinzufügen? Schauen wir uns ihre Optionen etwas genauer an.

Option 1: Einen neuen Dienst einrichten

Die Geschäftsanforderungen sind so unterschiedlich, dass es sinnvoll sein könnte, sie in einen neuen Dienst zu integrieren. Aber was ist mit den Daten? Die neue Geschäftsfunktion benötigt einige der alten Daten, aber diese Daten sind derzeit im bestehenden Dienst eingeschlossen. Außerdem hat das Team keinen wirklichen Prozess, um neue, völlig unabhängige Dienste einzuführen. Andererseits wird das Team langsam zu groß, und das Unternehmen wächst schnell. Wenn das Team in Zukunft aufgeteilt werden muss, könnten modulare und unabhängige Systeme die Aufteilung der Verantwortlichkeiten wesentlich erleichtern.

Dieser Ansatz birgt einige Risiken. Das Team muss einen Weg finden, Daten aus dem ursprünglichen Datenspeicher zu beziehen und in den neuen Datenspeicher zu kopieren. Dabei muss es sicherstellen, dass es sein Innenleben nicht preisgibt und dass die Änderungen, die es an seinen Datenstrukturen vornimmt, keine Auswirkungen auf andere Teams haben, die seine Daten kopieren. Außerdem werden die Daten, die kopiert werden, immer etwas veraltet sein, da sie es sich nur leisten können, die Produktionsdaten alle 30 Minuten in Echtzeit zu kopieren, um den Datenspeicher nicht mit Abfragen zu überschwemmen. Diese Verbindung muss überwacht und gewartet werden, um sicherzustellen, dass sie korrekt funktioniert.

Auch die Einrichtung und der Betrieb eines neuen Dienstes sind mit Risiken verbunden. Sie müssen zwei Datenspeicher und zwei Dienste verwalten und dafür Protokollierungs-, Überwachungs-, Test-, Bereitstellungs- und Rollback-Prozesse einrichten. Außerdem müssen sie dafür sorgen, dass Änderungen an der Datenstruktur synchronisiert werden, damit sie sich nicht auf das abhängige System auswirken.

Option 2: Hinzufügen zum bestehenden Dienst

Die andere Möglichkeit ist, die neuen Datenstrukturen und die Geschäftslogik innerhalb des bestehenden Dienstes zu erstellen. Die benötigten Daten befinden sich bereits im Datenspeicher, und die Prozesse für die Protokollierung, Überwachung, Prüfung, Bereitstellung und das Rollback sind bereits definiert und im Einsatz. Das Team ist mit dem System vertraut und kann sich sofort an die Implementierung der Logik machen, und die monolithischen Muster unterstützen diesen Ansatz der Dienstgestaltung.

Dieser Ansatz birgt auch Risiken, die allerdings etwas subtiler sind. Die Grenzen innerhalb der Implementierung können bei Änderungen verschwimmen, vor allem weil Module oft in derselben Codebasis gebündelt werden. Es ist viel zu einfach, schnell neue Funktionen hinzuzufügen, indem man diese Grenzen überschreitet und direkt mit dem Modul koppelt. Es ist ein großer Vorteil, schnell voranzukommen, aber der Preis dafür sind enge Kopplungen, weniger Zusammenhalt und ein Mangel an Modularität. Teams können dies zwar verhindern, aber das erfordert eine hervorragende Planung und die strikte Einhaltung von Grenzen, die angesichts enger Zeitpläne, Unerfahrenheit und wechselnderZuständigkeiten oft auf der Strecke bleiben.

Vor- und Nachteile der einzelnen Optionen

Die meisten Teams würden sich für die zweite Option entscheiden - das Hinzufügen der Funktionalität zum bestehenden System. An dieser Entscheidung ist nichts auszusetzen; monolithische Architekturen sind nützliche und leistungsfähige Strukturen und können einem Unternehmen einen außergewöhnlichen Nutzen bringen. Die erste Option stößt direkt auf zwei Probleme, die mit der traditionellen Datenverarbeitung verbunden sind:

• Es ist schwierig, zuverlässig auf die Daten eines anderen Systems zuzugreifen, vor allem in großem Umfang und in Echtzeit.

• Das Erstellen und Verwalten neuer Dienste ist mit erheblichem Aufwand und Risiko verbunden, vor allem, wenn es in der Organisation keine etablierte Methode dafür gibt.

Der Zugriff auf lokale Daten ist immer einfacher als der Zugriff auf Daten in einem anderen Datenspeicher. Daten, die im Datenspeicher eines anderen Teams gekapselt sind, sind nur schwer zugänglich, da sie sowohl die Grenzen der Implementierung als auch die der Geschäftskommunikation überschreiten müssen. Dies wird immer schwieriger zu warten und zu skalieren, wenn die Daten, die Anzahl der Verbindungen und die Leistungsanforderungen wachsen.

Das Kopieren der notwendigen Daten ist zwar ein lohnender Ansatz, aber nicht narrensicher. Dieses Modell fördert viele direkte Punkt-zu-Punkt-Kopplungen, deren Aufrechterhaltung problematisch wird, wenn eine Organisation wächst, Geschäftsbereiche und Eigentümer wechseln und Produkte reifen und auslaufen. Es schafft eine strikte technische Abhängigkeit zwischen den Kommunikationsstrukturen beider Teams (des Teams, das die Daten speichert, und des Teams, das sie kopiert), so dass sie bei jeder Datenänderung synchron arbeiten müssen. Es muss besonders darauf geachtet werden, dass das interne Datenmodell einer Implementierung nicht übermäßig offengelegt wird, damit sich nicht andere Systeme eng daran koppeln. Skalierbarkeit, Leistung und Systemverfügbarkeit sind oft ein Problem für beide Systeme, da die Abfrage der Datenreplikation eine untragbare Belastung für das Quellsystem darstellen kann. Fehlgeschlagene Synchronisierungsprozesse werden möglicherweise erst bemerkt, wenn ein Notfall eintritt. Stammeswissen kann dazu führen, dass ein Team eine Kopie der Daten kopiert und denkt, dass dies die ursprüngliche Quelle der Wahrheit ist.

Kopierte Daten werden immer etwas veraltet sein, wenn die Abfrage abgeschlossen ist und die Daten übertragen werden. Je größer der Datensatz und je komplexer seine Herkunft, desto wahrscheinlicher ist es, dass eine Kopie nicht mehr mit dem Original übereinstimmt. Das ist problematisch, wenn Systeme voneinander erwarten, dass sie über perfekte, aktuelle Kopien verfügen, vor allem, wenn sie miteinander über diese Daten kommunizieren. So kann es zum Beispiel sein, dass ein Meldedienst andere Werte meldet als ein Abrechnungsdienst, weil die Daten veraltet sind. Das kann schwerwiegende Folgen für die Servicequalität, das Berichtswesen, die Analyse und die monetäre Entscheidungsfindung haben.

Die Unfähigkeit, Daten in einem Unternehmen korrekt zu verbreiten, liegt nicht an einem grundlegenden Fehler im Konzept. Ganz im Gegenteil: Es liegt an einer schwachen oder gar nicht vorhandenen Datenkommunikationsstruktur. Im obigen Szenario erfüllt die Kommunikationsstruktur des Teams für die Umsetzung eine doppelte Aufgabe: Sie ist eine extrem eingeschränkte Datenkommunikationsstruktur.

Tipp

Einer der Grundsätze der ereignisgesteuerten Microservices ist, dass die Kerngeschäftsdaten leicht zu beschaffen und für jeden Dienst, der sie benötigt, nutzbar sein sollten. Damit wird die Ad-hoc-Datenkommunikationsstruktur in diesem Szenario durch eine formalisierte Datenstruktur ersetzt. Für das hypothetische Team könnte diese Datenkommunikationsstruktur die meisten Schwierigkeiten bei der Beschaffung von Daten aus anderen Systemen beseitigen.

Das Team-Szenario, Fortsetzung

Spulen Sie ein Jahr zurück. Das Team entschied sich für die Option 2 und integrierte die neuen Funktionen in denselben Dienst. Das ging schnell und einfach, und seitdem haben sie eine Reihe neuer Funktionen eingeführt. Da das Unternehmen gewachsen ist, ist auch das Team gewachsen, und jetzt ist es an der Zeit, es in zwei kleinere, konzentriertere Teams umzuorganisieren.

Jedem neuen Team müssen nun bestimmte Geschäftsfunktionen des vorherigen Dienstes zugewiesen werden. Die geschäftlichen Anforderungen der einzelnen Teams sind sauber nach den Bereichen aufgeteilt, die am meisten Aufmerksamkeit benötigen. Die Aufteilung der Kommunikationsstruktur für die Umsetzung erweist sich jedoch als nicht einfach. Nach wie vor scheint es, dass beide Teams große Mengen der gleichen Daten benötigen, um ihre Anforderungen zu erfüllen. Es stellen sich neue Fragen:

• Welches Team sollte welche Daten besitzen?

• Wo sollen die Daten gespeichert werden?

• Was ist mit Daten, bei denen beide Teams die Werte ändern müssen?

Die Teamleiter/innen beschließen, dass es am besten wäre, den Dienst zu teilen, damit beide an verschiedenen Teilen arbeiten können. Das erfordert viel mehr teamübergreifende Kommunikation und Synchronisation, was sich negativ auf die Produktivität auswirken kann. Und was ist mit der Zukunft, wenn sich die Größe des Unternehmens erneut verdoppelt? Oder wenn sich die Geschäftsanforderungen so stark ändern, dass nicht mehr alles mit der gleichen Datenstruktur erfüllt werden kann?

Widersprüchlicher Druck

Auf dem ursprünglichen Team lasten zwei gegensätzliche Zwänge. Es wurde beeinflusst, alle Daten lokal in einem Dienst zu halten, um das Hinzufügen neuer Geschäftsfunktionen schneller und einfacher zu machen, auf Kosten der Erweiterung der Kommunikationsstruktur für die Implementierung. Schließlich machte das Wachstum des Teams eine Aufteilung der Geschäftskommunikationsstruktur erforderlich - eine Anforderung, der die Neuzuweisung der Geschäftsanforderungen an die neuen Teams folgte. Die Kommunikationsstruktur für die Umsetzung kann jedoch die Neuzuweisungen in ihrer derzeitigen Form nicht unterstützen und muss in geeignete Komponenten aufgeteilt werden. Keiner der beiden Ansätze ist skalierbar und beide deuten darauf hin, dass wir die Dinge anders angehen müssen. Diese Probleme haben alle dieselbe Ursache: eine schwache, schlecht definierte Methode für die Datenübertragung zwischen den Kommunikationsstrukturen der Umsetzung.

Ereignisgesteuerte Kommunikationsstrukturen

Der ereignisgesteuerte Ansatz bietet eine Alternative zum traditionellen Verhalten von Implementierungs- und Datenkommunikationsstrukturen. Die ereignisbasierte Kommunikation ist kein Ersatz für die Anfrage-Antwort-Kommunikation, sondern eine völlig andere Art der Kommunikation zwischen Diensten. Eine ereignisbasierte Datenkommunikationsstruktur entkoppelt die Produktion und den Besitz von Daten vom Zugriff auf sie. Die Dienste koppeln sich nicht mehr direkt über eine Anfrage-Antwort-API, sondern über Ereignisdaten, die in Ereignisströmen definiert sind (auf diesen Prozess wird in Kapitel 3 näher eingegangen). Die Aufgaben der Produzenten beschränken sich darauf, genau definierte Daten in ihren jeweiligen Ereignisströmen zu produzieren.

Ereignisse sind die Grundlage der Kommunikation

Alle Daten, die geteilt werden können, werden in einer Reihe von Ereignisströmen veröffentlicht, die eine kontinuierliche, kanonische Erzählung über alles, was in der Organisation passiert ist, bilden. Dies ist der Kanal, über den die Systeme miteinander kommunizieren. Nahezu alles kann als Ereignis kommuniziert werden, von einfachen Ereignissen bis hin zu komplexen, zustandsbezogenen Aufzeichnungen. Ereignisse sind die Daten; sie sind nicht nur Signale, die anzeigen, dass Daten an anderer Stelle bereitstehen, oder nur ein Mittel zur direkten Datenübertragung von einer Implementierung zur anderen. Vielmehr fungieren sie sowohl als Datenspeicherung als auch als Mittel zur asynchronen Kommunikation zwischen Diensten.

Ereignisströme liefern die einzige Quelle der Wahrheit

Jedes Ereignis in einem Stream ist eine Tatsachenbehauptung, und zusammen bilden diese Aussagen die einzige Quelle der Wahrheit - die Grundlage der Kommunikation für alle Systeme innerhalb der Organisation. Eine Kommunikationsstruktur ist nur so gut wie der Wahrheitsgehalt ihrer Informationen. Deshalb ist es wichtig, dass die Organisation den Ereignisstrom als eine einzige Wahrheitsquelle akzeptiert. Wenn einige Teams stattdessen widersprüchliche Daten an anderen Stellen ablegen, wird die Funktion des Ereignisstroms als Rückgrat der Datenkommunikation im Unternehmen erheblich beeinträchtigt.

Verbraucher führen ihre eigene Modellierung und Abfrage durch

Die ereignisbasierte Datenkommunikationsstruktur unterscheidet sich von einer übermäßig ausgedehnten Implementierungskommunikationsstruktur dadurch, dass sie keine Abfrage- oder Datenabfragefunktionen bietet. Die gesamte Geschäfts- und Anwendungslogik muss in den Produzenten und Konsumenten der Ereignisse gekapselt sein.

Die Anforderungen an den Datenzugriff und die Modellierung werden vollständig auf den Verbraucher verlagert, wobei jeder Verbraucher seine eigene Kopie der Ereignisse aus den Quell-Ereignisströmen erhält. Auch die Komplexität der Abfragen wird von der Kommunikationsstruktur des Dateneigentümers auf die des Verbrauchers verlagert. Der Verbraucher ist weiterhin für das Mischen von Daten aus mehreren Ereignisströmen, spezielle Abfragefunktionen oder andere geschäftsspezifische Implementierungslogik verantwortlich. Sowohl Produzenten als auch Konsumenten sind ansonsten von ihrer Pflicht entbunden, Abfragemechanismen, Datenübertragungsmechanismen, APIs (Application Programming Interfaces) und teamübergreifende Dienste für die Datenübermittlung bereitzustellen. Sie sind jetzt nur noch dafür verantwortlich, die Anforderungen ihres unmittelbaren Umfelds zu erfüllen.

Die Datenkommunikation wird in der gesamten Organisation verbessert

Die Verwendung einer Datenkommunikationsstruktur ist eine Umkehrung, bei der alle gemeinsam nutzbaren Daten außerhalb der Kommunikationsstruktur der Implementierung veröffentlicht werden. Nicht alle Daten müssen gemeinsam genutzt werden, und daher müssen auch nicht alle Daten in den Ereignisströmen veröffentlicht werden. Allerdings müssen alle Daten, die für ein anderes Team oder einen anderen Dienst von Interesse sind, in den gemeinsamen Ereignisströmen veröffentlicht werden, so dass die Produktion und der Besitz von Daten vollständig entkoppelt werden. So wird die Datenproduktion und der Besitz von Daten vollständig entkoppelt. Dies liefert die formalisierte Datenkommunikationsstruktur, die lange Zeit in Systemarchitekturen fehlte, und hält sich besser an die Bounded-Context-Prinzipien der losen Kopplung und der hohen Kohäsion.

Anwendungen können jetzt auf Daten zugreifen, die sonst nur mühsam über Punkt-zu-Punkt-Verbindungen zu beschaffen gewesen wären. Neue Dienste können einfach alle benötigten Daten aus den kanonischen Ereignisströmen beziehen, ihre eigenen Modelle und Zustände erstellen und alle notwendigen Geschäftsfunktionen ausführen, ohne auf direkte Punkt-zu-Punkt-Verbindungen oder APIs mit anderen Diensten angewiesen zu sein. So kann ein Unternehmen seine riesigen Datenmengen in jedem Produkt effektiver nutzen und sogar Daten aus mehreren Produkten auf einzigartige und leistungsstarke Weise mischen.

Zugängliche Daten unterstützen Veränderungen in der Unternehmenskommunikation

Ereignisströme enthalten wichtige Ereignisse, die für den Betrieb des Unternehmens von zentraler Bedeutung sind. Auch wenn Teams umstrukturiert werden und Projekte kommen und gehen, bleiben die wichtigen Kerndaten für jedes neue Produkt, das sie benötigt, unabhängig von einer bestimmten Kommunikationsstruktur der Implementierung verfügbar. Das gibt dem Unternehmen eine unvergleichliche Flexibilität, da der Zugriff auf die Kerndaten nicht mehr von einer bestimmten Implementierung abhängt.

Asynchrone ereignisgesteuerte Microservices

Ereignisgesteuerte Microservices ermöglichen die Transformationen und Operationen der Geschäftslogik, die erforderlich sind, um die Anforderungen des begrenzten Kontexts zu erfüllen. Diese Anwendungen haben die Aufgabe, diese Anforderungen zu erfüllen und alle notwendigen Ereignisse an andere nachgelagerte Verbraucher weiterzuleiten. Hier sind einige der wichtigsten Vorteile der Verwendung von ereignisgesteuerten Microservices:

Granularität

Dienste lassen sich gut auf begrenzte Kontexte abbilden und können leicht umgeschrieben werden, wenn sich die Geschäftsanforderungen ändern.

Skalierbarkeit

Einzelne Dienste können je nach Bedarf hoch- oder runtergestuft werden.

Technologische Flexibilität

Die Dienste verwenden die am besten geeigneten Sprachen und Technologien. Dies ermöglicht auch ein einfaches Prototyping mit bahnbrechender Technologie.

Flexibilität der Geschäftsanforderungen

Die Zuständigkeit für granulare Microservices lässt sich leicht umorganisieren. Im Vergleich zu großen Diensten gibt es weniger teamübergreifende Abhängigkeiten, und das Unternehmen kann schneller auf Änderungen der Geschäftsanforderungen reagieren, die sonst durch Barrieren beim Datenzugriff behindert würden.

Lose Kopplung

Ereignisgesteuerte Microservices sind an Domänendaten gekoppelt und nicht an eine bestimmte Implementierungs-API. Mit Hilfe von Datenschemata kann die Verwaltung von Datenänderungen erheblich verbessert werden, wie in Kapitel 3 erläutert wird.

Unterstützung der kontinuierlichen Lieferung

Es ist einfach, einen kleinen, modularen Microservice auszuliefern und ihn bei Bedarf wieder zurückzunehmen.

Hohe Testbarkeit

Microservices haben in der Regel weniger Abhängigkeiten als große Monolithen, was es einfacher macht, die erforderlichen Test-Endpunkte zu mocken und eine angemesseneCodeabdeckung zu gewährleisten.

Beispielteam mit ereignisgesteuerten Microservices

Kommen wir noch einmal auf das Team von vorhin zurück, aber mit einer ereignisgesteuerten Datenkommunikationsstruktur.

Eine neue Geschäftsanforderung wird dem Team vorgestellt. Sie hat etwas mit den aktuellen Produkten zu tun, ist aber auch so unterschiedlich, dass sie in einen eigenen Dienst aufgenommen werden könnte. Verstößt das Hinzufügen dieser Anforderung zu einem bestehenden Dienst gegen das Prinzip der einzigen Verantwortung und übersteigt den derzeit definierten begrenzten Kontext? Oder handelt es sich um eine einfache Erweiterung eines bestehenden Dienstes, vielleicht um neue Daten oder Funktionen?

Frühere technische Probleme - wie z. B. die Frage, woher die Daten kommen und wie sie gesenkt werden können, Probleme bei der Batch-Synchronisierung und die Implementierung synchroner APIs - sind jetzt weitgehend gelöst. Das Team kann einen neuen Microservice aufsetzen und die erforderlichen Daten aus den Ereignisströmen einlesen, bei Bedarf sogar bis zum Beginn der Zeit zurück. Es ist durchaus möglich, dass das Team die in anderen Diensten verwendeten Daten mit einbezieht, solange diese Daten nur für die Anforderungen des neuen Kontexts verwendet werden. Die Speicherung und Struktur dieser Daten ist ganz dem Team überlassen, das entscheiden kann, welche Felder es behält und welche es verwirft.

Auch die geschäftlichen Risiken werden gemildert, da die kleinen, feinkörnigen Dienste eine einzige Teamverantwortung ermöglichen, so dass die Teams bei Bedarf skalieren und umorganisieren können. Wenn das Team zu groß wird, um von einem einzigen Eigentümer verwaltet zu werden, kann es sich nach Bedarf aufteilen und die Verantwortung für den Microservice neu zuweisen. Das Eigentum an den Ereignisdaten wechselt mit dem produzierenden Dienst, und es können organisatorische Entscheidungen getroffen werden, um den Umfang der teamübergreifenden Kommunikation zu reduzieren, die für die Durchführung künftiger Arbeiten erforderlich ist.

Die Natur des Microservice verhindert, dass sich Spaghetti-Code und ausgedehnte Monolithen durchsetzen, vorausgesetzt, der Aufwand für die Erstellung neuer Dienste und die Beschaffung der erforderlichen Daten ist minimal. Die Skalierung konzentriert sich nun auf die einzelnen ereignisverarbeitenden Dienste, die ihre CPU, ihren Speicher, ihre Festplatte und die Anzahl der Instanzen nach Bedarf skalieren können. Die restlichen Skalierungsanforderungen werden auf die Datenkommunikationsstruktur verlagert, die sicherstellen muss, dass sie die verschiedenen Lasten der Dienste, die ihre Ereignisströme konsumieren und produzieren, bewältigen kann.

Dazu muss das Team jedoch sicherstellen, dass die Daten auch tatsächlich in der Datenkommunikationsstruktur vorhanden sind, und es muss die Möglichkeit haben, eine Flotte von Microservices einfach aufzusetzen und zu verwalten. Dies erfordert eine organisationsweite Einführung der EDM-Architektur.

Synchrone Microservices

Microservices können asynchron mit Hilfe von Ereignissen implementiert werden (der Ansatz, den dieses Buch befürwortet) oder synchron, wie es in serviceorientierten Architekturen üblich ist. Synchrone Microservices werden in der Regel über einen Request-Response-Ansatz realisiert, bei dem die Dienste direkt über APIs kommunizieren, um die Geschäftsanforderungen zu erfüllen.

Nachteile von synchronen Microservices

Es gibt eine Reihe von Problemen mit synchronen Microservices, die es schwierig machen, sie in großem Maßstab einzusetzen. Das heißt nicht, dass ein Unternehmen mit synchronen Microservices nicht erfolgreich sein kann, wie die Erfolge von Unternehmen wie Netflix, Lyft, Uber und Facebook zeigen. Aber viele Unternehmen haben auch mit archaischen und schrecklich verworrenen Spaghetti-Code-Monolithen ein Vermögen gemacht, also verwechsle nicht den letztendlichen Erfolg eines Unternehmens mit der Qualität der zugrunde liegenden Architektur. Es gibt eine Reihe von Büchern, die beschreiben, wie man synchrone Microservices implementiert. Ich empfehle dir, diese zu lesen, um ein besseres Verständnis für synchrone Ansätze zu bekommen.¹

Außerdem ist zu beachten, dass weder Punkt-zu-Punkt-Anfrage-Antwort-Microservices noch asynchrone ereignisgesteuerte Microservices grundsätzlich besser sind als die anderen. Beide haben ihren Platz in einer Organisation, denn manche Aufgaben sind für die eine besser geeignet als für die andere. Meine eigene Erfahrung und die vieler meiner Kollegen und Kolleginnen zeigt jedoch, dass EDM-Architekturen eine unvergleichliche Flexibilität bieten, die bei synchronen Request-Response-Microservices fehlt. Vielleicht wirst du im Laufe dieses Buches anderer Meinung sein, aber zumindest wirst du ein Verständnis für ihre Stärken und Nachteile entwickeln.

Hier sind einige der größten Unzulänglichkeiten von synchronen Request-Response Microservices.

Punkt-zu-Punkt-Kupplungen

Synchrone Microservices sind auf andere Dienste angewiesen, damit sie ihre Aufgaben erfüllen können. Diese Dienste haben wiederum ihre eigenen abhängigen Dienste, die wiederum ihre eigenen abhängigen Dienste haben, und so weiter. Das kann zu einer übermäßigen Auffächerung führen und die Nachverfolgung der Dienste erschweren, die für bestimmte Teile der Geschäftslogik verantwortlich sind. Die Anzahl der Verbindungen zwischen den Diensten kann schwindelerregend hoch werden, was die bestehenden Kommunikationsstrukturen weiter verfestigt und zukünftige Änderungen erschwert.

Abhängige Skalierung

Die Fähigkeit, den eigenen Dienst zu skalieren, hängt von der Fähigkeit aller abhängigen Dienste ab, ebenfalls zu skalieren, und steht in direktem Zusammenhang mit dem Grad des Kommunikations-Fanouts. Implementierungstechnologien können einen Engpass für die Skalierbarkeit darstellen. Dies wird durch stark schwankende Lasten und schwankende Anfragemuster, die in der gesamten Architektur synchron verarbeitet werden müssen, zusätzlich erschwert.

Behandlung von Dienstausfällen

Wenn ein abhängiger Dienst ausfällt, müssen Entscheidungen getroffen werden, wie mit der Ausnahme umgegangen werden soll. Die Entscheidung, wie man mit Ausfällen umgeht, wann man es erneut versucht, wann man fehlschlägt und wie man die Datenkonsistenz wiederherstellt, wird umso schwieriger, je mehr Dienste es im Ökosystem gibt.

API-Versionierung und Abhängigkeitsmanagement

Oft müssen mehrere API-Definitionen und Dienstversionen gleichzeitig existieren. Es ist nicht immer möglich oder wünschenswert, Kunden zum Upgrade auf die neueste API zu zwingen. Dies kann die Orchestrierung von API-Änderungsanfragen über mehrere Dienste hinweg sehr kompliziert machen, vor allem wenn sie mit Änderungen an den zugrunde liegenden Datenstrukturen einhergehen.

An die Umsetzung gebundener Datenzugriff

Synchrone Microservices haben dieselben Probleme wie traditionelle Dienste, wenn es um den Zugriff auf externe Daten geht. Es gibt zwar Strategien für das Design von Diensten, umdie Notwendigkeit des Zugriffs auf externe Datenzu verringern, doch müssen Microservices häufig trotzdem auf häufig verwendete Daten anderer Dienste zugreifen. Damit liegt die Verantwortung für den Datenzugriff und die Skalierbarkeit wieder bei der Kommunikationsstruktur der Implementierung.

Verteilte Monolithen

Dienste können so komponiert werden, dass sie wie ein verteilter Monolith wirken, wobei viele ineinandergreifende Aufrufe zwischen ihnen gemacht werden. Diese Situation entsteht oft, wenn ein Team einen Monolithen zerlegt und beschließt, synchrone Punkt-zu-Punkt-Aufrufe zu verwenden, um die bestehenden Grenzen innerhalb ihres Monolithen nachzuahmen. Punkt-zu-Punkt-Dienste machen es einfach, die Grenzen zwischen den abgegrenzten Kontexten zu verwischen, da sich die Funktionsaufrufe zu entfernten Systemen Zeile für Zeile in den bestehenden Monolith-Code einfügen können.

Testen

Integrationstests können schwierig sein, da jeder Dienst voll funktionsfähige abhängige Dienste benötigt, die wiederum ihre eigenen benötigen. Sie auszulagern mag für Unit-Tests funktionieren, reicht aber selten für umfangreichere Testanforderungen aus.

Vorteile von synchronen Microservices

Es gibt eine Reihe von unbestreitbaren Vorteilen, die synchrone Microservices bieten. Bestimmte Datenzugriffsmuster eignen sich gut für direkte Anfrage-Antwort-Kopplungen, z. B. die Authentifizierung eines Benutzers und die Berichterstattung über einen AB-Test. Integrationen mit externen Lösungen von Drittanbietern verwenden fast immer einen synchronen Mechanismus und bieten im Allgemeinen einen flexiblen, sprachunabhängigen Kommunikationsmechanismus über HTTP.

Die Verfolgung von Vorgängen über mehrere Systeme hinweg kann in einer synchronen Umgebung einfacher sein als in einer asynchronen. Detaillierte Protokolle können zeigen, welche Funktionen auf welchen Systemen aufgerufen wurden, was eine hohe Fehlersuchbarkeit und Transparenz der Geschäftsabläufe ermöglicht.

Dienste, die Web- und Mobilerlebnisse hosten, werden im Großen und Ganzen durch Anfrage-Antwort-Designs betrieben, unabhängig davon, ob sie synchron oder asynchron sind. Die Kunden erhalten eine zeitnahe Antwort, die ganz auf ihre Bedürfnisse zugeschnitten ist.

Der Faktor Erfahrung ist ebenfalls sehr wichtig, vor allem weil viele Entwickler/innen auf dem heutigen Markt viel mehr Erfahrung mit synchroner, monolithischer Programmierung haben. Das macht es im Allgemeinen einfacher, Talente für synchrone Systeme zu finden als für asynchrone, ereignisgesteuerte Entwicklung.

Tipp

Die Architektur eines Unternehmens wird nur selten, wenn überhaupt, vollständig auf ereignisgesteuerten Microservices basieren. Hybride Architekturen werden sicherlich die Norm sein, bei denen synchrone und asynchrone Lösungen nebeneinander eingesetzt werden, je nachdem, was die Problemstellung erfordert.

Zusammenfassung

Kommunikationsstrukturen bestimmen, wie Software im Laufe des Lebens einer Organisation erstellt und verwaltet wird. Datenkommunikationsstrukturen sind oft unterentwickelt und ad hoc, aber die Einführung eines dauerhaften, leicht zugänglichen Satzes von Domänenereignissen, wie sie von ereignisgesteuerten Systemen verkörpert werden, ermöglicht die Verwendung kleinerer, zweckgebundener Implementierungen.

¹ Siehe z.B. Building Microservices von Sam Newman (O'Reilly, 2015) und Microservices for the Enterprise von Kasun Indrasiri und Prabath Siriwardena (Apress, 2018).