Patterns, um bestehende Systeme Schritt für Schritt umzugestalten
E-Book, Deutsch, 266 Seiten
ISBN: 978-3-96010-424-7
Verlag: O'Reilly
Format: EPUB
Kopierschutz: 6 - ePub Watermark
Sam Newman ist Entwickler, Architekt, Autor und Redner, der mit verschiedenen Unternehmen aus den verschiedensten Bereichen auf der ganzen Welt zusammengearbeitet hat. Er arbeitet unabhängig und konzentriert sich hauptsächlich auf die Cloud, Continuous Delivery und Microservices. Er ist Autor des Bestsellers 'Building Microservices', ebenfalls bei O'Reilly erschienen. Wenn er nicht von einem Zug auf den anderen springt, trifft man ihn auf dem Land in East Kent an, wo er sich über verschiedene Formen des Sports aufregt.
Weitere Infos & Material
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...
