© deomis/Shutterstock.com
Unter dem Druck der Ereignisse – Teil 4

Events in Azure I


Unsere im letzten Heft durchgeführten Experimente mit ActiveMQ haben gezeigt, dass eine Event-Broker-Software nicht unbedingt im Thread der Applikation leben muss, die für die Generierung und/oder Verarbeitung der Ereignisse verantwortlich ist.

Diese eigentlich logische Feststellung ist Anbietern von Cloud-Systemen ebenfalls bekannt. Da sie seit Jahren permanent auf der Suche nach „Value Added Services“ sind, die über die Vermietung von Servern hinausgehen, gibt es mittlerweile eine wahre Plethora von Event-Management-Systemen in der Cloud. In diesem Artikel im Windows Developer werden wir praktische Beispiele mit Microsofts Cloud-Computing-Plattform Azure durchführen. Schon in der Einleitung sei allerdings angemerkt, dass auch Amazon und Google mit dem gleichen Wasser kochen – die hier besprochenen Konzepte finden sich mit minimalen Unterscheidungen auch in den dortigen Produkten.

Semantisches

Der einfachste Weg, um sich den Microsoft’schen Event-Verwaltungssystemen zu nähern, ist die Unterteilung in Gruppen. Die erste Taxonometrie unterscheidet die in diesem Artikel besprochenen General-Purpose-Systeme, die für allgemeine Aufgaben im Bereich der Systemarchitektur vorgesehen sind, von ihren Special-Purpose-Kollegen. Möchte man spezifische Jobs, wie beispielsweise das Ausliefern von Push Notifications an Handcomputer (Dienst: Azure Notification Hub) oder die Entgegennahme von IoT-Informationen (Dienst: IoT Hub), bewerkstelligen, so stellt Microsoft zusätzliche Werkzeuge zur Verfügung. Mit ihnen wollen wir uns in diesem Artikel aber nicht auseinandersetzen. Damit bleiben drei verschiedene Dienste im Rennen: Event Grid, Event Hub und Service Bus. An dieser Stelle sei schon einmal festgestellt, dass sich die von den drei Diensten angebotenen Funktionen zumindest bis zu einem gewissen Grad überschneiden. In realen Cloud-Systemen findet man zudem immer wieder hybride Architekturen, die mehrere Microsoft-Dienste im Rudel einsetzen.

Zur Unterteilung und/oder Ermittlung der idealen Einsatzszenarien wendet sich Microsoft der Payload zu. Sie wird in Events und Messages unterteilt. Eine Message ist dabei ein Rohdatenpaket, das von einem Service für die Verarbeitung in einem bestimmten anderen Dienst vorgesehen ist. Wichtig ist, dass der Erzeuger der Message mit der Erzeugung dieser Payload beim Empfänger eine gewisse Handlung auslösen möchte. Ein Klassiker dafür wäre das Absenden einer Message, die in einem Avionik-System dafür sorgt, dass die Schubumkehr einer Turbine aktiviert wird. Aus der Logik folgt, dass ein Event in der Welt von Microsoft eine Notification ist, deren Absender keinerlei Gedanken oder Annahmen darüber hat, was mit den von ihm in die Atmosphäre ausgesendeten Informationen passieren wird bzw. soll.

Events unterteilt Microsoft weiter in diskrete und serialisierte Events. Diese Unterteilung erfolgt durch Betrachtung der Rolle der Payload – ein diskretes Event ist alleinstehend sinnvoll. Hinter diesem auf den ersten Blick akademisch klingenden Begriff verbirgt sich der Gedanke, dass der Empfänger mit der in diesem Event enthaltenen Payload sofort losarbeiten kann und keine weiteren Informationen oder Zustandsdaten benötigt. Im Fall unseres Avionik Systems könnte das eine Meldung sein, die auf etwas erhöhte Vibrationen ob der Aktivierung eines Sonderregimes hinweist. Jedoch hat diese Meldung insofern keine Konsequenzen, als die Turbine auch im Sonderregime glücklich weiter ackert.

Sozusagen die Gegen-Events dafür sind die genannten Serialized Events. Dabei handelt es sich um verkettete Daten, zu deren Interpretation Sequenzinformationen erforderlich sind. Ein gutes Beispiel dafür wäre das Erfassen, wie bzw. wie schnell sich die Drehzahl einer Turbine in Reaktion auf ein Änderungsereignis verändert. Das ist übrigens kein fiktives Beispiel des Autors, denn die Reaktionsgeschwindigkeit eines mechanischen Systems ist in vielen Beispielsituationen (denken Sie an mechanische Türen) ein guter Prädiktor für die Ausfallswahrscheinlichkeit. Mit diesem Wissen bewaffnet können wir die Azure-Dienstauswahl wie in Tabelle 1 gezeigt zusammenfassen.

Dienst

Idealer Datentyp

Sondereignung laut Microsoft

Event Grid

Verteilung diskreter Events

exzellente Integration in andere Azure-Dienste

gut skalierbar

geringe Kosten

Event Hubs

Streaming serieller Events

sehr geringe Latenz

extrem hoher Durchsatz (im Bereich von Millionen Messages pro Sekunde)

Service Bus

Messages

fortgeschrittene Message-Zustellungsoptionen

garantierte Auslieferung von Nachrichten in Sequenz

sichere Auslieferung von Messages, auch dann, wenn asynchroner Betrieb erforderlich ist

Tabelle 1: Azure-Dienstauswahl im Überblick

Bevor wir mit unseren Experimenten mit Azure-Events wirklich beginnen, s...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang