Was ist Serverless?
Serverless bezeichnet – wie der Name schon sagt – serverloses Computing. Sie fragen sich vielleicht, wie es möglich ist, ohne Server zu rechnen? In Wirklichkeit bedeutet Serverless nicht, dass es buchstäblich keine Server gibt. Stattdessen nutzt es Technologie, um das Konzept der Server von der Geschäftslogik zu abstrahieren, sodass Entwickler sich ausschließlich auf ihre Anwendungen konzentrieren können, ohne sich um die zugrunde liegende Infrastruktur kümmern zu müssen.
Wie funktioniert Serverless?
Seit dem Aufkommen von Serverless haben viele Entwickler es als eine neuartige Technologie wahrgenommen, was es aufgrund seiner Bequemlichkeit zweifellos ist. Es besteht jedoch kein Grund, es übermäßig zu verkomplizieren oder sich davon einschüchtern zu lassen. Die zugrundeliegende Logik der Ausführung von Anwendungen bleibt unverändert. Serverless verwendet lediglich technische Mittel, um uns vor den damit verbundenen Komplexitäten zu schützen – wie jede andere Cloud-Technologie auch.
Vor Serverless war das Bereitstellen einer Webanwendung ein umständlicher Prozess. Um unsere Anwendung auszuführen, mussten wir zunächst eine Laufzeitumgebung auf der Serverseite aufbauen. Das bedeutete, virtuelle Maschinen zu kaufen, deren Umgebungen zu initialisieren, erforderliche Abhängigkeiten zu installieren – und dabei eine möglichst große Übereinstimmung mit unserer lokalen Entwicklungsumgebung sicherzustellen. Als nächstes mussten wir, um die Anwendung für Benutzer zugänglich zu machen, eine Domain kaufen, sie mit der IP-Adresse der virtuellen Maschine registrieren, Nginx konfigurieren und starten und schließlich den Anwendungscode hochladen und starten.
Im krassen Gegensatz zum traditionellen Workflow erfordert die Serverless-Bereitstellung nur drei einfache Schritte und ist damit eine extreme Abstraktion der serverseitigen Vorgänge. Im Wesentlichen bleibt die gesamte Kette der Benutzer-HTTP-Datenanforderungen qualitativ unverändert; Serverless vereinfacht lediglich das Gesamtmodell.
Um dies zu verdeutlichen: Früher mussten wir eine Laufzeitumgebung auf der Serverseite aufbauen, während FaaS-Anwendungen diesen Schritt in Funktionsdienste abstrahieren. Früher brauchten wir Load Balancing und Reverse Proxys, aber FaaS-Anwendungen abstrahieren dies in HTTP-Funktionstrigger. Das Hochladen von Code und das Starten der Anwendung war früher notwendig, aber FaaS-Anwendungen abstrahieren dies in Funktionscode.
Wenn ein Benutzer zum ersten Mal auf einen HTTP-Funktionstrigger zugreift, hält der Trigger die HTTP-Anfrage des Benutzers fest und generiert ein HTTP-Request-Ereignis-Notification für den Funktionsdienst.
Der Funktionsdienst prüft dann auf freie Funktionsinstanzen. Wenn keine verfügbar sind, holt er Ihren Code aus dem Funktionscode-Repository, initialisiert und startet eine Funktionsinstanz, führt die Funktion aus, übergibt das HTTP-Request-Objekt als Parameter und führt die Funktion aus.
Darüber hinaus wird die HTTP-Response der Funktionsausführung an den Funktionstrigger zurückgegeben, der das Ergebnis dann an den wartenden Benutzer-Client weiterleitet.
Der bedeutendste Unterschied zwischen Serverless und PaaS-Plattformen zum Hosten von Anwendungen liegt in der Ressourcennutzung, was die bemerkenswerteste Neuerung von Serverless darstellt. Serverless-Anwendungsinstanzen können auf null herunterskalieren, während PaaS-Plattformen mindestens einen ständig laufenden Server oder Container benötigen.
Vor dem ersten Aufruf beträgt die tatsächliche Serverbelegung einer Funktion null. Erst wenn ein Benutzer eine HTTP-Datenanfrage stellt, wird der Funktionsdienst durch das HTTP-Ereignis ausgelöst und startet eine Funktionsinstanz. Das bedeutet, dass ohne Benutzeranfragen der Funktionsdienst keine laufenden Instanzen hat und keine Serverressourcen verbraucht. Im Gegensatz dazu dauert das Erstellen einer Anwendungsinstanz auf einer PaaS-Plattform normalerweise Dutzende von Sekunden, und um die Dienstverfügbarkeit zu gewährleisten, muss mindestens ein Server Ihre Anwendungsinstanz kontinuierlich ausführen.
Um einen Vergleich zu ziehen: Serverless ist wie ein sprachgesteuertes Licht, das schnell leuchtet, wenn jemand anwesend ist, und sich ausschaltet, wenn niemand da ist. Im Vergleich zu herkömmlichen manuell bedienten Lampen zeichnen sich sprachgesteuerte Lampen durch ihre Energieeffizienz aus. Diese energiesparende Fähigkeit hängt jedoch davon ab, dass das sprachgesteuerte Licht bei Bedarf schnell eingeschaltet werden kann.
Ähnlich liegt der Schlüssel zu den Vorteilen von Serverless in seiner schnellen Startzeit. Wie erreicht es das?
Warum kann Serverless so schnell starten?
Kaltstart (“Cold Start”) ist ursprünglich ein PC-Konzept und bezeichnet den Vorgang des erneuten Ladens der BIOS-Tabelle – im Wesentlichen das Booten von den Hardware-Treibern – nach einem Stromausfall, was zu langsamen Startzeiten führt.
In heutigen Cloud-Umgebungen ist das Aus- und Wiedereinschalten physischer Server fast unbekannt. Im Zusammenhang mit Serverless bezieht sich Kaltstart auf den gesamten Prozess vom Funktionsaufruf bis zur Bereitschaft der Funktionsinstanz. Unser Fokus liegt hier auf der Minimierung der Startzeit, da kürzere Startzeiten direkt zu einer höheren Ressourcennutzung führen. Aktuelle Cloud-Anbieter haben mit sprachspezifischen Optimierungen durchschnittliche Kaltstartzeiten zwischen 100 und 700 Millisekunden erreicht. Dank der Just-In-Time-Kompilierung von Google in seiner JavaScript-Engine hat Node.js die schnellsten Kaltstarts.
Es ist erwähnenswert, dass ein Serverless-Dienst von Grund auf starten, eine Funktion ausführen und den Vorgang innerhalb von 100 Millisekunden abschließen kann – ein Hauptgrund, warum Serverless getrost auf null herunterskalieren kann. Beim Öffnen einer Webseite gilt eine Antwortzeit von unter einer Sekunde im Allgemeinen als hervorragend. In diesem Zusammenhang hat eine Startzeit von 100 Millisekunden einen vernachlässigbaren Einfluss auf die Seitenladezeiten.
Darüber hinaus kann man davon ausgehen, dass Cloud-Anbieter ihre Infrastruktur weiter optimieren werden, um noch schnellere Startzeiten zu erreichen, was letztlich zu einer höheren Ressourcennutzung führt. Beispielsweise ist das Herunterladen von Funktionscode ein zeitaufwändiger Schritt während eines Kaltstarts. Daher initiieren Cloud-Anbieter bei Code-Updates oft proaktiv die Ressourcenplanung, um Container-Images für Ihre Funktionsinstanzen herunterzuladen und zu erstellen. Wenn die erste Anfrage eintrifft, können sie diese zwischengespeicherten Images nutzen, den Schritt des Code-Downloads eines Kaltstarts überspringen und den Container direkt aus dem Image starten. Diese Technik wird als Warmstart (“Warm Start”) bezeichnet. Daher können wir für latenzempfindliche Anwendungen Warmstarts oder Instanz-Vorwärmstrategien verwenden, um Kaltstartzeiten zu beschleunigen oder zu umgehen.
Wie ist Serverless geschichtet?
Wenn Ihre Serverless-Instanz ausgeführt wird, besteht sie aus mindestens drei Schichten: Container, Runtime und Funktionscode.
Stellen Sie sich den Container als Betriebssystem (OS) vor. Die Codeausführung erfordert die Interaktion mit der Hardware, und der Container simuliert den Kernel und die Hardware-Informationen, sodass Ihr Code und die Runtime darin funktionieren können. Zu den Containerinformationen gehören Speichergröße, OS-Version, CPU-Details, Umgebungsvariablen und mehr. Derzeit können FaaS-Implementierungen Docker-Container, virtuelle Maschinen (VMs) oder sogar Sandbox-Umgebungen verwenden.
Die Runtime repräsentiert den Kontext, in dem Ihre Funktion ausgeführt wird. Zu den Runtime-Informationen gehören die verwendete Programmiersprache und -version, z. B. Node.js v10 oder Python 3.6; aufrufbare Objekte wie das aliyun SDK; und Systeminformationen wie Umgebungsvariablen.
Was sind die Vorteile dieses geschichteten Ansatzes? Die Containerschicht bietet eine breitere Anwendbarkeit und ermöglicht es Cloud-Anbietern, zahlreiche Container-Instanzen vorzuwärmen und so physische Serverressourcen effektiv zu fragmentieren. Runtime-Instanzen mit geringerer Anwendbarkeit können in kleineren Zahlen vorgewärmt werden. Sobald Container und Runtime festgelegt sind, wird das Herunterladen und Ausführen des Codes unkompliziert. Diese geschichtete Architektur ermöglicht eine effiziente Ressourcenoptimierung und eine schnelle und kosteneffektive Ausführung Ihres Codes.
Zusammenfassung
- Die Aufrufkette einer reinen Serverless-Anwendung besteht aus drei Hauptkomponenten: Funktionstrigger, Funktionsdienste und Funktionscode. Diese ersetzen jeweils die traditionellen serverseitigen Vorgänge von Load Balancing & Reverse Proxys, Servern & Anwendungs-Laufzeitumgebungen und der Bereitstellung von Anwendungscode.
- Der bedeutendste Unterschied zwischen Serverless und traditionellen PaaS-Plattformen zum Hosten von Anwendungen liegt in der Fähigkeit von Serverless-Anwendungen, auf null herunterzuskalieren und bei Ereignisauslösung schnell zu starten. Node.js-Funktionen können beispielsweise einen Start und die Ausführung innerhalb von 100 Millisekunden erreichen.
- Serverless opfert durch sein Design die Benutzerkontrolle und den Anwendungsbereich, um das Code-Modell zu vereinfachen. Seine geschichtete Struktur verbessert zudem die Ressourcennutzung, was ein Hauptgrund für seine bemerkenswert kurzen Kaltstartzeiten ist.
Novita AI wird einen Serverless-Dienst für unsere Benutzer einführen. Treten Sie jetzt der Warteliste bei und starten Sie Ihr Geschäft mit Serverless Computing.
Novita AI ist die All-in-One-Cloud-Plattform, die Ihre KI-Ambitionen unterstützt. Integrierte APIs, Serverless, GPU-Instanz – die kosteneffektiven Tools, die Sie brauchen. Infrastruktur überflüssig, kostenlos starten und Ihre KI-Vision verwirklichen.
Empfohlene Lektüre
