Jeder Vorteil des serverlosen Ansatzes, über den Sie lesen werden – elastische Skalierung, geringere Kosten im Leerlauf, schnellere Bereitstellung –, geht auf dieselbe grundlegende Entscheidung zurück: Sie tauschen die Kontrolle über die Infrastruktur gegen eine schnellere Entwicklung ein.
Um die richtige Entscheidung zum Thema Serverless Computing zu treffen, müssen Sie zunächst klären, worum es dabei eigentlich geht. Auf dieser Grundlage können Sie dann die Vorteile, die sich unter realen Arbeitslasten bewähren, mit den Kompromissen abwägen, die sich nach der Migration ergeben, sobald Sie sich bereits festgelegt haben.
Kurzinfo: Was Sie über serverloses Computing wissen müssen
- Serverless Computing bedeutet, dass der Cloud-Anbieter die Bereitstellung, Skalierung und Wartung der Server übernimmt. Der Kunde verwaltet den Code und zahlt nur für die Ausführungszeit.
- Es gibt drei Hauptkategorien: Function-as-a-Service (FaaS), Backend-as-a-Service (BaaS) und verwaltete, containerbasierte serverlose Plattformen.
- Zu den wichtigsten Vorteilen zählen die nutzungsabhängige Abrechnung, die automatische Skalierung und schnellere Bereitstellungszyklen, da Entwickler Funktionen bereitstellen, anstatt Umgebungen einzurichten.
- Die wichtigsten Kompromisse sind die Latenz beim Kaltstart, ein aufwendigeres Debugging und die Bindung an einen Anbieter, da Ihre Anwendungslogik eng an die Laufzeitumgebung eines bestimmten Anbieters gekoppelt ist.
- Serverless Computing eignet sich gut für variable, ereignisgesteuerte Workloads. Für konstante Workloads mit hohem Durchsatz ist es hingegen weniger geeignet, da dedizierte Rechenleistung ist oft günstiger.
Was genau ist serverloses Computing?
Serverless Computing ist ein Cloud-Ausführungsmodell, bei dem ein Anbieter Rechenressourcen nach Bedarf zuweist, Ihren Code ausführt und diese Ressourcen nach Abschluss des Auftrags wieder freigibt.
Sie schreiben Funktionen oder Backend-Logik. Der Anbieter entscheidet, wo dieser Code ausgeführt wird, wie viele Instanzen dafür benötigt werden und wann diese heruntergefahren werden.
Der Name ist im wörtlichen Sinne irreführend. Physische und virtuelle Server Jede Anfrage wird weiterhin bearbeitet. Was tatsächlich weggefallen ist, ist Ihr Einblick in diese Anfragen sowie Ihre Verantwortung für deren Verwaltung.
Dies unterscheidet sich von Infrastructure-as-a-Service (IaaS), bei dem Sie virtuelle Maschinen direkt bereitstellen und verwalten, sowie von Platform-as-a-Service (PaaS), bei dem Sie eine Anwendung auf einer Infrastruktur verwalten, die zwar teilweise abstrahiert ist, aber dennoch dauerhaft läuft. Serverless geht noch einen Schritt weiter: Es läuft nichts, solange es nicht durch eine Anfrage oder ein Ereignis ausgelöst wird.
Die drei Arten des serverlosen Computings
- Function-as-a-Service (FaaS): Dies ist das Modell, das die meisten Menschen meinen, wenn sie von “serverlos” sprechen. Plattformen wie AWS Lambda, Google Cloud Functions, Cloudflare Workers und Azure Functions führen einzelne Funktionen als Reaktion auf Auslöser – beispielsweise eine HTTP-Anfrage, einen Datei-Upload oder eine Warteschlangen-Nachricht – aus und berechnen die Kosten anhand der Ausführungszeit und des zugewiesenen Speichers.
- Backend-as-a-Service (BaaS): Diese Version umfasst verwaltete Backend-Komponenten, die Sie sonst selbst erstellen müssten: Authentifizierung, Datenbanken, Dateispeicher und Push-Benachrichtigungen. Sie rufen eine API auf, anstatt diesen Dienst selbst einzurichten und zu warten. Firebase und AWS Amplify bieten Dienste in dieser Kategorie an.
- Serverlose Container: Plattformen wie Azure Container Apps, AWS Fargate und Google Cloud Run ermöglichen es Ihnen, containerisierte Anwendungen bereitzustellen, ohne den zugrunde liegenden Cluster verwalten zu müssen. Sie verbinden die Flexibilität von Containern bei der Paketierung mit dem wartungsfreien Betriebsmodell der serverlosen Architektur.
Die meisten serverlosen Produktionsarchitekturen kombinieren alle drei Komponenten: FaaS wird für ereignisgesteuerte Logik genutzt, BaaS für gängige Backend-Dienste und Container für alles, was eine längere Laufzeit oder eine angepasste Umgebung erfordert.
Die 5 größten Vorteile des serverlosen Computing
Ganz einfach ausgedrückt liegen die Vorteile in geringeren Kosten und weniger Wartungsaufwand, doch es lohnt sich, etwas genauer hinzuschauen.
- Sie zahlen nicht mehr für ungenutzte Kapazitäten. Bei einem herkömmlichen Servermodell muss man Kapazitäten für Spitzenauslastungen bereitstellen und rund um die Uhr für diese Kapazität bezahlen – selbst um 2 Uhr morgens, wenn das Datenaufkommen nur einen Bruchteil der Spitzenauslastung beträgt. Serverlose Plattformen berechnen die Kosten nach der tatsächlichen Ausführungszeit, oft sogar millisekundengenau.
- Skalierung ist nicht mehr nur eine Frage der Kapazitätsplanung. Eine serverlose Plattform startet so viele Instanzen einer Funktion, wie die aktuelle Nachfrage erfordert, und fährt sie anschließend wieder herunter. Sie müssen den Datenverkehr nicht prognostizieren und entsprechende Ressourcen im Voraus bereitstellen. Sie erhalten keinen Anruf außerhalb der Geschäftszeiten, weil ein Launch viral gegangen ist und Ihr fester Serverpool nicht mithalten konnte.
- Die Bereitstellungszyklen verkürzen sich. Da vor der Bereitstellung von Code kein Server eingerichtet, aktualisiert oder konfiguriert werden muss, können Teams einzelne Funktionen unabhängig voneinander bereitstellen, anstatt ein Monolith-System neu zu deployen. Dies ist ein wesentlicher Grund dafür, dass die Verbreitung von Serverless so eng mit der Verbreitung von Microservices einhergeht. Der Markt spiegelt dieses Tempo wider: Das weltweite Marktvolumen für Serverless Computing betrug geschätzt im Jahr 2024 bei $24,51 Milliarden und wird voraussichtlich bis 2030 $52,13 Milliarden erreichen.
- Der Betriebsaufwand für das Infrastrukturteam sinkt. Keine Betriebssystem-Patches, keine Kapazitätsüberwachung, keine Serverflotte, die auf dem neuesten Stand gehalten werden muss. Das bedeutet jedoch nicht, dass die Arbeit im Betrieb wegfällt. Vielmehr verlagert sie sich hin zur Überwachung der Funktionsleistung, zur Verwaltung von Berechtigungen und zur Kostenkontrolle auf Funktionsebene statt auf Serverebene.
- Workloads mit unvorhersehbarem oder sprunghaft schwankendem Datenverkehr werden kostengünstiger und ausfallsicherer. Stellen Sie sich zum Beispiel einen Batch-Job vor, der täglich zehn Minuten lang läuft, eine API, deren Auslastung bei einer Produkteinführung sprunghaft ansteigt, oder eine IoT-Pipeline, die nur dann aktiv wird, wenn ein Sensor ein Signal auslöst. Das sind die klassischen Fälle, in denen die Wirtschaftlichkeit des serverlosen Modells die eines dedizierten Servers übertrifft, der den Rest der Zeit im Leerlauf steht.
5 Herausforderungen, bei denen Serverless keine Abhilfe schafft
Ein serverloser Ansatz ist nicht immer die ideale Lösung.
- Kaltstarts gibt es tatsächlich, und sie werden nicht vollständig verschwinden. Wenn eine Funktion in letzter Zeit nicht ausgeführt wurde, muss die Plattform vor der Ausführung Ihres Codes eine neue Ausführungsumgebung initialisieren, was zu einer zusätzlichen Latenz führt. Für latenzempfindliche Anwendungen ist das ein Problem.
- Das Debuggen wird schwieriger, nicht einfacher. Bei einer monolithischen Anwendung tritt ein Fehler an einer Stelle auf, die Sie direkt überprüfen können. Eine serverlose Anwendung ist ein verteiltes System aus unabhängig voneinander ausgelösten Funktionen, was bedeutet, dass ein Fehler in einer Funktion, einem Trigger, einer Warteschlange oder im Zusammenspiel aller drei entstehen kann. Lokale Testumgebungen bilden das Triggerverhalten in der Produktion selten exakt nach.
- Lang andauernde oder stationäre Arbeitslasten werden teurer, nicht billiger. Die Preisgestaltung bei serverlosen Lösungen ist auf Spitzenauslastung und Leerlaufphasen optimiert. Eine Workload, die kontinuierlich mit hohem Durchsatz läuft, verursacht bei einem serverlosen Modell, bei dem pro Ausführung abgerechnet wird, oft höhere Kosten als bei einer reservierten, dedizierten Instanz. Passen Sie die Workload an das Preismodell an – nicht umgekehrt.
- Anbieterabhängigkeit. Funktionen werden unter Berücksichtigung der Laufzeitumgebung, des Triggermodells und der verwalteten Dienste eines bestimmten Anbieters geschrieben. Die Migration einer serverlosen Architektur zwischen AWS, Google Cloud und Azure bedeutet in der Regel, dass wesentliche Teile der Anwendung neu geschrieben werden müssen.
- Die Verantwortung für die Sicherheit verschwindet nicht, sie verlagert sich lediglich. Der Anbieter sorgt für die Sicherheit der zugrunde liegenden Infrastruktur. Sie sind weiterhin für die Berechtigungen auf Funktionsebene, die Verwaltung vertraulicher Daten und den Code selbst verantwortlich. Zu weit gefasste IAM-Rollen (Identity and Access Management) für einzelne Funktionen gehören zu den häufigsten Fehlkonfigurationen im Serverless-Bereich, die Sicherheitsteams bei Audits feststellen.
Die Umstellung auf eine serverlose Infrastruktur
Serverless Computing ist ein spezielles Modell, das sich für bestimmte Workload-Muster eignet: ereignisgesteuert, mit Spitzenlasten, lose gekoppelt und tolerant gegenüber Abweichungen beim Kaltstart im Bereich von einigen hundert Millisekunden.
Jedes Mal, wenn sich ein Unternehmen dazu entschließt, Serverless in großem Maßstab einzusetzen, entsteht zudem eine Vielzahl physischer Server, Racks vor Ort oder reservierter Cloud-Hardware, die für die jeweilige Arbeitslast nicht mehr benötigt wird.
Die Verlagerung von Workloads von dedizierter Infrastruktur auf ein serverloses Modell ist einer der häufigsten Auslöser für eine Hardware-Erneuerung oder die vollständige Stilllegung eines Rechenzentrums – und diese Hardware entsorgt sich nicht von selbst verantwortungsbewusst, nur weil die Workloads in die Cloud verlagert wurden.
Falls eine serverlose Migration, die auf Ihrer Roadmap vorgesehen ist, dazu führt, dass Serverracks, Festplatten oder die gesamte Fläche eines Rechenzentrums wegfallen, Die Dienstleistungen von exIT Technologies zur Stilllegung von Rechenzentren und zur Verwertung von IT-Anlagen den Teil der Migration übernehmen, der im Architekturdiagramm nicht dargestellt ist.