Leigh Prather - stock.adobe.com

Ereignisgesteuerte Anwendungen: Serverless oder Container?

Serverless Computing und Container erlauben IT-Teams, ereignisgesteuerte Anwendungen zu hosten. Die Auswahl der Plattform ist hierfür der erste Schritt.

Als Serverless Computing in die Public-Cloud-Szene eindrang, begeisterte es alle. Als Serverless Computing bezeichnet man bekanntlich ein Ausführungsmodell in der Cloud, bei dem Nutzer Anwendungen erstellen und ausführen, ohne dabei einen Gedanken an den oder die darunterliegenden Server verschwenden zu müssen.

Einige Anwender berichteten bei Serverless Computing von unglaublichen Einsparungen und Vorteilen, insbesondere bei sogenannten event-driven – also ereignisgesteuerten, Anwendungen. Dann tauchten plötzlich Anwender auf, die sich für Serverless entschieden und von enormen Kostenüberschreitungen berichteten. Es gab sogar Berichte über eine Beeinträchtigung der Anwendungsleistung. Einige dieser Benutzer wechselten daher für die Ereignisverarbeitung auf Container.

Damit stehen die Entwicklungsteams vor einem Dilemma: Sie müssen sich bei der Ereignisverarbeitung für eine der zwei Seiten entscheiden: Serverless versus Container.

Warum ist Ereignisverarbeitung untypisch?

Die Ereignisverarbeitung unterscheidet sich stark von der typischen Transaktionsverarbeitung. Ein Ereignis ist ein Signal, das anzeigt, dass etwas passiert. Es kann sowohl von außen, zum Beispiel durch Benutzereingaben oder Sensorwerte, als auch vom System selbst, zum Beispiel durch Änderungsbenachrichtigungen, ausgelöst werden. Eine ereignisgesteuerte Architektur erlaubt kaum Kontrolle darüber, wann Daten verarbeitet werden. Ein einfaches Beispiel ist die grafische Benutzeroberfläche: Hier bestimmt der Benutzer, wann welche Daten verarbeitet werden, indem er Aktionen ausführt und damit Ereignisse auslöst.

Ereignisverarbeitung erfordert meist nur eine einfache Antwort statt komplexer Änderungen und Aktualisierungen. Transaktionen sind zwar ziemlich vorhersehbar, da sie aus bestimmten, gut überschaubaren Quellen stammen. Ereignisse können jedoch überall entstehen, und die Häufigkeit der Ereignisse kann von gar keinem Ereignis bis zu Zehntausenden von Events pro Sekunde reichen. Diese wichtigen Unterschiede zwischen Transaktionen und Ereignissen lösten den Serverless-Trend aus und führten auch zur Strategie der funktionalen Programmierung.

Funktionale Programmierung ist relativ einfach. Eine Funktion, welche oft Lambda genannt wird, ist eine Softwarekomponente, die nur Ausgaben enthält, die auf dem Input basieren. Wenn Y eine Funktion von X ist, dann variiert Y nur so, wie X das tut. Aus praktischen Gründen speichern Funktionen keine Daten, die ihre Ausgaben intern verändern könnten. Daher kann jede Kopie einer Funktion die gleiche Eingabe verarbeiten und wird die gleiche Ausgabe erzeugen. Dies ermöglicht hoch belastbare und skalierbare Anwendungen.

Eine Funktion kann auf verschiedene Arten ausgeführt werden: auf einem physischen Server, auf einer virtuellen Maschine (VM), in einem Container oder mit Infrastructure as a Service (IaaS). Allerdings ist die Ereignisverarbeitung in der Regel verteilt. Das bedeutet, dass Funktions-Hosting auf physischen Servern (Bare Metal) und VMs keinen Sinn macht. Schließlich sind diese Ansätze auf das Rechenzentrum beschränkt. Zusätzlich benötigen VMs und IaaS sowohl das Betriebssystem als auch die Middleware als Teil des Maschinen-Images, was eine Menge Ressourcen bei der Ausführung einer einfachen Funktion verschwendet. Damit haben wir die Wahl zwischen zwei verbleibenden Hosting-Möglichkeiten: Serverless oder Container.

Serverlos versus Container: Was ist besser?

Die Ereignisverarbeitung über Serverless Hosting lässt die Anzahl der Funktionsinstanzen – oder Kopien einer Funktion – mit dem Ausmaß der Ereignisgenerierung steigen. Wenn ein Serverless-System richtig eingerichtet ist, wird es aber nicht von einer massiven Flut von Ereignissen überschwemmt.

Da eine Funktion nicht an eine bestimmte Cloud-Ressource gebunden ist, ist es auch wenig wahrscheinlich, dass Serverless ausfällt, sollten einige Cloud-Ressourcen verloren gehen. Und das Beste daran: Sie müssen keine bestimmten Cloud-Instanzen kaufen und dafür bezahlen, während sie auf die Verarbeitung eines Ereignisses warten.

Der Pay-per-Use-Faktor ist der primäre Vorteil von Serverless, allerdings gibt es auch zwei bemerkenswerte Nachteile. Erstens: Wenn man viele Events ausführt, zahlt man viel. Folglich kann Serverless tatsächlich ungeplant teuer werden. Das gilt aber nur, wenn man die Anzahl der Ereignisse unterschätzt. Der zweite Nachteil ist: Serverless kann mehr Zeit zum Laden und Ausführen einer Funktion benötigen, und diese Verzögerung kann sich zu einem Problem entwickeln.

Die Ereignisverarbeitung über das Container-Hosting kann beide Probleme lösen. Sie können viele Event-Handling-Funktionen in Containern auf einem einzelnen Host oder einer VM ablegen. Sie können containerisierte Funktionen in Ihrem Rechenzentrum oder in der Cloud hosten. Da das Hosting explizit ist, wissen Sie, wie hoch Ihre Kosten sein werden. Zudem gibt es keine Verzögerung bei den Ladefunktionen für die Nutzung.

Es gibt aber auch Nachteile bei der Container-basierten Ereignisverarbeitung. Das größte Problem besteht darin, dass die Ressourcenelastizität und -resilienz durch die kommerziellen Bedingungen der verwendeten Cloud-VM oder des IaaS-Dienstes begrenzt sind. Im Gegensatz zum Serverless Hosting – das fast unendlich elastisch ist – müssen Sie die Kapazität planen, um die Bandbreite der zu bewältigenden Event-Volumina zu bestimmen.

Ansonsten riskieren Sie höhere Kosten oder es gehen Ihnen die Ressourcen aus. Allerdings sollten Sie dies auch für Serverless tun. Indem Sie die Ereignishäufigkeit Ihrer Anwendung ermitteln, können Sie schnell feststellen, ob Serverless oder Container-Hosting effizienter ist. Außerdem erfahren Sie, wie viel Kapazität Sie für unterschiedliche Event-Volumina benötigen.

Die Container-basierte Ereignisverarbeitung hat auch den Nachteil, dass ein spezifisches Software-Framework fehlt, das Serverless-Cloud-Anbieter anbieten. Sie können zwar funktionale oder Lambda-Programme auf Containern schreiben und ausführen. Aber statt eines praktischen Cloud-Toolkits müssen Sie sich Ihre eigene Middleware aussuchen und Ihre eigene Anwendung entwerfen. Für die Erstellung ereignisgesteuerter Funktionsprogramme und deren Ausführung auf Standard-Cloud-Diensten oder sogar im Rechenzentrum sind mehrere Beispiele verfügbar. Es ist deshalb eine gute Idee, sich diese Beispiele zu Gemüte zu führen und zu bewerten.

Ein weiterer Punkt, der in der Debatte zwischen Serverless und Container-Ereignisverarbeitung eine Rolle spielt, ist die Ereigniskorrelation. AWS Step Functions kann diese Art von Korrelation durch Orchestrierung bereitstellen. Aber die Ereigniskorrelation mit Serverless-Funktionen kann die Generierung sekundärer Ereignisse erfordern. Dies erhöht die Kosten für Serverless Hosting.

Ein weiterer Punkt ist, dass ereignisgesteuerte Anwendungen historisch auf spezifischen Event-Korrelations-Werkzeugen basieren. Diese sind in Containern oder sogar in Cloud-basierten VMs verfügbar. Complex Event Processing (CEP) Software – verbunden mit Stream Analytics und Predictive Analytics – ist sowohl in Open Source als auch in kommerziellen Standardformaten verfügbar. Die Software kann Ereignisse empfangen und sie auf einer Zeitleiste analysieren, um Muster zu finden und Prozesse aufzurufen.

CEP-Tools haben jedoch spezifische Eigenschaften, die ihren Nutzen auf bestimmte Arten von Ereignissen oder Missionen beschränken. Sie sollten also die Tools testen, um den besten Ansatz zu finden. Wenn das Werkzeug passt, kann die CEP-Software ausschlaggebend für die Wahl von Containern sein.

Wenn es Spitz auf Knopf steht bei der Entscheidung Serverless versus Container, kann die Tatsache, dass die Verarbeitung von Container-Ereignissen oft billiger ist als die von Serverless, ausschlaggebend sein. Ja, es kann zusätzliches Management von Hosting-Ressourcen in der Cloud erforderlich sein. Und ja, das ist bei Serverless nicht notwendig. Aber dieser zusätzliche Aufwand muss kein Nachteil sein. Insbesondere, wenn man bedenkt, welchen zusätzlichen Aufwand Serverless für die Schätzung von Event-Volumina zur Kostenkontrolle erfordert. Fazit: Serverless kann großartig sein, aber es ist nicht immer der beste Ansatz. Und Sie müssen die Verarbeitung von Container-Ereignissen sorgfältig überdenken.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

Microservices, Lambda und Functional Computing im Vergleich.

Kostenloser E-Guide: Die Serverless-Plattform AWS Lambda.

Serverless Computing: Darauf müssen Sie achten.

Erfahren Sie mehr über Cloud Computing

ComputerWeekly.de
Close