Wenn Sie über Softwarearchitektur nachdenken, sind Sie wahrscheinlich schon auf Microservices innerhalb der Prozessorchestrierung gestoßen, die zur Standardmethode für die Erstellung von Anwendungen geworden ist.
Bei der Microservices-Architektur liegt der Schwerpunkt auf der Entwicklung einzelner Anwendungen, die als eine Reihe von "Microservices" betrieben werden, von denen jede ihre eigenen Prozesse ausführt und mit Mechanismen wie einer HTTP-Ressourcen-API kommuniziert. Die Anwendungen werden so entwickelt, dass sie unabhängig voneinander eingesetzt werden können und auf Geschäftsfunktionen mit automatischer Ausführung ausgerichtet sind. Die zentrale Verwaltung ist eine Komponente, die jedoch nur in geringem Umfang benötigt wird.
Wenn man von Microservices spricht, ist es hilfreich, sie mit dem monolithischen Stil der Anwendungsentwicklung zu vergleichen, bei dem es eine clientseitige Benutzeroberfläche, eine Datenbank und die serverseitige Anwendung gibt. Auf der Serverseite verwaltet die Anwendung HTTP-Anfragen, setzt Domänenlogik ein, empfängt und aktualisiert Informationen aus der Datenbank und wählt dann HTML-Ansichten aus und zeigt sie über den Browser an. Als Monolith ist sie eine einzige ausführbare Datei. Wenn Änderungen erforderlich sind, muss eine neue Version der serverseitigen Anwendung erstellt werden.
Der monolithische Stil ist der "traditionelle" Ansatz für die Anwendungsentwicklung. Die Anwendung verarbeitet Anfragen über einen einzigen Prozess und nutzt grundlegende Funktionen, um die Anwendung in Klassen, Funktionen und Namespaces zu unterteilen. Wenn Sie mehrere Instanzen ausführen möchten, können Sie den Monolithen horizontal hinter einem Load-Balancer skalieren.
Der monolithische Stil der Anwendungsentwicklung kann zwar erfolgreich sein, er kann aber auch Hindernisse für die Bereitstellung einer größeren Anzahl von Anwendungen in der Cloud mit sich bringen. Da beispielsweise die Änderungszyklen miteinander verknüpft sind, erfordert jede Anwendungsänderung einen kompletten Neuaufbau und eine Neubereitstellung. Mit der Zeit wird die Aufrechterhaltung einer organisierten modularen Struktur sehr viel komplexer und zeitaufwändiger. Wenn Ihr Unternehmen Geschäftsanwendungen skalieren möchte, müssten Sie jede einzelne Anwendung skalieren - und zwar eine nach der anderen, anstatt nur eine einzelne Komponente, die mehr Ressourcen benötigt.
Vom Monolithen zum Microservice
Die Popularität von Microservices ist zum Teil auf die Frustrationen zurückzuführen, die mit dem monolithischen Stil verbunden sind. Ganz zu schweigen davon, dass der Microservice-Stil sicherstellt, dass die Dienste unabhängig voneinander skalierbar und bereitstellbar sind und dass verschiedene Dienste in verschiedenen Sprachen geschrieben werden können. Außerdem kann er von unterschiedlichen Teams verwaltet werden. Die Wurzeln des Microservice-Stils gehen auf Unix-Designprinzipien zurück und sind im Cloud-Zeitalter wesentlich effizienter.
Eigentum am Produkt über seinen gesamten Lebenszyklus
Im monolithischen Stil gilt eine App, sobald sie entwickelt ist, als abgeschlossen. Der nächste Schritt besteht darin, die Verantwortung an das Wartungsteam zu übertragen. Im Gegensatz dazu umfasst der Microservice-Stil die lebenslange Verantwortung des Projektteams, das die Anwendung entwickelt hat. Denken Sie an das Mantra von Amazon: "Sie bauen es, Sie betreiben es". Infolgedessen hat das Entwicklungsteam die tägliche Kontrolle darüber, wie sich seine Anwendung verhält und übernimmt einige der Supportaufgaben. Der Gedanke dahinter ist, dass eine kontinuierliche Beziehung mit der Anwendung besteht, um sicherzustellen, dass sie die beabsichtigten Geschäftsfunktionen durchgehend erfüllt.
Tatsächlich schrecken Microservice-Teams oft vor strikt durchgesetzten Standards zurück. Allerdings kann es auch davon abhängen, wie die Standards festgelegt und durchgesetzt werden. In der Unternehmenswelt werden Standards beispielsweise oft von Teams entwickelt, die wenig oder gar keine Programmiererfahrung haben. Eine Möglichkeit, sich dies vorzustellen, ist die Betrachtung des Domain-Driven Design of Bounded Context. DDD unterteilt eine komplexe Domäne in mehrere begrenzte Kontexte mit einer Karte, die die Beziehungen miteinander verbindet. Der DDD-Prozess ist sowohl in monolithischen als auch in Microservice-Architekturen von Vorteil, da er zur Klärung und Verstärkung von Trennungen beiträgt. Bei Microservices werden jedoch Entscheidungen über die Datenspeicherung dezentralisiert, da jeder Dienst seine eigene Datenbank verwalten kann, auch wenn es verschiedene Instanzen gibt. Dieser Ansatz wird als polyglotte Persistenz bezeichnet. Jeder Dienst hat eine bestimmte Funktion und verwendet ein Medium für die Interaktion und gemeinsame Nutzung von Daten. Wie das geht? Entweder durch Orchestrierung oder Choreographie.
Was ist Prozessorchestrierung?
Ähnlich wie ein Orchester auf einen "Dirigenten" oder "Orchestrator" angewiesen ist, verwendet eine Microservice-Interaktion "Process Orchestration", um alle Interaktionen zu verwalten, die auf eine Antwort warten, bevor der nächste Dienst angefordert wird. Die Orchestrierung folgt einem Anfrage/Antwort-Paradigma. Hier einige Vorteile der Orchestrierung:
- Einfache Verwaltung durch Zentralisierung der Geschäftsprozesse
- Der Anwendungsfluss wird durch synchrone Verarbeitung effizient koordiniert
Wo liegen die Grenzen? Nun, die Orchestrierung schafft auch eine Art von Abhängigkeit, da sie Dienste koppelt. Wenn der Dienst A ausfällt, wird der Dienst B nicht aufgerufen. Und wenn der Orchestrator ausfällt, wird die gesamte Verarbeitung gestoppt und die Sichtbarkeit geht verloren.
Was ist Choreografie?
Wenn Ihr Ziel darin besteht, Abhängigkeiten zu vermeiden und jedem Dienst die Möglichkeit zu geben, unabhängig zu arbeiten, dann wäre die Choreografie die optimale Methode. Bei diesem Ansatz müssen die Dienste nicht auf Anweisungen warten - sie handeln unabhängig. Mit dem asynchronen Ansatz wissen die Dienste, wie sie auf Ereignisse reagieren sollen. Hier sind einige Vorteile:
- Schnelle Verarbeitung, da die Dienste nicht auf einen Orchestrator warten müssen.
- Einfaches Hinzufügen von Diensten oder Aktualisieren über den Ereignisstrom.
- Beseitigt alle einzelnen Fehlerquellen.
- Passt zu einem agilen Bereitstellungsmodell, bei dem sich die Teams auf bestimmte Dienste statt auf die gesamte Anwendung konzentrieren können.
Choreografie scheint die logische Wahl für eine Microservices-Infrastruktur zu sein, aber es gibt einige Einschränkungen, darunter die Tatsache, dass die Prozesse verteilt sind, was es schwieriger macht, den gesamten Prozess zu verwalten. Infolgedessen ist die Komplexität ein durchschlagendes Problem.
Wenn Sie Choreografie und Orchestrierung verstehen wollen, kann es hilfreich sein, sie zunächst mit Beispielen aus der Praxis zu vergleichen. Denken Sie zum Beispiel an den Kauf eines Schokoriegels aus einem Automaten. Ein grundlegender Arbeitsablauf würde Folgendes beinhalten:
- Geld in den Automaten stecken
- Wählen Sie Ihren Artikel
- Kabinett strahlt die Süßigkeit aus
- Holen Sie sich Ihre süße Leckerei
- Nehmen Sie das Wechselgeld (falls vorhanden)
Sie können dies weiter in drei verschiedene Komponenten aufteilen:
- Zahlung
- Ihre Bestellung aufgeben
- Versand von Artikeln
Stellen wir uns nun die Aspekte einer Garagenband vor - es gäbe keinen Dirigenten. Beim Verkaufsautomaten löst jedes Ereignis eine andere Aktion aus, die zur Ausführung bereit ist. Wenn Sie Ihr Geld einwerfen, wird der Automat aktiviert, um eine Auswahl an Snackoptionen zu ermöglichen. Sobald Sie den Knopf Ihrer Wahl drücken, beginnt die Auszahlung. Jede Komponente funktioniert nur in Abhängigkeit von dem Ereignis, das zuvor eingetreten ist.
Im Gegensatz zu einer Garagenband ist bei einem Orchester ein Dirigent erforderlich. Jede Note, die gespielt wird, und die Art und Weise, wie sie gespielt wird, wird vom Dirigenten geleitet. In diesem Beispiel könnte man von einer Orchestrierung mit einem Dirigenten oder Prozessmanager sprechen, der die Abfolge aller Ereignisse bestimmt. Der Dirigent ist also über den gesamten Arbeitsablauf informiert. Da der Dirigent über alles Bescheid weiß, kann er auch Statusaktualisierungen vornehmen - die Musik kommt immer zum richtigen Zeitpunkt.
Wie in dem Beispiel einer Garagenband improvisieren viele der Mitglieder; sie arbeiten unabhängig und wissen nicht, was als nächstes passiert. Wenn Sie also ein Unternehmen sind, das laufend aktualisiert werden muss, dann wäre die Orchestrierung das Richtige für Sie. Wenn sich Ihr Unternehmen hingegen ständig verändert, ist eine Choreografie sinnvoller. Beide müssen sich jedoch nicht gegenseitig ausschließen, da sie in verschiedenen Aspekten unterschiedlicher Arbeitsabläufe zusammenarbeiten können.
Prozessorchestrierung vs. Choreographie: Was sind die beiden Arten der Interaktion?
Wenn ein Arbeitsablauf einem Muster der Prozessorchestrierung folgt, gibt es immer eine Punkt-zu-Punkt-Verbindung zwischen den Ereignissen - es wäre eine Herausforderung, erforderliche Ereignisse zu entfernen, da jede Verbindung vermerkt ist. Im Gegensatz dazu bedeutet der Choreographie-Ansatz, dass die Ereignisse nicht miteinander "sprechen", sondern autonom handeln. Die Orchestrierung erfordert eine aktive Steuerung, die Choreographie hingegen nicht.
Wenn Sie Hunderte oder Tausende von Prozessen verwalten müssen, wird die "Choreografie" zu einer Herausforderung. In großem Maßstab erleichtert die Orchestrierung die gleichzeitige Überwachung aller Prozesse. Außerdem können menschliche Interaktionen einfach und schnell eingefügt werden.
Stellen Sie sich ein Team von Tänzern vor, das bei einer Veranstaltung auftritt. Sie kennen ihre Choreografie bereits, so dass sie tanzen können, ohne dass ihnen jemand sagt, wohin sie gehen, wann sie sich drehen oder wann sie eintauchen sollen. Sie machen die richtigen Schritte und verpassen keinen einzigen Takt. Die Aufführung ist asynchron - wenn sie auf der Bühne vor ihrem Publikum stehen, warten sie nicht mehr auf den Choreografen. Choreografie ist die logische Wahl, wenn Aufgaben keine synchrone Antworten und Anfragen.
Vergleichen Sie also das Tanzteam mit Prozessen. Selbst wenn ein Ereignis fehlschlägt, können alle anderen Aktionen wie geplant weiterlaufen. Wenn ein Tänzer einen Sprung im gleichen Kontext verpasst, können die anderen Tänzer mit der Aufführung weitermachen, als wäre der Fehler nie passiert. Infolgedessen gibt es viel weniger Bewegung und Abwechslung. Jede Aufgabe ist miteinander verbunden, agiert aber auch unabhängig, was zu Zeiteinsparungen führt und den Bedarf an manueller Arbeit verringert. Die Prozesse werden schneller ausgeführt, da sie bereits programmiert sind und nicht aktiv verwaltet werden müssen. Die Leistung ist bewährt und zuverlässig. Im Wesentlichen funktioniert die Orchestrierung am besten in einem begrenzten Kontext während die Choreografie am besten zwischen begrenzten Kontexten funktioniert.
Da Dienste jederzeit ausfallen können, ist es wichtig, über Verfahren zu verfügen, mit denen Ausfälle schnell festgestellt und die Wiederherstellung von Diensten automatisiert werden können. Dazu ist eine Anwendungsüberwachung in Echtzeit zusammen mit semantischen Überwachung um Frühwarnungen zu erhalten, wenn etwas schief läuft. Darüber hinaus ist dies in einer Microservices-Architektur noch viel wichtiger, da Microservices implizit den Choreographie-Ansatz bevorzugen.
Lasst uns tanzen: Choreographie oder Orchestrierung?
Unsere Antwort ist beides. Die Verwendung einer Mischung aus synchronen und asynchronen Prozessblöcken - eine Kombination aus Orchestrierung und Choreografie - bedeutet, dass der Ablauf verteilt und gegen einen einzelnen Ausfallpunkt geschützt ist. Dienste können bis zu einem gewissen Grad entkoppelt werden. Die Kombination von Orchestrierung und Choreografie bietet Ihnen die Möglichkeit, optimierte Ergebnisse zu erzielen und jeden Ansatz an die Anforderungen Ihrer Architektur anzupassen.
Möchten Sie mehr darüber erfahren, wie ein ausgewogener Ansatz für Ihr Unternehmen funktionieren kann? Setzen Sie sich noch heute mit Processmaker in Verbindung, um herauszufinden, wie Sie Ihre Prozesse dynamisch integrieren können, damit Sie Ihre Geschäftsziele schnell erreichen können.
