Vom Monolithen zu Microservices

Patterns, um bestehende Systeme Schritt für Schritt umzugestalten

Sam Newman, Thomas Demmig

• Verlag: O'Reilly
• Jahr: 2020
• ISBN:
  9783960104247
• Thema: Ciencia de la computación
• Thema: Desarrollo de software

Bestehende Systeme erfolgreich in eine Microservices-Architektur umgestalten

• Unerlässliches Expertenwissen für Organisationen, die ihre Codebasis modernisieren wollen
• Autor des geschätzten Grundlagenwerks »Building Microservices«
• Orientierung und Anleitung für den anspruchsvollen Migrationsprozess

Wie entflechtet man ein monolithisches System und überführt es in eine Microservices-Architektur? Und wie erhält man gleichzeitig den normalen Betrieb aufrecht? Sam Newman, Autor des viel beachteten Titels "Building Microservices", beschreibt Szenarien und erprobte Strategien, um bestehende Systeme erfolgreich zu migrieren: von der ersten Planung bis zum Zerlegen von Anwendung und Datenbank. Newman greift hierbei auf viele anschauliche Beispiele zurück, stellt aufschlussreiche Pattern für die Migration vor und gibt praktische Ratschläge.

- Für Organisationen, die ihre Codebasis in Richtung einer Microservices-Architektur überführen und nicht komplett neu aufbauen wollen

- Unterstützt Unternehmen bei der Frage, ob und wann sie migrieren und wo sie konkret beginnen sollten

- Befasst sich mit der Integration und Migration von Legacy-Systemen und der Kommunikation mit diesen Systemen

- Stellt Migrationspattern vor und beschreibt, wo und wie sie am besten eingesetzt werden

- Bietet Beispiele für die Datenbankmigration und begleitende Synchronisationsstrategien

- Beschreibt das Zerlegen von Anwendungen einschließlich einer Reihe von Refaktorisierungspattern

KAPITEL 1

Gerade genug Microservices

Mann, das ist ganz schön eskaliert!

– Ron Burgundy, Anchorman – Die Legende von Ron Burgundy

Bevor wir uns eingehender damit befassen, wie man mit Microservices arbeitet, ist es wichtig, ein gemeinsames Verständnis von der Microservices-Architektur zu erlangen. Ich möchte ein paar Missverständnisse ansprechen, denen ich regelmäßig begegne, aber auch auf Feinheiten hinweisen, die oft übersehen werden. Sie werden diese Grundlagen benötigen, um das Beste auf dem Rest des Buchs herausholen zu können. Daher finden Sie in diesem Kapitel eine Erläuterung von Microservices-Architekturen, es wird kurz ein Blick darauf geworfen, wie sich Microservices entwickelt haben (womit wir logischerweise auch auf Monolithen eingehen müssen), und einige der Vorteile und Herausforderungen bei der Arbeit mit Microservices werden unter die Lupe genommen.

Was sind Microservices?

Microservices sind unabhängig deploybare Services, die rund um eine Businessdomäne modelliert wurden. Sie kommunizieren untereinander über das Netzwerk und bieten als Architektur viele Möglichkeiten, Probleme zu lösen, denen Sie sich gegenübersehen. Damit basiert eine Microservices-Architektur auf vielen zusammenarbeitenden Microservices.

Es handelt sich um einen Typ einer serviceorientierten Architektur (SOA), wenn auch mit einer starken Meinung dazu, wo die Servicegrenzen gezogen werden sollten und dass eine unabhängige Deploybarkeit entscheidend ist. Microservices haben zudem den Vorteil, aus Technologiesicht agnostisch zu sein.

Aus technologischer Perspektive stellen Microservices die Businessfähigkeiten bereit, die sie über einen oder mehrere Endpunkte im Netz kapseln. Microservices kommunizieren untereinander über dieses Netzwerk – und machen sich damit zu einem verteilten System. Zudem kapseln sie das Speichern und Einlesen von Daten sowie das Bereitstellen von Daten über wohldefinierte Schnittstellen. Daher werden Datenbanken innerhalb der Servicegrenzen verborgen.

Es gibt dabei manches, was genauer zu betrachten ist, daher wollen wir uns einige dieser Ideen im Detail anschauen.

Unabhängige Deploybarkeit

Unabhängige Deploybarkeit ist die Idee, einen Microservice ändern und in eine Produktivumgebung deployen zu können, ohne dabei andere Services anfassen zu müssen. Wichtiger ist noch, dass es nicht darum geht, es tun zu können – es ist der Weg, wie Sie Deployments in Ihrem System tatsächlich umsetzen. Dabei handelt es sich um eine Disziplin, die Sie für den allergrößten Teil Ihrer Releases einhalten. Eine einfache Idee, die dennoch in der Ausführung kompliziert ist.

Wenn Sie aus diesem Buch nur eine Sache mitnehmen wollen, dann sollte es diese sein: Stellen Sie sicher, dass Sie das Konzept der unabhängigen Deploybarkeit Ihrer Microservices verstanden haben. Machen Sie es sich zur Gewohnheit, Änderungen an einem einzelnen Microservice in die Produktivumgebung zu bringen, ohne etwas anderes deployen zu müssen. Aus dieser Disziplin folgen viele gute Dinge.

Um eine unabhängige Deploybarkeit zu garantieren, müssen wir sicherstellen, dass unsere Services lose gekoppelt sind – mit anderen Worten: Wir müssen einen Service ändern können, ohne etwas anderes ändern zu müssen. Wir brauchen dazu also explizite, wohldefinierte und stabile Verträge zwischen Services. Bei der Implementierung können manche Entscheidungen dazu führen, dass das kompliziert wird – so ist beispielsweise die gemeinsame Verwendung von Datenbanken besonders problematisch. Der Wunsch nach lose gekoppelten Services mit stabilen Schnittstellen bringt unser Denken dazu, nach Servicegrenzen Ausschau zu halten.

Modellierung rund um eine Businessdomäne

Es ist teuer, eine Änderung über eine Prozessgrenze hinweg vorzunehmen. Müssen Sie zwei Services anpassen, um ein Feature bereitzustellen, und das Deployen dieser zwei Änderungen orchestrieren, ist das mehr Arbeit, als die gleiche Änderung in einem einzelnen Service vorzunehmen (oder einem Monolithen). Daraus folgt, dass wir Wege finden wollen, auf denen sichergestellt ist, dass wir serviceübergreifende Änderungen so selten wie möglich vornehmen.

Mit dem gleichen Ansatz wie dem in Building Microservices nutzt dieses Buch eine Beispieldomäne und eine Beispielfirma, um bestimmte Konzepte deutlich zu machen, bei denen ich keine realen Vorkommnisse erzählen kann. Die fragliche Firma ist Music Corp – eine große internationale Organisation, die es irgendwie schafft, im Geschäft zu bleiben, obwohl sie sich fast vollständig darauf konzentriert, CDs zu verkaufen.

Wir haben uns dazu entschieden, Music Corp trotz aller Widerstände ins 21. Jahrhundert zu befördern, und dazu gehört auch, die bestehende Systemarchitektur unter die Lupe zu nehmen. In Abbildung 1-1 sehen wir eine einfache Architektur mit drei Schichten. Wir haben eine webbasierte Benutzeroberfläche, eine Businessschicht (einen Business Layer) in Form eines monolithischen Backends und die Datenablage in einer klassischen Datenbank. Diese Schichten gehören – wie das so üblich ist – verschiedenen Teams.

Abbildung 1-1: Die Systeme von Music Corp als klassische Architektur mit drei Schichten

Wir wollen eine einfache Änderung an unserer Funktionalität vornehmen: Unsere Kunden sollen ihr bevorzugtes Musikgenre angeben können. Für diese Änderung müssen wir die Benutzeroberfläche anpassen, um das Genre auswählen zu können, der Backend-Service muss dafür sorgen, dass das Genre im UI erscheinen und die Werte geändert werden können, und die Datenbank muss diese Änderung übernehmen. All diese Anpassungen müssen von den einzelnen Teams gemanagt werden (siehe Abbildung 1-2), und das Ganze muss in der richtigen Reihenfolge geschehen.

Diese Architektur ist gar nicht schlecht. Alle Architekturen sind schließlich auf bestimmte Ziele hin optimiert. Die Drei-Schichten-Architektur ist so verbreitet, weil sie universell ist – jeder hat schon davon gehört. Ein Grund für das häufige Auftreten dieses Patterns ist, dass viele eine Architektur wählen, die ihnen an anderer Stelle bereits begegnet ist. Aber ich denke, der Hauptgrund liegt darin, dass das Muster darauf basiert, wie wir unsere Teams organisieren.

Das mittlerweile berühmte Gesetz von Conway besagt:

Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.

– Melvin Conway, How Do Committees Invent?

Die Drei-Schichten-Architektur ist ein gutes Beispiel dafür. In der Vergangenheit haben IT-Organisationen ihre Mitarbeiter*innen anhand ihre Kernkompetenz gruppiert: Datenbankadministratoren befanden sich in einem Team mit anderen Datenbankadministratoren, Java-Entwickler zusammen mit anderen Java-Entwicklern, und Frontend-Entwickler (die heutzutage so exotische Dinge wie JavaScript und die Entwicklung nativer Mobile-Apps beherrschen) steckten wieder in einem anderen Team. Wir bringen die Leute anhand ihrer Kernkompetenz zusammen, daher erzeugen wir auch IT-Produkte, die zu diesen Teams passen.

Abbildung 1-2: Eine Änderung über alle drei Schichten ist aufwendiger.

Das erklärt, warum diese Architektur so verbreitet ist. Sie ist nicht schlecht, sondern nur entlang bestimmter Kräfte optimiert – so wie wir traditionell die Leute nach ihren Kenntnissen gruppiert haben. Aber die Kräfte haben sich geändert. Unsere Ansprüche rund um unsere Software haben sich geändert. Wir fassen die Menschen jetzt in fähigkeitsübergreifenden Teams zusammen, um Übergaben und Silos zu reduzieren. Wir wollen Software schneller als je zuvor ausliefern. Das bringt uns dazu, beim Organisieren unserer Teams andere Entscheidungen zu treffen, womit wir auch unsere Systeme anders aufteilen.

Änderungen an der Funktionalität sind meist Änderungen an der Businessfunktionalität. Aber in Abbildung 1-1 ist unsere Businessfunktionalität ineffektiv über alle drei Schichten verteilt, was die Wahrscheinlichkeit erhöht, dass eine Änderung an der Funktionalität schichtübergreifend erfolgen muss. Das ist eine Architektur, in der wir einen engen Zusammenhang verwandter Technologien, aber nur einen losen Zusammenhang der Businessfunktionalität haben. Wollen wir Änderungen vereinfachen, müssen wir das Gruppieren unseres Codes verändern – wir wählen einen engen Zusammenhang der Businessfunktionalität statt der Technologien. Jeder Service kann dann eventuell aus einer Mischung dieser drei Schichten bestehen, aber das ist Sache der lokalen Serviceimplementierung.

Vergleichen wir das mit einer potenziellen alternativen Architektur, die Sie in Abbildung 1-3 sehen. Wir haben einen dedizierten Customer-Service, der ein UI bereitstellt, auf dem die Kunden ihre Informationen aktualisieren können. Der Status des Kunden wird ebenfalls innerhalb dieses Service gespeichert. Die Wahl eines Lieblingsgenres ist mit einem bestimmten Kunden verbunden, daher ist diese Änderung deutlich lokaler. In Abbildung 1-3 sehen Sie auch, dass die Liste der verfügbaren Genres von einem Catalog-Service geholt wird, der vermutlich in der einen oder anderen Form schon vorhanden ist. Ebenfalls zu finden ist dort ein neuer Recommendation-Service, der unser Lieblingsgenre abruft – etwas, das sich leicht in einem Folge-Release umsetzen ...

Inhaltsverzeichnis

• Cover
• Titel
• Impressum
• Inhalt
• Vorwort
• 1 Gerade genug Microservices
• 2 Eine Migration planen
• 3 Den Monolithen aufteilen
• 4 Die Datenbank aufteilen
• 5 Wachsende Probleme
• Abschließende Worte
• A Literatur
• B Pattern-Index
• Fußnoten
• Index
• Über den Autor
• Kolophon