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.
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