Serverless ist Betrug: Nutzt einfach einen Container
(sliplane.io)- Serverless wirkt einfach, verursacht in der Praxis aber Komplexität, Einschränkungen und hohe Kosten
- Container bieten Portabilität, Zustandsbehaftung und klare Kontrolle und sind für die meisten Anwendungsfälle besser geeignet
- Bei Serverless ist die Kostenstruktur intransparent und unvorhersehbar und führt zwischen den Komponenten zu unnötiger Komplexität
- Die Skalierbarkeit und Einfachheit von Serverless eignen sich nur für begrenzte Anwendungsfälle
- In realen Betriebsumgebungen sind containerbasierte Deployments einfacher, skalierbarer und kosteneffizienter
Serverless Is a Scam. Just Use a Container.
Was ist Serverless?
- Bei Serverless wird Code als einzelne Funktionen deployt, während die Cloud-Plattform Ausführung und Skalierung automatisch übernimmt
- In der Praxis gibt es jedoch die folgenden Probleme
- Laufzeitbegrenzungen (z. B. hat AWS Lambda ein Limit von 15 Minuten)
- Kein zustandsbehafteter Betrieb (bei jeder Ausführung wird neu initialisiert)
- Cold-Start-Probleme
- Eine Umgebung, die sich praktisch nicht debuggen lässt
- Plattformspezifische Einstellungen und Konfigurationen
- Übermäßiger Einsatz von YAML
- Es wirkt simpel, ist für komplexe Aufgaben aber ungeeignet
Container: einfach, leistungsstark und im guten Sinne langweilig
- Container haben die folgenden Vorteile
- Schneller Start
- In jeder Umgebung ausführbar
- Zustandsbehaftung möglich (mit
Docker volume) - Keine Laufzeitbegrenzung
- Debugging, lokale Entwicklung und der Wechsel in Produktionsumgebungen sind problemlos möglich
- Beispielcode:
docker run -v my-data:/data my-app - Dadurch lassen sich zustandsbehaftete Workloads überall konsistent ausführen
- Keine Vendor-Lock-in, keine versteckten Kosten, keine unnötigen Architekturänderungen
Serverless-Preismodelle: auf Nutzerverwirrung ausgelegt
- Die Kosten für Serverless sind sehr komplex aufgebaut
- Kosten pro Aufruf
- Speichernutzung
- Ausführungszeit
- Übertragene Datenmenge
- Unterschiede je nach Region
- Kosten für den Zugriff auf Secrets usw.
- Beispiele für verwirrende Begriffe:
- Provisioned Concurrency Units
- GB-seconds
- Requests Tier 1/2/3
- Durch die unvorhersehbare Abrechnungsstruktur können unerwartete Rechnungen entstehen
- Zum Vergleich: Ein VPS für 5 US-Dollar bietet einen planbaren Pauschalpreis bei voller Kontrolle über alle Ressourcen
Gegenargument zu „Serverless ist skalierbar“
- Serverless ist technisch skalierbar, aber die meisten Apps brauchen das in der Praxis nicht
- Die meisten Anwendungen benötigen vor allem Folgendes
- Vorhersehbarkeit
- Beobachtbarkeit
- Angemessene Ressourcenlimits
- Entwicklungs- und Staging-Umgebungen
- Auch in einer containerbasierten Umgebung ist Skalierung einfach
replicas: 5 - Oder horizontale Skalierung per Load Balancer
Zustandsloses Design erzeugt künstliche Probleme
- Serverless erzwingt ausnahmslos zustandsloses Design
- Keine Caches, Sessions, temporären Dateien oder dauerhaften Verbindungen
- Dadurch werden am Ende folgende Komponenten nötig:
- Externe Datenbank
- Verteilter Cache
- Dateispeicher
- Event-Bus
- Zustandsmaschine
- So bekommt eine „einfache“ Serverless-App am Ende mehr als sechs SaaS-Abhängigkeiten
- In Containern ist dagegen Folgendes möglich
- In-Memory-Cache
- Schreibzugriffe auf Festplatte
- Session-Persistenz
- Unbegrenzte Laufzeit
Antwort auf „Ich will keine Server verwalten“
- Es gibt Möglichkeiten, containerbasierte Plattformen zu nutzen, ohne Server selbst zu verwalten
- Plattformen wie Sliplane, Railway oder Coolify nutzen
- Oder einfach auf einem VPS nur mit Docker + systemd arbeiten
- Git-basiertes Deployment, Rollbacks, Logging und Metriken sorgen für komfortablen Betrieb
- Gleichzeitig bleibt Verständnis und Kontrolle über das Gesamtsystem erhalten
Gegenargument zur Behauptung „Serverless ist günstiger“
- Bei extrem niedriger Aufruffrequenz kann es günstiger sein
- In den folgenden Fällen steigen die Kosten jedoch schnell
- Wenn der Traffic ein gewisses Niveau überschreitet
- Wenn mehr Speicher benötigt wird
- Wenn tatsächlich viel Rechenarbeit anfällt
- Wenn viel Datenübertragung stattfindet
- Bei Serverless ist Optimierung schwierig, weil die Plattform alles verbirgt
- Container dagegen
- können auch auf günstiger Hardware dauerhaft laufen
- lassen sich mit Cache und Storage kombinieren
- sind leicht zu benchmarken und zu tunen
- haben keine Abrechnung im Millisekunden-Takt
Wann Serverless tatsächlich geeignet ist
- Geeignet für die folgenden sporadischen und zustandslosen Aufgaben
- Ereignisgesteuerte Funktionen (z. B. Bildgrößenanpassung)
- Selten ausgeführte Jobs oder Webhooks
- Interne Tools
- POC
- Wenn schnelles Hoch- und Runterskalieren erforderlich ist
- Bei echten Anwendungen stößt man jedoch schnell an Grenzen,
- und zahlt einen hohen Preis in Form von Zeit, Kosten und Komplexität
Warum Container die bessere Wahl sind
- Container bieten
- Portabilität
- Kontrolle
- Einfachheit
- Transparenz
- Flexibilität
- Einzel- oder Multi-Container-Deployments, Skalierung, Zustandsbehaftung, Hintergrundjobs und DB-Anbindung sind alle möglich
- Auch ein Plattformwechsel ist möglich, ohne den Code neu schreiben zu müssen
Zusammenfassung (TL;DR)
- Serverless sieht in der Theorie cool aus
- In der Praxis ist es:
- intransparent
- teuer
- übermäßig komplex
- überhypt
Frage dich vor dem Start selbst:
„Kann ich das nicht einfach als Container bauen?“
- Wenn die Antwort „Ja“ lautet, ist es besser, mit einem Container zu starten
Empfohlene nächste Schritte
- Es wird empfohlen, Erfahrungen mit unerwarteten Kosten oder ineffizienten Workflows durch Serverless zu teilen
- Einfache Probleme sollten nicht unnötig verkompliziert werden
19 Kommentare
Es gibt xfaas ... und auch CF Workers. Wirkt wie ein einseitiger Artikel.
Ich hatte daran gedacht, beim Mieten einer GPU etwas kurzzeitig als serverlose Funktion auszuführen.
Würde das auch mit Containern gehen?
Bei früheren PHP-Webhosting-Diensten kann ich den Gedanken nicht abschütteln, dass sie schwer von typischen serverlosen FaaS-Plattformen zu unterscheiden wären, wenn man PHP herausnimmt und dafür jede Menge vendor-lock-in-lastiges JS einsetzt....
Ich kann den Gedanken nicht abschütteln, dass sie schwer von typischen serverlosen FaaS-Plattformen zu unterscheiden wären.
Natürlich nutze ich das als Drecks-Gourmet, der hauptsächlich PHP und JS/TS verwendet, durchaus zufriedenstellend,
a ber ich verstehe trotzdem nicht so recht, warum so viele Leute das für so toll halten.
Meiner persönlichen Meinung nach ist es riskant, den serverlosen Dienst eines Anbieters zu nutzen. Eine serverlose Umgebung unternehmensintern mit Containern bereitzustellen, scheint mir jedoch gut zu sein. Es wäre wohl sinnvoll, Serverless nicht als Service, sondern als ein Konzept zu nutzen.
Eine Zeit lang waren ein Tweet und ein Video darüber, dass Vercel das Edge Rendering aufgegeben hat[1], sowie ein Artikel über einen serverless server (lol)[2] ziemlich heiß diskutiert. Ich glaube, ich habe eine ähnliche Ansicht wie die Texte, die damals erschienen sind.
Das ist nur meine persönliche Meinung, aber aus Sicht eines Frontend-Entwicklers ist es meiner Meinung nach noch Zukunftsmusik, Serverless Functions direkt an Nutzeranfragen zu hängen (es sei denn, die Anwendung, die man bauen will, ist ein MVP).
[1] https://youtu.be/lAGE-k1Zfrg
[2] https://vercel.com/blog/…
[2-1] https://bobaekang.com/blog/…
Natürlich wirkt es, wie auch unter diesem Beitrag kommentiert wurde, so, als wäre es ein übertrieben provokativer Artikel :(
Aus der Perspektive von jemandem, der sowohl containerbasierte Umgebungen (vor allem ECS Fargate, Kubernetes-Cluster) als auch serverlose Umgebungen (AWS) erlebt hat, kommt das bei mir nicht besonders stark an.
Die Punkte, die als Vorteile einer containerbasierten Umgebung aufgezählt wurden, sind zugleich auch Bereiche, die zu Nachteilen werden können.
Alles, was mit „man kann es direkt kontrollieren und es kann zustandsbehaftet sein“ erwähnt wurde, wird letztlich zu einem zusätzlichen Managementpunkt, der den Betriebsaufwand erhöht.
Ich würde Serverless gerade kleinen Organisationen oder Organisationen ohne spezialisiertes Server-Management-Team nachdrücklich empfehlen.
Ach ja, dass die Kostenberechnung komplex oder schwer vorhersehbar ist, und auch das Vendor-Lock-in-Problem — dem stimme ich zu.
Da hier jemand Entwicklungserfahrung und Observability angesprochen hat, möchte ich noch etwas ergänzen:
Wenn man die anfängliche Integrationsumgebung gut aufsetzt, kann man eine Entwicklungserfahrung erreichen, die einer containerbasierten in nichts nachsteht — vielleicht sogar nativer ist als eine containerbasierte. (Dafür gibt es verschiedene Tools.)
Und was Observability angeht: Wenn man wirklich tief einsteigen will, ist das weder bei Serverless noch bei containerbasierten Ansätzen gleichermaßen ein einfaches Problem. Zentrale Log-Sammlung, Visualisierung verschiedenster Metriken, APM, Visualisierung der CPU-/Speicherauslastung und darauf aufbauend die Entwicklung einer Skalierungsstrategie usw. ...
Wenn man noch nicht auf diesem Niveau ist, sind die von Cloud-Anbietern standardmäßig bereitgestellten integrierten Metriken und Logs so leistungsfähig, dass es letztlich auf dasselbe hinausläuft.
Etwas provokant formuliert würde ich gern fragen: „Wie weit habt ihr Serverless eigentlich schon wirklich richtig ausprobiert?“ 😅
Ich frage mich allerdings auch, ob es nicht besser wäre, nur einige wirklich benötigte Endpunkte auf Lambda laufen zu lassen. Von Haus aus habe ich selbst keine Erfahrung mit serverloser Entwicklung, daher kann ich dazu nicht viel sagen, aber für einige spezielle Fälle scheint es doch ganz gut geeignet zu sein.
Ist der Artikel nicht vielleicht aus einer voreingenommenen Perspektive geschrieben, weil das Unternehmen, das ihn verfasst hat, eine Plattform für Container-Hosting betreibt? haha
Früher gab es schon jemanden, der den Beitrag eines Netlify-Entwicklers (Konkurrent) mit Bedenken zu Next.js (Vercel) aus dem Frontend-Bereich angezweifelt hat. Wenn man sich die Kommentare ansieht, wirkt es aber nicht voreingenommen.
Ich komme eher aus dem Frontend-Bereich ... mit diesem Bereich bin ich also nicht besonders vertraut, aber das Meme „serverless (es gibt sehr wohl Server)“ scheint mir ziemlich verbreitet zu sein, haha.
Der größte Pain Point ist, dass die Developer Experience im Vergleich zu nativen Umgebungen deutlich schlechter ist, und weil die Software selbst von der Infrastruktur des Anbieters abhängig wird, ist ein Ausstieg schwierig, sobald man sich einmal festgelegt hat. Ganz abgesehen davon, dass es deutlich weniger Referenzen gibt, ist auch die Observability viel zu schwach.
Cloudflare scheint im Vergleich zu anderen Unternehmen zumindest zu versuchen, Serverless ordentlich umzusetzen. Auch Datenbanken sind serverless, Key-Value-Storage ist serverless, sogar Message Queues gibt es serverless ...
(Natürlich fühlt es sich dadurch auch so an, als würde man sich vollständig an die Plattform binden und von ihr abhängig machen, was wiederum Ablehnung auslösen kann.)
Trotzdem wird es weiterhin ein Treten auf der Stelle bleiben, wenn sich Debugging, Observability und Developer Experience nicht verbessern.
Cloud Run los.
Serverless für einen Servicebetrieb zu nutzen, bedeutet, das falsche Werkzeug zu wählen.
Es gibt bestimmte Probleme, für die Serverless nötig ist. Für Anwendungsfälle mit sporadischer Nutzung ist es geeignet.
Gilt dieselbe Meinung auch für serverlose Container-Dienste?
Wegen der Probleme bestehender serverloser Dienste (wie Lambda) hat AWS Fargate entwickelt und mit App Runner sogar noch etwas Einfacheres geschaffen 🤔
Es gibt sogar mit Cloud Run von Google Cloud einen großartigen serverlosen Container-Dienst mit Scale-to-Zero.
Von diesen fand ich persönlich, dass Cloud Run die beste Developer Experience geboten hat.
Serverless (es gibt Server)
Hacker-News-Meinungen
Von Anfang an war es nicht Serverless, sondern Serverlease.
Hahaha