Diese Dinge gilt es bei Microservices zu beachten

Microservices gelten als das Wundermittel schlechthin bei der Modernisierung der Unternehmens-IT. Dabei sollte die Komplexität des Architektur-Ansatzes nicht unterschätzt werden. Matthias Gronwald, Co-CTO bei der Digitalagentur Turbine Kreuzberg, erklärt, worauf bei der Umstellung zu achten ist.

IT-Verantwortliche in Unternehmen müssen stets jede Menge Bälle gleichzeitig in der Luft halten: Neue Produkte und Features müssen entwickelt und implementiert werden, das System soll störungsfrei laufen und gleichzeitig den tagtäglichen wechselnden Anforderungen der Nutzer:innen oder Kund:innen entsprechen. Kein Wunder, dass dabei der Wunsch immer stärker wird, mehr Agilität und Flexibilität in die Weiterentwicklung von Systemlandschaften zu bringen.

Microservices – Durchaus verlockend…

Seit einigen Jahren landen Unternehmen immer häufiger bei “Microservices”-Architekturen, um diesem Wunsch nachzukommen. Die Vorteile ergeben sich aus der Modularität des Ansatzes – und sprechen für sich: Neue Funktionen einer Anwendung können hierbei schnell implementiert und erweitert werden, ohne dass dafür das gesamte System geändert werden muss. Im Gegensatz zu klassischen monolithischen Applikationen, die auf einem einzelnen umfassenden Quellcode basieren, werden bei Microservices-Architekturen die unterschiedlichen Funktionen der Anwendung in separate Komponenten aufgeteilt, die für sich einen Teil beziehungsweise einen Prozessschritt der Applikation als “kleinen Service” ausführen (daher der Name für den Ansatz).

Dadurch lässt sich die Time-to-market deutlich verringern. Zudem zahlt der Ansatz auf die Resilienz (die einzelnen Module können unabhängig voneinander bestehen), die Agnostik (freie Technologiewahl für die Module, solange die API-Kommunikation unterstützt wird) sowie die Skalierbarkeit (Services lassen sich über mehrere Instanzen einer Infrastruktur deployen) der Anwendung beziehungsweise des Systems ein. Insgesamt also alles Eigenschaften, die dem Anspruch an Agilität und Flexibilität nachkommen. Gerne wird dabei übersehen, dass diese Eigenschaften auch einige Herausforderungen mit sich bringen.

… wenn man den Herausforderungen gewachsen ist

Zunächst einmal sollte man sich bewusst machen, dass Microservices mit einer deutlichen Steigerung der Komplexität der Infrastruktur einhergehen. Die diversen Module müssen separat deployed und betrieben werden und je nach Tech-Stack kommen neue Technologien zum Einsatz, mit denen die Entwicklung und der Betrieb zurechtkommen müssen. Dabei ist es besonders wichtig, für Konsistenz zwischen den einzelnen Technologien sowie Modulen zu sorgen. Das führt unter Umständen nicht nur zu einem Mehraufwand für die DevOps-Teams, sondern erfordert auch spezifisches Fachwissen im Umgang mit den eingesetzten Lösungen.

Außerdem steigt der Kommunikationsaufwand des Systems insgesamt, da alle Module untereinander Informationen austauschen müssen. Ohne entsprechende zusätzliche Netzwerkressourcen wird das System aufgrund etwaiger höherer Latenzen ineffizient und das erhoffte Ziel der Agilität rückt in weite Ferne. Doch es bedarf nicht nur mehr Ressourcen insgesamt, sondern diese müssen auch entsprechend besser verteilt werden. Etablierte Lasttests sowie das Monitoring sollte man daher ebenfalls auf die neuen Gegebenheiten anpassen. Und nicht zuletzt gilt es, bestehende Kommunikationswege zu überdenken, denn der Umstieg beziehungsweise die Einführung von Microservices-Architekturen sind in der Regel mit erheblichem Aufwand verbunden. Hier empfiehlt sich vorab definitiv eine Abwägung des zusätzlichen Aufwands hinsichtlich Zeit und Ressourcen gegenüber des erhofften Mehrwerts des Ansatzes für das eigene System.

Bedingungen für den Umstieg auf Microservices

Sollte der Wunsch eines Umstiegs auf Microservices an IT-Verantwortliche herangetragen werden, dann ist es an ihnen, die Bedingungen festzulegen, um diesen Umstieg auch erfolgreich zu meistern. Die Grundvoraussetzungen lassen sich dabei wie folgt zusammenfassen:

• Langfristigkeit: Es muss klar sein, dass sich die Vorteile vor allem langfristig auswirken. Wenn sich hinter dem Wunsch des Managements zum Umstieg auf Microservices eher der Wunsch nach einem schnellen Start eines Produkts oder Projekts verbirgt, sollte die Bremse gezogen werden. Die oben erwähnte Abwägung spricht eindeutig dagegen. Hier ist es sinnvoller, das neue Projekt in Form eines Monolithen aufzubauen und diesen separat vom System auf einem anderen Server zu hosten. Dies ist deutlich zeit- und ressourceneffizienter.

• Wille zum Investment: Der Ressourcenaufwand für Entwicklung und Orchestrierung ist hoch. Gerade wenn fachliche Kompetenzen intern fehlen und nicht sofort aufgebaut werden können, müssen gegebenenfalls externe Partner eingebunden werden. Dies ist im Falle von Microservices zwar deutlich leichter, denn die Dritte können für spezielle Module hingezogen werden, ohne Zugriff auf das gesamte System zu benötigen. Doch zusätzliche Kosten entstehen dennoch, sowohl kurz als auch langfristig. Insgesamt amortisieren sich solche Investment besonders gut, wenn es um komplexe und hochgradig skalierbare Anwendungen geht.

• Vertrauen in das Team: Microservices-Architekturen bauen auf die Kombination unterschiedlicher Technologien, um ihre Stärken vollständig zu entfalten. Das bedingt jedoch, dass man dem Team möglichst freie Hand bei der Auswahl dieser Technologien lässt und Entwicklungsentscheidungen sowie Verantwortlichkeiten in den für das jeweilige Modul zuständigen Teams belässt. Besteht das Unternehmen auf etablierte Hierarchien oder gar einen bestimmten Tech-Stack, dann läuft dies dem Ansatz entgehen. Gleiches gilt für die Entscheidungen hinsichtlich der Entwicklungspipeline: Wer auf Deployment-Intervalle besteht, erschafft keine Microservices, sondern de-facto-monolithische Systeme.

Fazit

Microservices lösen zunehmend die monolithischen Systeme ab. Doch nicht jedes Unternehmen erfüllt die Anforderungen für den Einsatz des Architektur-Ansatzes und IT-Verantwortliche müssen über etwaige Stolpersteine frühestmöglich aufklären. Der strukturelle Erfolg von Microservices ist keinesfalls garantiert und nur wenn das Management und die IT bereit sind, alte Muster zu überwinden, kann der Ansatz erfolgreich implementiert werden.