Serverless Computing bietet Webentwicklern eine Reihe von Vorteilen wie Skalierbarkeit, schnellere Markteinführung und geringere Kosten. In einigen Fällen können andere Bedenken diese Vorteile aufwiegen.
Nach Lektüre dieses Artikels können Sie Folgendes:
Ähnliche Inhalte
Was ist Serverless?
Serverless gegenüber Containern
Serverless und JavaScript
Edge-Computing
Function as a Service (FaaS)
Abonnieren Sie theNET, Cloudflares monatliche Zusammenfassung der beliebtesten Einblicke in das Internet!
Link zum Artikel kopieren
Serverless Computing bietet eine Reihe von Vorteilen gegenüber herkömmlichen Cloud-basierten oder serverzentrierten Infrastrukturen. Vielen Entwicklern bieten Serverless-Architekturen eine größere Skalierbarkeit, mehr Flexibilität und schnellere Releases zu reduzierten Kosten. Mit Serverless-Architekturen müssen sich Entwickler nicht um den Kauf, die Bereitstellung und die Verwaltung von Backend-Servern kümmern. Trotzdem ist Serverless Computing kein Wundermittel für alle Entwickler von Webanwendungen.
Serverless Computing ist eine Architektur, in der ein Anbieter Backend-Dienste nach Bedarf bereitstellt. Weitere Informationen zu Serverless Computing finden Sie unter Was ist Serverless Computing?
Obwohl Computing „ohne Server“ tatsächlich auf Servern stattfindet, müssen sich Entwickler nie mit den Servern befassen. Sie werden vom Anbieter verwaltet. Das kann die notwendigen Investitionen für DevOps reduzieren, was die Kosten senkt. Es gibt Entwicklern auch die Möglichkeit, ihre Anwendungen zu erstellen und zu erweitern, ohne dass die Serverkapazität sie eingeschränkt.
Wie bei einem "Pay-as-you-go"-Telefontarif wird Entwicklern nur das berechnet, was sie nutzen. Code wird nur ausgeführt, wenn die Serverless-Anwendung Backend-Funktionen benötigt. Der Code wird bei Bedarf automatisch skaliert. Die Bereitstellung erfolgt dynamisch, präzise und in Echtzeit. Einige Dienste sind so exakt, dass sie ihre Gebühren in Schritten von 100 Millisekunden ermitteln. Im Gegensatz dazu müssen Entwickler in einer herkömmlichen Architektur „mit Server“ im Voraus planen, wie viel Serverkapazität sie benötigen, und diese Kapazität dann erwerben, unabhängig davon, ob sie sie letztendlich nutzen oder nicht.
Stellen Sie sich vor, die Post könnte Zustellfahrzeuge auf wundersame Weise nach Belieben hinzufügen und außer Betrieb setzen, indem sie die Flotte entsprechend der Spitzen bei den Sendungen (z. B. kurz vor dem Muttertag) vergrößert und die Flotte in den Zeiten wieder verkleinert, in denen weniger Zustellungen erfolgen. Dies ist im Prinzip das, was Serverless-Anwendungen können.
Anwendungen, die mit einer Serverless-Infrastruktur erstellt wurden, skalieren automatisch, wenn die Benutzerbasis wächst oder die Nutzung zunimmt. Wenn eine Funktion in mehreren Instanzen ausgeführt werden muss, fahren die Server des Anbieters nach Bedarf hoch, laufen und fahren wieder herunter. Dabei werden häufig Container verwendet (die Funktionen starten schneller, wenn sie erst kürzlich ausgeführt wurden – siehe weiter unten „Performance kann betroffen sein“). Infolgedessen kann eine Serverless-Anwendung eine ungewöhnlich hohe Anzahl von Anfragen genauso gut verarbeiten wie eine einzige Anfrage eines einzelnen Benutzers. Eine herkömmlich strukturierte Anwendung mit festgelegtem Serverplatz kann von einem plötzlichen Anstieg der Nutzung überfordert sein.
Bei der Nutzung einer Serverless-Infrastruktur ist es nicht erforderlich, Code auf Server hochzuladen oder Backend-Konfigurationen vorzunehmen, um eine funktionierende Version einer Anwendung herauszubringen. Entwickler können sehr schnell Codeteile hochladen und ein neues Produkt veröffentlichen. Sie können Code auf einmal oder jeweils nur eine Funktion hochladen, da die Anwendung kein einzelner monolithischer Stack ist, sondern eine Ansammlung von Funktionen, die der Anbieter bereitgestellt.
Das ermöglicht auch das schnelle Aktualisieren, Patchen, Korrigieren oder Hinzufügen neuer Funktionen zu einer Anwendung. Es ist nicht erforderlich, Änderungen an der gesamten Anwendung vorzunehmen. Stattdessen können Entwickler die Funktionen einer Anwendung einzeln aktualisieren.
Da die Anwendung nicht auf einem Ursprungsserver gehostet ist, kann ihr Code von überall ausgeführt werden. Daher ist es in Abhängigkeit vom Anbieter möglich, Anwendungsfunktionen auf Servern auszuführen, die sich in der Nähe des Endbenutzers befinden. Das verkürzt die Latenz, da Anfragen des Benutzers nicht mehr bis zu einem Ursprungsserver gesendet werden müssen. Cloudflare Workers ermöglicht diese Art der Reduzierung der Serverless-Latenz.
Es ist schwierig, die Umgebung ohne Server zu replizieren, um zu sehen, wie sich Code nach der Bereitstellung tatsächlich verhält. Das Debuggen ist komplizierter, da Entwickler keinen Einblick in Backend-Prozesse haben und die Anwendung in separate, kleinere Funktionen unterteilt ist. Der Cloudflare Workers Playground ist eine Sandbox, die Reibungsverluste beim Testen und Debuggen verringert
Wenn Anbieter das gesamte Backend ausführen, ist es gegebenenfalls nicht möglich, die Sicherheit allumfassend zu überprüfen. Das kann insbesondere bei Anwendungen ein Problem sein, die mit persönlichen oder sensiblen Daten umgehen.
Da Unternehmen keine eigenen diskreten physischen Server zugewiesen bekommen, führen Serverless-Anbieter häufig Code von mehreren ihrer Kunden zu einem bestimmten Zeitpunkt auf einem Server aus. Dieses Problem der gemeinsamen Nutzung von Maschinen mit anderen Parteien wird als „Mehrmandantenfähigkeit“ bezeichnet. Stellen Sie sich mehrere Unternehmen vor, die gleichzeitig versuchen, ein einziges Büro zu mieten und dort zu arbeiten. Die Mehrmandantenfähigkeit kann die Performance der Anwendung beeinträchtigen und, wenn die Server mit mehreren Mandanten nicht entsprechend konfiguriert sind, zum Verlust der Vertraulichkeit von Daten führen. Mehrmandantenfähigkeit hat nur geringe bis keine Auswirkungen auf Netzwerke, in denen die Sandbox richtig funktioniert und die Infrastruktur leistungsfähig genug ist. Zum Beispiel betreibt Cloudflare ein Netzwerk mit 15 Tbit/s und genügend überschüssiger Kapazität, um die Verschlechterung des Dienstes zu verhindern. Alle von Cloudflare gehosteten Serverless-Funktionen werden in ihrer eigenen Sandbox ausgeführt (über die Chrome V8 Engine).
Das schränkt die Art der Anwendungen ein, die in einer Serverless-Architektur kostengünstig ausgeführt werden können. Da Serverless-Provider die Zeit in Rechnung stellen, in der Code ausgeführt wird, kann es teurer sein, eine Anwendung mit lang andauernden Prozessen in einer Serverless-Infrastruktur auszuführen als in einer herkömmlichen.
Da er nicht ständig ausgeführt wird, muss Serverless-Code gegebenenfalls zur Verwendung hochgefahren werden. Diese Startzeit kann die Performance beeinträchtigen. Wenn ein Code regelmäßig verwendet wird, hält der Serverless-Anbieter ihn zur Aktivierung bereit. Eine Anfrage für diesen einsatzbereiten Code wird als „Warmstart“ bezeichnet. Eine Anfrage für Code, der seit einiger Zeit nicht mehr verwendet wurde, heißt „Kaltstart“.
Cloudflare Workers vermeidet das Problem des Kaltstarts mithilfe der Chrome V8 Engine weitgehend. Sie kann JavaScript-Code in den meisten Fällen in weniger als 5 Millisekunden starten und ausführen. Wenn der Code bereits ausgeführt wird, liegt die Reaktionszeit unter einer Millisekunde. Erfahren Sie mehr über die Performance der verschiedenen serverlosen Plattformen.
Zuzulassen, dass ein Anbieter alle Backend-Dienste für eine Anwendung bereitstellt, erhöht zwangsläufig die Abhängigkeit von diesem Anbieter. Das Einrichten einer Serverless-Architektur bei einem Anbieter kann es schwierig machen, bei Bedarf den Anbieter zu wechseln, zumal jeder Anbieter ein wenig unterschiedliche Funktionen und Workflows anbietet. (Cloudflare Workers können einfacher migriert werden, da sie in JavaScript geschrieben und gegen die weit verbreitete API von Service Workers geschrieben sind.)
Entwickler, die ihre Markteinführungszeit verkürzen und ressourceneffiziente, flexible Anwendungen erstellen wollen, die schnell erweitert oder aktualisiert werden können, können sehr vom Serverless Computing profitieren.
Serverless-Architekturen senken die Kosten für Anwendungen mit inkonsistenter Nutzung, wobei sich Spitzenzeiten mit Zeiten mit wenig bis gar keinem Traffic abwechseln. Für solche Anwendungen kann der Kauf eines Servers oder eines Serverblocks, der kontinuierlich läuft und ständig bereit ist, auch wenn er nicht genutzt wird, eine Verschwendung von Ressourcen darstellen. Ein Serverless-Setup reagiert bei Bedarf sofort und verursacht im Ruhezustand keine Kosten.
Auch Entwickler, die einige ihrer Anwendungsfunktionen mit dem Ziel geringerer Latenz in die Nähe der Endbenutzer bringen wollen, benötigen zumindest eine teilweise Serverless-Architektur, da hierfür einige Prozesse vom Ursprungsserver verschoben werden müssen.
Es gibt Fälle, in denen es sowohl aus Kostengründen als auch aus Sicht der Systemarchitektur sinnvoller ist, dedizierte Server zu verwenden, die entweder selbst verwaltet oder als Dienst angeboten werden. Beispielsweise erfordern große Anwendungen mit einigermaßen konstanter, vorhersehbarer Auslastung gegebenenfalls ein herkömmliches Setup, das wahrscheinlich auch kostengünstiger ist.
Darüber hinaus kann es schlicht zu schwierig sein, ältere Anwendungen auf eine neue Infrastruktur mit völlig anderer Architektur zu migrieren.
Cloudflare Workers ist ein Produkt, mit dem Entwickler JavaScript-Funktionen schreiben und am Rand des Cloudflare-Netzwerks bereitstellen können. So kann Anwendungscode in einer Serverless-Architektur so nah wie möglich am Endbenutzer ausgeführt werden, was die Latenz minimiert.