Warum Serverless Computing einsetzen?
Serverless Computing bietet eine Reihe von Vorteilen gegenüber herkömmlichen cloudbasierten oder serverzentrierten Infrastrukturen. Für viele Entwickler bieten Serverless-Architekturen größere Skalierbarkeit, mehr Flexibilität und schnellere Release-Erstellung, alles zu reduzierten Kosten. Mit serverlosen Architekturen müssen sich Entwickler keine Gedanken über den Kauf, die Bereitstellung und die Verwaltung von Backend-Servern machen. Trotzdem ist Serverless Computing kein Wundermittel für alle Entwickler von Webanwendungen.
Wie funktioniert Serverless Computing?
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?
Was sind die Vorteile von Serverless Computing?
Kein Servermanagement erforderlich
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.
Entwicklern wird nur der von ihnen genutzte Serverplatz in Rechnung gestellt, was die Kosten senkt
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.
Serverlose Architekturen sind von Natur aus skalierbar
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.
Schnelle Bereitstellungen und Updates sind möglich
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.
Code kann näher am Endbenutzer ausgeführt werden, was die Latenz verkürzt
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.
Was sind die Nachteile des Serverless Computings?
Testen und Debuggen werden schwieriger
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
Serverless Computing bringt neue Sicherheitsbedenken mit sich
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).
Serverless-Architekturen sind nicht für lange dauernde Prozesse gedacht
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.
Die Performance kann beeinträchtigt sein
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.
Anbieter-Lock-in ist ein Risiko
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.)
Wer sollte eine Serverless-Architektur nutzen?
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.
Wann sollten Entwickler die Nutzung von Serverless-Architektur vermeiden?
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.
Wie hilft Cloudflare Entwicklern beim Aufbau von Serverless-Architekturen?
Cloudflare Workers ist ein Produkt, mit dem Entwickler JavaScript-Funktionen schreiben und am Rand des Cloudflare-Netzwerks bereitstellen können. Dies ermöglicht die Ausführung von Anwendungscode in einer serverlosen Architektur so nah wie möglich am Endbenutzer, wodurch die Latenz minimiert und der Grundsatz „Das Netzwerk ist der Computer®“ (The Network is the Computer®) verkörpert wird.