Interview mit Michael Vitz

Microservices sollten kein technischer Selbstzweck sein

Hartmut Schlosser

Michael Vitz

Die Aufgabe, Altanwendungen zu modernisieren, kommt früher oder später auf jeden Entwickler zu. Wann es dann sinnvoll ist, bei der Modernisierung an eine Microservices-Architektur zu denken, haben wir mit Michael Vitz (Consultant bei innoQ und Sprecher auf dem Microservices Summit 2016) im Interview besprochen.

JAXenter: Du zeigst auf dem Microservices Summit, wie man monolithische Anwendungen modernisiert – zum Beispiel in Richtung einer Microservice-Architektur. Beginnen wir einmal bei der Frage, warum man das überhaupt tun sollte. Wann ist es aus deiner Sicht sinnvoll, ein Altsystem in Microservices zu überführen?

Michael Vitz: Worauf wir sehr viel Wert legen und dies auch in unserem Workshop klar zum Ausdruck bringen, ist, dass eine Modernisierung nie technischer Selbstzweck sein sollte. Letztendlich ist es Aufgabe eines jeden IT-Systems, die Wertschöpfungskette eines Unternehmens zu unterstützen. In einer so dynamischen Welt, wie wir sie heute haben, bestehen die Anforderungen an ein IT-System, neben den rein fachlichen Aspekten, insbesondere in der Wandelbarkeit. Häufig nimmt diese jedoch mit der Größe eines Systems ab. Hieraus entsteht der Wunsch nach kleineren Systemen, um diesem Effekt zu begegnen. Microservices bieten sich hierzu an, da diese ein großes System in mehrere kleine zerteilen. Da man nun allerdings die Komplexität von den Systemen in die Kommunikation zwischen eben diesen verschiebt, muss man sich im konkreten Einzelfall anschauen, ob eine Microservices-Architektur hier passt.

DevOps Docker Camp 2017

Das neue DevOps Docker Camp – mit Erkan Yanar

Lernen Sie die Konzepte von Docker und die darauf aufbauende Infrastrukturen umfassend kennen. Bauen Sie Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf!

JAXenter: Ihr bringt da ja durchaus auch finanzielle Aspekte ins Spiel – nach dem Motto: „Können Sie mir mal vorrechnen, wieso eine Microservice-Architektur die finanziell bessere Entscheidung ist?“ Kann man das wirklich genau beziffern?

Michael Vitz: Natürlich würde man sich wünschen, genau sagen zu können, wie hoch die Kosten für im System identifizierte Probleme sind und auch wie teuer es wäre, diese zu beheben. Es geht uns allerdings gar nicht darum, diese exakt beziffern zu können. Unsere Erfahrung zeigt, dass es Entscheidern vor allem wichtig ist, eine grobe Einschätzung zu haben und zu sehen, dass man sich überhaupt Gedanken gemacht hat.

Zu oft haben wir schon erlebt, dass einfach beschlossen wurde, das System zu modernisieren und anschließend ohne Planung an diversen Stellen im System Verbesserungen begonnen wurden. Hierbei entsteht jedoch häufig der Effekt, dass entweder Stellen verbessert werden, die nur von geringem Nutzen sind oder dass wichtige Stellen nicht verbessert werden, da der Aufwand zu groß ist. Kennt man jedoch vorab die groben Kosten, welche die Probleme aktuell verursachen und wie teuer eine saubere Behebung dieser ist, kann man hierüber mit dem Management sprechen, und es sind auch größere Verbesserungen möglich. Zu diesem Zweck reicht eine grobe Bezifferung der Kosten jedoch aus. Ein angenehmer Nebeneffekt von Microservices ist hierbei, dass zukünftige Änderungen in kleineren Systemen stattfinden und somit auch deren Auswirkungen und Kosten besser geschätzt werden können.

JAXenter: Und wann bringen Microservices nichts? Man könnte ja auch nur den Technologie-Stack erneuern und dennoch beim Monolithen bleiben?

Natürlich gibt es Szenarien, in denen Microservices keine  Vorteile bringen.

Michael Vitz: Natürlich gibt es auch Szenarien, in denen eine Microservices-Architektur keine oder nur geringe Vorteile bringt. Aus diesem Grund beleuchten wir im Workshop auch kritisch, welche Nachteile die Entscheidung für Microservices mit sich bringen. Die Teilnehmer sollten sich vor der Entscheidung für oder gegen Microservices die bei ihnen konkret vorhandene Problemstellung anschauen und genau betrachten, ob, und wenn ja, wo die Vorteile einer Microservices-Architektur zum tragen kommen. Weiterhin warnen wir explizit davor, eine Modernisierung nur anzugehen, um das System auf eine neue Technologie zu portieren. Technik ist leider heutzutage häufig zu einem Selbstzweck geworden. Wir als Entwickler sollten jedoch, obwohl Technik uns natürlich Spaß macht, ein solches Vorgehen kritisch hinterfragen und die Wertschöpfung, an der unser System beteiligt ist, nicht aus dem Blick verlieren.

Natürlich müssen auch Technologien erneuert werden, um langfristig die Wartbar- und Erweiterbarkeit des Systems zu erhalten. Die Erfahrung zeigt jedoch, dass es in einem großen System nur sehr schwer möglich ist, einen neuen Technologie-Stack einzubinden. Gerade dies macht Microservices ja auch so attraktiv. Man erhält kleine Systeme mit überschaubaren Auswirkungen und kann in diesen viel schneller Teile austauschen bzw. neu schreiben.

JAXenter: Dann nehmen wir einmal an, die Entscheidung ist gefallen, ein Altsystem zu modularisieren. Wie geht man dabei vor? Welchen Ansatz verfolgt ihr da?

Michael Vitz: Unserer Erfahrung nach scheitern die wenigsten Projekte rein an der Technik. Aus diesem Grund halten wir es für sehr wichtig, dass man die Leute im Projekt nicht überfordert. Man muss diese bei jedem Schritt, den man unternimmt, mitnehmen. Deshalb warnen wir, wie schon viele vor uns, vor einem großen Big-Bang-Ansatz und raten dazu, den Übergang Schritt für Schritt anzugehen. Im Workshop stellen wir hierzu aus dem Fundus von aim42 verschiedene Ansätze vor, die wir schon erfolgreich in unserer Projekterfahrung gesehen oder selber angewandt haben. Gemeinsam haben diese alle, das sei bereits vorab verraten, dass man sich zuerst einen Überblick über das aktuelle System verschaffen muss, um anschließend geplant und nachhaltig an einer Verbesserung zu arbeiten.

JAXenter: Welche Tools/Technologien unterstützen dabei, einen Monolithen zu modularisieren?

Michael Vitz: Diese Frage ist uns nur zu gut bekannt. Häufig kommen Kunden auf uns zu, damit wir ihnen einen Microservice-Stack vorschlagen. Leider lässt sich diese Frage nicht so einfach und pauschal beantworten. Eine Microservices-Architektur besteht aus vielen einzelnen Komponenten und insbesondere deren Zusammenspiel. Die verschiedenen Ausprägungen einer jeden Komponente bringen dabei eigene Vor- und Nachteile mit sich und müssen immer im konkreten Kontext betrachtet werden. Das wohl wichtigste „Tool“, welches wir als Entwickler hierbei einsetzen können, ist, neben einer soliden Ausbildung, unsere Erfahrung und das kritische Hinterfragen und Bewerten von Entscheidungen und technischen Lösungen.

Auf keinen Fall sollte man blind ein Tool X oder eine Technologie Y einsetzen, nur weil dies aktuell gehypt wird. Die primäre Arbeit besteht beim Weg vom Monolithen zu Microservices darin, zusammengehörige Teile zu erkennen und zu extrahieren. Hierzu helfen uns im ersten Schritt die gängigen Tools zur Architekturanalyse. Anschließend lassen sich mit bekannten Design-Patterns Module schneiden, die dann im letzten Schritt in eigene Microservices extrahiert werden können.

JAXenter: Was ist die Kernbotschaft Eures Workshops – was sollten die Teilnehmer auf alle Fälle mit nach Hause nehmen?

Michael Vitz: Uns ist wichtig, dass die Teilnehmer die folgenden Dinge mit nach Hause nehmen:

  • Entwickler sollten neben den vielen spannenden technischen Themen auch die Wertschöpfung durch das IT-System im Blick haben.
  • Langfristige Verbesserungen an einem großen IT-System benötigen eine solide Planung und verlangen Ausdauer. Macht man hierbei zu große oder zu viele Schritte auf einmal, überfordert man seine Organisation schnell. Aus diesem Grund muss man hier einen vernünftigen Mittelweg finden.
  • Microservices sind in vielen Fällen eine gute Architektur-Entscheidungen, aber nicht in jedem Fall.

JAXenter: Vielen Dank für dieses Interview!

michael_vitz-innoqMichael Vitz ist Consultant bei innoQ und verfügt über mehrjährige Erfahrung in der Entwicklung und im Betrieb von JVM-basierten Systemen. Zur Zeit beschäftigt er sich vor allem mit den Themen DevOps, Continuous Delivery und Cloud-Architekturen sowie Clojure.

Verwandte Themen:

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

Schreibe einen Kommentar

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