Microservices und ESBs

2 Kommentare

Ein zentraler Enterprise Service Bus ist dafür zuständig, die Kommunikation zwischen Systemen innerhalb eines Unternehmens zu übernehmen. Dabei übernimmt der ESB Routing-, Transformations- und Mapping-Funktionalität und bietet in der Regel eine Fülle von Adaptern für unterschiedliche Technologien. Wie passt so ein ESB nun in eine Microservices-Architektur?
Im Folgenden werde ich die Einsatzmöglichkeiten skizzieren und bewerten.

ESBs als Kommunikationsplattform in einer reinen Microservices-Architektur

esb-microservices
Ich gehe davon aus, dass wir eine Basisarchitektur für die Kommunikation zwischen Microservices festgelegt haben, also beispielsweise REST über HTTP für synchrone Service-Aufrufe und Messaging über ein bestimmtes Messaging-System für asynchrone Kommunikation.
Microservices müssen also irgendwie kommunizieren. Da kann man natürlich auf die Idee kommen, einen zentralen ESB zu nutzen, um diese Kommunikation durchzuführen. Schauen wir mal etwas genauer darauf, was bei der Kommunikation zwischen Microservice A und Microservice E passiert:

  • Routing: Irgendwie müssen sich die Services finden.
  • Fachliches Mapping: Die beiden Services haben unterschiedliche Modelle. Irgendwo muss ein Mapping zwischen diesen Modellen stattfinden.

Und das ist es auch schon. Eine Protokolltransformation benötigen wir nicht, da alle Microservices die gleiche Basisarchitektur für die Kommunikation verwenden.
Der ESB könnte also das Routing übernehmen – dieses ist aber ebensogut, vielleicht sogar besser in einer eigenen Service Registry aufgehoben.
Okay, dann könnte der ESB das fachliche Mapping übernehmen – das ist jedoch eine ganz schlechte Idee. Wenn ein zentrales ESB-Team in einer zentral deployten Komponente im Wesentlichen Fachlichkeit implementiert, die nicht ihr Fachgebiet ist, werden alle Vorteile, die Microservices bringen, ohne Not weggeworfen.
Fazit
Ein ESB innerhalb einer reinen Microservices-Architektur ist nicht nur überflüssig, sondern hinderlich.
esb-microservices-cross

ESB als Kommunikationsplattform zwischen Microservices und Legacy-Systemen

Die Stärke eines ESBs liegt in der Protokolltransformation, wie wäre es also, einen zentralen ESB zur Kommunikation zwischen unseren Microservices und unseren Legacy-Systemen zu nutzen?
esb-legacy
Da allerdings die Protokolltransformation in der Regel mit dem fachlichen Mapping einhergeht, haben wir hier dieselben Probleme wie oben – ein zentrales ESB-Team bearbeitet Fachlichkeit und wird zum Bottleneck. Im schlimmsten Fall wird noch ein kanonisches Datenmodell verwendet, auf das sich alle einigen müssen – und nicht können, da unterschiedliche Bounded Contexts nun mal unterschiedliche Modelle haben.
Besser ist es da, einzelne kleine Anti-Corruption-Layer-Anwendungen vor jedes Legacy-System zu schalten. Diese Anwendung wird von dem Team verantwortet, das auch das Legacy-System betreut. Und diese Anwendung kann natürlich Adapter und Implementierungen von Integrationslösungen sinnvoll verwenden – aber eben nicht als zentraler ESB.
esb-legacy-acl

Fazit

Ein zentraler ESB macht in einer Microservices-Welt keinen Sinn. Die Integrations-Funktionalität von ESB-Produkten kann jedoch in einzelnen ACL-Anwendungen gut genutzt werden.

Tobias Flohre

Tobias Flohre arbeitet als Senior-Softwareentwickler/Architekt bei der codecentric AG. Seine Schwerpunkte sind Java-Enterprise-Anwendungen und Architekturen mit JEE/Spring. Er ist Autor diverser Artikel und schreibt regelmäßig Blogbeiträge zu den Themen Architektur und Spring. Zurzeit beschäftigt er sich mit Integrations- und Batch-Themen im Großunternehmen sowie mit modernen Webarchitekturen.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Roger Butenuth

    21. Januar 2016 von Roger Butenuth

    Wenn man sich die Umstände passend (und dazu noch ungeschickt) definiert, dann kann man jede Aussage begründen (ex falso sequitur quodlibet).

    Nehmen wir den ersten Teil (nur Microservices): Wer sagt denn, dass ein ESB EINE zentrale Komponente sein muss und vor allem EIN zentrales Team den ESB betreibt? Sinnvollerweise teilt man einen ESB auf, so dass z.B. eine Denial of Service Attacke auf den Webshop nicht auch noch die interne Kommunikation lahmlegt. Zentrale Teams (die schnell in einen Elfenbeinturm abwandern) sind ebenso nicht nur im ESB-Kontext eine schlechte Idee. Da ist es schon besser, die einzelnen Teams zu unterstützen, damit sie auch selbst lernen, mit einer Technik umzugehen. Dann hat man auch wieder fachliches Know How und Umsetzungsteam vereint.

    Nun zum zweiten Teil (Anbindung Legacy, wohl eher der Regelfall): Die wenigsten Unternehmen werden alle Software selbst bauen. (Buchhaltung etc. ist einfach zu standardisiert). Du hast ja selbst schon geschrieben, dass man dort ACLs benötigt. Wenn es ein selbst geschriebenes System ist, kann die ACL von dem Team des Systems gebaut werden (in der Theorie, Cobol-Entwickler, die REST-Schnittstellen bauen, sprengen zumindest meine Vorstellungskraft). Bei gekauften Systemen ist man gezwungen, es selbst zu lösen. Das kann man natürlich „zu Fuß“ mit einem Microservice machen. Aber wozu? Schreiben wir heute auch alle unsere http-Server selbst? Eher nicht. Hier kann ein ESB mit seinem Werkzeugkasten helfen. In entsprechenden Produkten gibt es meistens nicht nur generische Mapper, sondern oft schon fertige Konnektoren für gängige Systeme (SAP, Siebel, etc.).

    Ich sehe generell die Gefahr, dass Microservice-Evangelisten die Welt in Schwarz und Weiß aufteilen und dazu neigen, Dinge selbst zu bauen, die es bereits fertig auf dem Markt gibt.

    Wann ein ESB lohnt (und wann nicht) habe ich schon mal ausfürhlicher geschrieben: http://www.heise.de/developer/artikel/Relevanz-eines-Enterprise-Service-Bus-2148896.html

    • Tobias Flohre

      14. Februar 2016 von Tobias Flohre

      Hallo Roger,

      in Deinem Abschnitt für den ersten Teil steht keine Begründung dafür, dort doch einen ESB zu benutzen, zumindest lese ich sie nicht.
      In Deinem Abschnitt für den zweiten Teil steht, dass man den Werkzeugkasten eines ESBs für Integrattionszwecke nutzen kann, um den ACL zu schreiben. Das schreibe ich doch genauso. Du bist auch gegen zentrale Teams, prima, dann stehen wir doch auf einer Seite.

      Gruß,
      Tobias

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.