Obwohl sowohl PaaS als auch Serverless-Computing keine Backend-Verwaltung seitens des Entwicklers erfordern, unterscheiden sich die beiden Modelle durch mehrere Faktoren – darunter Skalierbarkeit, Preisgestaltung und die Fähigkeit, Anwendungen am Netzwerkrand bereitzustellen.
Nach Lektüre dieses Artikels können Sie Folgendes:
Link zum Artikel kopieren
Da die Backend-Architekturen sowohl bei Serverless-Computing als auch bei Platform-as-a-Service (PaaS) das gesamte Backend für Entwickler unsichtbar halten, sind sie sich in gewisser Weise ähnlich. Es gibt jedoch einige große Unterschiede zwischen diesen beiden Arten von Architekturen, und die meisten Anwendungsfälle funktionieren am besten entweder mit der einen oder der anderen Architektur, nicht aber mit beiden. Die Hauptunterschiede zwischen PaaS und Serverless-Computing liegen in der Skalierbarkeit, der Preisgestaltung, der Startzeit, der Tool-Ausstattung und der Fähigkeit, Anwendungen am Netzwerkrand bereitzustellen.
Serverless-Anwendungen passen sich sofort, automatisch und nach Bedarf an, ohne dass vom Entwickler oder Anbieter weitere Konfigurationen vorgenommen werden müssen. Sie können per Definition hochskaliert werden. Im Unterschied dazu können Entwickler PaaS-gehostete Anwendungen zwar so programmieren, dass sie abhängig von der Benutzernachfrage hoch- und herunterskaliert werden können. Dabei handelt es sich jedoch nicht um ein inhärentes Merkmal von PaaS, und Entwickler müssen einen gewissen Umfang an Vorhersagen durchführen, um eine korrekte Skalierung zu erreichen.
Serverless-Computing kann mit dem Abzapfen von Wasser aus einem Wasserhahn verglichen werden, wobei das Wasser die Rechenleistung darstellt. Ein Wasserhahn in einem modernen Haus kann jederzeit aufgedreht werden und so viel Wasser abgeben, wie nötig ist. PaaS gleicht eher einem Wasserspender und einem Wasserflaschen-Lieferdienst. Es ist immer noch möglich, so viel Trinkwasser zu erhalten, wie benötigt wird, aber es ist nicht so einfach, wie den Wasserhahn aufzudrehen. Der Verbraucher muss den Anbieter bitten, mehr zu liefern, wenn die Nachfrage steigt. In beiden Szenarien kümmert sich jemand anderes um die Versorgung – Reinigung des Wassers, Lieferung in das Gebäude usw. –, aber nur Leitungswasser kann präzise, bedarfsgerecht und in Echtzeit mengenmäßig angepasst – d. h. „skaliert“ – werden.
Bei einer Serverless-Architektur ist eine schnelle Hochskalierung möglich, indem neue Instanzen von Anwendungsfunktionen erstellt werden, sobald sie angefordert werden. Eine Herunterskalierung ist ebenfalls möglich, indem Funktionen abgeschaltet werden, wenn sie nicht mehr benötigt werden oder wenn sie eine festgelegte Zeit lang gelaufen sind. Tatsächlich kann die Aktivität bei einer Serverless-Webanwendung bis auf Null herunterskaliert werden und dann als Reaktion auf ein Ereignis innerhalb von Sekunden oder Millisekunden wieder neu starten. Anwendungen, die auf PaaS aufgebaut sind, können nicht so schnell oder in einem solchen Ausmaß hoch- oder herunterskaliert werden.
Um die Wasseranalogie fortzusetzen: Verbraucher, die Wasser aus dem Wasserhahn beziehen, zahlen für genau so viel Wasser, wie sie verbrauchen. Ebenso ist die Abrechnung bei Serverless-Computing äußerst präzise, und Entwickler zahlen nur für das, was sie benutzen. Einige Serverless-Computing-Anbieter berechnen den Entwicklern nur die genaue Zeit, die ihre Funktionen laufen – bis auf Sekundenbruchteile für jede einzelne Instanz jeder Funktion. Andere Anbieter berechnen die Anzahl der Anfragen.
Verbraucher, die einen Wasserspender benutzen und sich Wasser in Flaschen liefern lassen, zahlen ebenfalls nur für das, was sie verbrauchen, aber sie zahlen pro Flasche und nicht pro Milliliter. Ebenso berechnen einige PaaS-Anbieter Entwicklern nur das, was ihre Anwendungen nutzen. Die Rechnungsstellung ist jedoch nicht annähernd so präzise wie bei Serverless-Computing. Andere PaaS-Anbieter erheben eine monatliche Pauschalgebühr für ihre Dienste. Entwickler können in der Regel wählen, für wie viel Rechenleistung sie bezahlen. Das wird jedoch im Voraus beschlossen, ohne dass auf Zu- und Abnahmen der Nutzung in Echtzeit reagiert werden kann.
Dieser Unterschied bedeutet nicht unbedingt, dass eine Serverless-Architektur immer erschwinglicher ist. Genauso wie es schnell unerschwinglich teuer wird, einen Wasserhahn ständig laufen zu lassen, kann der Betrieb von Webanwendungen, die einen großen, konstanten Nutzungsstrom haben, der nicht stark schwankt, mit Serverless-Computing teuer werden.
Wie oben beschrieben, können Serverless-Anwendungen fast augenblicklich aktiv werden, sobald ein Ereignis eine Anwendungsfunktion auslöst. PaaS-Anwendungen können schnell einsatzbereit sein, aber sie sind nicht so ressourceneffizient wie Serverless-Anwendungen und brauchen länger, bis sie einsatzbereit sind. Um Latenz aus Sicht des Benutzers zu vermeiden, müssen zumindest einige Funktionen von PaaS-Anwendungen die meiste Zeit oder die ganze Zeit laufen.
Im Allgemeinen stellen PaaS-Anbieter den Entwicklern mehr Tools zur Erstellung und Verwaltung ihrer Anwendungen zur Verfügung, einschließlich Tools zum Testen und Debuggen. Da Serverless-Anwendungen nicht auf bestimmten Maschinen laufen, weder virtuell noch anderweitig, und Serverless-Funktionen auf allen Systemen gleich ausgeführt werden sollten, bieten Anbieter von Serverless-Anwendungen zwar einige Tools an, aber keine vollständige Umgebung für Erstellung und Test der Anwendung.
Serverless-Code läuft nicht auf bestimmten Servern und kann überall in jedem Teil des Internets ausgeführt werden, wodurch es möglich wird, Serverless-Anwendungen sehr nahe am Endbenutzer am Netzwerkrand bereitzustellen und so die Latenz erheblich zu reduzieren. Service Workers und Cloudflare Workers sind Beispiele für Serverless-Funktionen, die in der Nähe des Benutzers ausgeführt werden (siehe Wie funktioniert Serverless-JavaScript?).
Aus der Sicht des Entwicklers gibt es keine Server bei PaaS. Allerdings unterscheidet sich PaaS hinsichtlich des Orts, an dem der Code gehostet wird, immer noch von Serverless-Computing. PaaS-Anbieter nutzen entweder das IaaS-Angebot (Infrastructure-as-a-Service) eines anderen Anbieters oder haben ihre eigenen physischen Rechenzentren. Das Ergebnis ist, dass Anwendungen, die auf einer Cloud-Plattform erstellt wurden, wahrscheinlich nur auf bestimmten, dafür vorgesehenen Rechnern ausgeführt werden. Das hindert Entwickler daran, die Performance ihrer Anwendung durch die Ausführung von Code an der Netzwerk-Edge zu optimieren.