© Ekaphon maneechot/Shutterstock.com
Business Technology Magazin
Business Process Service Architecture

BPM und Microservices - passt das?

Mit dem neuen Architekturansatz der Microservices lassen sich scheinbar ohne viel Aufwand monolithische Anwendungen in lose gekoppelte Services zerlegen. Aber was passiert eigentlich mit der Geschäftslogik? Wie können bestehende Geschäftsprozesse in einer Microservices-Architektur sinnvoll umgesetzt werden?

Ralph Soika


Wenn es heute in Diskussionen um moderne Softwarearchitektur geht, gehören Microservices längst zum guten Ton. Sie folgen einem leichtgewichtigen Lösungsansatz, der einen Gegenpol zu den meist über Jahre gewachsenen monolithischen Unternehmensanwendungen ist. In einer monolithischen Enterprise-Applikation werden die Businesslogik, die Datenbankschicht und auch das UI in einem gemeinsamen Kontext behandelt. Dieser umfasst in der Regel alle Aspekte des dahinterliegenden Geschäftsprozesses, z. B. einer Auftragsabwicklung. Mit zunehmender Komplexität wachsen aber meist auch die Probleme. Da große Softwaresysteme von Natur aus schwieriger zu managen sind, scheinen heute Microservices die passende Lösung zu sein, um Fehler aus der Vergangenheit zu umgehen und gewachsene Komplexität zu verringern. Aber ist es wirklich so einfach, eine Enterprise-Anwendung in lose gekoppelte Services aufzuteilen (Abb. 1)?

Auf den ersten Blick erscheint es zunächst naheliegend, die Geschäftslogik einer Enterprise-Anwendung in einzelne isolierte Services aufzuteilen. Doch häufig enden diese Projekte in einem verteilten System mit mehr oder weniger eng gekoppelten Serviceschichten. Der Grund hierfür ist häufig die Datenbankschicht, die als monolithischer Block in einer Microservices-Architektur überlebt und damit gegen das Konzept des Bounded Context verstößt – also eines Modells, das klare Grenzen zur Außenwelt zieht. Das führt dann in der Folge oft zu sehr komplexen Problemen bei der Synchronisierung zwischen den unterschiedlichen Services und Teams. Eine Änderung in der Datenbankschicht betrifft dann schnell mehrere, eigentlich voneinander getrennte Services.

Abb. 1: Monolithische Enterprise-Applikation vs. Microservices mit gemeinsamer Datenbank

Ein möglicher Lösungsansatz ist hier eine konsequente Auftrennung in so genannte Verticals. Hier werden die Geschäftslogik und die Datenbank jeweils in einen vertikalen Service zusammengefasst, um so die Abhängigkeiten über die gemeinsame Datenbank aufzulösen.

Abb. 2: Entkopplung über synchrone und asynchrone Events

Typischerweise erfolgt die Kommunikation zwischen den Services hier über das Versenden von synchronen oder asynchronen Nachrichten. So kann die Businesslogik eines einzelnen Microservices von den übrigen Services entkoppelt werden (Abb. 2). Aber löst dieser Ansatz wirklich die Probleme eines monolithischen Anwendungssystems, oder entstehen dadurch Probleme von ganz neuer Qualität?

Was machen wir mit dem Geschäftsprozess?

Ein Probl...

Business Technology Magazin
Business Process Service Architecture

BPM und Microservices - passt das?

Mit dem neuen Architekturansatz der Microservices lassen sich scheinbar ohne viel Aufwand monolithische Anwendungen in lose gekoppelte Services zerlegen. Aber was passiert eigentlich mit der Geschäftslogik? Wie können bestehende Geschäftsprozesse in einer Microservices-Architektur sinnvoll umgesetzt werden?

Ralph Soika


Wenn es heute in Diskussionen um moderne Softwarearchitektur geht, gehören Microservices längst zum guten Ton. Sie folgen einem leichtgewichtigen Lösungsansatz, der einen Gegenpol zu den meist über Jahre gewachsenen monolithischen Unternehmensanwendungen ist. In einer monolithischen Enterprise-Applikation werden die Businesslogik, die Datenbankschicht und auch das UI in einem gemeinsamen Kontext behandelt. Dieser umfasst in der Regel alle Aspekte des dahinterliegenden Geschäftsprozesses, z. B. einer Auftragsabwicklung. Mit zunehmender Komplexität wachsen aber meist auch die Probleme. Da große Softwaresysteme von Natur aus schwieriger zu managen sind, scheinen heute Microservices die passende Lösung zu sein, um Fehler aus der Vergangenheit zu umgehen und gewachsene Komplexität zu verringern. Aber ist es wirklich so einfach, eine Enterprise-Anwendung in lose gekoppelte Services aufzuteilen (Abb. 1)?

Auf den ersten Blick erscheint es zunächst naheliegend, die Geschäftslogik einer Enterprise-Anwendung in einzelne isolierte Services aufzuteilen. Doch häufig enden diese Projekte in einem verteilten System mit mehr oder weniger eng gekoppelten Serviceschichten. Der Grund hierfür ist häufig die Datenbankschicht, die als monolithischer Block in einer Microservices-Architektur überlebt und damit gegen das Konzept des Bounded Context verstößt – also eines Modells, das klare Grenzen zur Außenwelt zieht. Das führt dann in der Folge oft zu sehr komplexen Problemen bei der Synchronisierung zwischen den unterschiedlichen Services und Teams. Eine Änderung in der Datenbankschicht betrifft dann schnell mehrere, eigentlich voneinander getrennte Services.

Abb. 1: Monolithische Enterprise-Applikation vs. Microservices mit gemeinsamer Datenbank

Ein möglicher Lösungsansatz ist hier eine konsequente Auftrennung in so genannte Verticals. Hier werden die Geschäftslogik und die Datenbank jeweils in einen vertikalen Service zusammengefasst, um so die Abhängigkeiten über die gemeinsame Datenbank aufzulösen.

Abb. 2: Entkopplung über synchrone und asynchrone Events

Typischerweise erfolgt die Kommunikation zwischen den Services hier über das Versenden von synchronen oder asynchronen Nachrichten. So kann die Businesslogik eines einzelnen Microservices von den übrigen Services entkoppelt werden (Abb. 2). Aber löst dieser Ansatz wirklich die Probleme eines monolithischen Anwendungssystems, oder entstehen dadurch Probleme von ganz neuer Qualität?

Was machen wir mit dem Geschäftsprozess?

Ein Probl...

Neugierig geworden?


    
Loading...

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