Wie kann sich dieses Problem zeigen?
Wann kann sich das Problem zeigen?
Globale versus lokale Optimierung
Wie kann sich dieses Problem zeigen?
Wann kann sich das Problem zeigen?
Wie kann sich dieses Problem zeigen?
Wann kann sich das Problem zeigen?
Wie kann sich dieses Problem zeigen?
Wann kann sich das Problem zeigen?
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.
|
|