In fast allen wichtigen Branchen wächst das Interesse an Microservices, die eine schnelle, regelmäßige und zuverlässige Bereitstellung komplexer Anwendungen ermöglichen. Aber Microservices allein sind nicht genug. Um das Potenzial von Microservices zu maximieren, müssen Unternehmen sie durch eine ereignisgesteuerte Architektur unterstützen, damit Daten nicht nur „in Ruhe“, sondern vollständig „in Bewegung“ sind.
Jonathan Schabowsky, Field CTO bei Solace, stellt eine nützliche Checkliste zur Verfügung und erläutert, wie Unternehmen nur durch ereignisgesteuerte Microservices das volle Potenzial ihrer Geschäftsanwendungen ausschöpfen können.
Laut einer aktuellen O'Reilly-Studie unter Softwareingenieuren und technischen Fachleuten haben mehr als drei Fünftel (61 %) der Befragten Microservices bereits seit einem Jahr oder länger im Einsatz. Die Studie ergab auch, dass der Finanz- und Bankensektor bei der Nutzung von Microservices führend ist und dass viele andere Branchen diesem Beispiel folgen, vor allem Einzelhandel/E-Commerce, Telekommunikation, Fertigung, Transport und Logistik.
Die Microservices-Architektur ist definitiv auf dem Vormarsch und bereits Bestandteil zahlreicher aktueller Transformationsprojekte. Dabei werden traditionell monolithische Anwendungen in geschlossene, unabhängig voneinander bereitgestellte Services aufgeteilt, die mithilfe von bereichsbezogenem Design identifiziert werden.
Warum nicht alle Microservices gleich sind
Microservices versprechen mehr Flexibilität, Skalierbarkeit, Ausfallsicherheit und eine schnellere Bereitstellung und Wartung von Komponenten. Leider können nicht alle Microservice-Architekturen diese Vorteile nutzen, denn die Brüchigkeit der verteilten Verarbeitung, die Herausforderungen bei der Integration des Ökosystems und die mangelnde Harmonie der Dienste stellen große Hindernisse dar.
Die Implementierung von Microservices in der Praxis ist, wie so oft, komplizierter als gedacht. Das liegt zum großen Teil an den Irrtümern der verteilten Datenverarbeitung – einer Reihe falscher Annahmen, denen Programmierer und Architekten erliegen, wenn sie die Welt der verteilten Anwendungen betreten.
Das Paradox der Service-Aufteilung: Irrtümer der verteilten Datenverarbeitung
Die Liste der Trugschlüsse beim verteilten Rechnen, die 1994 von L. Peter Deutsch und anderen bei Sun Microsystems aufgestellt wurde, ist noch heute gültig. Insbesondere diese fünf fehlerhaften Annahmen sind für die Implementierung von Microservices von besonderer Bedeutung : Das Netzwerk ist zuverlässig, die Latenzzeit ist gleich null, das Netzwerk ist sicher, die Transportkosten sind gleich null, das Netzwerk ist homogen.
Dabei gilt: Je kleiner die einzelnen Microservices sind, desto größer ist die Anzahl der Dienste und desto stärker wirken sich die Irrtümer der verteilten Datenverarbeitung auf Stabilität, Benutzerfreundlichkeit und Systemleistung aus. Daher ist es von entscheidender Bedeutung, eine Architektur zu implementieren, die die Latenzzeit minimiert und mit der Realität von Netzwerk- und Serviceausfällen umgehen kann.
Neue Eventing- und Messaging-Tools erforderlich
Eine weitere Herausforderung besteht darin, dass Microservices natürlich Konnektivität und Daten benötigen, um ihre Aufgaben zu erfüllen und einen geschäftlichen Mehrwert zu liefern. Die Erfassung und Kommunikation von Daten wurde jedoch weitgehend vernachlässigt, sodass die Werkzeuge stark hinterherhinken. Das zeigt sich bei API-Management- oder Gateway-Produkten, die nur synchrone Anfrage/Antwort-Muster unterstützen.
Dadurch werden die Herausforderungen der verteilten Datenverarbeitung verschärft, denn sie ist so nicht in der Lage, Daten aus Altsystemen zu integrieren oder zu erfassen. Gleichzeitig sind Eventing- und Messaging-Tools in einer veralteten, nicht agilen Welt stecken geblieben, was dazu führt, dass sie mit vielen Leitprinzipien von Microservices wie DevOps und Self-Service nicht kompatibel sind.
Aber es ist gerade das Eventing und Messaging, das am besten mit den Eigenheiten der verteilten Datenverarbeitung zurechtkommt und damit den Schlüssel zur Erschließung des Potenzials der Microservices-Architektur darstellt.
Das Integrationsproblem – Herausforderungen beim Datenflusses zwischen Microservices in einer Legacy-Umgebung
Je kleiner die Dienste werden und je spezifischer ihr Zweck ist, desto größer ist das Potenzial für ihre Wiederverwendbarkeit, die aber von der Fähigkeit der Dienste zur Zusammenarbeit abhängt. Die Beschaffung von Daten für neue Systeme ist einfach, aber Microservices sind fast immer ein Nebeneffekt der digitalen Transformation, der Modernisierung oder der Notwendigkeit, neue Funktionen in einem schnelleren Tempo zu entwickeln.
Entwickler haben es also praktisch immer mit einem Ökosystem von Altsystemen zu tun – von denen einige modernisiert werden, andere aber auf absehbare Zeit unverändert bleiben. Hier ist eine Kluft zu überwinden, denn die meisten bestehenden Systeme sind vor Ort installiert, während Microservices in privaten und öffentlichen Clouds laufen.
Daten durch die oft instabile und unberechenbare Welt der Weitverkehrsnetze (WANs) zu transportieren, ist schwierig und zeitaufwendig. Außerdem sind auch das Aufkommen und die Spezialisierung durch IoT, mobile Endgeräte und Big Data zu berücksichtigen. Das Volumen und die Vielfalt dieser Systeme führen zu einem sehr großen Vorlaufrisiko für Microservices-Initiativen.
Sehen Sie sich diese Diskrepanzen an – wie viele davon gibt es bei Ihnen?
Wenn man alles zusammenzählt, gibt es überall Inkompatibilitäten: Aktualisierungen von Altsystemen sind langsam, Microservices müssen jedoch schnell und agil sein. Legacy-Systeme verwenden alte Kommunikationsmedien, Microservices hingegen moderne offene Protokolle und APIs. Legacy-Systeme sind fast immer vor Ort installiert und nutzen bestenfalls Virtualisierung, während Microservices auf Clouds und IaaS-Abstraktion setzen.
IoT-Systeme verwenden hochspezialisierte Protokolle, die jedoch von den meisten APIs und Frameworks der Microservices nicht nativ unterstützt werden. Mobile Geräte schließlich verwenden zwar REST, erfordern aber auch asynchrone Kommunikation, während die meisten API-Gateways nur synchrone RESTful-Interaktionen unterstützen.
Wenn man all das berücksichtigt, wird der Fall klar: Unternehmen brauchen eine ereignisgesteuerte Architektur, um all diese Unterschiede zwischen Legacy-Systemen und Microservices zu überwinden.
Punkt-zu-Punkt-Orchestrierung von Microservices und eng gekoppelte Systeme, die die Agilität und Skalierbarkeit behindern
Wie bereits beschrieben, ist der unmittelbare Nutzen eines Dienstes für den Endbenutzer umso geringer, je kleiner er ist. Der Wert entsteht erst durch Orchestrierung. In der Vergangenheit war die Orchestrierung Aufgabe einer zentralen Komponente wie BPEL-Engines oder ESB, heutzutage übernehmen das die API-Gateways.
Orchestrierung ist eine gute Bezeichnung für das, was hier erforderlich ist. Denn Komponisten erstellen Partituren, deren Stimmen die Musiker auf verschiedenen Instrumenten spielen. Jede Stimme ist mit ihrem Instrument wie ein Microservice. In einer komplexen Sinfonie mit hundert Musikern, die eine Vielzahl von Instrumenten spielen, ist – wie auch in jedem Unternehmen mit komplexen Anwendungen – viel Orchestrierung erforderlich.
Microservices geraten nicht aus dem Takt
Ein Beispiel für die Orchestrierung von Microservices ist das Ausführen einer Reihe von Schritten innerhalb des Codes. Die Eingabe oder Ausgabe eines Microservices ist ein Datenereignis, das eine Bedeutung für die Domäne hat.
Entscheidend ist jedoch, dass der Microservice, der lediglich ein Ereignis erzeugt, nicht weiß, ob und wann es verarbeitet werden wird. Andere Dienste müssen ihr Interesse an dem Ereignis oder der Gruppe von Ereignissen anmelden und entsprechend reagieren. Das erfordert eine Orchestrierung der Microservices.
Die Zukunft der Microservices ist ereignisgesteuert
Die Ereignissteuerung maximiert die Agilität, da sie Daten aus dem „Ruhezustand“ (z. B. in einer Datenbank hinter einer API) in den „Bewegungszustand“ versetzt, d. h. sie können in Echtzeit verarbeitet werden, wenn im Unternehmen Ereignisse auftreten. Die Wahl der richtigen Eventing- oder Messaging-Plattform ist einer der wichtigsten Schritte auf dem Weg zur Nutzung der enormen Vorteile von Microservices.
Microservices an sich sind nicht genug. Gartner hat diese Notwendigkeit bereits 2018 erkannt, als es „ereignisgesteuert“ als einen der wichtigsten strategischen Technologietrends hervorhob: „Das digitale Geschäft ist ereignisgesteuert, daher müssen Unternehmen in ereignisgesteuerte Design-Praktiken und Technologien investieren, um digitale Geschäftsmomente zu nutzen.“
Ereignisgesteuerte Plattformen unabdingbar für maximalen Erfolg von Microservices
Nehmen wir zum Beispiel eine Bank, die eine Marketingkampagne für eine neue Kreditkarte durchführt. Die Verwendung einer ereignisgesteuerten Architektur macht es einfach, Ereignisse bei der Kontoeröffnung zu nutzen und die Kreditkarte der Bank auf der Grundlage der Metadaten des Kontos – wie Eröffnungssaldo, Adresse, Beruf und mehr – an den neuen Kunden zu vermarkten.
Durch die Kombination von ereignisgesteuerter Architektur und Microservices können Entwickler verteilte, hoch skalierbare, verfügbare, fehlertolerante und erweiterbare Systeme aufbauen. Diese Systeme können extrem große Mengen an Ereignissen oder Informationen in Echtzeit nutzen, verarbeiten, aggregieren oder korrelieren.
Moderne Ereignisplattformen sollten in jeder Cloud und auf jeder Plattform als Service bereitgestellt werden und problemlos WANs überbrücken können. Sie sollten auch die DevOps-Automatisierung unterstützen und Entwicklern vollständigen Self-Service bieten. Unternehmen müssen in der Lage sein, in einer sich schnell verändernden Welt mit dem Strom zu schwimmen. Das können sie nur, wenn ihre Geschäftsanwendungen es ihnen ermöglichen – und genau das ist die wesentliche Rolle von ereignisgesteuerten Microservices.