Microservice

So geht es bei der Anwendung einer Microservice-Architektur darum, ein Projekt nicht als großes Ganzes zu realisieren, sondern die verschiedenen Arbeitsschritte in einzelne, voneinander unabhängige Aufgaben zu unterteilen.

Das Ziel: eine bessere Realisierung großer Programmierungsprojekte und der Aufbau einer modularen Software-Struktur, die schneller und flexibler auf Veränderungen oder Erweiterungen reagieren kann.

Herangehensweise

Hinter jedem Microservice steht in der Programmentwicklung im Idealfall ein eigenes Entwickler-Team. Von der Entstehung und Programmierung bis zur Auslieferung bzw. Implementierung und anschließenden Überwachung – jedes Team für sein Endprodukt selbst verantwortlich. Die Teams agieren unabhängig von anderen Microservices, können sich voll auf ihre eine Aufgabe konzentrieren und eigene Herangehensweisen zur Lösung spezieller Probleme finden.

Monolith vs. Microservice

Bei einer Microservice-Architektur sind die einzelnen Teams nur für ihr Modul, d. h. ihren eigenen Microservice zuständig und arbeiten mit individuellen Lösungswegen und Methoden an der Erledigung ihrer Aufgabe. Alle Microservices werden dann in einer Anwendung zusammengeführt. Das Gegenstück hierzu bildet die Programmentwicklung nach dem monolithischen Prinzip. Zwar arbeiten auch beim Monolithen verschiedene Teams an unterschiedlichen Entwicklungen. Die Arbeitsgruppen werden jedoch nach Technologie und Anforderung zusammengestellt und kümmern sich jeweils getrennt voneinander um Datenbanken, Services, Wartungsarbeiten etc. Dabei werden alle Aufgaben von Anfang an zusammen in einer großen Anwendung realisiert, die Teams sind immer voneinander abhängig. Das soll bei der Microservice-Architektur vermieden werden.

Vorteile der Microservice Architektur

Die Entscheidung für die Verwendung von Microservices für eine Anwendung bietet viele Vorteile. Was diese Art des Systemaufbaus auszeichnet? Sie ist äußerst:

• flexibel

Das Entwickler-Team eines Microservice agiert völlig eigenständig und autonom von anderen Teams. Das kann sogar so weit gehen, für unterschiedliche Microservices verschiedene Programmiersprachen oder eigene Datenbanken und Systeme zu verwenden, wenn dies für den jeweiligen Microservice die beste Lösung darstellt.

• stabil

Fällt ein Microservice aus, funktioniert nur dieser Baustein nicht mehr – es bricht nicht gleich die komplette Anwendung zusammen. Dadurch sind Microservice-Architekturen langfristig deutlich robuster als monolithische Systeme. Fehlersuche und Problembehebung sind deutlich einfacher, da nur ein kleiner, in sich geschlossener Teil des Programms analysiert werden muss. Das zuständige Entwickler-Team kann Bugs zudem sehr zügig fixen.

• kompatibel

Damit eine Microservice-Architektur am Ende reibungslos funktioniert, müssen die unterschiedlichen Bausteine zu einer Anwendung verknüpft werden. Für diese Verbindung verwenden Entwickler meist REST-APIs (Programmierschnittstellen auf Basis des technischen Webstandards „Representational State Transfer“) und schlanke HTTP-Methoden, die Kommunikation und Informationsaustausch der Microservices untereinander erleichtern.

• ressourcenschonend

Microservice-Architekturen können sehr punktuell angepasst werden, indem man nur einzelne Services stärkt, hinzufügt oder ausbaut. Im Gegensatz zum Monolithen, bei dem man das komplette System spiegeln müsste, bleiben Systeme auf der Basis von Microservices schlank und ohne großen Aufwand nach oben skalierbar.

Praktische Anwendungsgebiete

Wer profitiert von Microservice-Architekturen? Gerade schnell wachsende Unternehmen, die zeitnah auf Marktveränderungen wie Gesetzesvorgaben und Lizenzrechte oder steigende Nutzerzahlen sowie eine hohe Content-Nachfrage reagieren müssen, haben die Vorteile dieser Herangehensweise erkannt und ihre Systeme entsprechend umgestellt.

Die Video- und Audiostreaming-Dienste Netflix und Spotify etwa, die gegen eine starke Konkurrenz antreten, brauchen eine IT-Struktur, mit der sie in kürzester Zeit gegen neue Entwicklungen antreten, eigene Änderungen und Innovationen live stellen oder Reparaturen vornehmen können. Auch die Verkaufsplattform eBay startete ursprünglich als monolithisches System. Parallel zum Erfolg der Firma erreichte auch deren Code eine so kritische Masse, dass man sich zur Entwicklung einzelner Microservices entschied, die untereinander kommunizieren leichter zu handhaben sind.

Fazit

Einfaches Handling, unabhängig und flexibel agierende Teams, schnelle Umsetzung und Aktualisierung einzelner Services oder größerer System-Updates: die Vorzüge einer modernen Microservice-Architektur stellen die traditionelle monolithische Struktur auf den ersten Blick eindeutig in den Schatten. Schaut man genauer hin, sind Microservices jedoch nicht für jedes Projekt oder Unternehmen die richtige Lösung. Gerade bei Computerprogrammen mit weniger komplexen Strukturen oder einem insgesamt recht kleinen Entwicklerteam, steht der Aufwand zur Etablierung einzelner Microservices und Teams in keinem Verhältnis zu Kosten und Nutzen einer solchen Umstrukturierung.

Um die Vorteile beider System-Architekturen bestmöglich zu nutzen, empfehlen einige Experten daher eine „Monolith-first-Strategie“. Dabei wird ein Programmierprojekt zunächst als Monolith angelegt und erst dann auf Microservices umgestellt, wenn die Anwendung einen gewissen Umfang erreicht hat.