Microservices in der Projektentwicklung: Zwischen Flexibilität und Komplexität

„Sollte ich Microservices verwenden?” Diese Entscheidung beruht letztendlich darauf, welche Ressourcen dem Projekt zur Verfügung stehen. Die Ressourcen eines Projektes fallen meist in zwei allgemeine Kategorien: Verfügbare Rechnerkapazität und verfügbares technisches Know-how. In der Entscheidung, wie beide am besten genutzt werden, können Microservices – bei richtiger Verwendung – viel Flexibilität bieten. Justin Theiss, ehemaliger Senior Backend Java Entwickler von Neofonie Mobile, gibt uns einen Einblick.

Microservices verkapseln einzeln einsetzbare Code-Bausteine und Abhängigkeiten, die sie zum Betrieb benötigen. Allgemein haben Entwickler eine große Bandbreite an Auswahlmöglichkeiten bezüglich der Entscheidung, wie sie beispielsweise einen Webservice, eine Push-Benachrichtigungen oder einen asynchronen Service programmieren. Es ist möglich, mit Programmiersprachen wie Python (Flask) oder C++ einen „Hallo Welt”-Webservice in zwei oder drei Codezeilen zu schreiben. Unter den Java-basierten Frameworks wird derzeit vor allem Spring Boot bevorzugt, sodass Entwickler ein breites Spektrum an Programmiersprachen und effektive Frameworks zur Verfügung haben. Während andere Java-Frameworks wie Play (unterstützt Java und Scala) und Dropwizard Entwicklern zwar moderate Flexibilität in Technologie-Stack-Entscheidungen ermöglichen, hat Spring Boot es an die Spitze geschafft. Grund dafür ist, dass ein Java-Container angeboten wird, der es ermöglicht mithilfe der Bausysteme Grails oder Maven Ruby, Groovy, Kotlin und Node.js zu verkapseln. Zusätzlich zu Springs D.I-Container und den zahllosen Frameworks sind dies wichtige Pluspunkte.

Microservices ermöglichen es also Entwicklern, ihre eigene, bevorzugte Programmiersprache zu nutzen. Aber wenn der Service REST lesen und schreiben oder sich generisch mit einer gemeinsamen Datenquelle verbinden kann, warum sollte man sich über die verwendete Programmiersprache, Gedanken machen? Microservices bieten zwar Flexibilität, aber sie können die Komplexität auch deutlich steigern!

Erhöhte Komplexität bedeutet mehr Problemstellen und Herausforderungen. Die Verengung des Technologie-Stacks reduziert nicht nur die Komplexität, sondern kann auch ein Ramp-up für neue Mitarbeiter vereinfachen. Auch das Risiko in eine Wartungsfalle zu geraten wird weitestgehend minimiert. Das Gleichgewicht zwischen Entscheidungsmöglichkeiten des Entwicklers und einem ausgefeilten Technologie-Stack ist eine der wichtigsten architektonischen Entscheidungen, die in den frühen Phasen des Projekts getroffen werden müssen.

Microservices können Projektmanager und Entwickler von traditionellen „monolithischen” Webservern und Web-Containern befreien. Solche Services, vor allem wenn sie Java-basiert sind, verwenden eingebettete Container und Server (als Abhängigkeiten) in einer deployten JAR-Datei. Das bedeutet, dass große, monolithische Java-Container nicht mehr zwingend benötigt werden und der Einsatz von Komponenten deutlich vereinfacht wird.

Wenn man den Microservice-Einsatz abstrahiert darstellt, lässt sich sagen, dass er vier Haupteinheiten enthält:

1. den Service an sich

2. den Host (d.h. eine Bare-Metal-Maschine, Rack)

3. eine VM (virtuelle Maschine) und

4. einen Container (Technologien mit virtueller Kapazität, meist Docker).

Kosten und/oder die verfügbaren Ressourcen sind der Schlüssel, um zu entscheiden, welche Konfiguration den Bedürfnissen des Projektes am besten entspricht.  

Obwohl Microcontainer helfen, die Last von monolithischen Web-Containern und Servern abzubauen, dezentralisieren sie zudem auch einige Aspekte der Netzwerkkommunikation. Deswegen müssen Netzwerkentscheidungen früh angesprochen und evaluiert werden, um Vorteile daraus zu ziehen.

Während dies in gewisser Hinsicht ein Kompromiss sein mag, integrieren moderne Frameworks zur Virtualisierung auch einiges der Einsatzkomplexität in jede einzelne Komponente (Docker, AWS, zahlreiche andere). Dadurch kann für jede einzelne Komponente von vornherein zusätzliche Entwicklungszeit sowie weiterer Aufwand während der anfänglichen Planungs- und architektonischen Projektphasen generiert werden.

Microservices – wenn sinnvoll eingesetzt – können die Komplexität innerhalb eines Entwicklerteams aufteilen. Somit ist ein Entwickler für einen Service verantwortlich. Außerdem kann die Arbeitsaufteilung dabei helfen, während der Entwicklungszeit Komplexität einzudämmen und gleichzeitig Entwicklern Autonomie in ihren Technologie-Stack-Entscheidungen zu erlauben.

Natürlich ist es großartig, dass das Projekt nun in einzelne Komponenten heruntergebrochen wurde. Aber was passiert, wenn diese Teile wieder zusammengefügt werden müssen? Die Orchestrierung von Services in einem dezentralisierten Netzwerk ist zugegebenermaßen einer der komplexesten Aspekte der modernen Service-Entwicklung, da mit der Anzahl der Services auch die Komplexität in der Orchestrierung steigt. Es gibt heute Frameworks zur Orchestrierung (und weitere sind in Planung), die versuchen, den Orchestrierungsprozess zu abstrahieren, wie zum Beispiel Kubernetes und Docker Swarm.

Und obwohl ein modularer Ansatz zu Microservices die Komplexität erhöhen kann, kann er im gleichen Zug die Entwicklung und Testbemühungen vereinfachen. Um komplexe Systeme zu bewältigen, zeigt sich das Implementieren realistischer Dummy-Services, welche das „Henne-Ei”-Entwicklungsprobleme lösen können, als hilfreiche Taktik. Dies können beispielsweise Abhängigkeiten von externen Services sein, die potentiell erst zu einem späten Zeitpunkt des Lebenszyklus eines Projekts verfügbar werden, oder besonders komplexe Komponenten, die zu Ressourcen-Engpässen führen könnten. Neben der Eindämmung von Komplexität kann Microservice-Architektur von Natur aus dabei helfen, Problemstellen in einem laufenden System zu isolieren. Was das Testen betrifft, ermöglichen die Vorteile von Container-basiertem Einsatz es den Entwicklern, realistische End-to-End Tests leichter durchzuführen.

Ein letzter wichtiger Punkt der Orchestrierung ist die Notwendigkeit von Service-Discovery, also der Zuweisung von IP-Adressen an einzelne Microservices innerhalb von Containern oder virtuellen Maschinen, in denen diese Adressen sich verändern können und sich auch verändern werden. Frameworks wie NGINX in Kombination mit Infrastrukturinstrumenten wie Consul (welches einen DNS-Service anbietet) können in der Sicherung der Kommunikation der Services untereinander und korrektem Routing zum Internet (ein und aus) sehr hilfreich sein.

Planung und eine solide Architektur sind wesentlich für die Implementierung einer Microservices basierten Architektur. Entwickler erhalten dadurch eine größere Eigenständigkeit in Technologie-Stack-Entscheidungen, jedoch könnte ein heterogener Technologie-Stack potentiell die Komplexität erhöhen. Die Orchestrierung der wesentlichen Komponenten eines Netzwerks, in dem unklar ist, inwiefern der Projektbesitzer die Kontrolle innehat, ist einer der herausfordernden Aspekte von Microservice-Architekturen. Wenn man sich von monolithischen Anwendungen weg entfernt, sind Netzwerkkommunikation und Design ebenfalls wichtige Punkte.

Veröffentlichung am 22. Juni 2017, aktualisiert am 17. Oktober 2020

Bildquelle: shutterstock, Anatoli Styf