Integrationsarchitekturen in modernen Microservice-Architekturen
Integrationsarchitekturen spielen insbesondere in modernen stark verteilten Architekturen eine besondere Rolle. Die Architekturen unterliegen aufgrund des technologischen Wandels und notwendigen schnellen Marktanpassungen ständigen Änderungen. Daher ist es notwendig, insbesondere auf Integrationen von Systemen zu achten, um letztlich flexibel und anpassbar auf diese Veränderungen reagieren zu können, ohne das Gesamtsystem zu gefährden.
Was sind Integrationsarchitekturen?
Integrationsarchitekturen bilden den Klebstoff zwischen den Modulen einer gesamten Anwendungslandschaft eines Unternehmens [1]. Stellen wir uns einen Versicherer vor mit Bestandssystem, Verkauf, Schadensverwaltung, aber auch Human Ressources, Buchhaltung, Einkauf usw. Ein solches Unternehmen mit seinen zahlreichen Verflechtungen muss sich auf eine gute Integrationsarchitektur verlassen können, damit Einführungen von neuen Anwendungen und Ablösungen von überkommenen Strukturen nicht zum Zusammenbruch des Gesamtsystems führen. Das Beispiel in diesem Artikel konzentriert sich auf die Bereiche Verkauf, Bestand und Schaden, um die Verständlichkeit zu wahren.
Integrationsarchitekturen übernehmen dabei die Verantwortung für Datenflüsse und Schnittstellen, so dass Datenflüsse über die Gesamtarchitektur nachvollziehbar sind.
Peer-to-Peer Integrationen
Unterschiedliche Integrationen haben sich im Laufe der Zeit entwickelt. Die einfachste Integration ist eine Punkt-zu-Punkt-Integration (oder auch Peer-to-Peer-Integration). Diese Integration ist auf der einen Seite einfach aufzusetzen, führt aber auf der anderen Seite zu hohen Komplexitäten und schlechter Wartbarkeit.
Enterprise Service Bus
Enterprise Service Bus wurde als Integrationsarchitektur entwickelt und versprach alle Unternehmensanwendungen über einen Bus verbinden zu können. Dieses zentrale Versprechen wurde nicht gehalten. Ein Enterprise Service Bus setzt ein einheitliches Domänenmodell über das gesamte Unternehmen voraus. Ein solches Domänenmodell ist zu unflexibel und zu mächtig, als dass es in einem Unternehmen durchgesetzt und gepflegt werden kann. Selbst in kleinen Unternehmen können einheitliche Domänenmodelle nicht durchgesetzt werden, da der Verkauf immer einen anderen Blick auf den Kunden hat als die Buchhaltung.
Microservices
Domänenobjekte können gut für Microservices definiert und entsprechend getrennt implementiert werden. Das ermöglicht es, Domänenobjekte nicht mehr unternehmensweit definieren zu müssen, sondern mehr spezifisch innerhalb einer Domäne – also z. B. das Kundenobjekt für den Verkauf oder das Vertragsobjekt für den Bestand. Allerdings möchte man immer noch Daten zwischen den Domänen austauschen und braucht auch hierfür eine Integrationsarchitektur.
Integrationsszenarien für Microservices
Microservices erlauben flexibles und gut wartbares API-Management
API-Management beschreibt den Erzeugungs- und Veröffentlichungsprozess von Applikations-Programmier-Interfaces (APIs). Es werden Verwendungsregeln definiert, Zugriffe kontrolliert, Statistiken gesammelt und als Berichte zur Verfügung gestellt. API-Management-Tools stellen Mechanismen zur Unterstützung sowohl von Abonnenten als auch von Entwicklern zur Verfügung [2]. Ein API-Management-Tool besteht in der Regel aus einem Gateway, Veröffentlichungs-Werkzeugen, einem Entwicklerportal und Berichts- und Analysetools. Zusätzlich werden i. d. R. Werkzeuge zur Abrechnung angeboten, die die Inrechnungstellung der API-Nutzung ermöglichen.
API-Management-Szenarien befähigen einzelne Microservices REST-APIs für ihre jeweilige Fachlichkeit auszuprägen und sie Konsumenten zur Verfügung zu stellen. Ähnlich wie bei einer Fassade werden die Implementierungs-Details hinter dem API-Management "versteckt".
Service Mesh
Ein Service Mesh ist ein dedizierter Infrastruktur-Layer, um Service-zu-Service-Kommunikation zwischen Microservices zu unterstützen. Dabei wird das Muster eines Sidecars für den Service-Proxy benutzt. Der Sidecar übernimmt dann die Aufgabe, den eigentlichen Service ansprechen zu können oder auch andere Services anzusprechen. Während ein zentraler Baustein Monitoring, Überwachung und Logging übernimmt.
Eventing
Eventing heißt hier, das Erzeugen und Konsumieren von Ereignissen. Diese Ereignisse enthalten nicht veränderbare Objekte, die zum Datenaustausch dienen können. Dabei können Ereignisse als echte Ereignisse aufgefasst werden. D. h. es wird ein stattgefundenes Ereignis – z. B. die Änderung an einem Vertrag – gemeldet. Ereignisse können aber auch Kommandos sein, wie z. B. das Erzeugen eines Vertrags.
Hybride Landschaften
Die vorgestellten Integrationsszenarien mit Peer-to-Peer-Integrationen und Microservices eventuell sogar noch mit Enterprise-Service-Bus existieren heute in typischen Unternehmenslandschaften alle parallel. Wie kann man nun erreichen, dass durch die Einführung neuer Anwendungen oder auch die Ablösung von alten Anwendungen, die Unternehmenslandschaft nicht noch komplexer und damit nicht mehr beherrschbar wird?
Die für Microservices vorgestellten Integrationsszenarien können auch in hybriden Landschaften angewendet werden. Dabei unterscheidet man zwischen Nord-Süd- und West-Ost-Kommunikation.
- Nord-Süd-Kommunikation bezeichnet die Kommunikation von Frontend-Applikation zu klassischen Backend-Applikationen.
- Unter Ost-West-Kommunikation versteht man die Kommunikation zwischen Unternehmensanwendungen.
Um hybride Architekturen zu unterstützen, wird für die West-Ost-Kommunikation Eventing eingesetzt. Für die Nord-Süd-Kommunikationen werden API-Calls definiert. In beiden Fällen muss die Kommunikation über ein einheitliches Schnittstellenmodell unterstützt werden. Dabei können aber die einzelnen Domänen ihre Schnittstellenmodelle unabhängig voneinander definieren, während Unternehmensabstimmung nur zwischen den Domänen notwendig ist.
Für die Legacy-Architekturen werden Adapter zur Verfügung gestellt. Diese Adapter unterstützen bereits die Zielarchitektur (in Abb. 4 grün markiert). Dabei müssen sowohl API-Adapter als auch Event-Adapter zur Verfügung gestellt werden. Dadurch können die Legacy-Anwendungen Schritt für Schritt abgelöst werden, ohne die Anwendungen, die bereits der Zielarchitektur folgen, zu gefährden. Durch diesen Ansatz können auch für moderne Integrations-Architekturen Migrationsansätze erreicht werden.
Dr. Annegret Junker auf den IT-Tagen 2021
Zu einem ähnlichen Thema hält Dr. Annegret Junker zwei Vorträge auf den diesjährigen IT-Tagen – der Jahreskonferenz der Informatik Aktuell.
Event-driven Architektur @Allianz
(07.12.2021, 14:00 Uhr)
Anwendung von Microfrontends in der Allianz-Gruppe
(09.12.2021, 15:00 Uhr)
Zusammenfassung
Integrationsarchitekturen erlauben unterschiedliche Services in unterschiedlichen Domänen zusammenzuführen, so dass sie Daten austauschen können. Diese Integrationen werden in modernen, komplexen Microservice-Architekturen über REST-APIs in einer Nord-Süd-Kommunikation bereitgestellt. Dabei werden die Provider und die Konsumenten dieser Schnittstellen über ein API-Management-Tool sowohl in der Bereitstellung als auch in der Benutzung abgesichtert.
Ein weiterer Weg ist die Kommunikation über Events in Service-zu-Service-Kommunikationen oder auch West-Ost-Kommunikationen. Dieser Weg ergänzt die Nord-Süd-Kommunikation. Eine solche Event-Kommunikation erlaubt flexible und unabhängige Architekturen.
In hybriden und Migrationsarchitekturen können moderne Integrationsansätze unterstützt werden, in dem man Adapter für Zielarchitekturen bereitstellt, die die Legacy-Architekturen abstrahieren.
