"Size doesn’t matter". Oder etwa doch?

Enterprise Tales: Wie groß sollte ein optimaler Microservice sein?

Lars Röwekamp

© Software & Support Media

Der Name Microservice legt nahe, dass es sich um etwas ziemlich Kleines handelt. Aber wie klein genau ist „klein“? Kann man die maximale Größe eines Microservice zum Beispiel in Lines of Code ausdrücken? Oder gibt es andere sinnvolle Messkriterien? Die Antwort darauf ist gar nicht so einfach. Und um es gleich vorweg zu nehmen: Sie lautet nicht 42.

In letzter Zeit werde ich von Kunden oder Kollegen bei Gesprächen rund um das Thema Microservices immer häufiger gefragt, was denn nun aus meiner Sicht die richtige Größe eines Microservice sei. Wenn ich dann mit „7“ antworte – diese Antwort habe ich mal in ähnlicher Form auf einer Konferenz gehört und sie einfach für meine Zwecke adaptiert – sind die meisten Fragenden erst einmal stark irritiert. Wenn ich dann im Anschluss erkläre, dass sich „7“ auch mit „Kommt darauf an …“ übersetzen lässt, sind sie zwar noch nicht wirklich schlauer, verstehen aber, was ich meine und lassen sich auf eine konstruktive Diskussion zu dem Thema ein.

Nicht selten kommt dann als erster Vorschlag, dass als Maßstab für die „richtige“ Größe eines Microservice ein Limit an LoC (Lines of Codes) angegeben werden sollte. Wenn man allerdings überlegt, dass als eines der grundlegenden Paradigmen in der Welt der Microservices die freie Wahl der Programmiersprache propagiert wird, scheint eine Bewertung auf Basis der LoC nicht wirklich sinnvoll zu sein. Zu unterschiedlich sind die möglichen Sprachaspiranten, zu unterschiedlich der resultierende Code. Und selbst wenn ein Vergleich möglich wäre, wie sollte es dann bewertet werden, wenn man in einigen wenigen Zeilen Code viele, viele Zeilen Library-Code referenziert?

SoC und SRP

Wenn also die Anzahl der Zeilen nicht das Maß der Dinge ist, wie sieht es dann mit Design Patterns aus? Ein Microservice soll etwas eigenständiges sein. Als passendes Muster würde sich somit das Single Responsibilty Principle (SRP) Pattern oder das Separation of Concern (SoC) Pattern anbieten.

SRP ergibt sicherlich Sinn, wenn man es mit relativ einfachen Services wie beispielsweise einem Validator für deutsche Telefonnummern oder Postleitzahlen zu tun hat. Was aber, wenn diese Services z. B. internationalisiert werden sollen, um so auch Telefonnummern oder PLZ anderer Länder zu validieren? Wären das dann neue Microservices? Oder würde man die bestehenden Services entsprechend erweitern und somit eher in Richtung des SoC Patterns gehen?

Beide Varianten sind denkbar und für beide Varianten gibt es Für und Wider. Entscheidend ist aus meiner Sicht vor allem, wie unabhängig der Service am Ende tatsächlich ist. Kann er zum Beispiel losgelöst von anderen Services geändert, erweitert oder sogar einfach neu implementiert und dann deployt werden? Oder bringt eine Änderung bzw. Erweiterung auch immer Änderungen in anderen Services mit sich. Spätestens dann sollte man die Grenzen seines Service noch einmal überdenken.

Bounded Context

In meinen bisherigen Projekten hat sich herauskristallisiert, dass ein Bounded Context gemäß DDD eine gute Ausgangsbasis für einen Microservice darstellt. Da die Grenzen eines Bounded Context fachlich motiviert sind, fühlt sich der resultierende Service für die Teammitglieder erst einmal recht „natürlich“ an. Richtig geschnitten gibt es per Definition wenig Abhängigkeiten zu anderen Bounded Contexts (also anderen Microservices) und somit auch wenig unnötige Kommunikation. Dies gilt sowohl aus technologischer Sicht als auch für die notwendige Kommunikation zwischen den einzelnen Teams – ebenfalls ein wichtiges Paradigma der Microservice-Welt. Darüber hinaus lassen sich mithilfe einer Context Map die Abhängigkeiten und Kommunikationsmuster der einzelnen Bounded Contexts untereinander optimal visualisieren. Starke Abhängigkeiten bzw. viel Kommunikation ist in der Regel ein Zeichen dafür, dass man die gewählten Grenzen noch einmal überdenken sollte.

2-Pizza-Team

Ein scheinbar anderer Ansatz zur Definition der optimalen Größe eines Microservice basiert auf der „richtigen“ Teamgröße. Amazon hat in diesem Zusammenhang den Begriff „2-Pizza-Team“ geprägt, was soviel bedeutet wie, dass ein optimales Team von zwei Pizzen „ernährt“ werden kann. Da Amazon eine Teamgröße von sechs bis zehn Personen für optimal hält, gehen wir einfach mal davon aus, dass es sich hier um Pizzen amerikanischer Größe handelt.

Natürlich geht es aber nicht wirklich um die Pizzen. Entscheidend ist, dass sich bei Amazons Philosophie ein Team ergibt, welches im höchsten Maße autonom arbeiten und entscheiden kann. Wäre das Team kleiner, wäre zusätzlicher Abstimmungsbedarf mit anderen Teams oder Vorgesetzten notwendig. Wäre das Team dagegen größer, würde die Kommunikation innerhalb des Teams unnötig komplex.

Zieht man jetzt noch Conway’s Law hinzu – das darf natürlich bei einer Kolumne zum Thema Microservices auf keinen Fall fehlen – und interpretiert es ein wenig freier, dann ergibt sich im Umkehrschluss zur gewählten „2 Pizza“-Teamgröße und den sich daraus ergebenden Kommunikationsstrukturen, dass die entstehenden Services der einzelnen Teams den optimalen Funktionsumfang haben und die gesamte Lösung aller Teams zusammen die bestmögliche Architektur ergeben.

Fazit

Wie groß sollte nun also der optimale Microservice sein? Zunächst einmal so klein bzw. so groß, dass er von einem kleinen Team komplett, d. h. sowohl fachlich als auch technologisch, beherrscht werden kann. Darüber hinaus muss eine losgelöste Entwicklung und Evolution des Service durch das Team möglich sein. Die Interaktion mit anderen Teams und anderen Services sollte dabei stark limitierter sein. Da das Team die volle Verantwortung für den Service übernimmt und das nicht nur zum Zeitpunkt der Entwicklung, sondern auch zur Laufzeit, gehört die Möglichkeit eines einfachen und losgelösten Deployments und Monitorings ebenfalls zu den Messkriterien für die „richtige“ Größe eines Microservice.

Sicherlich wird man seine Services in der Praxis nicht immer auf Anhieb richtig schneiden. Darüber hinaus wird es im Rahmen von geänderten oder neuen fachlichen Anforderungen an einen Service immer wieder Situationen geben, in denen es Sinn ergibt, mehrere Services zusammenzulegen oder einen bestehenden Service in mehrere Services aufzuteilen.

Für den Start auf dem Weg zur optimalen Servicegröße gibt es aus meiner Sicht zwei grundlegende Vorgehensweisen. Entweder startet man bewusst mit sehr kleinen Services und legt diese sukzessive zusammen. Oder man baut alternativ zunächst relativ grobgranulare Services auf und teilt diese dann Schritt für Schritt, bis man am Ende bei der für den gegebenen Kontext optimalen Größe landet. Die erste Variante liefert in der Regel einen sehr modularen Code, der aber zum Teil mit unterschiedlichen Domainmodellen arbeitet und relativ viel Kommunikation zwischen den Services benötigt. Der zweite Ansatz birgt dagegen die Gefahr, dass initial ein Monolith entsteht, der dann am Ende nur schwer aufzutrennen ist. In beiden Fällen sollte man also bewusst und von Anfang an die Services so flexibel bauen, dass sie entweder gut zusammengelegt oder alternativ gut aufgetrennt werden können. Hier helfen unsere alten Bekannten SRP und SoC. Und sollte man sich einmal nicht sicher sein, ob der eigene Microservice nun die richtige Größe hat oder nicht, dann einfach kurz an die „7“ denken und anfangen zu diskutieren. Dazu ist das Team schließlich da! In diesem Sinne: Stay tuned …

Geschrieben von
Lars Röwekamp
Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.