Serverless ist derzeit in aller Munde. Kaum ein Tag vergeht ohne Ankündigung eines neuen Serverless-Dienstes. Dabei ist die Bandbreite groß: von Function-as-a-Service (FaaS) bis zu Künstlicher Intelligenz (Serverless AI). Hat man sich einmal mit der Idee angefreundet hat, dass es auch ohne eigene Server gehen kann, stellt sich die Frage: „Kommt eine Serverless Architecture für uns in Frage?“

Serverless = keine sichtbaren Server

Der Begriff Serverless ist etwas missverständlich. Er könnte vermuten lassen, dass es um Systeme ohne Backend geht oder dass keine Server mehr zum Einsatz kommen. In einer Serverless Architecture ist jedoch sehr wohl ein Backend enthalten. Aus Kundensicht (Dev/Ops) werden jedoch keine eigenen Server dafür betrieben. Es geht sogar noch einen Schritt weiter: Das Konzept „Es läuft ein Prozess, der auf Anfragen wartet“ kommt so nicht mehr vor. Server werden somit „unsichtbar“.

Serverless: keine sichtbaren Server

Aber warum sollte man sich nun von seinen Servern trennen?

Keine Administration und Bereitstellung der Infrastruktur

Ohne die Verantwortung für Server fallen einige Aufgaben weg. Auslastung überwachen und optimieren, Instanzen hinzufügen oder entfernen, Betriebssystem auswählen und aktuell halten, Zugriff verwalten und absichern, Anwendung auf Instanzen verteilen: Das alles wandert in die Verantwortung der Cloud Service Provider.

Automatische Skalierung

Eigener Code, der als „Serverless Function“ (FaaS) hochgeladen wurde, wird bei Auftreten eines Ereignisses (HTTP Anfrage, neue Nachricht, etc.) zur Ausführung gebracht. Dazu wird die Funktion mit den nötigen Ressourcen wie CPU, RAM, Netzwerk ausgestattet. Treten Ereignisse gehäuft auf, geschieht dies einfach öfter.

Geringere Kosten für die Infrastruktur selbst

Es fallen nur Kosten für verwendete Ressourcen an. Oft gibt es sogar freie Kontingente z.B. für FaaS-Aufrufe. Neue Features können so ohne große finanzielle Verpflichtung ausprobiert werden.

Geringere Time-to-Market

Anwendungen lassen sich durch geschickte Einbindung von Backend-Services (BaaS) – wie Datenbanken, Messaging, Push Notification, Sprach-/Bilderkennung – „zusammenstecken“. Somit kann der Fokus verstärkt auf das fachliche Problem gelegt werden.

Demgegenüber steht eine Reihe von Nachteilen bzw. Risiken. Die wichtigsten sind die Abgabe der technischen Kontrolle und der mögliche Vendor Lock-in. Dazu kommen — je nach Provider und Ausbaustufe der Services — technische Einschränkungen. Da Serverless meist mit Public Cloud einhergeht, treffen die gleichen Sicherheitsrisiken und Bedenken z.B. zum Datenschutz zu. Zudem sind viele Serverless-Technologien noch recht jung und befinden sich noch stark in der Entwicklung. Dazu gehören nicht nur die Services selbst, sondern auch das Tooling für Entwicklung, Deployment und Monitoring.

Ob eine Serverless Architecture sich für ein konkretes Vorhaben eignet, sollte vor Einführung bewertet werden. Hat man seine Infrastruktur gut und kostengünstig im Griff und auch keine Probleme mit Skalierbarkeit, wird ein Serverless-Ansatz vermutlich erst einmal wenig konkreten Mehrwert bieten. Es empfiehlt sich zudem, die möglichen Nachteile und Risiken zu bewerten.

Skalierbarkeit von Function-as-a-Service

Function-as-a-Service (FaaS) erlaubt sehr kleine Skalierungseinheiten. Die Größe hat Einfluss darauf, wie schnell eine Funktion bereitgestellt wird, wenn sie eine Zeitlang nicht verwendet wurde („Aufwärmen“ einer „kalten“ Funktion). Ein Monolith lässt sich daher eher schlecht als FaaS abbilden, ein Microservice schon besser.

Bei synchroner Verwendung, z.B. für die Verarbeitung eines HTTP-Requests, kann die „Aufwärmzeit“ einer Funktion unschöne Spitzen in den Antwortzeiten hervorrufen. Performanzanforderungen mit geringen Latenzen passen da nicht so gut. Asynchrone Verarbeitungen wie Messaging und File Processing hingegen sind ideale Anwendungsszenarien.

Ressourcen wie RAM und CPU werden genau für eine Funktion zur Verfügung gestellt und in kleiner Taktung abgerechnet (je 100 Millisekunden). Für ein System mit schwankender Last kann das kostengünstig sein; für ein System mit konstant hoher Last bietet sich eher keine Kostenersparnis. Unter Umständen kann es sogar teurer werden als ein serverbasierter Infrastructure-as-a-Service-Ansatz.

FaaS können sich nicht auf einen lokalen Zustand im Hauptspeicher oder im Dateisystem verlassen. Optimierungsmöglichkeiten wie In-Memory Caching fallen somit weg. Funktionale Verarbeitungsschritte — z.B. Image und Video Processing —  die ohne weitere Abhängigkeiten für eine Eingabe eine Ausgabe berechnen, eignen sich sehr gut.

Ungewiss die Zukunft ist

Serverless ist (noch) kein Mainstream. Ob sich der Ansatz im größeren Stil durchsetzen wird, hängt davon ab, ob wir in kommender Zeit mehr Success Stories als Horrorgeschichten hören werden. Zumindest unsere Kunden, die bereits auf Serverless setzen, sind mit ihrer Entscheidung glücklich.