Was es bedeutet und wann es Sinn macht:

Serverless

Die Wahl zwischen einem klassischen Server und Serverless ist eine grundlegende Entscheidung zu Projektbeginn. Deshalb erklären wir, was Serverless bedeutet und welche Gründe dafür bzw. dagegen sprechen können.

Server oder Serverless #

Ein entscheidender Schritt in der Software- oder Webentwicklung ist die Wahl der passenden Technologie zu Beginn des Projekts. Wird diese Entscheidung im laufenden Projekt verändert, so hat dies weitreichende Konsequenzen, die bis zu einem kompletten Neustart reichen können. Um solche kostspieligen Änderungen zu vermeiden, ist es hilfreich bereits vor Projektbeginn zu wissen, für welche Aufgabenstellung sich welche Technologie am besten eignet. Ein Beispiel für eine solche Entscheidung ist die Wahl zwischen einer klassischer Server-Infrastruktur oder einer Serverless-Applikation.

Was ist Serverless #

Bevor diese Entscheidung getroffen werden kann, stellt sich erstmal die Frage, was ist "Serverless" überhaupt? Vorneweg, auch bei Serverless-Applikationen existiert ein Server, anders als bei klassischer Server-Infrastruktur haben die Anwender:innen aber nur sehr eingeschränkte Möglichkeiten, die Hardware- und Softwarekomponenten zu beeinflussen. Grundsätzlich wird Einrichtung und Verwaltung der Server-Umgebung komplett einem Cloud-Anbieter überlassen. Dadurch entsteht für die Anwender:innen eben jener Eindruck, dass die Applikation "serverless" läuft.

Bei bekannten Serverless-Plattformen wie AWS Lambda oder Azure Functions kann grundsätzlich gewählt werden, welche Programmiersprache verwendet wird und durch welchen Trigger die Serverless-Applikation ausgelöst wird. Die Auslöser beinhalten normalerweise Daten, welche von der Applikation verarbeitet werden sollen - zum Beispiel Bilder, die verkleinert werden sollen oder Datensätze, die bereinigt werden müssen.

Es gehört zu den best-practices, die Applikation so zu schreiben, dass sie unabhängig von vorangegangenen oder nachfolgenden Ausführungen ist - dies nennt man stateless. Dadurch ist es möglich, eintreffende Nachrichten unabhängig ihrer Reihenfolge abzuarbeiten um so eine einfache horizontale Skalierung (mehrere Instanzen der Applikation werden gleichzeitig ausgeführt) zu ermöglichen.
Außerdem ist es von Vorteil die Ausführungsdauer der Applikation möglichst kurz zu halten. Bei Serverless-Applikationen werden nämlich nur die tatsächlich verwendeten Ressourcen verrechnet. Dadurch kann man gegenüber klassischer Server-Architektur Kosten sparen.

Gründe für Serverless #

Wann macht es also Sinn auf Serverless statt Server zu setzten? Aus unserer Sicht sprechen folgende drei Punkte für die Nutzung einer Serverless-Applikation.

Einfache Skalierbarkeit #

Skalierbarkeit ist für viele Applikationen ein entscheidender Faktor. Schnell steigende Nutzerzahlen oder ein variables Nachrichtenaufkommen sind nur zwei Beispiele, bei denen automatische Skalierung von Serverless-Applikationen Kosten sparen, ohne auf Performance zu verzichten.

Schnell produktiv #

Wie bereits erwähnt, werden Serverless-Applikationen nach tatsächlicher Nutzung abgerechnet. Das führt dazu, dass man eine Idee schnell produktiv, also der Öffentlichkeit zugänglich machen kann, ohne große Kosten zu haben. In Kombination mit der einfachen Skalierbarkeit bleiben die Initialkosten überschaubar und ermöglichen ein schnelles Wachstum.

Eine Aufgabe #

Für Applikationen, welche nur eine Aufgabe haben, wie zum Beispiel das Aufbereiten eingehender Datensätze, ist es viel zusätzliche Arbeit, ganze Server inklusive Load Balancer, Security, Benutzerverwaltung, usw. einzurichten. Diese Funktionen werden bei Serverless-Applikationen vom Cloud-Anbieter bereits mitgeliefert. Dadurch kann Geld in der Entwicklung gespart werden.

Gründe gegen Serverless #

Abgesehen davon, dass sich manche Anforderungen nur schwer Serverless umsetzen lassen, gibt es auch technische Gründe, die gegen Serverless sprechen.

Langsamer Start #

Sollte zwischen dem Triggern der Serverless-Applikation zu viel Zeit vergehen, wird die Instanz der Applikation heruntergefahren. Dies spart dem Cloud-Anbieter Ressourcen, führt aber dazu, dass beim nächsten Trigger die Instanz zuerst hochgefahren werden muss. Dadurch ist die Reaktionszeit der Applikation deutlich geringer als bei einer bereits laufenden Instanz.

Abhängigkeit vom Cloud-Anbieter #

Vor allem wenn die Serverless-Applikation zusammen mit anderen Services des Cloud-Anbieters genutzt wird, ist es schwierig, den Anbieter zu wechseln.

Fazit #

Abhängig davon, ob man schnell auf den Markt will, mit hoher Nutzungsschwankung rechnet oder einfach nur alles selbst in der Hand haben will, kann die Entscheidung auf den klassischen Server oder eine Serverless-Applikation fallen. Sie sind nicht sicher, welches System am besten zu Ihrem Projekt passt? Wir beraten Sie gerne und helfen Ihnen, die richtige Wahl zu treffen.