Serverless, FaaS und PAYG – Was ist das eigentlich?

Was ist Serverless?

Nachdem wir nun bereits ein TechUp über Serverless geniessen durften, wollen wir einen Schritt zurück machen und das ganze Thema theoretisch genauer betrachten.

Figure: Quelle: https://www.reddit.com/r/ProgrammerHumor/comments/ki1uoh/the_room_full_of_serverless/

Beim Thema Serverless scheiden sich die Geister. Fragen wie “Hat man überhaupt noch Server?” und “Ist das nicht viel zu kostspielig?” können stundenlange Diskussionen anregen.

Aber was genau ist eigentlich Serverless und wie wird es definiert? Fragen wir ChatGPT: “Was ist Serverless in drei Sätzen?”:

Serverless bezieht sich auf eine Methode der Softwareentwicklung und -bereitstellung, bei der der Entwickler sich nicht um die Verwaltung oder Bereitstellung von Servern kümmern muss. Stattdessen werden die Anwendungen in der Cloud ausgeführt und die Infrastruktur wird automatisch von einem Cloud-Anbieter bereitgestellt und verwaltet. Die Anwendungen werden in kleinere, unabhängige Funktionen aufgeteilt, die nur dann ausgeführt werden, wenn sie benötigt werden.

Serverless beschreibt also ein Architektur-Muster, ähnlich wie Containerisierung oder Container-Orchestrierung, mit dem Computing im Cloud-Umfeld stattfinden kann. Dabei ist Serverless als “höchste” Abstraktionsebene zu verstehen, man ist also von dem eigentlichen Server oder der physischen Schicht am weitesten entfernt.

Kleiner Exkurs in die Küche:

Du erinnerst dich sicher an mein TechUp über Micro im Frontend, dort haben wir das Ravioli-Zeitalter, sprich den Microservice-Gedanken, genauer kennengelernt. Das Bild zeigt die Evolution in der Softwarearchitektur. Beim Vorbereiten dieses TechUps kam mir oft der Gedanke: Was kommt eigentlich nach Ravioli? Natürlich, Serverless, aber wie wird das assoziiert?

Ich bin mir sicher, Serverless ist, wenn man Essen beim Lieferdienst bestellt. Idealerweise bestellt man viele kleine unterschiedliche Teilchen und versucht, diese dann zu kombinieren, was je nach Hunger und Vorliebe schnell teuer werden kann. Wichtig ist aber, dass man sich nicht um den Backofen, das Mehl oder Ähnliches kümmern muss. Man bezahlt effektiv nur, wenn man etwas geliefert bekommt und dies dann auch verspeist ;-)

Zurück zum Thema: Oft assoziiert man Serverless mit “es gibt keinen Server”, doch das ist ein Irrglaube. Ganz weit unten, weit außerhalb des eigenen Verantwortungsbereichs, meist bei einem Cloud-Anbieter, steht der eigentliche Server. Er ist einfach so weit abstrahiert, dass man von “Serverless”, zu Deutsch “ohne Server”, spricht.

Merkmale einer Serverless Architektur

Ab wann ist meine Applikation oder meine Geschäftsdomäne dann Serverless, welche Merkmale müssen erfüllt sein?

1. Abstraktion von Servern: In einer Serverless-Architektur müssen sich Entwickler nicht um die Bereitstellung, Konfiguration oder Verwaltung von Servern kümmern (Stichwort FaaS, mehr dazu später).
2. Automatische Skalierung: Serverless-Funktionen werden automatisch skaliert, um Lastspitzen zu bewältigen, ohne dass Entwickler manuell eingreifen müssen. Die Skalierung erfolgt auch nach unten, bis hin zur Abschaltung.
3. Abrechnung nach Nutzung: Serverless-Plattformen berechnen nur die tatsächlich genutzten Ressourcen und nicht die zugewiesenen Ressourcen (Stichwort PAYG, mehr dazu später).
4. Event-getriebene Ausführung: Serverless-Funktionen werden nur dann ausgeführt, wenn bestimmte Ereignisse oder Anforderungen eintreten, anstatt ständig aktiv zu sein.

Wenn eine Architektur diese Merkmale erfüllt, kann sie als Serverless betrachtet werden.

Abgrenzung zu Cloud-Provider-Native

Oft kommt die Diskussion auf: Ist das nun Cloud-Provider-Native, wie z.B. AWS ECS o.ä., oder ist das schon Serverless, wie zum Beispiel AWS Amplify Serverless-Plattformen wie AWS Amplify und AWS Lambda sind speziell für die Bereitstellung von Funktionen als Service (FaaS) konzipiert und bieten eine stark abstrahierte und verwaltete Infrastruktur. Mit Serverless-Plattformen müssen sich Entwickler nicht um die Verwaltung von Servern, Netzwerken oder dem darunterliegenden Application Stack kümmern, da diese von der Plattform automatisch bereitgestellt und skaliert werden.

Im Gegensatz dazu bieten native Cloud-Provider-Dienste wie Amazon Elastic Kubernetes Service (EKS) oder Amazon Elastic Container Service (ECS) eine höhere Kontrolle und Flexibilität bei der Verwaltung von Containern oder dem darunterliegenden Application Stack. Hierbei ist es notwendig, dass Entwickler sich selbst um das Management und die Bereitstellung von Servern und Netzwerken kümmern, wodurch mehr Konfigurations- und Wartungsaufwand entsteht.

Während Serverless-Plattformen in der Regel für kleinere, aufgabenorientierte Anwendungen verwendet werden, die schnell und agil entwickelt werden können, eignen sich native Cloud-Provider-Dienste besser für größere, komplexe Anwendungen, die spezielle Anforderungen an die Skalierbarkeit, Performance oder Anpassbarkeit haben.

Was ist FaaS & PAYG?

FaaS - Function as a Service

Nach IaaS kommt CaaS, dann PaaS und schliesslich kommt FaaS, logisch oder?

Figure: FaaS Meme, generated with https://imgflip.com/memegenerator

FaaS steht für “Function as a Service” und bezieht sich auf eine Serverless-Architektur, bei der Anwendungen in kleine, unabhängige Funktionen aufgeteilt werden, die separat ausgeführt werden können. Jede Funktion wird nur dann ausgeführt, wenn sie benötigt wird, und kann automatisch skaliert werden. FaaS ermöglicht es Entwicklern, sich auf die Entwicklung von Code zu konzentrieren, anstatt sich um die Infrastruktur kümmern zu müssen, was schnellere und agilere Entwicklungszyklen ermöglicht.

Kurze Wiederholung: Cloud ist ja eigentlich ganz einfach ;-)

Figure: Quelle: https://cloud.google.com/learn/paas-vs-iaas-vs-saas?hl=de

Wichtig zu sehen ist aber, dass FaaS die letzte Stufe vor SaaS ist, also quasi Serverless als Service. Konkret kümmert man sich nur noch um den eigentlichen Code und die Konfiguration; alles andere wird vom Cloud-Provider bereitgestellt und verwaltet.

PAYG

Das sogenannte Pay as you go Modell ist ein Abrechnungsmodell, bei dem Kunden nur für die tatsächlich genutzten Dienstleistungen zahlen. Im Gegensatz zu traditionellen Vertragsmodellen bietet PAYG eine höhere Flexibilität und Skalierbarkeit, da die Abrechnung auf Basis des tatsächlichen Bedarfs erfolgt. Gerade für kleinere Aufgaben, CronJobs oder Ähnliches macht dieses Konzept in Zusammenspiel mit FaaS häufig Sinn. Grundsätzlich wird das PAYG-Konzept im Serverless-Bereich gerne angewendet, um eine schnelle Skalierung (auch der Kosten) bieten zu können. Ein großes Risiko bei PAYG können wuchernde Kosten sein, durch Fehlkonfiguration, DDoS-Angriffe oder Ähnliches. Hier sollten immer entsprechende Limits und Schutzmechanismen konfiguriert und aktiv sein!

Serverless Use Cases

Eine Serverless-Architektur aufzubauen sollte gut durchdacht und lange geplant sein! Meist muss man bei Null anfangen, da die komplette Architektur ein Umdenken erfordert. Im Gegensatz zur Containerisierung gibt es kaum “low hanging fruits”, um eine Applikation mal schnell Serverless zu machen.

Serverless macht immer Sinn bei:

• Aufgabenbasierte Anwendungen: Serverless eignet sich ideal für anwendungsunabhängige Funktionen, die bestimmte Aufgaben ausführen, wie z.B. Bildverarbeitung, Datenverarbeitung und Benachrichtigungen. Ein Beispiel dafür ist eine Anwendung, die Bilder in verschiedene Größen konvertiert und in einen Cloud-Speicher hochlädt.

• Eventbasierte Architekturen: Serverless eignet sich hervorragend für Anwendungen, die auf Ereignissen oder Benutzereingaben basieren, wie z.B. Benachrichtigungen und Echtzeitdatenverarbeitung. Ein Beispiel dafür ist eine Anwendung, die Benutzerbenachrichtigungen basierend auf Daten aus verschiedenen Quellen sendet.

• Skalierbare Anwendungen: Serverless bietet eine nahtlose Skalierbarkeit, sodass Anwendungen automatisch und schnell auf hohe Lasten reagieren können. Ein Beispiel dafür ist eine E-Commerce-Anwendung, die während des Weihnachtsgeschäfts schnell skalieren muss, um den erhöhten Verkehr zu bewältigen.

• Kosteneffiziente Anwendungen: Serverless kann kosteneffektiver sein als herkömmliche serverbasierte Architekturen, insbesondere für Anwendungen mit variabler Auslastung. Ein Beispiel dafür ist eine Anwendung, die in der Lage ist, Ressourcen nur dann zu verwenden, wenn sie benötigt werden.

• Experimentelle Anwendungen: Serverless bietet eine ideale Umgebung für experimentelle Anwendungen oder Prototypen, da sie schnell und einfach erstellt werden können, ohne dass umfangreiche Infrastruktur eingerichtet werden muss. Ein Beispiel dafür ist eine Anwendung, die verschiedene APIs integriert und automatisch auf Ereignisse reagiert.

• Microservices-Architekturen: Serverless eignet sich ideal für Anwendungen, die in Microservices aufgeteilt sind, da jede Funktion unabhängig voneinander skaliert werden kann. Ein Beispiel dafür ist eine Anwendung, die aus mehreren Microservices besteht, die jeweils eine bestimmte Funktion ausführen und über eine API kommunizieren.

Klassisches Beispiel

Im nachfolgendem Bild ist ein klassisches Beispiel einer Webanwendung als Serverless Architektur zu sehen. Hierbei wird auf einer Webseite ein Link geklickt, welcher Daten aus einer Datenbank abfragt und dem Benutzer wieder anzeigt.

Figure: Quelle: https://www.xenonstack.com/blog/aws-serverless-computing/

Dieses gesamte Beispiel kommt ohne “Server” aus, sprich nirgends sind Ressourcen wie CPU, RAM oder ähnliches fest allokiert und gestartet, PAYG kommt voll und ganz zum Einsatz, da sämtliche Komponenten Serverless bzw. FaaS Komponenten sind. Hierbei ist zu beachten, dass die Datenbank auch Serverless ist. Sie wird nicht auf einem Server betrieben, sondern als Service von AWS angeboten. Serverless ist also nicht nur eine Architektur einer einzelnen Applikation, sondern auch ein Konzept, welches sich auf alle Bereiche auswirkt.

Wann macht Serverless keinen Sinn?

In einigen Fällen macht es keinen wirklichen Sinn, auf das Serverless Pattern zu setzen, sondern eher auf die “klassische” Container Orchestrierung zu setzen. Dazu gehört:

• Sehr konstante Last - wenn die Applikation dauerhaft ausgelastet ist können die Vorteile einer Serverless Umstellung geringer sein
• Langlaufende Funktionen - eine AWS Lambda Funktion hat beispielsweise eine maximale Ausführungszeit von 5 Minuten. Hat man also sehr lange laufende Funktionen, könnte der Einsatz von Serverless (Function Chaining) etwas umständlich werden
• Nicht unterstütze Umgebung / Sprache usw.
• Auch Kostengründe können ein klares Nein zum Serverless-Ansatz sein

An dieser Stelle möchte ich betonen, dass das nicht heisst, das der alte Monolith einfach stehen bleiben soll! Es gibt immer Möglichkeiten unter Verwendung von Containerisierung mit Microservices und ähnliches eine Anwendung zu modernisieren und zu optimieren, auch wenn Serverless in diesem Fall nicht die richtige Lösung ist.

Anforderungen

Serverless zu werden ist nicht einfach nur ein “Lift & Shift”! Die Anwendung, sogar die gesamte Geschäftsdomäne, muss vollständig auf das Serverless-Muster ausgelegt sein. Daher gibt es unterschiedliche Anforderungen:

1. Zustandsloses Funktionsdesign: Funktionen sollten unabhängig voneinander sein und keine Abhängigkeiten von anderen Funktionen oder Ressourcen haben.
2. Ereignisgetriebene Architektur: Die Anwendung sollte auf Ereignisse reagieren und in der Lage sein, die Verarbeitung von Ereignissen zu orchestrieren und die entsprechenden Funktionen zu starten.
3. Skalierbarkeit: Die Anwendung sollte in der Lage sein, sich an die Anforderungen der Benutzer anzupassen und eine einfache Skalierung zu ermöglichen.
4. Modularität: Die Anwendung sollte modular und in kleine, unabhängige Funktionen aufgeteilt sein, um jede Funktion separat skalieren und verwalten zu können.
5. Leichtgewichtig: Schnelle Start- und Abschaltzeiten, kleiner Ressourcenverbrauch.
6. Standardisiert: Einsatz von modernen Technologien, die vollständig unterstützt werden.
7. Cloud-natives Design: Die Anwendung sollte auf Cloud-nativen Technologien basieren und in der Cloud-Umgebung ausgeführt werden.

Vor- & Nachteile von Serverless

Vorteile

• Skalierbarkeit und automatische Ressourcenverwaltung
• Niedrigere Kosten und Bezahlung nur für tatsächlich genutzte Ressourcen (PAYG)
• Reduzierte Zeit für Infrastruktur-Management und -Wartung
• Fokus auf die Entwicklung von Anwendungen statt auf die Verwaltung von Servern
• Voller Fokus auf die eigentliche Aufgabe, ereignisbasiert

Nachteile

• Einschränkungen bei der Laufzeitumgebung und der zugrunde liegenden Infrastruktur
• Einschränkungen bei der Größe der ausführbaren Funktionen und der Speicherkapazität
• Komplexität bei der Integration von Anwendungen und Abhängigkeiten
• Schwierigkeiten beim Debugging und Testen von Funktionen
• Mögliche Vendor-Lock-in-Effekte und eingeschränkte Portabilität
• Sicherheit, keine Möglichkeit für Hardening usw.
• Und nochmals, wie das folgende Bild zeigt, Komplexität aufgrund vieler einzelner, kleiner Teile

Figure: Quelle: https://docs.momentohq.com/develop/tutorials/serverless-cache-walkthrough/deploying-a-basic-serverless-application

CNCF-Landschaft

Es gibt eine Serverless-Landschaft, welche von der CNCF (Cloud Native Computing Foundation) erstellt wurde. Diese Landschaft zeigt die verschiedenen Serverless-Technologien sowie deren Stärken und Schwächen.

Was kommt nach Serverless?

Serverless ist derzeit einer der fortschrittlichsten Architekturansätze, um skalierbare, flexible und kosteneffiziente Anwendungen zu erstellen. Es ist jedoch wichtig zu beachten, dass Technologie und Innovation in der IT-Branche ständig voranschreiten und es immer Raum für Verbesserungen gibt. Einige Experten in der Branche glauben, dass “Functions as a Service” (FaaS) die nächste Entwicklungsstufe nach Serverless sein könnte. FaaS baut auf der Serverless-Architektur auf und bietet eine noch feinere Granularität, indem es die Funktionsaufrufe in kleinere Einheiten aufteilt und die Möglichkeit bietet, Funktionen schneller und mit geringerer Latenz auszuführen. Darüber hinaus gibt es auch Ansätze wie “Event-Driven Architecture” (EDA), die sich auf die Verarbeitung von Ereignissen konzentrieren, um Anwendungen zu orchestrieren und auszuführen. EDA ist besonders nützlich für Anwendungen, die auf Echtzeitereignissen basieren, wie beispielsweise IoT-Anwendungen.

Es ist jedoch schwierig zu sagen, was in Zukunft kommen wird, da die IT-Branche sehr dynamisch und innovativ ist. Es ist jedoch sicher, dass es immer neue Ansätze und Technologien geben wird, um Anwendungen effektiver, effizienter und skalierbarer zu machen. Was sicher ist: Serverless wird weiter wachsen! Und wir von b-nova sind dabei! Das zeigt auch der State of Serverless Report von DataDog, welcher die wichtigsten Trends und Entwicklungen im Serverless-Bereich aufzeigt.

Fazit

Soll ich Serverless nutzen? Diese Frage steht zentral im Vordergrund! Schaut man sich einen Entscheidungsbaum an, fällt die Antwort doch leicht, oder? ;-)

Figure: Quelle: https://www.ml4devs.com/articles/serverless-architecture-for-microservices-on-aws-vs-google-cloud-vs-azure-as-iaas-caas-paas-faas/

Aus meiner persönlichen Sicht macht es bei Neuentwicklungen oder Ausgliederung einzelner Teile auf jeden Fall Sinn! Kleinere Funktionen, Webseiten mit keiner dauerhaft hohen Last oder CronJobs o.Ä. sind mit Serverless sehr einfach und auch kostengünstig, da PAYG, zu betreiben. Einfach von heute auf morgen den großen Online-Shop auf eine Serverless-Architektur zu migrieren, benötigt etwas mehr Planung und idealerweise eine Neuentwicklung “auf der grünen Wiese”.

Wir von b-nova bleiben voll und ganz überzeugt von Serverless und dran am Thema! Freut euch auf weitere TechUp- und decodify-Folgen! Bleibt dran!