Was sind Microservices?

Microservices sind ein Architekturkonzept für die Anwendungsentwicklung. Als Architektur-Frameworks sind Microservices verteilt und lose gekoppelt, sodass die Änderungen eines Teams nicht dazu führen können, dass die gesamte Anwendung nicht mehr funktioniert. Der Vorteil bei der Verwendung von Microservices liegt darin, dass Entwicklungsteams schnell neue Anwendungskomponenten bauen können, um sich ändernden geschäftlichen Anforderungen gerecht zu werden.

Der Unterschied zwischen einer Microservice-Architektur und traditionellen, monolithischen Ansätzen besteht in der Art und Weise, wie Apps in ihre Kernfunktionen aufgeschlüsselt werden. Jede Funktion bzw. jeder Service kann unabhängig entwickelt und bereitgestellt werden. Das heißt, individuelle Services können ohne negative Auswirkungen auf andere Services ausgeführt werden (und ausfallen). Das hilft Ihnen dabei, die technologische Seite von DevOps anzunehmen, und CI/CD (Continuous Integration/Continuous Delivery) nahtloser und erreichbarer zu machen.

Erinnern Sie sich an Ihren letzten Einkauf in einem Online-Shop. Dabei haben Sie vielleicht die Funktion für die Produktsuche auf der jeweiligen Webseite verwendet. Diese Funktion ist ein Service. Vielleicht wurden Ihnen auch Empfehlungen für verwandte Produkte angezeigt, die aus der Datenbank der Käuferpräferenzen stammen. Auch das ist ein Service. Haben Sie Artikel zu Ihrem Warenkorb hinzugefügt? Genau, auch das ist ein Service.

Ein Microservice ist also eine Kernfunktion einer Anwendung und wird unabhängig von anderen Services ausgeführt. Bei der Microservice-Architektur aber geht es um mehr als nur die lose Kopplung solcher Kernfunktionen. Es geht um die Umstrukturierung der Entwicklungsteams und der serviceübergreifenden Kommunikation auf eine Art und Weise, die als Vorbereitung auf unvermeidbare Fehler, zukünftige Skalierbarkeit und die Integration neuer Funktionen fungiert.

Wie wird das erreicht? Durch die Anpassung der Grundlagen einer serviceorientierten Architektur (SOA) zur Bereitstellung von Microservices.

Kommt Ihnen die Idee, Apps in ihre Kernfunktionen aufzugliedern, um Probleme monolithischer Konzepte zu vermeiden, bekannt vor? Microservice Architekturen ähneln dem Muster der serviceorientierten Architektur (SOA), das bereits ein sehr ausgereiftes Software-Designmuster ist und vielfältig verwendet wird. 

In den Anfängen der Anwendungsentwicklung erforderten selbst minimale Änderungen an einer vorhandenen App ein komplettes Versions-Update mit einem eigenen Qualitätssicherungszyklus. Das wiederum hat die Effizienz zahlreicher nachgelagerter Teams enorm eingeschränkt. Dieses Konzept wird deshalb oft als „monolithisch" bezeichnet, weil sich der Quellcode für die gesamte App in einer untrennbaren Entwicklungseinheit (wie .war oder .ear) befand. Wenn also Updates für Teile einer App Fehler verursachten, musste das ganze System offline genommen, zurück skaliert und repariert werden. Zwar ist dieses Konzept für kleinere Anwendungen immer noch umsetzbar, die damit verbundenen Ausfallzeiten sind für wachsende Unternehmen allerdings nicht mehr tragbar.

Und genau hier kommt der SOA-Ansatz ins Spiel: Apps werden in diskrete, wiederverwendbare Services strukturiert, die über einen ESB (Enterprise Service Bus) kommunizieren. In dieser Architektur folgen die um einen bestimmten Geschäftsprozess organisierten Einzelservices einem Kommunikationsprotokoll (wie SOAP, ActiveMQ oder Apache Thrift), sodass sie über den ESB gemeinsam verwendet werden können. Diese über einen ESB integrierten Services bilden eine Anwendung.

Auf der einen Seite können dadurch Services ganz ohne monolithische Entwicklungszyklen gleichzeitig entwickelt, geprüft und angepasst werden. Auf der anderen Seite stellt der ESB einen Single Point of Failure für das gesamte System dar. Das heißt, beim Versuch, einen monolithischen Ansatz zu eliminieren, hat man einen neuen ins Leben gerufen, nämlich den ESB, der ein Hindernis für die gesamte Organisation sein kann.

Worin besteht der Unterschied? Microservices können, üblicherweise zustandslos, miteinander kommunizieren. Daher sind auf Microservices basierende Apps fehlertoleranter und weniger abhängig von einem einzelnen ESB. Und weil Microservices über sprachunabhängige APIs (Application Programming Interfaces / Programmierschnittstellen) kommunizieren, können Entwicklungsteams ihre eigenen Tools wählen.

Wenn man sich die Geschichte von SOA ansieht, sind Microservices eigentlich gar kein so neues Konzept. Allerdings ist ihre Realisierbarkeit dank der Fortschritte bei der Containerisierungstechnologie zwischenzeitlich enorm angestiegen. Mit Linux-Containern können Sie jetzt mehrere Teile einer App auf derselben Hardware unabhängig voneinander ausführen, während Sie gleichzeitig die einzelnen Bestandteile und Lifecycles viel besser steuern können. Zusammen mit APIs und DevOps-Teams bilden containerisierte Microservices die Basis für cloudnative Anwendungen.

Dank der verteilten Entwicklung von Microservices entstehen für Ihre Teams und Routinen ganz neue Möglichkeiten. Außerdem können Sie mehrere Microservices gleichzeitig entwickeln. Das heißt, dass mehrere Entwicklerinnen und Entwickler gleichzeitig an derselben App arbeiten und so die Entwicklungszeit deutlich reduziert werden kann.

Wenn Ihre Organisation über einen Wechsel zu einer Microservice-Architektur nachdenkt, dann beachten Sie, dass sich dadurch nicht nur die Funktionsweise der Apps ändert, sondern auch die Arbeitsweise Ihrer Teams angepasst werden muss. Organisatorische und kulturelle Änderungen gelten als Herausforderungen, weil jedes Team seine eigenen Entwicklungsabläufe hat und für individuelle Services mit einem eigenen Kundenstamm verantwortlich ist. Gedanken über teamübergreifende Auswirkungen mögen für einzelne Entwicklungsteams zwar nicht typisch sein, sind aber für den Erfolg einer Microservice-Architektur unerlässlich.

Neben den kulturellen und prozessualen Komponenten sind Komplexität und Effizienz zwei der größten Herausforderungen einer Microservice-Architektur. John Frizelle, Platform Architect bei Red Hat Mobile, hat bei seinem Vortrag anlässlich des Red Hat Summit 2017 die folgenden acht Herausforderungen für Microservices dargelegt:

1. Entwicklung: Sie benötigen Zeit, um die Abhängigkeiten zwischen Ihren Services zu identifizieren. Beachten Sie, dass der Abschluss eines Builds aufgrund solcher Abhängigkeiten mehrere weitere Builds auslösen kann. Dazu müssen Sie auch die Auswirkungen von Microservices auf Ihre Daten berücksichtigen.
2. Tests: Integrations- wie auch End-to-End-Tests können komplexer und wichtiger werden als je zuvor. Beachten Sie, dass – je nachdem, wie Sie die gegenseitige Unterstützung Ihrer Services strukturiert haben – ein Fehler in einem Teil Ihrer Architektur Probleme in einem anderen verursachen kann.
3. Versionierung: Vergessen Sie bei einem Update auf neue Versionen nicht, dass dadurch die Abwärtskompatibilität beeinträchtigt werden kann. Und auch wenn Sie eine bedingungsabhängige Logik integrieren, können Ihre Builds sehr schnell schwerfällig und ineffizient werden. Alternativ könnten Sie mehrere Live-Versionen für unterschiedliche Kunden hochfahren, das aber steigert wiederum den Wartungs- und Verwaltungsaufwand.
4. Deployment: Ja, auch dieser Punkt gehört zu den Herausforderungen, zumindest bei der anfänglichen Einrichtung. Um das Deployment zu erleichtern, sollten Sie großzügig in die Automatisierung investieren, da die Komplexität von Microservices für ein Deployment durch den Menschen überwältigend sein kann. Überlegen Sie, auf welche Art und Weise bzw. in welcher Reihenfolge das Rollout Ihrer Services erfolgen soll.
5. Protokollierung: Bei verteilten Systemen benötigen Sie zentrale Protokolle zur Erfassung aller Daten. Ansonsten wird eine effiziente Skalierung unmöglich.
6. Überwachung: Sie benötigen unbedingt eine zentrale Ansicht Ihres Systems, um die Ursachen von Problemen identifizieren zu können.
7. Debugging: Remote-Debugging mithilfe Ihrer lokalen IDE (Integrated Development Environment) ist hier keine Option und funktioniert nicht bei Dutzenden oder Hunderten von Services. Leider gibt es auf diese Frage zum jetzigen Zeitpunkt keine zufriedenstellende Antwort.
8. Konnektivität: Ziehen Sie eine Service-Discovery-Lösung in Betracht, zentral oder integriert.

Trotz der genannten Herausforderungen bietet eine Microservice Architektur viele Vorteile. Microservices ermöglichen es, bei der Erstellung neuer Anwendungen zukünftige Anforderungen besser zu berücksichtigen, leicht skalierbare und flexible Cloud-native Anwendungen zu erstellen und diese Anwendungen von Anfang an in den Rest des Unternehmens zu integrieren.