Читать книгу Vom Monolithen zu Microservices - Sam Newman - Страница 6

Vorwort

Noch vor ein paar Jahren plauderten manche von uns über Microservices als eine interessante Idee. Inzwischen ist es im Handumdrehen zur Standardarchitektur für Hunderte von Firmen auf der ganzen Welt geworden (von denen viele eventuell als Start-ups begannen, um die Probleme zu lösen, die durch Microservices verursacht werden), und jeder versucht, noch auf den fahrenden Zug aufzuspringen, bevor er hinter dem Horizont verschwindet.

Ich muss zugeben, dass ich daran nicht ganz unschuldig bin. Seit ich 2015 mein Buch Building Microservices (https://oreil.ly/building-microservices-2e) zu diesem Thema schrieb, habe ich mein Geld damit verdient, Menschen dabei zu helfen, diese Art von Architektur zu verstehen. Mein Ziel war immer, jenseits des Hypes Firmen dabei zu unterstützen, für sich herauszufinden, ob Microservices für sie das Richtige sind. Für viele meiner Kunden mit bestehenden (nicht auf Microservices ausgerichteten) Systemen lag die Herausforderung darin, wie die Microservices-Architektur übernommen werden konnte. Wie nehmen Sie ein bestehendes System und passen seine Architektur an, ohne die ganzen anderen Aufgaben zu kurz kommen zu lassen? Darum geht es in diesem Buch. Ich möchte Ihnen dabei auch ganz ehrlich zeigen, welchen Herausforderungen Sie sich bei der Microservices-Architektur gegenübersehen werden, und Ihnen dabei helfen, herauszufinden, ob diese Reise für Sie überhaupt die richtige ist.

Was Sie lernen werden

Dieses Buch soll tief in das Thema einsteigen: Wie planen Sie das Aufbrechen bestehender Systeme in eine Microservices-Architektur, und wie setzen Sie das dann auch um? Wir werden viele Aspekte dazu ansprechen, aber der Schwerpunkt liegt auf dem Auseinandernehmen von Dingen. Eine allgemeinere Beschreibung finden Sie in meinem vorherigen Buch Building Microservices. Tatsächlich möchte ich Ihnen das Buch als Begleitung zu diesem Buch sehr ans Herz legen.

Kapitel 1 liefert einen Überblick darüber, was Microservices sind und welche Ideen hinter dieser Art von Architekturen stehen. Es sollte denjenigen helfen, für die dieses Thema neu ist. Aber auch wenn Sie schon mehr Erfahrung mit Microservices haben, empfehle ich Ihnen, es nicht zu überspringen. Denn ich habe das Gefühl, dass einige der zentralen Ideen von Microservices bei all der technologischen Hektik leicht verloren gehen: Es sind Konzepte, auf die dieses Buch immer wieder zurückgreifen wird.

Es ist zwar gut, mehr über Microservices zu wissen, aber es ist doch etwas anderes, wenn Sie herausfinden wollen, ob sie das Richtige für Sie sind. In Kapitel 2 zeige ich Ihnen, wie Sie feststellen können, ob Microservices zu Ihnen passen, und gebe Ihnen wichtige Richtlinien dafür an die Hand, wie Sie einen Übergang von einer monolithischen zu einer Microservices-Architektur organisieren. Hier werden wir alles ansprechen – vom Domain-Driven Design bis hin zu Modellen zur Veränderung von Organisationen. Das sind wichtige Grundlagen, die Ihnen auch dann helfen, wenn Sie sich dafür entscheiden, keine Microservices-Architektur umzusetzen.

In Kapitel 3 und 4 steigen wir tiefer in die technischen Aspekte ein, die zum Auseinandernehmen eines Monolithen gehören, wir schauen uns Beispiele aus der realen Welt an und ziehen daraus unsere Migrations-Patterns. In Kapitel 3 geht es vor allem um die Aspekte des Dekonstruierens, während Kapitel 4 tief in die Datenthematik einsteigt. Wollen Sie wirklich von einem monolithischen System zu einer Microservices-Architektur wechseln, müssen wir auch ein paar Datenbanken auseinandernehmen!

In Kapitel 5 geht es schließlich um die Herausforderungen, denen Sie sich gegenübersehen, wenn Ihre Microservices-Architektur wächst. Diese Systeme können große Vorteile bieten, aber sie bringen auch viel Komplexität und diverse Probleme mit, die Sie zuvor nicht hatten. Dieses Kapitel ist mein Versuch, Ihnen dabei zu helfen, diese Probleme schon dann zu erkennen, wenn sie sich gerade erst entwickeln, und Ihnen Wege aufzuzeigen, wie Sie mit den wachsenden Schmerzen umgehen, die mit Microservices verbunden sind.

Konventionen in diesem Buch

Die folgenden typografischen Konventionen werden in diesem Buch genutzt:

Kursiv

Für neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen.

Nichtproportionalschrift

Für Programmlistings, aber auch für Codefragmente in Absätzen, wie zum Beispiel Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter.

Dieses Symbol steht für einen Tipp oder Vorschlag.

Dieses Symbol steht für eine allgemeine Anmerkung.

Dieses Symbol steht für eine Warnung oder Vorsichtsmaßnahme.

Danksagung

Ohne die Hilfe und das Verständnis meiner wundervollen Frau Lindy Stephens wäre dieses Buch gar nicht möglich gewesen. Es ist ihr gewidmet. Lindy – ich bitte um Entschuldigung, dass ich so mürrisch war, wenn die verschiedenen Deadlines kamen und gingen. Ich möchte mich auch beim lieben Gillman-Stynes-Clan für seine Unterstützung bedanken – ich bin froh, solch eine tolle Familie zu haben.

Dieses Buch hat stark von all denen profitiert, die freiwillig Zeit und Energie dafür aufgebracht haben, die verschiedenen Entwürfe zu lesen und Vorschläge zu machen. Insbesondere möchte ich Chris O’Dell, Daniel Bryant, Pete Hodgson, Martin Fowler, Stefan Schrass und Derek Hammer danken. Und es gibt noch andere Menschen, die auf die eine oder andere Art und Weise direkt beigetragen haben, daher möchte ich Graham Tackley, Erik Doernenberg, Marcin Zasepa, Michael Feathers, Randy Shoup, Kief Morris, Peter Gillard-Moss, Matt Heath, Steve Freeman, Rene Lengwinat, Sarah Wells, Rhys Evans und Berke Sokhan danken. Finden Sie Fehler in diesem Buch, sind das nicht ihre, sondern meine.

Das Team von O’Reilly hat mich ebenfalls außerordentlich unterstützt, und ich möchte meinen Lektorinnen Eleanor Bru und Alicia Young danken, dazu Christopher Guzikowski, Mary Treseler und Rachel Roumeliotis. Ebenfalls ein großer Dank gebührt Helen Codling und ihren Kollegen überall auf der Welt, die meine Bücher auf alle möglichen Konferenzen mitgenommen haben, Susan Conant, die mich auf dem Weg durch die sich verändernde Welt der Bücher geleitet hat, und Mike Loukides, der den ersten Kontakt mit O’Reilly hergestellt hat. Ich weiß, dass hinter den Kulissen noch viel mehr Menschen geholfen haben, bei denen ich mich ebenfalls bedanken möchte.

Neben denjenigen, die direkt zu diesem Buch beigetragen haben, bedanke ich mich auch bei allen, die auf anderen Wegen dabei geholfen haben, dieses Buch Realität werden zu lassen – ob ihnen das nun bewusst ist oder nicht. Daher möchte ich mich (ohne besondere Reihenfolge) bedanken bei Martin Kelppmann, Ben Stopford, Charity Majors, Alistair Cockburn, Gregor Hohpe, Bobby Woolf, Eric Evans, Larry Constantine, Leslie Lamport, Edward Yourdon, David Parnas, Mike Bland, David Woods, John Allspaw, Alberto Brandolini, Frederick Brooks, Cindy Sridharan, Dave Farley, Jez Humble, Gene Kim, James Lewis, Nicole Forsgren, Hector Garcia-Molina, Sheep & Cheese, Kenneth Salem, Adrian Colyer, Pat Helland, Kresten Thorup, Henrik Kniberg, Anders Ivarsson, Manuel Pais, Steve Smith, Bernd Rucker, Matthew Skelton, Alexis Richardson, James Governor und Kane Stephens.

Wie das immer in solchen Fällen ist, habe ich bestimmt einige vergessen, die wichtige Beiträge zu diesem Buch geliefert haben. Auch denen möchte ich meinen Dank aussprechen und um Entschuldigung bitten, dass ich sie nicht mit ihrem Namen erwähne. Ich hoffe, Sie können mir verzeihen.

Schließlich werde ich gelegentlich gefragt, mit welchen Tools ich dieses Buch geschrieben habe. Ich habe in AsciiDoc geschrieben und dabei Visual Studio Code zusammen mit dem AsciiDoc-Plug-in von João Pinto genutzt. Das Buch wurde in Git versioniert, und es kam das Atlas-System von O’Reilly zum Einsatz. Größtenteils schrieb ich auf meinem Laptop mit einer externen mechanischen Razer-Tastatur, aber zum Ende hin kam auch oft ein iPad Pro mit Working Copy zum Einsatz, um die letzten paar Dinge abzuschließen. Damit konnte ich auf Reisen schreiben – insbesondere blieb mir eine Fährfahrt zu den Orkneys in Erinnerung, auf der ich über das Refaktorieren von Datenbanken schrieb. Die daraus entstandene Seekrankheit war es wert.