Was bedeutet Serverless?

Serverless Computing

Die Entwicklung und Bereitstellung einer Anwendung bringt meist umständliche Entwicklungsprozesse, schwergewichtige Anwendungsserver und langsame Testzyklen mit sich. Die Idealvorstellung ist, dass sich Backend-Entwickler nur noch um die Implementierung der fachlichen Bausteine kümmern müssen und konzentriert Anwendungen programmieren können, ohne sich gleichzeitig um Server kümmern zu müssen.

Mit Serverless, auch Serverless Computing, Serverless Architecture und Serverless Infrastructure genannt, wird diese Idealvorstellung zur Wirklichkeit. Durch Serverless können Entwickler Cloud-Anwendungen und -Services erstellen und ausführen, ohne gleichzeitig für Server und deren Verwaltung verantwortlich zu sein. Ganz nach dem Motto: “Run code, not Server”.

Seit der Veröffentlichung von Amazon AWS Lambda 2014 hat sich Serverless etabliert und andere Cloud-Anbieter stellen nun ebenfalls serverlose Services zur Verfügung. Nach IaaS, PaaS, BaaS und SaaS ist mit FaaS (Function as a Service) ein weiterer bedeutende Schritt in der Cloud-Historie gemacht worden.

Was genau bedeutet eigentlich Serverless?

Als Serverless (zu Deutsch: Serverlos, ohne Server) bezeichnet man ein Ausführungsmodell, bei dem der Cloud-Anbieter den Server betreibt, für die Code-Ausführung verantwortlich ist und die Zuweisung von Ressourcen dynamisch verwaltet. Die Kosten basieren auf dem tatsächlichen Ressourcenverbrauch der Ausführung, Kunden zahlen also nicht für ungenutzte, sondern für die tatsächlich verwendeten Rechen- und Speicherressourcen.

Entwickler können dank Serverless Computing Anwendungen oder Services in der Cloud ausführen, ohne sich Gedanken über Bereitstellung, die Skalierbarkeit, die Kapazitätsplanungen und Sicherheitspatches sowie Wartungsarbeiten von Servern machen zu müssen.

Je nach eingesetzter Serverless-Plattform kann der Entwickler den Code in verschiedenen Programmiersprachen schreiben, wie zum Beispiel in Go, Java, JavaScript oder Python.

Zu den Anbietern für Serverless zählen unter anderem:

• Microsoft mit Azure Functions
• Amazon Web Services mit AWS Lambda
• Google mit the Cloud Functions oder IBM Cloud Functions (OpenWhisk)

Probleme bei Entwicklungsprozessen

Grundsätzlich werden Web-Apps so entwickelt, dass der Entwickler die http-Anfragen, die an den Server gemacht werden, kontrolliert. Die App läuft auf diesem Server, sodass Entwickler für die Bereitstellung, Wartung und Verwaltung der Ressourcen verantwortlich sind. Das ist mit viel Aufwand verbunden und lenkt von der eigentlichen Arbeit ab: nämlich dem Bauen von Apps.

Folgende Probleme treten auf:

• es entstehen Kosten, auch wenn der Server keine Anfragen erfüllt
• Entwickler sind für die Verfügbarkeit und Wartung des Servers verantwortlich
• der Server muss die aktuellsten Sicherheits-Updates haben
• der Server muss skaliert oder auch runterskaliert werden

In größeren Organisationen werden diese Aufgaben von einem Infrastruktur-Team erledigt und nicht von einzelnen Entwicklern. Nichtsdestotrotz verlangsamen diese Prozesse die Entwicklungszeiten. Bei der Lösung dieses Problems setzt Serverless an.

Microservices

Beim Serverless Computing müssen die Anwendungen in Form von Funktionen gestaltet werden, was die größte Änderung für Entwickler darstellt. Einzelne Anwendungen, die bisher als Rails- oder Express-Monolith-Apps bereitgestellt wurden, müssen bei Serverless als eine auf Microservice basierende Architektur integriert werden.

Funktionen werden normalerweise in stateless containers (Programmhüllen ohne Langzeitspeicher) ausgeführt, die durch Events wie http-Anfragen, Warteschlangendienste und Datei-Uploads ausgelöst werden, also wenn auf ein Ereignis reagiert werden muss. Dadurch entsteht eine Verzögerung, auch Cold Start (zu Deutsch: Kaltstart) genannt. Die Dauer der Verzögerung hängt von der verwendeten Laufzeit, der Größe der Funktion und vom jeweiligen Cloud-Anbieter ab. Es gibt allerdings zahlreiche Tricks, um eine Funktion, die regelmäßig ausgeführt wird, „warm“ zu halten.

Da der Code als einzelne Funktionen ausgeführt wird, wird er auch als Function as a Service (FaaS) bezeichnet. Bei FaaS bereitgestellten Produkte handelt es sich um kurzlebige Laufzeitumgebungen, die vom Provider dynamisch zugewiesen und skaliert werden.

Eine Besonderheit bei serverlosen Infrastrukturen ist, dass der Entwickler nicht nur einen Code in die Cloud lädt, sondern auch Funktionen definiert, festlegt und hochlädt, wie auf bestimmte Ereignisse (Events) reagiert werden soll. Die Funktionen werden dann ausgeführt, wenn vordefinierte Ereignisse eintreten. Man spricht hier von “Event-driven Computing”.

Serverless bedeutet nicht vollständig serverlos

Bei Serverless Computing wird die Server-Schicht vollkommen abstrahiert, aber natürlich ist physisch noch immer ein Server vorhanden, der Entwickler kommt jedoch nie damit in Berührung. Ein Beispiel ist Platform as a Service (PaaS): Der Entwickler muss hier nicht mit der API der Plattform interagieren und sich nicht darum kümmern, wie Server aufgesetzt, bereitgestellt und skaliert werden. Stattdessen sorgt der Serviceanbieter dafür, dass stets genügend Ressourcen für die jeweilige Anwendung zur Verfügung stehen.

Vorteile von Serverless

• unbegrenzte Ressourcen wie Rechenleistung und Arbeitsspeicher, die erst dann bereitgestellt werden, wenn sie benötigt werden
• Kunden zahlen nur für die Ressourcen, die verbraucht werden, um die Funktionen auszuführen
• vereinfachter Betrieb: Entwickler können sich auf ihre Kernkompetenzen konzentrieren
• automatische Skalierung und Fehlertoleranz
• schnelle Bereitstellung der Ressourcen
• automatisches Kapazitätsmanagement
• flexible Ressourcenverwaltung
• Konzentration auf den Kern des Source-Codes

Nachteile von Serverless

• nicht für alle Anwendungsfälle geeignet, da es manchmal effizienter und kostengünstiger ist einen Server selbst aufzusetzen
• Einschränkungen bei Monitoring und Debugging
• möglicher Kontrollverlust und Plattform-Abhängigkeit
• schlechtere Performance durch verzögerte Reaktionen wegen Startdauer der Laufzeitumgebung
• nicht zwingend sicherer, sondern genauso angreifbar wir traditionelle Prozesse
• Nutzer können Cloud-Workloads nicht mit traditionellen Sicherheitsprodukten schützen
• Gefahr eines Vendor Lock-ins, sobald man sich an herstellerspezifische Schnittstellen bindet
• Beispiele für Serverless-Anwendungen

• Automatische Videobearbeitung: Automatisches Konvertieren in unterschiedliche Formate beim Hochladen einer Videodatei.
• Automatische Bildbearbeitung: Beim Hochladen einer Bilddatei werden automatisch verschiedene Bildformate/-grössen erstellt.
• Monitoring und Debugging: Benachrichtigung oder Funktionen als Reaktion auf bestimmte Trigger, beispielsweise bei Änderungen von Daten oder dem Systemstatus.