Microservices

Was sind Microservices?

Microservices sind ein Architekturkonzept der Anwendungsentwicklung. Was sie von herkömmlichen, monolithischen Ansätzen unterscheidet, ist die Art und Weise, wie Apps in ihre Kernfunktionen aufgeschlüsselt werden. Jede Funktion bzw. jeder Service kann unabhängig entwickelt und implementiert werden. Das heißt, individuelle Services können ohne jegliche Beeinflussung anderer Services funktionieren (oder auch nicht).

Erinnern Sie sich nur einmal an Ihren letzten Besuch in einem Online-Shop. Dabei haben Sie vielleicht die Funktion für die Produktsuche auf der jeweiligen Site 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 er wird unabhängig von anderen Services ausgeführt. Bei der Microservice-Architektur aber geht es um mehr als nur die Verknüpfung solcher Kernfunktionen. Es geht um die Umstrukturierung der Entwicklerteams und der Kommunikation auf eine Art und Weise, die als Vorbereitung auf unvermeidbare Fehler, zukünftige Skalierbarkeit und Integration neuer Features fungiert.

Wie funktioniert das? Durch die Anpassung der Grundlagen einer SOA (Service-Oriented Architecture), sodass Microservices bereitgestellt werden.


Wenn es Ihnen bekannt vorkommt...

dass Apps in ihre Kernfunktionen aufgegliedert werden, um Probleme monolithischer Konzepte zu vermeiden, dann liegt das daran, dass der Architekturstil von Microservices dem etablierten Softwaredesign der SOA ähnelt.

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ückskaliert 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, bei dem Apps in diskrete, wiederverwendbare Services strukturiert werden, die über einen ESB (Enterprise Service Bus) kommunizieren. In dieser Architektur folgen die um einen bestimmten Geschäftsprozesses 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 Applikation.

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 Flaschenhals für die gesamte Organisation sein kann.


Was also ist er Unterschied zwischen SOA und Microservices?

Microservices können, üblicherweise stateless, miteinander kommunizieren. Daher sind auf Microservices basierende Apps fehlertoleranter und weniger abhängig von einem einzelnen ESB. Und weil Microservices über sprachunabhängige APIs kommunizieren, können Dev-Teams 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 den Fortschritten bei der Containerisierungs-Technologie 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.

Die größte Herausforderung einer jeder neuen Architektur sind die ersten Schritte. Möchten Sie neue Apps entwickeln oder alte transformieren? Sie sollten in jedem Fall über die Vorteile und Herausforderungen von Microservices nachdenken.


Welche Vorteile hat eine Microservices-Architektur?

Dank der verteilten Entwicklung von Microservices entstehen für Ihre Teams und Routinen ganz neue Möglichkeiten. So können Sie mehrere Microservices gleichzeitig entwickeln. Dies bedeutet, dass mehr Entwickler gleichzeitig an derselben App arbeiten und so die Entwicklungszeit deutlich reduziert werden kann.

Schnellere Markteinführung

Da die Entwicklungszyklen in einer Microservice-Architektur sehr viel kürzer sind, können auch Implementierungen und Updates viel agiler durchgeführt werden.

Hochgradig skalierbar

Wenn der Bedarf für bestimmte Services steigt, können diese über mehrere Server und Infrastrukturen hinweg flexibel implementiert werden.

Robustheit

Wenn diese unabhängigen Services ordnungsgemäß entwickelt sind, haben Sie keinerlei Auswirkungen aufeinander. Das heißt, wenn eine Komponente ausfällt, streikt im Gegensatz zum monolithischen Ansatz nicht gleich die gesamte App.

Einfache Implementierung

Da microservice-basierte Apps modular und dazu viel kleiner als herkömmliche monolithische Apps sind, können Sie die mit der alten Methodologie verbundenen Probleme getrost vergessen. Zwar erfordert die neue Variante eine intensivere Koordination, dieser Umstand kann jedoch durch die großen Vorteile mehr als wettgemacht werden.

Besserer Zugriff

Da eine größere App in kleinere Bestandteile aufgegliedert wird, können Entwickler die einzelnen Komponenten leichter verstehen, aktualisieren und verbessern, was wiederum zu kürzeren Entwicklungszyklen führt, speziell in Kombination mit agilen Methoden.

Mehr Offenheit

Dank sprachunabhängiger APIs können Entwickler ihre bevorzugte Sprache bzw. Technologie für die notwendige Funktion frei wählen.


Und die Herausforderungen?

Wenn Ihre Organisation über einen Wechsel zu einer Microservice-Architektur nachdenkt, dann seien Sie darauf gefasst, dass sich dadurch nicht nur die Funktionsweise der Apps, sondern auch die Arbeitsweise Ihrer Mitarbeiter ändert. 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. Diese Gedanken mögen für Entwickler 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 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. Test: 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. Implementierung: Ja, auch dieser Punkt gehört zu den Herausforderungen, zumindest bei der Ersteinrichtung. Um die Implementierung zu erleichtern, sollten Sie großzügig in die Automatisierung investieren, da die Komplexität von Microservices für eine Entwicklung 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 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.

Microservices haben noch viel mehr zu bieten