Serverless Computing beziehungsweise Function as a Service (FaaS), ein 2014 von AWS erstmals etabliertes Modell zur Erstellung und Ausführung von Anwendungen in der Cloud, entwickelt sich zunehmend auch in der Kundenkommunikation zu einer attraktiven Option. Grund dafür ist der steigende Anteil an transaktionaler Verarbeitung im Dokumenten- und Output-Management. Standardisierte Batch-Jobs, in denen Hunderttausende Dokumente gesammelt und zum Stichtag X produziert werden, bestimmen nicht mehr ausschließlich das Geschehen. Vielmehr haben es Unternehmen, Organisationen und Behörden immer mehr mit einer Art defragmentierter Kundenkommunikation auf unterschiedlichen analogen und digitalen Kanälen zu tun, die ein hohes Maß an Schnelligkeit und Flexibilität erfordert.
Will sagen: Individuelle Anfragen von Kunden gilt es zügig zu bearbeiten auf dem von ihm bevorzugten Medien. Heute möchte der Verbraucher die Wahl haben, über welchen Kanal er mit seinem Versicherer, seiner Bank, seinem Telekommunikationsanbieter und seiner Behörde in Kontakt treten will. Will er zum Beispiel die Nachricht auf seinem iPhone oder seinem Tablet lesen – dann wird das entsprechende Dokument für eine optimale Anzeige im responsiven HTML-Format benötigt. Geht es dagegen um ein sensibles oder haptisch wertvolles Dokument wie den Kaufvertrag oder die Versicherungspolice, dann spielen Druck und damit der klassische Briefversand sicher eine Rolle.
Sehr viele dokumentenbezogene Aufgaben fallen in Unternehmen sporadisch statt. Man benötigt also die für die Aufgabenerledigung notwendigen Applikationen nur zu bestimmten Zeiten bzw. für einen begrenzten Zeitraum. Man denke beispielsweise an die Vereinheitlichung und Migration von Archiven (oftmals eine Folge von Fusionen und Akquisitionen und einer daraus resultierenden heterogenen IT-Landschaft), bei der Dokumente aus unterschiedlichen Quellen mit teils sehr proprietären Formaten in ein zentrales Archiv überführt und dazu in das für eine revisionssichere PDF/A-Format konvertiert werden sollen.
Sich dafür extra eine komplett neue Konvertierungssoftware anzuschaffen (on premise) oder über eine Cloud zu beziehen, ist sicher der einfachste, aber nicht unbedingt der kostengünstigste Weg. Schließlich fallen dafür auch Kosten an, wenn die Software nicht genutzt wird.
Wie schön wäre es, wenn man stattdessen ad hoc oder bei Bedarf zu Peak-Zeiten für solche Jobs dedizierte Funktionen entwickeln und einsetzen kann, ohne dafür eigene Ressourcen (Server, Datenbank, Speicher etc.) vorhalten zu müssen! Mit dem FaaS-Modell ließe sich in einer serverless Umgebung eine entsprechende Anwendung als Microservice programmieren, entsprechend dem Dokumentenaufkommen skalieren und so lange betreiben, bis alle Dokumente konvertiert sind (Beispiel Archivmigration). Anschließend skaliert man den Service auf null. Bezahlt wird nur für die tatsächlich in Anspruch genommenen Rechen- und Speicherkapazitäten, die der Cloud-Provider zur Verfügung stellt.
Wie der Einsatz von FaaS in der Kommunikation konkret zum Einsatz kommt, zeigt das folgende Beispiel. Ein großer Telekommunikationsanbieter ist mit der Situation konfrontiert, dass Kunden immer mal wieder Einzelverbindungsnachweise für ihre Telefonate anfordern. Allerdings macht das nur einen sehr geringen Prozentsatz aus. Nun könnte der Dienstleister pauschal für jeden Kunden solche Nachweise erstellen und verschicken und das Problem wäre gelöst. Doch warum auf Verdacht produzieren, wenn die überwiegende Mehrheit der Kunden das gar nicht braucht? Besser, weil kostengünstiger wäre es, nur bei konkreten Anfragen diese Dokumente zu generieren – dann aber schnell und ohne dafür extra eine eigene Software implementieren zu müssen.
Daher entwickelte das Unternehmen einen auf FaaS basierenden Microservice, über den sich solche Einzelverbindungsnachweise bei Bedarf (on demand) schnell und unkompliziert erstellen lassen. Dabei kommt die von Compart entwickelte Software DocBridge® Gear zum Einsatz. Sie stellt sogenannte wiederverwendbare Worklets zur Verfügung, die für ganz bestimmte Prozesse bzw. Funktionalitäten stehen und sich im Prinzip auch als FaaS-Funktionen einsetzen lassen. Die Telefondaten werden über eine ID (z. B. Kundennummer oder Name) aus der Fachanwendung abgerufen, validiert, zu einem Dokument formatiert und dem Kunden zugeschickt – entweder elektronisch oder als Papierdokument.
Business-Szenarien wie diese gibt es in der Kundenkommunikation einige, die sich in einer serverless Umgebung sehr gut als FaaS-Prozesse bzw.-Funktionen umsetzen lassen. Man denke nur an klassische Operationen wie das Formatieren (Erstellen) und Konvertieren von Dokumenten, an die Outbound-Integration (Anbindung an die Schnittstellen der entsprechenden Kommunikationskanäle wie Mail, SMS, Messaging, Kundenportal, Archiv, Druck-Spooler etc.) oder die Einbindung technischer Abläufe innerhalb von Business Workflows (AWS Step Functions, Azure Logic Apps usw.). Hier unterscheidet man zwischen rein fachlichen Business Workflows und technischen Workflows, die eher als Einzelschritte verstanden werden. Die FaaS-Angebote der Cloud-Anbieter bieten mittlerweile Möglichkeiten, um eine Reihe unabhängiger Funktionen entlang eines Ablaufes mittels (fachlicher oder operativer) Logik zu verbinden, ähnlich wie bei traditionellen Business-Automation-Tools, allerdings leichtgewichtiger und einfacher.
Anbieter wie Compart treiben das Thema aktiv voran und werden in den kommenden Jahren immer mehr Werkzeuge bieten, die es Kunden auf einfache Art ermöglichen, fachlich sinnvolle und in sich geschlossene Funktionen auf Basis der Compart-Technologien auf den verschiedenen gängigen serverless-Plattformen der Cloud-Anbieter einschließlich Knative zu deployen und in der Produktion bereitzustellen. Die technologischen Mittel dafür sind bei Compart vorhanden, erste Anfragen von Kunden diesbezüglich gibt es bereits. Eine zentrale Rolle spielt dabei die Plattform DocBridge® Gear mit den genannten Worklets (Low-Code/No-Code-Funktionen), die sich als FaaS für typisch kleinteilige Prozesse innerhalb des Dokumenten- und Output Managements verwenden und zu einem beliebigen Workflow zusammenstellen lassen.
Der Vorteil: Statt diese FaaS komplett als Code programmieren zu müssen, kann man sie einfach als Worklet abbilden. Im Prinzip lässt sich mit DocBridge® Gear automatisch ein Worklet generieren, als Container „verpacken“ und auf einer serverless Plattform bereitstellen (Deployment).
Tatsache ist: FaaS in der Kundenkommunikation wird kommen. Dabei sollte man Vor- und Nachteile genau abwägen. FaaS sind granulare, dedizierte Funktionen, die sich nur für kleine, zeitlich begrenzte fachliche Aufgaben eignen. Je mehr ein Unternehmen damit zu tun hat und das auch nur sporadisch, desto attraktiver wird das FaaS-Modell. Bei komplexen Prozessen und sogenannten zustandsbehafteten (stateful) Operationen dagegen empfiehlt sich das FaaS-Modell eher nicht.
Hinzu kommt: Da der Cloud-Anbieter viele Ressourcen zur Verfügung stellt, scheint FaaS auf den ersten Blick teuer. Andererseits spart man, da man ja nur für die tatsächliche Nutzung bezahlt. Die Kostenfrage ist nicht einfach zu beantworten, da man auch immer die Personalkosten in Betracht ziehen muss. Die Grundüberlegung sollte daher lauten: Wie teuer wäre es, mit eigenen personellen Kapazitäten eine Anwendung zu entwickeln und zu implementieren einschließlich der Bereitstellung von Middle- und Hardware?
Ein weiterer Nachteil beim FaaS-Modell ist die mangelnde Kontrolle von Low-Level Aspekten, speziellen Optimierungen und Optionen, die manchmal notwendig, aber auch aufwändig sind. Ohnehin sollte man sich über das generelle Verhältnis zum FaaS-Provider im Klaren sein. Nutzt man die Ressourcen eines bestimmten Anbieters, funktioniert der programmierte Code bzw. die serverless Funktion auch nur dort. Eine Alternative zu diesem Cloud Lock-in genannten Abhängigkeitsverhältnis sind neutrale Plattformen wie Knative, die genauso die Vorzüge einer FaaS-Umgebung anbieten, aber mit einer selbstverwalteten Kubernetes-Orchestrierung
Als Serverless Computing bezeichnet man ein Ausführungsmodell in der Cloud, bei dem Nutzer Anwendungen erstellen und ausführen, ohne dafür eigene Ressourcen (Server, Datenbank, Middleware, Speicher) verwenden zu müssen. Es ist gewissermaßen die konsequenteste Form von Cloud-Computing bzw. die höchste Abstraktion, die in diesem Zusammenhang denkbar ist. Sie wird in Analogie zu den bekannten Cloud-Diensten Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS) in drei Hauptkategorien eingeteilt:
Da FaaS aber fast immer BaaS benötigt, wird serverless Computing oft synonym mit FaaS verwendet. Bei den als Function as a Service bezeichneten Anwendungen handelt es sich um sehr granulare, dedizierte Funktionen, die nur für einen ganz konkreten Prozessschritt bzw. kleine, konkrete Aufgaben gedacht sind – beispielsweise in der Kundenkommunikation für die Erzeugung und Konvertierung von Dokumenten, das Generieren von Barcodes oder den E-Mail-Versand.
Obwohl der Name etwas Anderes suggeriert: Auch serverless Computing braucht Server. Aus Anwendersicht werden diese allerdings noch weiter abstrahiert als dies etwa bei einer Platform as a Service (PaaS) schon der Fall wäre. Für den Entwickler entfällt die Notwendigkeit, mit der API der Plattform zu interagieren oder zusätzliche Ressourcen zuzuweisen respektive freizugeben. Mit anderen Worten: Nutzer von serverless Computing müssen sich überhaupt nicht mehr darum kümmern, wie Server aufgesetzt oder skaliert werden.
Stattdessen sorgt der Serviceanbieter dafür, dass stets genügend Ressourcen für die jeweilige Anwendung zur Verfügung stehen. Das schließt Verfügbarkeit und Fehlertoleranz ein. Zu den wichtigsten Anbietern zählen Microsoft mit Azure Functions, Amazon Web Services mit AWS Lambda und Google mit den Cloud Functions.
Ein großer Vorteil von serverless bzw. Function as a Service ist die Abrechnung nach tatsächlichem Verbrauch. Anwender müssen also nicht für zu viel gebuchte bzw. ungenutzte Ressourcen aufkommen, sondern bezahlen nur für die tatsächlich verwendeten Rechen- und Speicherkapazitäten. Außerdem auf der Haben-Seite: ein vereinfachter Betrieb, so dass sich die Entwickler auf ihre Kernkompetenzen konzentrieren.
Nachteilig können sich entsprechende FaaS-Anwendungen allerdings auf die Performance niederschlagen: Anders als durchgehend laufender Code auf dedizierten Servern sowie in virtuellen Maschinen oder Containern können Provider serverlos bereitgestellte Anwendungen herunterfahren und erst bei Bedarf neu initialisieren. Je nach Startdauer der jeweiligen Laufzeitumgebung kann das zusätzliche und unerwünschte Verzögerungen verursachen. FaaS eignet sich zudem nicht für alle Anwendungsfälle, beispielsweise nicht für zustandsbehaftete (stateful) Operationen (Mehr zum Unterschied zwischen stateful und stateless Anwendungen siehe Glossar). Auch für High-Performance-Computing kann es effizienter und kostengünstiger sein, die benötigten Server selbst aufzusetzen.
Weitere Nachteile:
Die Entscheidung für oder gegen FaaS ist nicht zuletzt eine komplexe, bei der natürlich auch die Kosten eine Rolle spielen. Eine attraktive Alternative zu traditionellen Cloud-Modellen mit ihren monatlichen Grundgebühren, die auch anfallen, wenn die Ressourcen nicht genutzt werden, ist das FaaS-Modell in jedem Fall.
Knative ist ein Open-Source-Projekt, an dessen Entwicklung zahlreiche Unternehmen wie Google, IBM, Red Hat und viele weitere mitgearbeitet haben. Es handelt sich um eine Plattform zur Realisierung von serverlosen, cloud-nativen Anwendungen. Erstmals offiziell vorgestellt wurde Knative im Jahr 2018 von Google.
Die Plattform basiert auf der Container-Orchestrierungssoftware Kubernetes. Sie erweitert diese um verschiedene Funktionen, mit denen sich serverlose Anwendungen bereitstellen, verwalten und betreiben lassen. Dazu zählen unter anderem folgende Funktionen für
Die Grundlage zur Realisierung von cloud-nativen, serverlosen Anwendungen bilden die in Container verpackten Microservices. Die mit Kubernetes orchestrierten Container lassen sich auf beliebigen Umgebungen betreiben. Für die serverlose Anwendung spielt es keine Rolle, ob die Container in einer Cloud-Umgebung, in einem Rechenzentrum eines Dienstleisters oder lokal on premise betrieben werden. Die verschiedenen Container-Einheiten werden zu Clustern zusammengefasst, die aus physischen oder virtuellen Nodes bestehen und im Master-Slave-Modus arbeiten.
Für Entwickler bietet sich der Vorteil, dass sie sich vollständig auf das Schreiben des Programmcodes konzentrieren können und sich nicht um die Bereitstellung und Konfiguration einer Infrastruktur oder einzelner Server und Container kümmern müssen. Da die Container nahezu beliebig zwischen den Plattformen und Umgebungen portierbar sind, ergibt sich eine große Flexibilität in der Bereitstellung der serverlosen Infrastruktur. Die Vorteile der Container-Technologie und des Modells der serverlosen Anwendungen werden in der Knative-Plattform vereint.
Weitere Vorteile:
Quelle: Cloud Computing online, Juni 2020
DocBridge® Gear ist eine Plattform, mit der sich sämtliche Prozesse der Dokumentenerstellung, -konvertierung, -modifizierung und –ausgabe kundenspezifisch und einfach konfigurieren lassen. Auch typische Abläufe der Qualitätssicherung (Dokumentenprüfung/-vergleich, Validierung, Freigabe-Workflows etc.) können modelliert werden.
Das Grundprinzip von DocBridge® Gear ist der Gebrauch von wiederverwendbaren, sogenannten Worklets, die für ganz bestimmte granulare Funktionalitäten und Teilprozesse stehen. Auf Grund ihrer Struktur (Low-Code/No-Code-Funktion) lassen sich diese Worklets auch als Functions as a Service (FaaS) erzeugen und in einer serverless Umgebung betreiben. Ein Vorteil ist, dass dafür keine aufwändige Code-Programmierung notwendig ist. Die Geschäftslogik wird automatisch im Worklet hinterlegt.
Weitere Vorteile:
DocBridge® Gear richtet sich in erster Linie an Unternehmen, die sich mit Omnichannel-Kommunikation beschäftigen und eine Lösung zur nahtlosen Integration verschiedener Business-Anwendungen suchen.
Mehr zu DocBridge® Gear
Moderne Anwendungen und Legacy-Anwendungen haben eine Eigenschaft gemeinsam, nämlich ob sie einen Zustand speichern oder nicht. Ob man es mit Monolithen oder Microservices zu tun hat, hängt von den Bedürfnissen der Anwendung ab. Einige müssen den Status (Nutzerverhalten) speichern, während andere sich nicht darum kümmern müssen.
Sogenannte zustandsbehaftete Anwendungen (stateful) speichern den Status von Client-Anfragen auf dem Server selbst und verwenden diesen Status, um weitere Anfragen zu verarbeiten. Sie verwenden eine Datenbank zum Speichern von Daten als Backend, aber die Sitzungsinformationen selbst werden auf dem Server gespeichert. Wenn ein Benutzer eine Login-Anfrage sendet, kann er sich anmelden und der Benutzer wird authentifiziert, und bei der zweiten Anfrage sieht der Benutzer das Dashboard. Stateful-Applikationen müssen keinen zweiten Aufruf an die Datenbank machen, da die Session-Informationen auf dem Server selbst gespeichert sind.
Der Vorteil dieser Art von Anwendungen besteht also in einer höheren Verarbeitungsgeschwindigkeit. Aber sie haben auch Nachteile. So gibt es in der Regel bei stateful applications einen Load Balancer (LB), hinter dem zwei Server stehen, auf denen die gleiche Anwendung läuft. Die erste Anfrage zum Einloggen geht an Server 1 und die zweite Anfrage könnte an Server 2 gehen; da nun nur der eine Server das Einloggen aktiviert hat, wird der Benutzer nicht in der Lage sein, sich anzumelden, wenn der Load Balancer den Request zum zweiten Server schickt. Es ist also nicht möglich, stateful Anwendungen horizontal zu skalieren.
Zustandslose Anwendungen (stateless) hingegen speichern keinen Status von Client-Anfragen auf dem Server, sondern ausschließlich in einer Datenbank. Diese wiederum ist zustandsbehaftet (stateful), d.h. sie verfügt über einen persistenten Speicher.
Typischerweise fordert ein Benutzer eine Anmeldung mit Anmeldeinformationen an, einer der Server verarbeitet die Anfrage, generiert ein Auth-Token, speichert es in der Datenbank und gibt das Token an den Client am Frontend zurück. Die nächste Anfrage wird zusammen mit dem Token gesendet. Das bedeutet: Egal, welcher Server die Anfrage verarbeitet – in jedem Fall wird das Token mit den Informationen in der Datenbank abgeglichen und dem Benutzer die Anmeldung gewährt. Jede Anfrage ist unabhängig und hat keine Verbindung zu vorherigen oder nächsten Anfragen, genau wie bei REST.
Obwohl zustandslose (stateless) Anwendungen einen zusätzlichen Overhead durch den Aufruf der Datenbank haben, sind diese Anwendungen erstaunlich gut horizontal skalierbar, was für moderne Anwendungen, die Millionen von Benutzern haben können, entscheidend ist.
Beide, stateful und stateless, sind heute allgegenwärtig. Aber moderne Software wird in der Regel als zustandslose Variante entwickelt, weil sie sich – anders als bei stateful Anwendungen – horizontal skalieren lässt – ein wesentliches Kriterium heutzutage unter anderem für den Einsatz von Microservices in Cloud-Umgebungen.
Die acht Hauptunterschiede zwischen Stateful und Stateless Anwendungen sind:
1. Arbeitszustand: Stateful-Applikationen reagieren nach dem aktuellen Zustand, während Stateless-Applikationen eigenständig unter Berücksichtigung der vorherigen/nächsten Anfrage agieren.
2. Gespeicherte Daten: Wenn der Webserver Daten im Backend speichert und sie dazu verwendet, den Benutzer als immer verbundenen Client zu identifizieren, ist der Dienst Stateful. Bei Stateless hingegen speichert der Server zwar Daten, aber in einer Datenbank, um den Benutzer/Client zu verifizieren, wann immer er eine Verbindung herstellen muss.
3. Reaktion gegenüber Clients: Bei Stateful denkt der Server, dass der Client nur eine dumme Maschine ist, während der Server bei Stateless denkt, dass der Client eine intelligente Maschine ist, die nicht von irgendeinem Zustand auf der Serverseite abhängig sein muss.
4. Anfragen: In Stateless sind Anfragen (Requests) in sich abgeschlossen, d.h. alles ist in der Anfrage enthalten und wird in zwei getrennten Phasen verarbeitet. („Anfrage“ / „Antwort“) Bei Stateful sind die Anfragen immer vom serverseitigen Zustand abhängig.
5. Generated State: Beim Browsen im Internet wird der Zustand generiert und irgendwo gespeichert. Obwohl dieses Benutzerverhalten in beiden Typen beim Speichern auf dem Server generiert wird, erzeugt dieser eine Sitzung. Dies wird eine Stateful-Anwendung genannt.
6. State Stored: Wenn das Verhalten des Clients gespeichert wird, erzeugt er einige Daten, die für weitere Anfragen verwendet werden, obwohl er technisch gesehen Stateful ist, da er auf einen Zustand verweist. Aber der Zustand wird vom Client gespeichert, daher nennt man ihn Stateless.
7. Cookie speichert: Auf der Client-Seite speichert das Cookie Authentifizierungsdaten. Auf der Server-Seite werden temporäre Client-Daten angelegt oder in einer Datenbank gespeichert (dies ist der typische Fall). Wenn der Nutzer zum Dashboard zurückkehrt, um eine weitere Zahlung vorzunehmen, ist es ein Cookie, das im Browser gespeichert wird und den Zustand mit dem Server herstellt.
8. User Base: Stateful ist Vergangenheit, als es Monolithen und keine dynamische Benutzerbasis gab. Stateless ist Zukunft, da Microservices im Umlauf sind und meist über REST-Schnittstellen kommunizieren und alles skalierbar ist, da kein Zustand gespeichert wird.
Wichtigste Vorteile von Stateless
1. Entfernt den Overhead zum Erstellen/Verwenden von Sitzungen.
2. Skaliert horizontal für die Bedürfnisse moderner Benutzer.
3. Neue Instanzen einer Anwendung werden bei Bedarf hinzugefügt/entfernt.
4. Ermöglicht Konsistenz über verschiedene Anwendungen hinweg.
5. Statelessness macht eine Anwendung komfortabler und wartbarer.
Zusätzliche Skalierungs- und Leistungsvorteile von zustandslosen Anwendungen:
1. Reduziert den Speicherverbrauch auf der Serverseite.
2. Eliminiert das Problem des Ablaufs von Sitzungen – Manchmal verursachen ablaufende Sitzungen Probleme, die schwer zu finden und zu testen sind. Zustandslose Anwendungen benötigen keine Sessions & und leiden daher nicht unter diesen Problemen.
3. Aus Sicht des Benutzers ermöglicht die Zustandslosigkeit, dass Ressourcen verlinkt werden können. Wenn eine Seite zustandslos (stateless) ist, wird sichergestellt, dass der Benutzer, wenn er einen Freund auf diese Seite verlinkt, die gleiche Ansicht wie ein anderer Benutzer sieht.
Quelle: Gursimran Singh, Home Healthcare Report, Oktober 2020
