Schritt 2: Organisiere deine Teams auf die richtige Weise

Bisher schien der Aufbau von Microservices im Wesentlichen eine technische Angelegenheit zu sein. Man musste eine Codebasis in mehrere Services aufteilen, die richtigen Muster implementieren, um die Services bei Fehlern ordnungsgemäß zu beenden und nach Netzwerkproblemen wiederherzustellen, mit der Datenkonsistenz umzugehen, die Servicelast zu überwachen usw. Jetzt musst du dich mit einer Vielzahl neuer Konzepte vertraut machen. Was du jedoch unbedingt berücksichtigen musst, ist die Umstrukturierung der Organisation deiner Teams.

Das Gesetz von Conway ist keine Erfindung, sondern lässt sich in allen Arten von Teams beobachten. Ein Softwareteam, das sich aus drei unabhängig voneinander arbeitenden Teams im Backend, im Frontend und im Betrieb zusammensetzt, entwickelt separate Frontend- und Backend-Monolithen, die das Betriebsteam ohne jegliche Möglichkeit der Einflussnahme in die Produktion übernehmen muss. Diese Art von Struktur ist für Microservices nicht geeignet, da jeder Service als ein eigenes Produkt gelten sollte, das unabhängig von den anderen ausgeliefert werden muss.

Stattdessen solltest du kleinere DevOps-Teams bilden, die über alle Kompetenzen verfügen, die sowohl für die Entwicklung als auch die Wartung ihrer jeweiligen Services erforderlich sind. Es hat große Vorteile, deine Teams auf diese Weise zu organisieren. Zunächst einmal bekommen deine Entwickler eine bessere Vorstellung von den Auswirkungen ihres Codes in der Produktion. Das hilft ihnen dabei, bessere Releases zu erstellen und verringert das Risiko von Problemen für die Kunden. Zweitens werden Deployments für jedes Team zu einer Selbstverständlichkeit, da sie an Verbesserungen des Codes und an der Automatisierung der Deployment-Pipeline gemeinsam arbeiten.

Schritt 3: Teile den Monolith auf, um eine Microservices-Architektur zu erstellen

Sobald du die Grenzen deiner Services ermittelt hast und weißt, wie du deine Teams umstrukturieren willst, kannst du deinen Monolithen aufteilen und mit der Erstellung der Microservices beginnen. Im Folgenden findest du die wichtigsten Punkte, über die du zu diesem Zeitpunkt nachdenken solltest.

Eine RESTful API sorgt für einfache Kommunikation zwischen Services

Wenn du noch keine REST-API verwendest, ist dies jetzt ein guter Zeitpunkt, sie in deinem System einzuführen. Wie Martin Fowler erklärt, brauchst du "intelligente Endpunkte und dumme Pipes". Das Kommunikationsprotokoll zwischen deinen Services sollte so einfach wie möglich und nur für die Übertragung von Daten verantwortlich sein, ohne sie zu transformieren. Das eigentliche Wunder findet an den Endpunkten statt: Sie erhalten eine Anfrage, verarbeiten sie und geben im Gegenzug eine Antwort aus.

Microservices-Architekturen streben danach, die Dinge so einfach wie möglich zu halten, um eine enge Kopplung der Komponenten zu vermeiden. In einigen Fällen kannst du eine ereignisgesteuerte Architektur mit asynchroner nachrichtenbasierter Kommunikation verwenden. Aber du solltest dir auf jeden Fall grundlegende Warteschlangenservices für Nachrichten wie RabbitMQ ansehen und vermeiden, die über das Netzwerk übertragenen Nachrichten komplexer zu machen.

Teile Daten in Kontextgrenzen oder Datendomänen auf

Monolith-Anwendungen verwenden eine einzelne Datenbank für alle Geschäftsfunktionen der Anwendung. Wenn ein Monolith in Microservices aufgebrochen wird, ergibt diese einzelne Datenbank keinen Sinn mehr. Eine zentrale Datenbank kann bei der Skalierung des Datenverkehrs sogar zum Engpass werden. Wenn ein bestimmter Service mit hoher Last auf die Datenbank zugreift, wird unter Umständen der Datenbankzugriff eines anderen Services unterbrochen. Darüber hinaus kann eine einzelne Datenbank die Zusammenarbeit mehrerer Teams beeinträchtigen, die versuchen, das Schema gleichzeitig zu verändern. Dann wird möglicherweise eine Aufteilung der Datenbank notwendig oder es müssen zusätzliche Datenspeichertools hinzugefügt werden, um die Datenanforderungen der Microservices zu erfüllen.

Das Refactoring eines monolithischen Datenbankschemas kann eine heikle Angelegenheit sein. Es muss eindeutig definiert werden, welche Datensätze jeder Service benötigt und wo es zu Überscheidungen kommt. Eine solche Schemaplanung kann mit Hilfe von Kontextgrenzen erfolgen, einem Muster aus dem Domain Driven Design. Eine Kontextgrenze wird als eigenständiges System definiert, einschließlich der Ein- und Ausgänge in bzw. aus dem System.

Wenn ein Benutzer in diesem System auf eine Bestellung zugreift, kannst du seine Kundeninformationen in einer Tabelle anzeigen. Diese Tabelle kann zudem genutzt werden, um die vom Abrechnungssystem verwaltete Rechnung zu befüllen. All das scheint logisch und einfach zu sein, aber mit Microservices sollten diese Services entkoppelt werden, damit auf Rechnungen auch dann zugegriffen werden kann, wenn das Bestellsystem nicht verfügbar ist. Außerdem kannst du die Rechnungstabelle unabhängig von anderen Services optimieren oder weiterentwickeln. Jeder Service verfügt somit möglicherweise über einen eigenen Datenspeicher, um auf die benötigten Daten zuzugreifen.

Aber es entstehen dadurch auch neue Probleme, da einige Daten in verschiedenen Datenbanken dupliziert werden. Kontextgrenzen können den besten Ansatz für den Umgang mit gemeinsam genutzten oder duplizierten Daten aufzeigen. Du solltest eine ereignisgesteuerte Architektur einführen, um die serviceübergreifende Synchronisierung von Daten zu unterstützen. Zum Beispiel können deine Abrechnungs- und Lieferverfolgungsservices auf Ereignisse des Kontoservices reagieren, wenn Kunden ihre persönlichen Daten aktualisieren. Nachdem die Services dieses Ereignis empfangen haben, aktualisieren sie ihren Datenspeicher entsprechend. Diese ereignisgesteuerte Architektur ermöglicht es, die Kontoservicelogik einfach zu halten, da sie nicht alle anderen abhängigen Services kennen muss. Sie teilt dem System einfach mit, was geschehen ist, und die anderen Services reagieren entsprechend darauf.

Du kannst auch alle Kundeninformationen im Kontoservice und nur eine Fremdschlüsselreferenz in deinem Abrechnungs- und Lieferservice aufbewahren. Du interagierst dann mit dem Kontodienst, um bei Bedarf die relevanten Kundendaten zu erhalten, anstatt vorhandene Datensätze zu duplizieren. Es gibt keine universelle Lösung für diese Probleme und du musst dich mit jedem Einzelfall befassen, um festzustellen, welcher Ansatz jeweils der beste ist.

Plane beim Aufbau deiner Microservices-Architektur das Auftreten von Fehlern ein

Wir haben gesehen, wie Microservices gegenüber einer monolithischen Architektur große Vorteile bieten können. Sie sind kleiner und spezialisiert, was sie leicht verständlich macht. Sie sind entkoppelt, was bedeutet, dass du einen Service refaktorieren kannst, ohne befürchten zu müssen, die anderen Komponenten des Systems zu beschädigen oder die Entwicklung der anderen Teams zu verlangsamen. Sie bieten deinen Entwicklern auch mehr Flexibilität, da sie bei Bedarf verschiedene Technologien auswählen können, ohne durch die Anforderungen anderer Services eingeschränkt zu werden.

Kurz gesagt, eine Microservices-Architektur erleichtert die Entwicklung und Aufrechterhaltung jeder Geschäftsfunktion. Wie alle Services in ihrer Gesamtheit miteinander interagieren, um Aktionen durchzuführen, ist jedoch etwas komplizierter. Dein System ist jetzt verteilt und verfügt über mehrere mögliche Schwachstellen, die du berücksichtigen musst. Dabei geht es nicht nur um fehlende Reaktionen eines Services, sondern auch um den Umgang mit langsameren Reaktionen im Netzwerk. Die Wiederherstellung nach einem Fehler kann ebenfalls manchmal schwierig sein, da du sicherstellen musst, dass Services, die wieder in Betrieb gehen und ausgeführt werden, nicht durch ausstehende Nachrichten überflutet werden.

Wenn du damit beginnst, Funktionen aus deinen monolithischen Systemen zu extrahieren, darfst du auf keinen Fall vergessen, von Anfang an den Umgang mit Fehlern einzuplanen.

Lege Wert auf Überwachung, um das Testen von Microservices zu erleichtern

Tests sind ein weiterer Nachteil von Microservices im Vergleich zu einem monolithischen System. Eine Anwendung, die als eine einzige Codebasis erstellt wird, benötigt nicht viel, um eine Testumgebung in Betrieb zu nehmen. In den meisten Fällen musst du einen Backend-Server in Verbindung mit einer Datenbank starten, um deine Testsuite ausführen zu können.

In der Welt der Microservices ist dies nicht so einfach. Komponententests dürften sich nicht allzu sehr von denen des Monoliths unterscheiden und sollten dir keine Probleme bereiten. Integrations- und Systemtests gestalten sich hingegen schwieriger. Unter Umständen musst du mehrere Services zusammen starten, verschiedene Datenspeicher in Betrieb nehmen und deine Konfiguration muss möglicherweise Nachrichtenwarteschlangen enthalten, die bei deinem Monolith nicht erforderlich waren. In dieser Situation wird die Durchführung von Funktionstests wesentlich kostspieliger und die zunehmende Anzahl von dynamischen Elementen macht es sehr schwierig, die verschiedenen Arten von Fehlern vorherzusagen, die auftreten können.

Mithilfe der Überwachung kannst du Probleme frühzeitig erkennen und entsprechend reagieren. Du musst die Grundlagen deiner verschiedenen Services verstehen und nicht nur reagieren können, wenn sie ausfallen, sondern auch, wenn sie sich unerwartet verhalten. Ein Vorteil der Einführung einer Microservices-Architektur besteht darin, dass dein System gegen teilweisen Ausfall widerstandsfähig sein sollte. Wenn du also Anomalien im Lieferverfolgungsservice unserer Pizzup-Anwendung feststellst, ist dies weniger schlimm als in einem monolithischen System. Unsere Anwendung sollte so gestaltet sein, dass alle anderen Services ordnungsgemäß reagieren und unsere Kunden Pizzen bestellen können, während wir die Live-Lieferverfolgung wiederherstellen.

Nutze Continuous Delivery für reibungslosere Deployments

Die manuelle Freigabe eines monolithischen Systems in die Produktion ist mühsam und riskant, aber nicht unmöglich. Natürlich empfehlen wir diesen Ansatz nicht und ermutigen jedes Softwareteam, Continuous Delivery für alle Entwicklungsarbeiten zu nutzen. Zu Beginn eines Projekts kannst du jedoch deine ersten Deployments selbst über die Befehlszeile durchführen.

Dieser Ansatz ist nicht nachhaltig, wenn du eine zunehmende Anzahl von Services hast, die mehrmals täglich bereitgestellt werden müssen. Daher ist es im Rahmen deiner Umstellung auf Microservices von entscheidender Bedeutung, dass du Continuous Delivery einführst, um das Risiko eines Releasefehlers zu reduzieren und sicherzustellen, dass sich dein Team auf die Entwicklung und den Betrieb der Anwendung konzentriert, anstatt sich mit dem Deployment aufzuhalten. Continuous Delivery bedeutet auch, dass dein Service Akzeptanztests bestanden hat, bevor er in die Produktion geht. Natürlich werden Fehler auftreten, aber im Laufe der Zeit entsteht eine robuste Testsuite, sodass sich dein Team zunehmend auf die Qualität der Releases verlassen kann.