Microservices: Eventgetriebene Integrationsarchitekturen im Einsatz
Legacy-Systeme führen zu hohem Wartungsaufwand. Mit Eventgetriebenen Ansätzen lassen sie sich schrittweise modernisieren und ablösen.
(Bild: Shutterstock)
- Annegret Junker
Integrationsarchitekturen bestimmen die IT-Landschaft in Unternehmen. Keine Anwendung existiert nur für sich, sondern ist in eine vielfältige Landschaft einzubetten – neue Angebotsseiten oder Apps müssen in vorhandene Kundenmanagement- und Abrechnungssysteme integriert werden, oder auch in Systeme für den Eingang und den Ausgang von Dokumenten. Diese Prozesse verfügen über einen individuellen Lebenszyklus und damit auch über unterschiedliche technische Grundlagen. Wie kann man diese unterschiedlichen Systeme miteinander verbinden, ohne den Lösungsraum der Neuentwicklungen auf die historischen technischen Grundlagen der vorhandenen Systeme zu beschränken?
Technische Hinterlassenschaften
Neben den typischen Microservice-Integrationen mit API-Management und Eventing trifft man in heutigen Unternehmenslandschaften immer noch auf Punkt-zu-Punkt-Verbindungen oder Service-orientierte Architekturen unter Benutzung des Netzwerkprotokolls SOAP (Simple Object Access Protocol). Alle diese Integrationsmechanismen gilt es zu berücksichtigen und innerhalb einer Landschaft schrittweise zu harmonisieren.
Abbildung 1 zeigt die Aufgabe, vor der viele Architekten heute stehen: Wie lässt sich eine klassische schichtenorientierte Architektur in eine neue Microservice-Architektur überführen?
In klassischen Architekturen sind Frontend und Backend strikt getrennt. Die Frontend-Anwendungen sind hierbei nach groben Funktionsbereichen wie "Verkauf", "Kundenbetreuung" und "Schadenabwicklung" unterteilt. Das Backend ist überwiegend nach Geschäftsobjekten gegliedert und stellt eine exklusive Persistenzschicht zur Verfügung. Im Beispiel wären das Schnittstellen für "Kunde", "Vertrag" und "Schaden", wie sie für eine Versicherung typisch sind. Heute sind diese Systeme eine Hinterlassenschaft (engl. Legacy).
Üblicherweise nehmen die Probleme in ihrer Wartung und im Betrieb zu, je länger man solche Systeme betreibt. Mehrfache Erweiterungen oder Fehlerbehebungen machen sie immer schwerer wartbar. Technologien ändern sich, sodass sich Legacy-Systeme nicht mehr aktualisieren lassen und sich dadurch zum Sicherheitsrisiko entwickeln. Es ist daher wichtig, sie abzulösen. Allerdings sind sie nicht einfach von heute auf morgen verschwunden.
Legacy-Systeme sind technische Hinterlassenschaften. Sie sind durch ihre Historie und ihren langen Lebenszyklus schwer zu warten und ebenso schwer zu betreiben. Veraltete Technik, die der Hersteller nicht mehr unterstützt, macht sie zum Sicherheitsrisiko. Langfristig gilt es, Legacy-Systeme über geeignete Wege zu ersetzen. Dabei ist das Ersetzen im Verhältnis von 1:1 oftmals nicht möglich.
Moderne Microservice-Architekturen sind funktional orientiert, wobei ein Frontend mit Web- und Mobile-Anwendung einem Domain-Service zugeordnet ist. Zusammen bilden sie einen Bounded Context [1]. Die Domänenservices verfügen über eine eigene Persistenzschicht und stellen eine Geschäftsfunktion zur Verfügung. Der Austausch zwischen den einzelnen Domänenservices erfolgt über Events, sodass einzelne Services auf Änderungen von Geschäftsobjekten gezielt reagieren können. Im Beispiel sind das die Services "Aufgaben", "Beratung", "Vertragsänderung", "Schadensmeldung" und "Auszahlung".
Der Begriff Bounded Context stammt aus dem Domain Driven Design (DDD) und bezeichnet einen Bereich einer komplexen Unternehmensanwendung, der sich durch ein Team sowohl im Frontend- als auch im Backend-Bereich abdecken lässt. Der Bounded Context verfügt über eine eigene Sprache und eine eigene Persistenzschicht. Dabei stellen ausschließlich wohl definierte Schnittstellen die Verbindungen zu anderen Bounded-Context-Bereichen her.
In heutigen hybriden Landschaften sind alle Spielarten vertreten. Wie kann man nun klassische Architekturen in moderne Architekturen überführen? Big-Bang-Ansätze, in denen man einfach das eine mit dem anderen ersetzt, sind in der Regel ausgeschlossen – Schritt-für-Schritt-Ansätze sind diesen vorzuziehen. Allerdings fordern diese Prozesse jeweils individuelle Herangehensweisen. Integrationsarchitekturen bieten hierbei die Möglichkeit, Architekturen miteinander zu verbinden. Man unterscheidet zwischen System-zu-System-Integrationen oder auch West-Ost- sowie Frontend-zu-Backend- oder auch Nord-Süd-Integrationen.
Insbesondere West-Ost-Integrationen verlangen nach Eventgetriebenen Architekturen, da nur diese entkoppelte Systeme in einer Microservice-Architektur ermöglichen. Eventgetriebene Architekturen sind hierbei Architekturen, in denen die Systeme nicht direkt, sondern vielmehr über einen Event-Bus miteinander kommunizieren. Die Systeme erreichen auf diese Weise eine hohe Unabhängigkeit, die mehr Stabilität und unabhängigere Entwicklung ermöglicht.
Eventgetriebene Architekturen sind Softwarearchitekturen, die einen Event-Bus verwenden, um Information über sogenannte Events auszutauschen. Events sind Ereignisse aus einem System. Die Information, dass ein solches Ereignis stattgefunden hat, wird über den Event-Bus einem anderen System zur Verfügung gestellt. Das kann beispielsweise das Erzeugen oder das Ändern eines Vertrages sein.
