Microservices versus OSGi: Über Sinn und Unsinn der 'neuen Inkarnation des Webservice'

Hartmut Schlosser

Anwendungen in Module aufzuteilen, gehört seit langem zu den Best Practices moderner Softwareentwicklung. Realisieren kann man eine modulare Anwendung freilich auf unterschiedliche Weise – JAR-Module, Packages, Web Services, OSGi, SOA-Architekturen, etc. In der letzten Zeit schiebt sich nun der Begriff Microservice in den Vordergrund. Was ist damit gemeint – und warum kann OSGi-Erfinder Peter Kriens nur über den Begriff lachen?

Was sind Microservices?

Zur Definition von Microservices trifft es sich gut, dass sich das aktuelle Java Magazin gerade in seinem Schwerpunkt mit dem Thema beschäftigt. Eberhard Wolff gibt dort in seinem Artikel „Microservices – Lösen sie alle unsere Probleme?“ einige Merkmale von Microservices wieder:

  • Bei Microservices wird jedes Modul zu einem Service – ein getrennter Prozess mit einer Schnittstelle.
  • Bei Microservices werden Funktionalitäten in fachliche Services unterteilt, die einzeln deployt werden können.
  • Microservices sollen so klein sein, dass sie von einem Menschen oder einem kleinen Team verstanden und gewartet werden können (10–100 Codezeilen).
  • Die Idee ist auch, dass Microservices einfach ersetzt werden können, statt sie zu warten.
  • Im Gegensatz zu einer SOA nutzen Microservices leichtgewichtige Infrastrukturen und Protokolle und können eine GUI enthalten.
  • Beispiel E-Commerce-Shop: Ein Service stellt die Lieferadresse bereit, ein anderer Service die Rechnungsdresse.

Was gefällt nun OSGi-Erfinder Peter Kriens nicht an dieser Idee der Microservices?

„Sie haben unseren Begriff gestohlen“

Im OSGi-Umfeld sind die Begriffe Service und Microservices (OSGi µservices) schon seit langem geläufig. Wie Peter Kriens in seinem Blogpost „Software mixed with marketing: micro-services“ erzählt, schien 1998 der Service-Begriff originell genug, um ihn in das OSGi-Vokabular einzugliedern. Dann kam SOA – und brachte „Services“ den zweifelhaften Ruf ein, schwergewichtig, teuer und komplex zu sein.

Und danach die Karriere der Webservices: „The web-services guys have stolen our name“, resumierte Kriens schon 2010 und nennt den Unterschied zu einem OSGi-Service: Ein Web-Service kommuniziert mit einer Entität außerhalb des eigenen Prozesses – ein OSGi Service kommuniziert immer innerhalb des selben Prozesses. Dadurch sei ein OSGi Service fast so schnell wie ein leichtgewichtiges Objekt:

Calling a method on a [OSGi] service is as fast as calling a method on an object, services are almost as lightweight objects. There is some overhead in signalling the life cycle of the service for the providers and the consumers but in runtime all that overhead is gone.

Und jetzt Microservices?

I realized that they had stolen our name again!

Ein Microservice bleibt ein Webservice oder ein REST-Service, sagt Kriens. Microservices erbten damit die oftmals gar nicht so kleinen Kommunikationsstacks und den Overhead, der mit Fernaufrufen von Prozeduren verbunden sei.

Looking at the discussions it seems that micro-services talk like a web-service, they walk like a web-service (that is, they don’t walk, they are actually kind of static), and they quack like a web-service. Ergo?

„Microservices“, diese neue Inkarnation von Webservices, seien nur konzeptuell klein, lautet Kriens’ Einschätzung. Dabei sollte es bei einer modularen Architektur nicht einmal so sehr um die Größe der Module gehen. Modulgrenzen sollten auf der Basis der „Kohäsion„, d.h. der konzeptuellen Nähe der Service-Methoden im Verhältnis zum Gesamtsystem gezogen werden. In den aktuellen Diskussionen gehe es also nicht wirklich um „Microservices“, sondern um etwas wie „cohesive web-services.“

Cohesion measures the conceptual closeness of the service’s methods in relation to the overall system, a cohesive services has a well defined single responsibility. When I read about the micro-web-services I think they actually just mean cohesive web-services.

Zum Abschluss bittet Kriens deshalb die Microservices-Leute, ihre „brilliante“ Idee „cohesive web-services“ zu nennen, anstatt den Microservice-Begriff weiter zu verfälschen.

So can someone please ask them to call their bright idea cohesive web-services? Then we all know what they are talking about, we keep the vocabulary consistent, and we can keep using the term µservices because in OSGi they actually are!

OSGi versus Microservices

Wie dem auch sei, über Begriffe kann man bekanntlich trefflich streiten. Dem Microservice-Gedanken sollte man sich aber, genauso übrigens wie den OSGi µservices, zunächst einmal offen zeigen. Zu empfehlen ist deshalb die Lektüre des Java-Magazin-Schwerpunkts: Neben der Einführung von Eberhard Wolff zeigt hier Timmo Freudl-Gierke, wie sich das Microservice-Modell in der Praxis bewährt hat. Das Fazit seines Artikels „Nie wieder Monolithen! – Micro Services in der Praxis“ fällt jedenfalls positiv aus:

Einen Micro Service zu entwickeln, ist wie ein green-field-Projekt in den ersten drei Monaten. Das macht richtig Spaß. Und zwar nachhaltig. Zufriedene und hoch motivierte Mitarbeiter sind die Konsequenz.

Fachlich bilden unsere Services eine geschlossene Funktionalität ab. Neue Anforderungen werden in neuen Services implementiert (Open Closed Principle). Einem grenzenlosen Wachstum der Code Base bis hin zu einem Monolithen ist damit ein für alle mal ein Riegel vorgeschoben. Jeder Service bleibt in Gänze verständlich und wartbar.

Durch die technologische Unabhängigkeit jedes Micro Service, sind Updates, neue Frameworks oder andere Programmiersprachen problemlos möglich. Entwickler profitieren von den Vorteilen aktueller Frameworks und kurzer Turnaround-Zeiten. Damit können wir Anforderungen schneller umsetzen.

Auf der JAX haben wir uns außerdem mit Eberhard Wolff über das Thema unterhalten. Passen Microservices in Ihr Architektur-Modell? Bilden Sie sich selbst ein Urteil!

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare
  1. Peter Kriens2014-06-24 12:52:16

    Thanks for asking! :-)

Schreibe einen Kommentar

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