Kolumne: Stropek as a Service

Freudige Ereignisse: eventbasierte Architekturen erobern die Cloud
Keine Kommentare

Eventbasierte Programmierung ist an sich nichts Neues. In grafischen Benutzeroberflächen bestimmen seit eh und je Ereignisse wie Mausklick oder Tastendruck den Programmablauf. Ähnliches gilt auch für hardwarenahe Programmierung, wo Ereignisse in Form von Interrupts signalisiert werden. Innerhalb von .NET-Programmen sind Events und Callbacks ebenfalls ein gängiger Mechanismus, um über Ereignisse zu informieren.

Moderne Cloud-Lösungen orientieren sich mehr und mehr am Microservices-Pattern. Statt komplexe Funktionen in einem monolithischen Programm zu implementieren, setzt man auf viele autonome, relativ kleine Services. Um größere Funktionen anbieten zu können, müssen die Services zusammenarbeiten. Simple Workflows, die bei Benutzerinteraktion einen Service nach dem anderen aufrufen, sind zu wenig. In der Praxis will man, dass Ereignisse in einem Service automatisch Aktionen in nachgelagerten Services anstoßen. Diese Bindung muss lose sein, damit rasch auf Anforderungsänderungen reagiert werden und man Services anders zusammenstecken kann. So wie man auf der Konsole STDOUT von dem einen Tool mit STDIN des anderen verbinden kann, muss man szenariospezifisch Services verketten können.

Die Schlussfolgerung: Eventbasierte Programmierung muss die Grenzen eines Prozesses oder eines einzelnen Computers sprengen. Eine Lösung für serviceübergreifende Events ist unverzichtbar in jeder Software, die auf Microservices aufbaut. In dieser Kolumne möchte ich Lösungsansätze aufzeigen und auf einen neuen vielversprechenden PaaS-Dienst hinweisen, den Microsoft in ihrer Azure-Cloud kürzlich in einer Previewversion vorgestellt hat.

Webhooks

Eine der ältesten Lösungen von Events zwischen Microservices sind Webhooks, also auf HTTP POST-basierte Callbacks. Jeder Microservice erlaubt bei Webhooks das Hinterlegen einer Liste von URLs, an die ein Web-Request geschickt wird, wenn ein definiertes Ereignis auftritt. Nahezu alle großen SaaS-Lösungen bieten heute Webhooks an (z. B. GitHub, VSTS, Slack, Office 365, Dropbox etc.) und ich empfehle, in jeder neuen, Cloud-basierten SaaS-Lösung die Unterstützung von Webhooks von Anfang an ernsthaft in Betracht zu ziehen.

Der Webhooks-Mechanismus ist so beliebt, weil er technisch einfach umzusetzen und vollkommen plattformunabhängig ist. Die perfekte Lösung sind Webhooks aber nicht. Sie haben eine Reihe von Nachteilen. Hier einige Beispiele:

  • Was ist, wenn der Empfänger, aus welchem Grund auch immer, kurz nicht erreichbar ist? Braucht der Sender eine Retry-Logik? Muss der Empfänger Duplikaterkennung einbauen?
  • Wie sichert man sich gegen Sicherheitslücken ab? Ein Angreifer könnte versuchen, einen Webhook einzuschmuggeln, damit er über alle Events informiert wird.
  • Wie macht man Fehlerbehandlung? Meldet der Service an den Aufrufer Erfolg, selbst wenn die nachgelagerten Webhooks Fehler zurückliefern?
  • Wie geht man mit lange laufenden Webhooks um? Dürfen sie den Aufrufer bremsen?
  • Wie behält man den Überblick über das entstehende Netz aus Punkt-zu-Punkt-Verbindungen?

Zusammenfassend kann man sagen, dass Webhooks sehr gut geeignet sind, um unkritische Verbindungen zwischen Microservices herzustellen (z. B. „schicke Slack-Nachricht, wenn GitHub-Check-in in einem gewissen Branch erfolgt ist“). Eine einfache Google-Suche genügt in der Regel, um für seine jeweilige Programmierplattform Hilfsbibliotheken zum Umsetzen von Webhooks zu finden.

Message Broker

Message Broker lösen einen Teil der oben genannten Probleme von Webhooks. Über ein plattformunabhängiges Protokoll senden Microservices Nachrichten an einen zentralen Dienst. Dieser speichert die Nachrichten zwischen und leitet sie an einen oder mehrere Empfänger weiter. Diese Struktur hat gegenüber HTTP POST-basierten Webhooks einige Vorteile:

  • Solange der Message Broker hoch verfügbar ist, macht ein kurzer Verbindungsausfall zum Empfänger nichts. Der Message Broker kümmert sich um das Retry.
  • Für Fehlerbehandlung und Logging hat man eine zentrale Stelle.
  • Der Message Broker kann Logik zum Filtern (ein Client ist nur an Events mit gewissen Eigenschaften interessiert) oder Vervielfältigen von Events (ein Sender, viele Empfänger) beinhalten.
  • Der Message Broker kann Funktionen für Authentifizierung und Autorisierung enthalten.

Wer wie ich in Microsoft Azure zu Hause ist, der kennt wahrscheinlich den Azure Service Bus. Dieser PaaS-Dienst bietet seit Langem alle oben genannten Features und noch viele mehr. Die Kosten sind moderat (wenige Euro pro Monat Basispreis plus nutzungsabhängige Kosten, die sich an der Anzahl an Nachrichten orientieren). Der Azure Service Bus hat außerdem den Vorteil, dass er den plattformunabhängigen Standard Advanced Message Queuing Protocol (AMQP) unterstützt. Dadurch kann man sein Programm so schreiben, dass es mit jedem AMQP-kompatiblen Message Broker kompatibel bleibt. Will man seine SaaS-Lösung On-Premises oder in einer anderen Cloud betreiben, kann man auf andere kompatible Message-Broker-Dienste oder Produkte (z. B. Apache ActiveMQ Artemis) zurückgreifen.

Warum also überhaupt Webhooks in Betracht ziehen, wenn es Message Broker gibt? Der Grund ist die Einfachheit. Webhooks brauchen keinen zentralen hoch verfügbaren Dienst. Außerdem funktioniert ein HTTP POST praktisch überall, auch durch die meisten Firewalls. Message Broker brauchen meist eigene Portfreigaben, die gerade in großen Firmen organisatorisch nicht einfach zu bekommen sind.

IoT

In Umgebungen mit ressourcenmäßig stark eingeschränkten Clients schwächeln Webhooks und Message Broker aus dem Enterprise-Umfeld. HTTP ist nicht optimal auf minimale Bandbreiten ausgelegt. AMQP bietet viele Funktionen, deren Umsetzung Speicher sowie Rechenleistung und damit Batterielaufzeit kostet. Ein Message-Protokoll, das für minimalisierte IoT-Geräte optimiert wurde, ist das Message Queuing Telemetry Transport (MQTT) Protocol. Bei IoT-Szenarien, die etwas stärkere Clients umfassen, ist natürlich das zuvor genannte AMQP auch ein gangbarer Weg.

Microsoft unterstützt MQTT und AMQP in der Azure IoT Suite. Ich werde oft gefragt, wo der Unterschied zwischen Azure Service Bus und dem Messaging in der IoT Suite ist. Im Gegensatz zum Service Bus sind die PaaS-Dienste für IoT-Messaging sowohl technisch als auch preislich auf eine riesige Anzahl von Clients ausgelegt. Hunderttausende Temperatursensoren, die alle paar Sekunden eine Message schicken? Kein Problem für IoT- und Event-Hub, eine weniger gute Idee für Service Bus.

Azure Event Grid

Vor wenigen Wochen hat Microsoft ein neues Produkt in Sachen eventbasierte Programmierung ins Rennen geschickt: das Event Grid. Ähnlich wie im IoT-Bereich ist es auf Kosteneffizienz, sehr hohen Durchsatz und gleichbleibende Performance optimiert. Der primäre Anwendungsbereich ist aber nicht die Verbindung zu externen IoT-Clients, sondern das Informieren über Events in Serverless-Microservices-Umgebungen. Die zweite Besonderheit, die das Event Grid aus meiner Sicht besonders spannend für Microservices macht, ist die tiefe Integration in von Microsoft bereitgestellte PaaS-Dienste. Blob Storage, Azure Management Operations und Event Hubs können schon jetzt in der Previewphase automatisch Events über das Event Grid verschicken, ohne dass man dafür Code schreiben müsste. Microsoft hat angekündigt, dass rasch weitere Azure-Services folgen werden. Das erspart eine Menge Programmier- und Verwaltungsaufwand.

Fokus auf Public-Cloud

Wer auf Microservices setzt, kommt wie erwähnt um eine Strategie für die Kopplung der Services über Events kaum herum. Gerade hier zeigt sich aber, dass die häufige Forderung nach Unterstützung der Cloud und der einer Installation On-Premises folgenschwer ist. Die Stabilität einer Microservices-Architektur hängt wesentlich von der Verlässlichkeit und Skalierbarkeit der Event- und Messaginginfrastruktur ab. Wer hier spart, spart am falschen Platz. In der Public-Cloud sind Event und Message Broker ein „Grundrohstoff“, der in sehr hoher Qualität für ganz wenig Geld eingekauft werden kann. Darauf zu verzichten, sollte gut überlegt sein.

Dazu kommt, dass in der Public-Cloud eine Menge an PaaS-Hilfsdiensten angeboten werden, die in Verbindung mit eventbasierter Architektur erheblichen Mehrwert bieten. Man braucht nur an Azure Stream Analytics zur Echtzeitanalyse von Events oder Azure Logic Apps zur grafischen Modellierung von Workflows zu denken. Natürlich gibt es für diese Aufgabenstellungen auch Produkte, die man im eigenen Rechenzentrum betreiben kann. Meiner Erfahrung nach zahlt sich das aber nur für wenige Szenarien aus, die sehr groß sind oder sehr spezielle Anforderungen, z. B. an den Datenschutz, haben.

Lesen Sie alle Ausgaben der Kolumne „Stropek as a Service„!
In der Kolumne greift Rainer Stropek spannende Aspekte wie die Finanzierung, den Customer Lifetime Value, aber auch wichtige Themen wie Billing, Kundenbindung durch Qualität oder APIs auf – alles aus der Sicht eines Unternehmers, der seit 20 Jahren in der IT-Branche tätig ist und seit fünf Jahren intensive Erfahrungen mit SaaS gesammelt hat.
Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -