Microservices mit Kotlin, Vert.x und OpenAPI, Teil 1
Dank neuer Konzepte und Techniken lassen sich mit wenig Boilerplate-Code und in kurzer Zeit schlanke und auch ressourcenschonende Microservices implementieren. Ein zweiteiliger Praxisartikel mit Vert.x, OpenAPI und Kotlin.
- Jan Weinschenker
Wenn in den vergangenen Jahren ein Architekturmuster als Königsweg oder Wunderwaffe bezeichnet wurde, um komplexe und gleichzeitig beherrschbare Anwendungssoftware zu entwickeln, dann war es in den meisten Fällen der Microservice. Das nicht zuletzt deswegen, weil viele Meinungen darüber kursieren, was genau ein Microservice ist, was er tun darf und was nicht. Dabei sind einige Ansichten weiter verbreitet als andere. Zu den verbreiteteren zählen:
- Sie sind individuell ausrollbar.
- Ein Microservice bildet eine klar abgegrenzte Geschäftsfunktion ab.
- Ein Microservice ist keine Schicht im Sinne der Drei-Schichten-Architektur. Vielmehr ist er ein in sich abgeschlossenes Stück Software, das im Rahmen seiner Geschäftsfunktion für alle Aspekte von der Datenhaltung bis zur angebotenen Schnittstelle selbst verantwortlich ist.
- Ein Entwicklerteam ist für den Microservice in Gänze verantwortlich.
- Ein Microservice sollte eine REST-Schnittstelle anbieten.
- Ein Microservice ist in seinem Umfang an Code klein und überschaubar.
In der Unix-Welt gibt es eine Philosophie zur Softwareentwicklung, die lautet: "Mache nur eine Sache und mache sie gut!" Der Microservice-Gedanke entspricht dieser Philosophie. Man möchte kleine, gut beherrschbare Softwarekomponenten mit klar definierten Schnittstellen haben, um daraus größere und komplexere Systeme zu bauen. Dadurch verringert sich die Komplexität des IT-Systems im Vergleich zu monolithischen Systemen üblicherweise nicht. Das Gegenteil ist meist der Fall: Microservice-Architekturen sind in der Regel komplex.
Das ist der Preis, mit dem man sich jedoch eine Reihe anderer Vorteile erkauft. Microservices lassen sich einzeln und unabhängig voneinander weiterentwickeln und skalieren. Da sie sich nach außen nur über eine definierte Schnittstelle abgrenzen, kann ihre Implementierung, sogar die zugrunde liegende Technik bei Bedarf erneuert oder ganz ausgetauscht werden, ohne dass diese Änderungen zwangsläufig bei den anderen Komponenten nachzuziehen sind.
Microservices mögen nicht für jeden Anwendungsfall der Königsweg oder die Wunderwaffe sein. Allerdings stehen ihr Nutzen und ihre Sinnhaftigkeit bei vielen Aufgaben außer Frage.
