Serverless vs. Persistente Server
Leapcell bietet zwei primäre Bereitstellungsmodi, um unterschiedlichen Anwendungsanforderungen gerecht zu werden: Serverless (Pay-as-you-go) und Persistent (Charge-by-time).
Auf Leapcell kann Ihr Dienst jederzeit zwischen den Modi Serverless und Persistenter Server wechseln. Sie können den Modus wählen, der am besten zu Ihrem spezifischen Anwendungsfall passt.
Das Verständnis ihrer unterschiedlichen Funktionen und Kompromisse wird Ihnen helfen, die am besten geeignete Option für Ihr Projekt auszuwählen.
Serverless (Pay-as-you-go)
Der Serverless-Modus ist ein ereignisgesteuertes Rechenmodell, bei dem Sie nur für die Zeit bezahlen, in der Ihr Code aktiv ausgeführt wird.
Die Abrechnung beginnt, wenn eine Anfrage empfangen wird, und endet, sobald die Anfrage vollständig verarbeitet wurde. Für die Leerlaufzeit, in der Ihre Anwendung keinen Datenverkehr bedient, fallen keine Kosten an.
Automatische Skalierung
Die Plattform skaliert die Anzahl der Instanzen automatisch nach oben oder unten, basierend auf dem Datenverkehrsvolumen.
Sie kann auf Tausende von Instanzen skaliert werden, um Verkehrsspitzen mühelos zu bewältigen.
Kaltstarts
Wenn Ihr Dienst für einen bestimmten Zeitraum keinen Datenverkehr empfängt (z. B. 30 Minuten), können seine Instanzen in den Ruhezustand wechseln. Eine neue eingehende Anfrage löst einen „Kaltstart“ aus, um eine neue Instanz bereitzustellen, was eine Latenz von bis zu 250 ms verursachen kann. Dienste mit konstantem Datenverkehr treten selten auf.
Serverless-Vorteile und -Einschränkungen
Wesentliche Vorteile
| Vorteil | Beschreibung |
|---|---|
| Kostengünstig | Eliminiert Gebühren für ungenutzte Ressourcen und ist somit ideal für Anwendungen mit variablen oder unvorhersehbaren Datenverkehrsmustern. |
| Automatische Skalierung | Die Plattform skaliert die Anzahl der Instanzen automatisch nach oben oder unten, basierend auf dem Datenverkehrsvolumen. Sie kann auf Tausende von Instanzen skaliert werden, um Verkehrsspitzen mühelos zu bewältigen. |
Zu beachtende Einschränkungen
| Einschränkung | Beschreibung |
|---|---|
| Nur kurzlebige HTTP-Anfragen | Das Serverless-Modell ist für kurzlebige HTTP-Anfragen optimiert. Es ist nicht geeignet für lang andauernde Verbindungen wie WebSockets, Long-Polling oder Hintergrundaufträge. |
| Temporäres Dateisystem | Nur das /tmp-Verzeichnis ist beschreibbar. Alle anderen Pfade im Dateisystem sind schreibgeschützt. |
| Anfrage-Timeout | Die maximale Ausführungszeit für eine einzelne Anfrage beträgt 15 Minuten. |
| CPU-Aussetzung | Während Leerlaufzeiten wird die CPU der Instanz ausgesetzt. Dies bedeutet, dass sie keine Hintergrundaufgaben ausführen kann, wenn keine eingehenden Anfragen vorhanden sind. |
Persistenter Modus (Charge-by-time)
Der persistente Modus bietet Ihnen eine dedizierte, kontinuierlich laufende Instanz, ähnlich wie eine lokale Maschine oder ein traditioneller Cloud-Server.
Sie bleibt aktiv und bereit, jederzeit Datenverkehr zu bedienen, unabhängig vom eingehenden Anfragevolumen. Dieser Modus wird auf Basis eines festen Zeitintervalls abgerechnet, z. B. pro Stunde oder pro Monat.
Wesentliche Vorteile:
| Funktion | Beschreibung |
|---|---|
| Günstiger pro Zeiteinheit | Das Festpreismodell kann für Anwendungen mit gleichmäßiger Auslastung kostengünstiger sein. Weitere Informationen finden Sie unter Leapcell Pricing. |
| Keine Kaltstarts | Die Instanz ist immer aktiv und gewährleistet die geringstmögliche Latenz für jede Anfrage. |
| Dateisystem | Bietet ein beschreibbares Dateisystem über das /tmp-Verzeichnis hinaus, das lokale Datei-E/A, Caching und Statusverwaltung ermöglicht. |
| Lang andauernde Aufgaben | Ideal für Prozesse, die über längere Zeiträume ohne Unterbrechung ausgeführt werden müssen, z. B. Hintergrundaufträge, Datenverarbeitung oder die Aufrechterhaltung persistenter Verbindungen (z. B. WebSockets). |
Serverless oder Persistent für meinen Anwendungsfall?
Für die meisten Anwendungsfälle empfehlen wir aufgrund der ausgezeichneten Flexibilität und Kosteneffizienz mit dem Serverless-Modus zu beginnen.
Wann sollte Serverless verwendet werden
| Wann sollte Serverless verwendet werden | Beschreibung |
|---|---|
| Jeder zustandslose HTTP- oder Webdienst | Der Status Ihrer Anwendung sollte in einem Objektspeicher oder einer Datenbank gespeichert werden, nicht im Dienst selbst. |
| Dienste mit unvorhersehbarem Datenverkehr in der frühen Phase | In der frühen Phase, wenn der Datenverkehr gering oder ungewiss ist, ist das Serverless-Modell die kostengünstigste Wahl. |
Wann sollten persistente Server verwendet werden
Der Persistente-Modus ist in den folgenden Szenarien die bessere Wahl:
| Wann sollten persistente Server verwendet werden | Beschreibung |
|---|---|
| Hoher und anhaltender Datenverkehr | Wenn Ihr Dienst kontinuierlich hohen Datenverkehr verarbeitet, können die Kosten pro Stunde einer persistenten Instanz geringer sein als die kumulativen Kosten für häufige Serverless-Aufrufe. |
| Lang andauernde Hintergrundaufträge | Für Aufgaben, die die 15-Minuten-Grenze überschreiten, wie z. B. Videokodierung, komplexe Datenanalyse oder das Trainieren von Modellen für maschinelles Lernen. |
| Abhängigkeit vom lokalen Dateisystem | Wenn Ihre Anwendung persistenten lokalen Speicher über /tmp hinaus benötigt, z. B. für Caching oder Statusverwaltung. |
| Anforderungen an extrem niedrige Latenz | Ideal für Anwendungen, bei denen selbst minimale Latenz durch gelegentliche Kaltstarts inakzeptabel ist. |
| WebSockets oder langlebige Verbindungen | Wenn Ihr Dienst WebSockets oder andere langlebige Verbindungen benötigt, müssen Sie persistente Server verwenden. |