© Ekaphon maneechot/Shutterstock.com
Wie lässt sich Ordnung in einen Haufen (Micro-)Services bringen?

BPM und Microservices


Microservices sind hip oder sogar Hype. Und Martin Fowler sagt, man braucht keine Orchestrierungs-Engine in Microservices-Architekturen [1]. Sind Workflow-Engines also überflüssig? Und wie gehen wir dann mit Geschäftsprozessen um?

Bei Microservices [1] handelt es sich um einen Architekturstil, der in den letzten Jahren zunehmend an Popularität gewonnen hat. Ein Gesamtsystem stellt für einen Benutzer zumeist mehrere Dienste bereit. Microservices zerlegen das Gesamtsystem in einzelne Teile – eben die Microservices – die jeweils einen einzelnen Dienst fokussieren. Dies klingt ein wenig nach Serviceorientierter Architektur (SOA), unterscheidet sich aber in einem entscheidenden Punkt: in der Art und Weise, wie Microservices entwickelt, deployt und betrieben werden und wie sich die einzelnen Services in die Gesamtarchitektur eingliedern. War bei SOA die Hauptmotivation noch Wiederverwendung („built for reuse“), ist es bei Microservices vielmehr die unabhängige Austauschbarkeit einzelner Komponenten („built for replacement“).

Einzelne Microservices sollen möglichst unabhängig voneinander funktionieren. Diese Unabhängigkeit bezieht sich auf verschiedene Aspekte:

  • Unabhängiger Lebenszyklus: Microservices müssen unabhängig voneinander von verschiedenen Teams entwickelt werden können. Zudem muss es muss möglich sein, Microservices unabhängig voneinander zu starten und zu stoppen und einen Microservice unabhängig von anderen zu aktualisieren.

  • Stabile Interfaces: Microservices stellen der Umwelt stabile Interfaces bereit, die bei Updates nicht gebrochen werden dürfen. Falls inkompatible Änderungen an einer Schnittstelle notwendig werden, müssen diese durch Versionierung der Schnittstelle abgebildet werden.

  • Kommunikation: Muss ein Microservice, um seinen Dienst zu erfüllen, mit anderen Microservices kommunizieren, muss der aufrufende Service vorhersehen, dass der Kommunikationspartner nicht notwendigerweise in der Lage ist, die Anfrage sofort zu beantworten. Eingesetzte Patterns sind die Akzeptanz von partiellen Ergebnissen (ist der Kommunikationspartner nicht in der Lage, die Anfrage zu beantworten, wird dennoch weitergemacht und gegebenenfalls die Leistung eingeschränkt) oder die Kommunikation muss asynchron, meist mithilfe von Messaging, stattfinden.

  • Robustheit und Fehlertoleranz: Einzelne Microservices müssen weiterhin funktionieren, auch wenn andere Services im Gesamtsystem gerade Probleme verursachen. In vielen Fällen ist es besser, den Fehler bis zu einzelne...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang