© Excellent backgrounds/Shutterstock.com
Java Magazin
Kolumne: EnterpriseTales

„Size doesn’t matter“. Oder etwa doch?

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.

Lars Röwekamp


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 ist 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 SRPSRP ist sicherlich sinnvoll, 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 [1]. 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 Context2-Pizza-TeamNatü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 ...

Java Magazin
Kolumne: EnterpriseTales

„Size doesn’t matter“. Oder etwa doch?

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.

Lars Röwekamp


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 ist 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 SRPSRP ist sicherlich sinnvoll, 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 [1]. 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 Context2-Pizza-TeamNatü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 ...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang