Experten-Check Teil 3

Microservices im Experten-Check: Wie groß sollte ein Microservice sein?

Melanie Feldmann

© Shutterstock/Login

Acht Microservice-Experten, Autoren des Java Magazins und Sprecher auf den Microservice Days der JAX 2016, geben in kurzen Statements Einblicke in ihre Praxiserfahrungen mit Microservices. Dieses Mal: Wovon man sich bei der Aufteilung von Microservices leiten lassen sollte und wie groß so ein Microservice eigentlich werden sollte.

Wovon sollte man sich bei der Aufteilung der Microservices leiten lassen?

Uwe Friedrichsen: Von den gleichen Prinzipien, die seit vielen Jahren für gute Modularisierung gelten: „Separation of concerns“, „High cohesion, low coupling“, usw. – das derzeit häufig zitierte Domain Driven Design gibt einem gute Hinweise, wie man diese Prinzipien praktisch umsetzen kann.

Alexander Heusingfeld: Aus meiner Sicht ist die Aufteilung nach fachlichen Anwendungsfällen mit einer hohen Kohäsion eine gute Idee. Ein derart vertikaler Schnitt erfordert allerdings entsprechende Querschnittskompetenzen in dem Team, welches den Microservice betreut. Grundsätzlich sollte für den Schnitt das wichtigste Ziel sein, dass bei einer fachlichen Änderung oder einem Feature möglichst wenige Microservices – im besten Fall nur ein einziger – geändert und neu deployed werden müssen. Die Fokussierungen auf Anwendungs-/ Geschäftsvorfälle unterstützt dieses Ziel.

Jörg Müller: Dafür gibt es viele Kriterien, die bei den anderen Fragen auch schon genannt wurden. Fachliche Grenzen haben Vorrang. Bounded Contexts im Sinne des Domain Driven Designs können da hilfreich sein. Ein Microservice sollte eine Verantwortlichkeit haben und er sollte eben nicht zu groß sein, damit er auch mal eben in ein paar Tagen neu erstellt werden kann.

Die Microservice-Experten

friedrichsen

Uwe Friedrichsen, CTO bei codecentric

heusingfeld_alexander_sw

Alexander Heusingfeld, Senior Consultant bei innoQ

joerg_mueller_mittel_13f34

Jörg Müller, Senior Software Engineer and Manager bei Hypoport

schwartz_alexander_wp

Alexander Schwartz, Principal IT Consultant bei msg systems

tilkov_stefan

Stefan Tilkov, Geschäftsführer und Principal Consultant bei innoQ

Stefan Toth

Stefan Toth, Softwarearchitekt bei embarc

Oliver Wehrens, Chief Architect bei Deutsche Post E-Post Development

Eberhard Wolff, Fellow bei innoq

Alexander Schwartz: Microservices als Konzept sollen es ermöglichen, fachliche Anforderungen schneller in Produktion zu bekommen. Damit eine neue oder geänderte fachliche Anforderung möglichst wenige Services betrifft, ist es notwendig, Microservices anhand der Fachlichkeit zu schneiden. Domain Driven Design ist hierfür ein guter Ansatz. Es hilft, Aggregates und Services zu identifizieren und fachlich zu benennen. Damit erhalten Fachabteilung und Entwicklung ein gemeinsames Vokabular.

Stefan Tilkov: Dazu kann es viele Treiber geben. Auf oberster Ebene habe ich die besten Erfahrungen damit gemacht, die Organisation und ihre Anwendungsfälle als Kriterien für einen Schnitt zu nehmen.

Stefan Toth: Ganz klar an der eigenen Domäne. Einen schlechten fachlichen Schnitt kann man technisch nicht mehr kitten. DDD hat hier bekannte Ansätze die helfen können – wie etwa Bounded Contexts.

Oliver Wehrens: Die Domäne sollte klar sein und ein Microservice sollte eine Fachlichkeit kapseln.

Eberhard Wolff: Die fachliche Aufteilung ist wichtig, wenn es um die unabhängige Entwicklung geht. Dazu sollte ein Microservice ein Bounded Context im Sinne von Domain-driven Design sein. Am Ende sind Microservices nur eine weitere Möglichkeit, Software zu modularisieren, Daher gelten die sonst üblichen Regeln für eine saubere Modularisierung auch in diesem Fall.

Sollte jeder Microservice in derselben Sprache geschrieben sein oder sind auch mehrere möglich?

Uwe Friedrichsen: Die Freiheit der Sprachwahl ist ein explizites Merkmal von Microservices. Wie schon erwähnt, entfalten Microservices in DevOps-Organisationen den größten Nutzen und dort sind die Argumente für eine einheitliche Programmiersprache von untergeordneter Bedeutung.

Alexander Heusingfeld: Aus meiner Sicht kann die Wahl der Programmiersprache dem Team überlassen werden, so dass es die für die Aufgabenstellung beste Sprache wählen kann. Allerdings müssen sich die Entscheidungsträger bewusst sein, dass ein nachträgliches Korrigieren eines falschen Serviceschnittes durch Zusammenfassen von zwei Microservices schwierig bis unmöglich ist, wenn diese in völlig unterschiedlichen Programmiersprachen geschrieben wurden.

Jörg Müller: Es sollte auf keinen Fall nur eine Sprache unterstützt werden. Technologieunabhängigkeit ist einer der bedeutenden Vorteile von Microservices. Die Möglichkeit, in kleinem Rahmen andere Sprachen zu wählen, die für die jeweilige Aufgabenstellung passen, schafft mehr Produktivität und sorgt vor allem für mehr Spaß beim Entwickeln.

Alexander Schwartz: Jeder Microservice sollte für sich in einer Sprache geschrieben sein. Nur so kann die Komplexität pro Microservice begrenzt werden. Verschiedene Microservices können auch verschiedene Sprachen benutzen.

Stefan Tilkov: „Sollte“? Das wäre mir zu stark. Es ist aus meiner Sicht ganz entscheidend wichtig, dass jeder Microservice in einer anderen Sprache geschrieben werden KANN. Ob man das dann auch tut oder die Auswahlmöglichkeiten auf eine, zwei oder n Sprachen begrenzt, ist auch eine spannende Frage, darf aber nichts mit der Microservices-Architektur zu tun haben.

Stefan Toth: Eine Ausprägungsfrage. Persönlich würde ich sagen nein, ich habe Kunden in bestimmten Umfeldern aber schon das Gegenteil empfohlen.

Oliver Wehrens: Solange das Kommunikationsprotokoll an alle Sprachen angebunden werden kann (z.B. REST oder Kommunikation über Messaging) sind alle Sprachen möglich. Dies ist oft eine Organisationsfrage, da entsprechend eingestellt oder ausgebildet werden muss.

Eberhard Wolff: Die Technologiefreiheit ist ein Trade-Off – sie geht mit höherer Komplexität einher und es ist schwieriger, Entwickler in anderen Teams oder an anderem Code arbeiten zu lassen. Meiner Meinung nach ist daher eine Standardisierung der Technologien vollkommen OK. Allerdings hat die Technologie-Freiheit auch bei einer Standardisierung Vorteile: Ein Team kann beispielsweise eine neue Version einer Library mit einem Bugfix recht einfach einführen, weil die Änderung auf einen Microservice und ein Team begrenzt ist.

Wie groß sollte ein Microservice sein?

Uwe Friedrichsen: Er sollte von einem Menschen verstanden werden können. Die Codezeilen-Diskussion, die immer wieder aufkommt, finde ich persönlich wenig zielführend.

Alexander Heusingfeld: So groß, dass eine Person, egal, ob Entwickler, Operator oder Tester, seine gesamte Funktionalität erfassen und im Kopf behalten kann.

Jörg Müller: Dies ist eine der Fragen, die besonders schwierig zu beantworten ist. Allein schon, weil nicht klar ist, worauf sich die Größe bezieht. Dass die Anzahl der Codezeilen kein vernünftiger Maßstab ist, ist vermutlich klar. Wenn man die implementierte Funktionalität betrachtet, gibt es eine Antwort, die sich am Single-Responsibility-Prinzip orientiert. Jeder Service sollte sich möglichst auf eine fachliche Funktion konzentrieren. Hilfreich ist es auch, die Zeit zum Erstellen eines Services zu betrachten. Ein wesentlicher Vorteil von Microservices ist, dass diese leicht ersetzt werden können. Um das zu ermöglichen, muss es möglich sein, einen Service in relativ kurzer Zeit von Grund auf neu zu erstellen. Dies setzt der Größe ebenfalls eine natürliche Obergrenze.

Alexander Schwartz: Teilt man ein System gemäß Domain Driven Design auf, so ergeben sich unter anderem Aggregates und Services, die jeweils eine fachliche Bedeutung haben. Ein Microservice sollte ein oder ein paar wenige Aggregates und Services bündeln, die ein gemeinsames fachliches Verständnis haben (Bounded Domain Context). Kleiner als ein Aggregate oder Service darf er nicht sein, da sonst der fachliche Bezug verloren geht. Nur mit klarem fachlichem Bezug eines Services können neue oder geänderte fachliche Anforderungen direkt dem richtigen Service zugeordnet werden.

Stefan Tilkov: Ich mag sehr sehr kleine Microservices, wie sie von Fred George favorisiert werden, die an einem Bus hängen, asynchron kommunizieren und ohne voneinander zu wissen, gemeinsam eine Aufgabe erledigen. Ich mag auch die Netflix-Variante kollaborierender, kleiner Services, die kollaborieren, um einen Benutzer-Request zu bedienen. Für die Strukturierung großer Systeme reichen diese meiner Meinung nach nicht aus – da möchte man sicher nicht einfach nur auf oberster Ebene ein paar Hundert winzig kleiner Microservices haben, die gleichberechtigt nebeneinander stehen. Deshalb bevorzuge ich dafür die Idee von Self-Contained Systems, die ihrerseits wiederum aus feingranularen Services bestehen können.

Stefan Toth: So groß, dass es in einen Entwicklerkopf passt. Eine genauere Aussage dazu ist schwierig und wird oft zu religiös beantwortet.

Oliver Wehrens: Ein Microservice sollte eine Funktionalität kapseln. Dies an einer Größe festzumachen, halte ich für kein gutes Kriterium.

Eberhard Wolff: Microservices sollten so groß sein, dass sie ein Team weiterentwickeln kann, ein Entwickler noch verstehen kann und dass sie durch eine Neuimplementierung ersetzt werden können. Die Wahl der Infrastruktur begrenzt die Anzahl und damit die Größe der Microservices. Docker-Container sind beispielsweise aufwändiger als Amazon Lambda, bei denen einzelne JavaScript-Funktionen deployt werden können.

W-JAX
Mike Wiesner

Data- und Event-driven Microservices mit Apache Kafka

mit Mike Wiesner (MHP – A Porsche Company)

Niko Köbler

Digitization Solutions – a new Breed of Software

with Uwe Friedrichsen (codecentric AG)

Software Architecture Summit 2017
Dr. Carola Lilienthal

The Core of Domain-Driven Design

mit Dr. Carola Lilienthal (Workplace Solutions)

Sascha Möllering

Reaktive Architekturen mit Microservices

mit Sascha Möllering (Amazon Web Services Germany)

Welche Technologie ist aus Ihrer Sicht bei Microservices besonders wichtig?

Uwe Friedrichsen: Keine bestimmte – außer vielleicht eine vernünftige Cloud-Infrastruktur, ein guter Scheduler und ggf. Container.

Alexander Heusingfeld: Man kann Microservices mit vielen verschiedenen Technologien realisieren. Wichtiger ist aus meiner Sicht, wie die jeweilige Technologie (Bibliothek, Framework, Software) die Konzepte wie beispielsweise Service Registration und Discovery umsetzt. Bei der Service Discovery gibt es mittlerweile einige unterschiedliche Ansätze, die jeweils andere Anforderungen an die Client-Implementierung stellen was Fehlerbehandlung und -toleranz angeht.

Jörg Müller: Spezifische Technologien sind nicht so bedeutend. Im Gegenteil: Die Möglichkeit stets die passende Technologie einzusetzen ist einer der großen Vorteile von Microservices. Wenn spezifische Technologien eine Rolle spielen, dann bei der Build- und Deployment-Infrastruktur. Dort ist Docker sehr hilfreich, um ein weitgehend standardisiertes Deployment zu bauen und gleichzeitig die Freiheitsgrade für die eingesetzten Technologien zu erhalten.

Stefan Tilkov: Eigentlich würde ich keine einzelne Technologie besonders herausheben wollen. Webtechnologien wie REST und HTTP oder die Integration über Browser-Möglichkeiten funktionieren nach meiner Erfahrung allerdings meistens sehr gut.

Stefan Toth: Genau die Chaosbändiger: Automatisierung im Deployment, gutes Monitoring, automatische Reaktion auf Ausfälle, paralleler Betrieb mehrerer Versionen, konkret Docker, Hystrix, der ELK-Stack, Consul etc.

Oliver Wehrens: Keine spezielle. Microservices kann man mit allen Technologien erreichen.

Eberhard Wolff: Die hauptsächlichen Herausforderungen sind im Betrieb, sodass Technologien für das effiziente Deployment und Monitoring der Microservices sehr wichtig sind. Darüber hinaus ist Infrastruktur für verteilte Systeme wie Service Discovery oder Technologien für Resilience sicher ebenfalls relevant.

Lesen Sie auch: Experten-Check Teil 1 – Warum eigentlich Microservices?

und: Experten-Check: Wann man Microservices nutzen sollte und wann eher nicht

 

 Aufmacherbild: Abstract geometrical 3d background von Shutterstock / Urheberrecht: Login

Geschrieben von
Melanie Feldmann
Melanie Feldmann
Melanie Feldmann ist seit 2015 Redakteurin beim Java Magazin und JAXenter. Sie hat Technikjournalismus an der Hochschule Bonn-Rhein-Sieg studiert. Ihre Themenschwerpunkte sind IoT und Industrie 4.0.
Kommentare

Schreibe einen Kommentar

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