Modernisierung mit Cloud Native und Serverless Computing Funktioniert Function as a Service in der Versicherung?

Anbieter zum Thema

adesso AG

Windhoff Group

Function as a Service, kurz FaaS, und Serverless Computing schicken sich an, den nächsten Trend bei der Entwicklung moderner Architekturen zu setzen. Aber eignet sich dieser Architekturansatz auch für Unternehmen mit sensiblen Bereichen wie Versicherungen?

Nachdem Microservice-basierte Architekturen sich zunehmend als Architekturansatz der Wahl bei der Neuentwicklung von Anwendungslandschaften und der Modernisierung von Monolithen etablieren, baut sich bereits die nächste Innovationswelle mit Function-as-a-Service (FaaS) und Serverless Computing auf.

Auf den ersten Blick hat der Einsatz von FaaS viele Vorteile für die Entwicklung moderner Anwendungen, der zweite Blick deckt aber auch Herausforderungen auf, die sich aus dem neuen Architekturansatz ergeben. Was bedeutet also Serverless Computing für den Aufbau einer Applikation und für den Prozess der Softwareentwicklung?

Dieser Fragestellung wollen wir uns im Folgenden widmen. Nicht zuletzt greift der Artikel typische Fragestellungen einer Versicherungs-IT in Bezug auf Function-as-a-Service auf und diskutiert unvoreingenommen welche Chancen und Risiken für ein Versicherungsunternehmen mit dem Einsatz verbunden sind.

Was bedeutet Serverless eigentlich genau?

In einer serverlosen Architektur werden Anwendungen nicht länger als paketiertes Artefakt auf einem Server im eigenen Rechenzentrum installiert. Vielmehr werden einzelne Funktionen extrahiert, welche dann zustandslos in einer Cloud-Umgebung zur Ausführung gebracht werden können.

Anders als bei anderen Cloud-Lösungen wie Plattform-as-a-Service oder Infrastructure-as-a-Service muss sich der Ersteller der Anwendung weder um die Laufzeitumgebung noch um die Infrastruktur kümmern. In diesem Artikel beschreibt der Begriff „Serverless“ somit die Umsetzung kleiner Funktionsbausteine der Geschäftslogik, welche auf einer Cloud-Infrastruktur zur Ausführung gebracht werden können.

Das Thema Cloud Computing ist allerdings deutlich größer und bietet derzeit unterschiedliche Arten der „Unterstützung“ bei Betrieb und Bereitstellung einer Softwarelösung an. Die voranstehende Grafik veranschaulicht die unterschiedlichen Kategorien von Cloud-Services und zeigt die Verantwortungsbereiche.

Chancen und Herausforderungen (auch) in der Versicherung

Zunächst werden die Chancen wie auch die Herausforderungen betrachtet, denen sich die Unternehmen stellen müssen, welche ihre Architektur in Richtung „Serverless“ erweitern möchten. Viele der aufgezählten Punkte sind im Kontext des Einsatzes in einem Versicherungsunternehmen gültig und lassen sich entsprechend übertragen. Sie gelten aber im weitesten Sinne auch für andere Unternehmen in anderen Branchen.

Bei näherer Betrachtung lassen sich mit der Entwicklung, dem Betrieb und den wirtschaftlichen Aspekten drei Themenschwerpunkte erkennen. Nachfolgend widmen wir uns diesen Punkten gesondert im Detail.

Entwicklung der Software

Die Entwicklung von serverlosen Komponenten zieht einen veränderten Umgang mit der Softwareentwicklung nach sich. Eine Funktion, welche als Service bereitgestellt werden soll, beinhaltet lediglich Fachcode und definiert weder wie Daten angezeigt noch wie sie nach der Verarbeitung gespeichert werden sollen.

Somit wird nicht, wie in der „traditionellen“ Softwareentwicklung üblich, über unterschiedliche Artefakte ein Gesamtsystem zusammengefügt, sondern die Geschäftslogik möglichst kleinteilig zusammengesetzt. Dieser klare fachliche Fokus führt zu einer guten Wart- und Testbarkeit der Funktionen.

Eine Function-as-a-Service (FaaS) ist in der Regel zustandslos, nimmt Eingabeparameter entgegen, führt eine definierte Funktionalität aus und gibt das Ergebnis weiter. Soll das Ergebnis persistent gespeichert werden, so hat dies in einem anderen System zu erfolgen.

Um ein Gesamtsystem herzustellen, bedarf es somit weiterer Komponenten, welche mit den FaaS interagieren und welche die fachlichen Funktionen verknüpfen. Dies kann über zusätzliche Microservices geschehen, welche Events an die FaaS weitergeben. FaaS können somit als Verbindungsstücke zwischen Microservices gesehen werden.

Eine FaaS wird, wie bereits erwähnt, durch ein Ereignis aktiviert und benötigt keinen laufenden Serverprozess. Bei der Ausführung einer FaaS wird jeweils eine neue Instanz erzeugt und nach der Ausführung verworfen. Die Ausführung einer FaaS kann zum Beispiel durch eine http-Anfrage oder ein Event ausgelöst werden.

Festzuhalten im Kontext der Entwicklung ist also, dass der Sourcecode bei Serverless-Functions im Vordergrund steht, während eine Cloud-Plattform – wie Amazon AWS, Google Cloud oder Microsoft Azure – die Verwaltung der Server-Infrastruktur übernimmt.

Auswertungen und Monitoring zu Last sowie Performance der einzelnen Funktion ist somit in der Regel schwierig und auch die Integrationstests werden erschwert. Hinzu kommt, dass eine Kommunikation über Events einen veränderten Umgang in der Fehlerverarbeitung mit sich bringt.

Betrieb und Ausführung der Softwarelösung

Neben der Entwicklung hat die Integration von Serverless-Functions Auswirkungen auf den Betrieb einer Softwarelösung. Wie zuvor angesprochen, werden FaaS als zustandslose Code-Artefakte in der Cloud installiert, so dass die Bereitstellung von Server-Ressourcen (On-Premises) nicht notwendig ist.

„Serverless“ bedeutet in diesem Zusammenhang nicht, dass es keine Infrastruktur gibt, auf dem die Funktion ausgeführt wird. Vielmehr wird eine optimierte Laufzeitumgebung zur Ausführung der Funktionen von einem Cloud Provider zur Verfügung gestellt, auf der die Funktionen ausgeführt werden. Dieser Faktor ermöglicht es, die Vorteile eine Cloud-Infrastruktur zu nutzen und sehr kleinteilig zu definieren.

FaaS-Laufzeitumgebungen skalieren in der Regel automatisch. Im Rahmen der Entwicklung und des Betriebs muss man sich somit zunächst keine Gedanken hinsichtlich der Skalierbarkeit machen. Dies übernimmt der Cloudprovider. Damit bietet sich der Einsatz von FaaS insbesondere für Anwendungen an, bei welchen deutliche Schwankungen hinsichtlich des Nutzungsverhaltens zu erwarten sind.

Im Kontext einer Versicherung könnten hier Tarifrechner genannt werden, aber auch Apps zur Einreichung von Schäden oder Rechnungen. In diesem Fall unterstützt der Cloud-Anbieter bei der Verwaltung von Kapazitäten und einer automatischen Skalierung. Dies ermöglicht zu Lastspitzen, wie beispielsweise dem KFZ-Geschäft zum Jahresende, eine schnelle Bereitstellung neuer Ressourcen zum Zeitpunkt, wenn sie wirklich benötigt werden.

Die Flexibilität der Cloud erkauft man sich dann allerdings mit den aus anderen Cloud-Kontexten bekannten Herausforderungen in Bezug auf Datenschutz und Sicherheit. Diese Herausforderung ist allerdings für alle Cloud-Alternativen gleichermaßen zu lösen. Ein weiterer Nachteil ist, dass Serverless-Functions bei der ersten Ausführung relativ lange für den Start benötigen.

Wirtschaftlicher Aspekt

Bisher haben wir uns bei allen genannten Punkten in erster Linie auf technische Gegebenheiten konzentriert, wobei der wirtschaftliche Aspekt oder der zu erzielende Business Value für die Entscheidung hin zu einer Serverless-Architektur nicht außer Acht gelassen werden darf. Der positive Aspekt der automatischen Skalierung nach Bedarf ermöglicht eine deutlich granularere Abrechnung der Leistungen anhand der genutzten Ressourcen.

Demgegenüber steht ein klassischer Betrieb, bei dem auch wenig genutzte Ressourcen bereitgehalten werden müssen. Die Abrechnung nach Bedarf hat aber auch Nachteile. So können sich Programmierfehler und damit eine höhere Auslastung der Cloud-Infrastruktur schnell finanziell bemerkbar machen.

Hier die Vor- und Nachteile auf einen Blick:

Möglichkeiten in der Versicherung

Nachdem nun die Herausforderungen wie auch die Stärken des „Serverless“-Architekturansatzes angesprochen wurden, stellt sich die Frage nach dem passenden Anwendungsgebiet im Versicherungsbereich. Der Aufbau einer Applikation mithilfe von Serverless-Functions bietet sich insbesondere in Kontexten an, wo eine schnelle und zustandslose Verarbeitung gefragt ist.

Passende Anwendungsbeispiele lassen sich im Kontext von Codierung, Bildverarbeitung, Formatkonvertierung, Anmeldung und Registrierung oder Video-Streaming finden, aber auch einfache Web-, Mobil- oder IoT-Anwendungen lassen sich gemäß dem Serverless-Ansatz umsetzen. Beispiele finden sich wie erwähnt in Tarifrechner-Applikationen, aber auch anderen, in sich abgeschlossenen Applikationen, welche keinen Zustand speichern müssen.

Sobald die Ausführung einer Funktion über ein Event aufgerufen werden soll, können Functions-as-a-Service eine gute Alternative sein. Aufgrund der geringen Vorarbeit hinsichtlich Infrastrutur und Betrieb, bietet sich „Serverless“ für die Umsetzung von Prototypen oder Proof of Concepts (PoC) an. So können auf einfache Weise neue Ansätze erprobt und laufend erweitert werden. Im Falle eines PoC entfällt zusätzlich die Herausforderung des Datenschutzes vorerst.

Ist die Bereitstellung von Anwendungen in der Cloud für das Versicherungsunternehmen eine Option, so bieten bekannte Cloud-Anbieter zusätzlich einen großen Mehrwert durch Services, insbesondere im Bereich der Künstlichen Intelligenz. Langlaufende Verarbeitungen widerstreben dem Nutzen von „Serverless“ hingegen und eine Umsetzung in der Cloud verspielt den Kostenvorteil, der sich aus der automatischen Skalierung und Anpassung der Ressourcen ergibt.

Die Verkettung von Serverless-Functions kann die Komplexität darüber hinaus schnell erhöhen und Applikationen unwartbar machen. Die Nachvollziehbarkeit leidet in diesem Fall stark. Somit gilt wie immer in der Softwarearchitektur auch hier der Grundsatz „It depends“ und der Einsatz der Technologie muss sinnvoll anhand der Problemstellung ausgewählt werden.

* Stefan Rogge ist erfahrener Software-Architekt und Entwickler mit mehr als zehn Jahren Berufserfahrung. Im Laufe der Jahre arbeitete er bei adesso in wechselnden Rollen und Projekten an der Konzeption und Entwicklung von Anwendungen im Versicherungsbereich mit. Sein aktueller Fokus liegt dabei auf dem Entwurf und der Umsetzung verteilter Architekturen. Neben seiner Tätigkeit in Kundenprojekten ist Herr Rogge seit 2013 in Gremien des Brancheninstituts Prozesse (BiPRO) aktiv.

(ID:46490512)