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
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 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?
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.
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.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Tobias Flohre
16.2.2022 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Tobias Flohre
Senior Software Developer
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.