Wenn die IT-Architektur das Geschäft ausbremst Eine Basis für Event-driven Microservices schaffen

Von Dipl. Betriebswirt Otto Geißler 4 min Lesedauer

Für den Fall, dass monolithische Anwendungen die Geschäftsanforderungen nicht mehr erfüllen, sollten Anwender über ereignisgesteuerte Microservices nachdenken. Bei der Implementierung lauern jedoch einige Gefahren. Was ist für eine erfolgreiche Projektierung zu beachten?

Mit Microservices erhalten Anwender die vollständige Kontrolle darüber, wie Geschäftsprobleme am besten gelöst werden können.
Mit Microservices erhalten Anwender die vollständige Kontrolle darüber, wie Geschäftsprobleme am besten gelöst werden können.
(Bild: Gerd Altmann)

Viele Organisationen erreichen irgendwann eine Phase, in der sie auf Grund eines starken Wachstums, neuer Technologien oder widersprüchlichen Anforderungen an die Performance vor große Herausforderungen gestellt werden. Für eine einzelne, monolithische Code-Basis sind solche Aufgaben dann nicht mehr effizient zu bewältigen.

Ereignisgesteuerte Microservices überwinden die Einschränkungen monolithischer Applikationen. Eine Anwendung wird hierbei in kleine, speziell entwickelte Services unterteilt, die individuell auf ein jeweiliges Geschäftsproblem zugeschnitten werden können und sich durch bestimmte Ereignisse auslösen lassen.

Kriterien für den Einsatz von Microservices

Ziehen Unternehmen eine ereignisgesteuerte Microservices-Architektur in Betracht, besteht der erste wesentliche Schritt darin, herauszufinden, ob bestimmte Dienste und Funktionen überhaupt benötigt werden. Eines der häufigsten Anzeichen dafür ist das Schreiben oder die Nutzung von APIs für den Massenexport von Daten. Ähnlich verhält es sich, wenn regelmäßige Abfrageaufträge zu schreiben sind, um Daten aus einer Datenbank abzurufen und in eine andere zu übertragen.

Dies sind Beispiele einer Ad-hoc-Datenkommunikationsschicht. Das bedeutet, für solche Fälle wird die Funktionalität des mit diesen Daten verbundenen Monolithen nicht benötigt. Dieses Muster trat früher häufiger auf, wenn Daten aus Online-Transaktionsverarbeitungssystemen (OLTP) extrahiert wurden, um Online Analytical Processing (OLAP) durchzuführen.

Mit dem extremen Wachstum von Daten, Leistungs- und Geschäftsanforderungen sind dieselben Extraktions- und Lademuster heute allerdings für jedes Betriebssystem, das für seine Funktion allgemeine Geschäftsdaten benötigt, weit verbreitet. Ereignisgesteuerte Microservices bieten eine Möglichkeit, sowohl auf historische als auch auf neue Daten in Form eines unveränderlichen Ereignisprotokolls zuzugreifen, das nur angehängt werden kann.

Fortschrittliche Cloud-Services verwenden

Jeder neue Service, der erstellt werden soll, erfordert eine Bereitstellungspipeline, Container-Verwaltung, Überwachung und Skalierungsdienste. Dutzende Microservices benötigen mehr Aufwand und Verwaltung als ein einzelner monolithischer Service. Doch dieser nicht unerhebliche Overhead lässt sich letztlich durch die Rationalisierung und Automatisierung der Abläufe bzw. verwaltete Cloud-Dienste reduzieren.

Ein Beispiel für diese Automatisierung liefert die im Grunde recht einfachen Bereitstellung, Verwaltung, Überwachung und Skalierung von Docker-Diensten auf Kubernetes. Ebenfalls ist das Erstellen und Verwalten von Kafka-Themen über Cloud-Services wie Confluent Cloud einfacher denn je. Dabei ist nur auf den Unterschied zwischen „verwalteten“ und „vollständig verwalteten“ Services zu achten.

Sukzessive auf bestehende Systeme aufbauen

Beim Umstieg auf eine Microservices-Architektur sollte der Anwender damit beginnen, einen spezifischen Use Case zu identifizieren, der einen echten Geschäftsbedarf bzw. Mehrwert darstellt. Beispielsweise möchte ein Anwender Daten aus verschiedenen relationalen Tabellen in einer Datenbank zusammenführen und umgestalten, um eine neue dokumentbasierte Suchfunktion zu erzeugen.

Die alles entscheidende Frage lautet nun: Wie lassen sich die vorhandenen Nicht-Streaming-Datenquellen in eine ereignisgesteuerte Architektur integrieren?

Kafka Connect ist eine hervorragende Option zum Bootstrapping von Datenbanktabellen in ihre eigenen Event-Streams. So kann der Anwender eine Verbindung zu einer ganzen Reihe lokaler und Cloud-Datenbanken herstellen, historische Daten aufzeichnen, Daten filtern, Spalten maskieren und vieles mehr. Dabei bleibt die Quelldatenbank unabhängig von Kafka Connect, sodass wichtige Geschäftsdaten schrittweise beschafft werden können, ohne bestehende Systeme zu beeinträchtigen.

Microservices lassen sich inkrementell erstellen und dabei die ursprüngliche monolithische Anwendung so lange beibehalten, wie sie benötigt werden. Es geht dabei nicht um ein Entweder-oder, sondern darum, die zusätzlich benötigten Daten und Funktionen in einer Geschwindigkeit bereitzustellen, die für das Unternehmen sinnvoll ist.

Microservices auf die Geschäftsanforderungen abstimmen

Idealerweise sollten Microservices so entworfen werden, dass sie spezifische, eng miteinander verbundene Geschäftsprobleme lösen, da für ähnliche Probleme in der Regel ähnliche Daten erforderlich sind. Wenn sich Microservices an Geschäftsproblemen ausrichten, ist es unwahrscheinlich, dass sie geändert werden müssen, es sei denn, das Unternehmen ändert sich grundlegend.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Softwareentwicklung und DevOps

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

So könnte beispielsweise ein E-Commerce-Unternehmen Mikroservices implementieren, die nur die Funktion Zahlungen, Bestandsverwaltung oder Versand ausüben. Alle am Versand-Workflow vorgenommenen Änderungen wirken sich dann nur auf den Versand-Microservice aus.

Durch die Ausrichtung der Microservices an konkreten Use Cases wird das Risiko unbeabsichtigter oder zufälliger Änderungen verringert, da die Funktionalität in einem Service gekapselt ist. In komplexeren Anwendungsfällen ist es nicht ungewöhnlich, dass sich ein Geschäfts-Workflow über mehrere Microservices erstreckt.

Überschaubare Anzahl an Microservices

Microservices müssen nicht immer die allerkleinsten Einheiten abbilden. Es kann hilfreich sein, sich einen solchen Dienst als einen dedizierten Service für eine Teilmenge von Geschäftsproblemen vorzustellen. Einer der größten Fallstricke, in den viele Anwender tappen, ist die Erstellung von Microservices für jede einzelne Funktionalität, was oft zu Hunderten oder Tausenden von Services führt.

Das Ziel einer ereignisgesteuerten Microservices-Architektur besteht nicht darin, so viele Dienste wie möglich aufzubauen, sondern vielmehr darin, dedizierte Lösungen mit den richtigen Tools für die jeweilige Aufgabe zu ermöglichen.

Katalog über Event-Streams und Services erstellen

Mit einem Katalog über Microservices behält der Anwender den Überblick über seine Event-Streams. Darin sollten unter anderem Antworten auf folgende Fragen enthalten sein: Wozu gehört ein Event-Stream? Welche Daten enthält er? Welche Struktur wird verwendet? Welche Microservices sind bereits vorhanden? Für welche Event-Streams (und APIs) sind sie verantwortlich?

Toolbox mit bewährten Sprachen und Frameworks erstellen

Einer der Vorteile ereignisgesteuerter Microservices besteht darin, dass sie die Tür zu einer größeren Auswahl an Technologien öffnen, darunter verschiedene Programmiersprachen, Frameworks, Datenbanken und Tools. Dies kann jedoch zu einem Problem werden, wenn Entwickler zu viele verschiedene Technologien verwenden, insbesondere weniger bekannte oder aktuelle Technologien.

(ID:49524470)