Vom Monolithen zu Microservices. Sam Newman

      Sie müssen Kubernetes, Docker, Container oder eine öffentliche Cloud nicht einsetzen. Sie müssen nicht in Go, Rust oder was auch immer programmieren. Tatsächlich ist die Wahl Ihrer Programmiersprache in Bezug auf Microservices-Architekturen ziemlich unwichtig, abgesehen davon, dass ein paar der Sprachen ein umfangreicheres Ökosystem aus unterstützenden Bibliotheken und Frameworks mitbringen. Wenn Sie sich in PHP am besten auskennen, dann beginnen Sie in PHP!¹ Es gibt da draußen viel zu viel technischen Snobismus in Bezug auf bestimmte Technologie-Stacks, der oft leider zu einer Verachtung derjenigen führt, die mit anderen Tools arbeiten.² Seien Sie nicht Teil des Problems! Wählen Sie einen Ansatz, der für Sie funktioniert, und ändern Sie Dinge, um Probleme anzugehen, wenn Sie auf sie stoßen.

       Größe

      »Wie groß sollte ein Microservice werden?«, das ist vermutlich die Frage, die mir am häufigsten gestellt wird. Das ist nicht überraschend, steckt doch der Begriff »Micro« im Namen. Aber wenn Sie verstanden haben, wie Microservices als Architektur funktionieren, ist das Konzept der Größe tatsächlich einer der uninteressantesten Punkte.

      Wie messen Sie die Größe? Ist es die Anzahl der Codezeilen? Das klingt nicht so sinnvoll. Es kann sein, dass jemand 25 Zeilen Java-Code benötigt, die auch in 10 Zeilen Clojure geschrieben werden könnten. Das heißt nicht, dass Clojure besser oder schlechter als Java ist, sondern nur, dass manche Sprachen expressiver als andere sind.

      Was »Größe« meiner Meinung nach am nächsten kommt, ist etwas, das der Microservices-Experte Chris Richardson einmal so beschrieben hat: Das Ziel von Microservices sei es, eine »möglichst kleine Schnittstelle zu haben«. Das passt zum Konzept des Information Hiding (auf das wir noch kommen werden), steht aber eher für einen Versuch, im Nachhinein noch eine Bedeutung dafür zu finden – als wir darüber erstmals sprachen, lag unser Hauptaugenmerk zumindest zu Beginn vor allem darauf, diese Dinge sehr einfach ersetzen zu können.

      Letztendlich ist das Konzept der Größe sehr kontextabhängig. Sprechen Sie mit jemandem, der seit 15 Jahren mit einem System arbeitet, wird er die 100.000 Zeilen Code leicht verständlich finden. Fragen Sie jemand anderen, der bei dem Projekt ganz frisch dabei ist, wird er es als viel zu groß ansehen. Oder fragen Sie eine Firma, die gerade mit der Umwandlung in Microservices begonnen hat und bei der vielleicht zehn oder weniger Microservices im Einsatz sind, erhalten Sie eine andere Antwort als bei einer Firma gleicher Größe, die seit Jahren mit Microservices arbeitet und nun Hunderte davon nutzt.

      Ich sage den Leuten immer, sie sollten sich nicht allzu viele Gedanken um die Größe machen. Wenn Sie mit dem ganzen Thema beginnen, ist es viel wichtiger, sich auf zwei zentrale Aspekte zu konzentrieren. Erstens: Mit wie vielen Microservices können Sie umgehen? Mit einer zunehmenden Zahl wird die Komplexität Ihres Systems wachsen, und Sie werden neue Fertigkeiten erlernen (und eventuell neue Technologien einsetzen) müssen, um das Ganze im Griff zu behalten. Aus diesem Grund rate ich deutlich dazu, schrittweise zu einer Microservices-Architektur zu migrieren. Zweitens: Wie definieren Sie die Grenzen Ihrer Microservices, um das Beste aus ihnen herauszuholen, ohne das Ganze in ein furchtbares Chaos ausarten zu lassen? Das sind die Themen, mit denen wir uns im Rest dieses Kapitels befassen wollen.

       Die Geschichte des Begriffs »Microservices«

      Als ich im Jahr 2011 noch bei einer Consulting-Firma namens ThoughtWorks arbeitete, interessierte sich mein Freund und damaliger Kollege James Lewis für etwas, das er als »Micro-Apps« bezeichnete. Er hatte dieses Pattern bei ein paar Firmen beobachtet, die eine serviceorientierte Architektur verfolgten – sie optimierten diese Architektur, um Services leicht ersetzen zu können. Die fraglichen Firmen waren daran interessiert, bestimmte Funktionalität schnell deployt zu bekommen, sie aber gleichzeitig auch komplett mit anderen Technologie-Stacks neu schreiben zu können, wenn die zu bedienenden Mengen wuchsen.

      Damals war besonders beachtenswert, wie klein diese Services bezüglich ihres Einsatzbereichs waren. Einige der Services konnten in wenigen Tagen geschrieben (oder umgeschrieben) werden. James sagte gern: »Services sollten nicht größer als mein Kopf sein.« Die Idee war, dass der Scope der Funktionalität leicht verständlich und damit auch leicht änderbar sein sollte.

      2012 präsentierte James diese Ideen bei einer Architekturkonferenz, auf der ein paar von uns anwesend waren. Bei dieser Session diskutierten wir darüber, dass diese Dinge eigentlich keine vollständigen Anwendungen wären und »Micro-Apps« nicht passte. Stattdessen schien »Microservices« ein besserer Begriff dafür zu sein.³

       Und Ownership

      Sind Microservices rund um eine Businessdomäne modelliert, sehen wir Übereinstimmungen zwischen unseren IT-Artefakten (den unabhängig deploybaren Microservices) und unserer Businessdomäne. Diese Idee hallt bei Technologiefirmen wider, die die Grenzen zwischen »Business« und »IT« niederreißen. In klassischen IT-Organisationen geschieht die Softwareentwicklung oft völlig getrennt vom Business, das die Anforderungen definiert und eine Verbindung zum Kunden hat (siehe Abbildung 1-4). Die Dysfunktionen dieser Art von Organisationen sind zahlreich und vielfältig, und wir müssen hier vermutlich nicht weiter darauf eingehen.

       Abbildung 1-4: Eine Organisationssicht auf die klassische IT-Business-Aufteilung

      Stattdessen sehen wir echte Technologieorganisationen, die diese zuvor getrennten organisatorischen Silos vereinen (siehe Abbildung 1-5). Product Owner arbeiten jetzt direkt als Teil der Delivery-Teams mit, die wiederum nicht mehr technischen Gruppen, sondern entsprechenden kundenzentrierten Produktlinien zugeordnet sind. Statt dass zentralisierte IT-Funktionen die Norm sind, ist das Ziel jeder zentralen IT-Funktion, diese kundenzentrierten Delivery-Teams zu unterstützen.

      Auch wenn nicht alle Organisationen diesen Wechsel vollzogen haben, sorgen Microservices-Architekturen dafür, dass er leichter umzusetzen ist. Wollen Sie mit den Produktlinien abgestimmte Delivery-Teams und mit der Businessdomäne abgestimmte Services haben, wird es einfacher, die Ownership ganz klar diesen produktorientierten Delivery-Teams zuzuweisen. Es ist wichtig, immer weniger von mehreren Teams betreute Services zu haben, um Ärger bei der Auslieferung zu vermeiden – Microservices-Architekturen, die an Businessdomänen orientiert sind, erleichtern diesen Wechsel der Organisationsstrukturen.

       Abbildung 1-5: Ein Beispiel dafür, wie echte Technologiefirmen Software-Delivery integrieren

       Der Monolith

      Wir haben über Microservices gesprochen, aber in diesem Buch geht es darum, von Monolithen zu Microservices zu migrieren. Daher müssen wir festlegen, was wir mit dem Begriff Monolith meinen.

      Rede ich in diesem Buch über die Monolithen, beziehe ich mich vor allem auf eine Deployment-Einheit. Muss die gesamte Funktionalität eines Systems gemeinsam deployt werden, betrachten wir es als einen Monolithen. Es gibt mindestens drei monolithische Systeme, die in dieses Schema passen: das Ein-Prozess-System, der verteilte Monolith und Black-Box-Systeme von Fremdherstellern.

       Der Ein-Prozess-Monolith

      Das Beispiel, das einem bei Gesprächen über Monolithen am häufigsten in den Sinn kommt, ist das eines Systems, bei dem der gesamte Code als ein Prozess