Microservices erfreuen sich zunehmender Beliebtheit. Im Zuge der Modernisierung der Unternehmens-IT gelten sie als besonders erfolgsversprechend, da sie leicht zu erweitern sind und kleine Funktionalitäten auf jede beliebige Weise implementiert werden können. Gerade wenn auf der Führungsebene der Ruf nach Flexibilität und Agilität laut wird, scheinen Microservices das Mittel der Wahl zu sein, um die IT-Architektur zu modernisieren.

Doch Unternehmen unterschätzen die Komplexität von Microservices-Architekturen. Um sie gut zu verwalten, braucht es eine geeignete Infrastruktur und es muss sichergestellt werden, dass die Orchestrierung der einzelnen Services funktioniert. Das ist mit einer Vielzahl von DevOps-Aufgaben verbunden und kann eine ziemliche Herausforderung sein.

Damit Unternehmen bei der Modernisierung ihrer IT-Infrastruktur den für sie geeigneten Weg finden und ihre Systeme auch Jahre später noch im Griff haben, sollen im Folgenden Microservices einmal genauer betrachtet werden.

Was genau sind Microservices-Architekturen?

Traditionell sind Applikationen oft monolithisch aufgebaut. Die Anwendung mit all ihren Funktionen wird innerhalb der Architektur zentral verortet und verwaltet. Das bedingt in der Regel eine einzelne, umfassende Codebasis, die alle Komponenten und ihre Schnittstellen beschreibt. Diese geschlossenen Entwicklungseinheiten, etwa .war-Dateien (Web Application Archive), enthalten dabei den gesamten Quellcode einer Anwendung.

Bei Microservices-Architekturen werden die einzelnen Komponenten dagegen in kleine Komponenten unterteilt, die jeweils einen bestimmten Prozess der Anwendung als eigenständigen Service ausführen. Beispiele für solche Services aus dem E-Commerce-Bereich sind etwa eine Suchfunktion, der Warenkorb oder die "Recommendations" (Empfehlungen, die auf den gespeicherten Vorlieben eines Käufers beruhen). Dadurch wird die Funktionalität in separat verteilte Module aufgespalten, die unabhängig voneinander deployed werden können und über APIs miteinander kommunizieren.

Microservices - Vorteile

Die wichtigsten Vorteile von Microservices-Architekturen ergeben sich direkt aus der Modularität. So ist man in der Lage, einzelne Funktionen zu aktualisieren, zu deployen oder zu skalieren, ohne dass andere Teile des Systems dafür angefasst werden müssen. Das ist besonders nützlich, wenn es sich um ein System handelt, das stetigem Wandel unterliegt - etwa im E-Commerce - oder sich den regelmäßig verändernden Geschäftsanforderungen anpassen muss. Dedizierte Vorteile umfassen:

• Verbesserte Time-to-market: Anwendungskomponenten lassen sich schneller implementieren und modifizieren, da unterschiedliche Entwicklungsteams unabhängig und parallel arbeiten können, ohne dass die Änderungen das Gesamtsystem tangieren. So können neue Features zeitnah und effizient parallel zum Live-Betrieb der Applikation entwickelt beziehungsweise bestehende Features aktualisiert werden. Durch das separate Deployment werden Continuous-Delivery-Prozesse erheblich verbessert.

• Resilienz: Damit einher geht auch die Resilienz des Systems, da die einzelnen Services unabhängig voneinander bestehen. Kommt es zu einer Störung oder einem Ausfall bei einem Service, kann das übrige System in der Regel problemlos weiter arbeiten. Zudem lassen sich Workarounds und Quick Fixes schneller umsetzen als bei monolithischen Systemen.

• Agnostik: Durch die Separierung der Komponenten und die Kommunikation - nicht nur mit Drittsystemen - über APIs, sind Unternehmen freier in der Technologiewahl. Theoretisch lassen sich für die Entwicklung von Microservices einer Anwendung diverse Stacks und Programmiersprachen kombinieren, solange die APIs kompatibel sind. Die Abhängigkeit von einer zentralen Codebasis und der entsprechenden Programmiersprache beziehungsweise einem Softwareanbieter (Vendor Lock-in) entfällt.

• Skalierbarkeit: Skalierung bei Microservices lässt sich theoretisch unbegrenzt realisieren, indem der gewünschte Service über multiple Server oder Infrastrukturen hinweg flexibel deployed wird. Bei monolithischen Architekturen müsste dafür das gesamte System auf einer zusätzlichen Infrastruktur implementiert werden.

Microservices - Nachteile & Herausforderungen

Im Gegensatz zu monolithischen Systemen, in denen in der Regel eine große Komponente deployed und betrieben wird, sind bei Microservices-Architekturen multiples Deployment und der Betrieb diverser modularer Elemente erforderlich. Daraus ergeben sich für Unternehmen neben den Vorteilen auch einige Herausforderungen - in der Entwicklung und vor allem im Betrieb:

• Hoher Aufwand für Betrieb und Orchestrierung: Oftmals wird unterschätzt, wie aufwändig es sein kann, eine Microservices-Landschaft zu betreiben und zu orchestrieren. Um das reibungslose Zusammenspiel der Services zu gewährleisten, werden hohe Anforderungen an die Infrastruktur gestellt. Für deren Betrieb bedeutet das, dass viele Ressourcen notwendig sind für Maintenance und Orchestrierung. Grundsätzlich gilt: Je mehr Baustellen, desto größer das Risiko, dass etwas schiefgeht. Das gilt auch für die genutzten Technologien. Unternehmen sollten eher auf technologische Ansätze setzen, für die sie bereits Kompetenzen aufgebaut haben, als gleichzeitig neue Technologien und Microservices einführen zu wollen.

• Höhere laufende Infrastrukturkosten: Mit mehr parallel laufenden Services steigt die Komplexität der Gesamtarchitektur. Generell gilt: Was für ein monolithisches System einmal notwendig ist, wird bei n Microservices auch n-Mal benötigt. Jeder Microservice an sich besitzt seine eigene Systemarchitektur. Das hat auch Konsequenzen für das benötigte Tooling, beispielsweise für das Monitoring der Systeme oder das Logging.

• Performance: Da es sich bei Microservices um dezentrale Komponenten handelt, ist der Kommunikationsaufwand zwischen ihnen unweigerlich höher. Im Vergleich zu monolithischen Systemen nehmen die Netzwerk-Latenzen zu.

Wann lohnen sich Microservices-Architekturen?

Generell lässt sich sagen, dass Microservices-Architekturen dedizierte Expertinnen und Experten mit entsprechendem Fachwissen voraussetzen. Zudem müssen Unternehmen bereit sein, sowohl bei der Technologieauswahl als auch bei den Entwicklungsentscheidungen und Verantwortlichkeiten auf die einzelnen Teams zu vertrauen. Einen Microservices-Ansatz sollte nur verfolgen, wer sich wirklich als Tech-Unternehmen versteht und bereit ist, viele Ressourcen beziehungsweise Know-how im Bereich IT aufzubauen - oder das bereits getan hat.

Eine starke Hierarchie mit strikten Tech-Stack-Vorgaben läuft dem Gedanken des schnellen und unabhängigen Deployments entgegen. Hier entsteht im schlimmsten Fall ein "De-facto-Monolith", bei dem zwar Microservices zum Einsatz kommen, die dann aber in bestimmten Intervallen immer alle auf einmal deployed werden. Somit wird ein Nachteil von monolithischen Systemen, die geringe Flexibilität, mit der Komplexität der Microservices kombiniert - und niemand gewinnt.

Des Weiteren sind Microservices eher für Projekte geeignet, die langfristig gedacht sind und bei denen der Wille zu investieren erkennbar ist. Für ein einzelnes Deployment oder den schnellen Start eines Projekts oder Produkts bieten sich eher monolithische Architekturen an, die auf einem einzelnen Server gehostet werden. Microservices-Architekturen erfordern deutlich mehr Ressourcen, sowohl was die Infrastruktur als auch die personellen Kapazitäten betrifft.

Sind die Ressourcen für die Entwicklung und Orchestrierung vorhanden, empfehlen sich Microservices-Architekturen definitiv für Projekte beziehungsweise Anwendungen, die komplex sind im Sinne vieler Komponenten und Schnittstellen, die räumlich stark verteilt laufen und die hochgradig skalierbar sein sollen. Dabei müssen die Vorhaben nicht unbedingt vollständig intern abgebildet werden. Microservices-Architekturen erlauben auch die Einbindung externer Partner zur Entwicklung neuer Features, ohne dass der Dienstleister Einsicht in das gesamte System erhalten muss.

Unternehmen sollten die Voraussetzungen erfüllen

Microservices ist ein Thema, das viele IT- und Produktabteilungen umtreibt. Die Vorteile sind verlockend und lassen sich schnell und einfach demonstrieren - etwa in Form der weitgehend unabhängigen Implementierung einzelner Komponenten, der hohen Anzahl der Deployments oder der Feature-Updates. Doch ohne ein ausreichendes Verständnis für den Business Case und die technologischen Anforderungen an Architektur und Betrieb kann der Einsatz schnell zu einem Fiasko werden. Unternehmen sollten sich darüber klar sein, ob sie die Voraussetzungen für den effizienten Einsatz von Microservices-Architekturen erfüllen können und auch wollen. Andernfalls werden sich die Investitionen kaum oder gar nicht amortisieren.