Darf’s noch etwas Hype sein? Zum Nutzen der Diskussion um Microservices

Microservices: Sturm im Wasserglas oder Wassergläser im Sturm?

Holly Cummins

(c) Shutterstock / r.classen

Dank des Hypes um Microservices mag es den Anschein haben, dass jedes Entwickler-Team und jedes Unternehmen sein monolithisches Empire zerstückeln muss, um dem allgemeinen Microservices-Trend zu folgen. Das aber ist nicht unbedingt jedermanns Sache, meint Holly Cummins (IBM), Sprecherin auf der diesjährigen JAX London

Wir haben eine neue Phase im Microservices-Hype-Zyklus ist erreicht: Die Diskussion über den Hype hat mittlerweile die eigentliche Diskussion über die Microservice-Technologie abgelöst. Wir alle reden über Microservices und wir alle reden darüber, wie wir über Microservices reden. Dieser Artikel trägt selbstverständlich zu diesem Kreislauf bei. Vielleicht wäre auch „Checkpoint des Geschwätzes“ ein besserer Titel gewesen.

Aber gehen wir einen Schritt zurück. Ich denke, dass wir alle uns doch auf einige grundlegende Prinzipien einigen konnten. Eines davon dürfte die Einsicht sein, dass die Verteilung von schmutzigem Wasser in sehr viele Wassergläser das Wasser selbst nicht im Geringsten trinkbarer macht. Microservices sind dementsprechend kein Ersatz dafür, die eigene Codebase in Ordnung zu bringen. Sie passen deshalb auch nicht für jeden Programmierer-Typ.

Auf der anderen Seite motivieren Microservices durch ihre Struktur zu einer ganzen Reihe von erfolgreichen Entwicklerpraktiken, etwa zu sauberen Interfaces, lockerem Coupling und zu einer hoher Kohäsion. Sie fördern außerdem Praktiken, die zwar noch neu sind, aber einen äußerst vernünftigen Eindruck machen, z.B. bessere Skalierbarkeit durch Verzicht auf Statuszuweisungen zu gewinnen oder die Erhöhung der Qualität durch entsprechende Verantwortlichkeiten („you write it, you make it work in the field“).

Bei den meisten dieser architektonischen Praktiken handelt es sich schlicht um gutes Softwareengineering. Zweifellos profitiert davon, sie zu übernehmen. Sollten Sie das aber noch nicht getan haben, sollten Sie sich die Frage stellen, ob sie gleichzeitig zu einem Wechsel auf Microservices überhaupt schaffen können. Ein großer Teil der Debatte kreist um den besten Weg hin zu Microservices: Soll der Wechsel in Form eines großen Knalls erfolgen, indem man die Services graduell von den Enden her umstellt oder sollten Microservices Greenfield-Projekten vorbehalten bleiben?

DevOpsCon Whitepaper 2018

Free: 40+ pages of DevOps expert knowledge

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Kai Tödter (Siemens), Nicki Watt (OpenCredo), Tobias Gesellchen (Europace AG) and many more.

„…die Codebasis aufbrechen, ohne sie zu zerbrechen“

Ich gehöre zum Team, das WebSphere Liberty schreibt. Als superleichtgewichtiger Application-Server schaffen wir eher die Voraussetzungen für Microservices als dass wir sie unmittelbar konsumieren. Gleichwohl haben wir die Erfahrung einer ähnlichen internen Transformation gemacht. Wir hatten eine Legacy Codebase, die in vielerlei Hinsicht ganz großartig war, aber auch äußerst monolithisch und ziemlich groß. Wir mussten sie aufbrechen, ohne sie zu zerbrechen.

Wir wussten, dass wir modularer werden mussten, was durch einen Wechsel auf OSGi-Services bewerkstelligt werden sollte, einer Technologie, die viele Charakteristiken mit Microservices teilt. OSGi-Services erlauben zwar radikales Decoupling. Ist man aber unachtsam, kann ihre Dynamik schnell zu ernsten Problemen führen. Für uns hat es gut funktioniert, einen ganz neuen Kernel zu schreiben, und die vorhandenen Libraries Stück für Stück darauf zu übertragen.

Übers Scheitern nachzudenken, ist immens wichtig. Stellen Sie sich ein winziges Microservice-Wasserglas vor, hin- und hergeworfen in den rauen Gewässern des Netzwerks und inklusive der gelegentlichen Hardware-Blitzschläge. In diesem Bild ist Scheitern keine bloße Möglichkeit, es ist praktisch eine Gewissheit. Auf jeder Stufe des Testings muss eine gewisse  Fehlertoleranz eingebaut und praktiziert werden. Binden Sie sich nicht zu sehr an eine bestimmte Service-Instanz. Das war eine der wichtigsten Lektionen auf unserem Weg.

Wir mussten sicher stellen, dass unser Design den nötigen Framework-Support für den Code gewährleistet, um auf die Services auf eine robuste Art und Weise konsumieren zu können. Dabei fiel uns auf, dass unsere Tests – übrigens auch Teile unseres Codes – Annahmen über die Aktionsabfolge oder über das Timing zur Service-Bereitstellung anstellten. Diese Annahmen stellten sich zwangsläufig als falsch heraus – in der Regel um ein Uhr morgens beim Versuch, einen Green Build zu produzieren.

Die menschlichen Implikationen von Microservices

Auch wenn wir dazu neigen, hauptsächlich über die technologischen Implikationen von Microservices zu reden, bleibt es gleichwohl wichtig, sich über die menschlichen Auswirkungen Gedanken zu machen. Nicht jedem behagt es, für die Kompatibilität mit Services zu coden, die so schnell wieder verschwinden, wie sie einmal aufgetaucht sind. Damit können sie sich in einer Situation wiederfinden, wo Sie Team-Mitglieder zusammen mit dem Monolithen über Bord werfen müssen.

Planen Sie deshalb Zeitpuffer für die Ausbildung und Eingewöhnung mit ein und denken Sie daran, dass es ebenso lange dauern kann, neue Fähigkeiten zu entwickeln wie Code zu schreiben. Als der Großteil unseres Teams auf Service-orientierte Entwicklung umgeschaltet hatte, waren wir bereits im Besitz einer Beta, die deutlich zeigte, wie gut unser neues Modell funktionierte. Die sich abzeichnenden positiven Ergebnisse waren eine gute Kompensation für das gelegentliche nächtliche Kopfzerbrechen.

Besonders spannend an der Diskussion über Microservices finde ich, dass sie uns nötigt, über Architektur-Schemata, Team-Organisation, Fehlertoleranz und Best Practices nachzudenken, Code zu schreiben und Services zu liefern. Und selbst, wenn Microservices nicht jedermanns Sache sein sollten: Das muss doch etwas Gutes sein, oder?

Aufmacherbild: fishbowl with a little swirl in the water von Shutterstock / Urheberrecht: r.classen

Geschrieben von
Holly Cummins
Holly Cummins
Dr. Holly Cummins is a senior software engineer developing enterprise middleware with IBM WebSphere, and a committer on the Apache Aries project. She is a co-author of Enterprise OSGi in Action and has spoken at Devoxx, JavaZone, The ServerSide Java Symposium, JAX London, GeeCon, and the Great Indian Developer Summit, as well as a number of user groups.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: