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

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