Gruselgeschichten aus der Serverless-Welt

• Bei verschiedenen SaaS- und Serverless-Diensten kommt es immer wieder zu Fällen von unerwartet hohen Rechnungen; diese Seite fasst sie übersichtlich zusammen
• Es wurden Fälle bekannt, in denen Nutzern, die regulär ihre monatliche Abogebühr zahlten, durch DoS-Angriffe oder unkontrollierten Ressourcenverbrauch innerhalb eines einzigen Tages Kosten von Zehntausenden bis Hunderttausenden Dollar berechnet wurden
• Bei einigen Diensten wurden sogar dann zusätzliche Gebühren erhoben, obwohl Ausgabenlimits festgelegt waren, was die systemischen Grenzen deutlich macht
• In der Entwickler-Community werden solche Erfahrungen geteilt; als zentrale Probleme gelten unvernünftige Abrechnungsstrukturen und mangelnde Transparenz
• In Serverless- und Cloud-Umgebungen kann bereits ein kleiner Fehler oder ein einzelner Angriff zu enormen finanziellen Verlusten führen, was die Notwendigkeit zur Vorsicht unterstreicht

---

Sammlung überhöhter Abrechnungsfälle bei Serverless- und SaaS-Diensten

#1 Hohe Rechnung bei Webflow

• Während der Nutzung eines Tarifs für 69 Dollar pro Monat wurden ohne ersichtlichen Grund 1.189,42 $ für einen Monat berechnet

#2 DoS-Angriff auf eine WebGL-Spieleseite

• Der Betreiber einer mittelgroßen Website zum Hochladen von WebGL-Spielen erhielt nach einem DoS-Angriff von Google Firebase innerhalb eines Tages eine Rechnung von mehr als 100.000 $

#3 Vercel Pro und überschrittenes Ausgabenlimit

• Trotz eines Vercel-Pro-Tarifs für 20 $ pro Monat und eines gesetzten Ausgabenlimits von 120 $ fielen unerwartete Zusatzkosten an

#4 Projektabrechnung und extrem hohe Forderung

• Bei einem Projekt, das monatlich 50 $ kostete, tauchte eines Morgens plötzlich eine Rechnung über 70.000 $ auf

#5 BigQuery-Nutzung und Kostenproblem mit öffentlichen Datensätzen

• Bei der Nutzung von BigQuery in einer Playground-Umgebung wurde eine enorme Rechnung von über 22.000 $ fällig

#6 Unverhältnismäßige Hostingkosten bei wenigen Besuchern

• Trotz nur 9.000 Besuchern im Monat wurden 250 $ pro Monat berechnet, was auf ein Jahr gerechnet 3.000 $ Ausgaben bedeutet

#7 Probleme nach Änderungen an der Codebasis durch Devin (AI)

• Ein Beispiel für unerwartete Folgen, nachdem die AI namens Devin Änderungen an einer Codebasis vorgenommen hatte

#8 Plötzliche Kosten nach kostenloser Nutzung

• Obwohl nie zuvor gezahlt worden war, tauchte eines Tages plötzlich eine Rechnung über 530 $ auf

#9 Abrechnung bei Dokumentationsseiten und anderen kleinen Projekten

• Selbst für eine einfache Dokumentationsseite wurden fast 400 $ berechnet; auch bei Diensten mit geringer Nutzung gibt es viele Fälle hoher Rechnungen

#10 Der Schrecken des Free Tiers

• Schon eine Rechnung von rund 103 $ wird als Problem wahrgenommen. Besonders bei der Nutzung des Free Tiers sorgt eine plötzliche Rechnung für Verunsicherung

#11 Cloudflare, AWS und weitere Probleme

• Bei Cloudflare gab es einen Fall, in dem innerhalb von 24 Stunden 120.000 $ verlangt wurden und der Dienst eingestellt wurde
• Auch bei AWS S3 kam es nach dem Anlegen eines leeren, privaten Buckets zu unerwarteten Kosten
• Ähnliche Fälle wiederholen sich bei verschiedenen Anbietern, etwa mit einer offenen Rechnung über 104.500 $ bei Netlify

#12 DoS-Angriff, E-Mails und Datenverlust

• Während eines DoS-Angriffs wurden durch den E-Mail-Versand 11.000 $ verbraucht; anschließend ging auch noch die Datenbank verloren

#13 Massenabrechnung bei Vercel sowie Probleme mit Accounts und Trials

• Bei Vercel führte ein Spam-Angriff innerhalb eines Tages zu 23.000 $ Kosten; dabei wurden 56.000 Accounts und Trial-Aktivierungen ausgelöst

#14 Unerwartete Kosten beim Testen und Deployen

• Beim Deployen von Funktionen zu Testzwecken auf Vercel und anderen Plattformen wurden unerwartete Beträge berechnet
• Eine Sitemap (sitemap.txt) verbrauchte Bandbreite in der Größenordnung von mehreren Hundert GB und verursachte hohe Kosten

#15 Testkosten bei Firebase und Cloud Run

• Schon zwei Tests mit Firebase und Cloud Run verbrauchten 72.000 $; der Dienst stand dadurch vor dem Ruin

Fazit und Implikationen

• Die Kostenstrukturen in Serverless- und Cloud-Umgebungen sind oft intransparent oder extrem anfällig für Angriffe und Fehler
• Es werden zahlreiche Fälle unerwarteter Abrechnungen gemeldet; daher sind sorgfältiges Monitoring, Nutzungsmanagement und das Setzen von Grenzwerten beim Betrieb eines Dienstes zwingend notwendig
• Wenn Automatisierungs- und Monitoringfunktionen unzureichend sind, kann schon ein einfacher Test oder ein einzelner externer Angriff zu unerwarteten Verlusten in Höhe von Zehntausenden Dollar führen
• Für Entwickler, Startups und andere SaaS-Nutzer wird die Bedeutung von Kostenkontrolle und Risikobewusstsein immer größer

[ahwjdekf]

Ich habe einmal an der Entwicklung eines internen DW für einen Großkonzern gearbeitet; dabei ging es darum, bestehende On-Premise-Daten nach AWS zu migrieren. Nach mehreren Monaten Entwicklung und Tests wurde das Projekt am Ende jedoch doch eingestellt. Der Grund war, dass die monatlichen Kosten voraussichtlich deutlich höher ausfallen würden als erwartet. Selbst für Großkonzerne sind Cloud-Ausgaben also nicht einfach.

[regentag]

Ich hatte auch einmal ein Konto erstellt, um AWS zu lernen, und obwohl es nur ein kleiner Betrag war, wurde mir etwas in Rechnung gestellt.
Mein Konto war kompromittiert, und jemand hatte über mein Konto Instanzen erstellt und betrieben ...
Ich habe sie schnell gestoppt, sodass es bei einem kleinen Betrag blieb. Da ich keine Zeit in die Verwaltung investieren konnte, habe ich das Problem schließlich gelöst, indem ich das Konto einfach gelöscht habe.

[ifmkl]

Ich würde empfehlen, vor dem Einstieg in die Cloud zunächst mit einer Mini-Server-Umgebung auf dem heute oft genannten N100- oder N150-Niveau zu starten und damit etwas Test- oder Betriebserfahrung zu sammeln.

[crawler]

Selbst bei einem sehr kleinen Projekt wirkt es wirklich beängstigend, dass schon das Bereitstellen auf einer Plattform bei einer Schwachstelle direkt zu finanziellen Verlusten führen kann.

Ich hatte Cloudflare vor meinen Inhalten vorgeschaltet, aber ein Hacker hat ein nicht gecachtes Objekt gefunden und es mehr als 100 Millionen Mal angegriffen. Als ich das blockiert habe, hat er sogar direkt die Adresse des Origin-Buckets herausgefunden und ihn angegriffen.

Ich frage mich, ob in so einem Fall die Kosten auch erstattet werden.

[GN⁺]

Hacker-News-Kommentare

• Als ich im Bootcamp programmieren lernte, habe ich versuchsweise eine Elastic-Beanstalk-Instanz kostenlos erstellt. Zur Identitätsprüfung brauchte man eine Kreditkarte, und damals dachte ich nicht, dass das ein Problem werden könnte. Später wurde mein Server jedoch von Bot-Spam angegriffen, und Amazon stellte mir 100.000 Dollar in Rechnung. Am Ende bekam ich zwar eine Erstattung, aber seit diesem Tag hasse ich Amazon und habe mir geschworen, im Fall von Cloud Computing andere Dienste zu nutzen. Mir gefiel diese komplexe Dashboard-Struktur nicht, die Kunden verwirrt und sie Geld verlieren lässt. Es wäre völlig ausreichend gewesen, die Kreditkarte nur als Verifizierungsmittel zu nutzen und Bots zu blockieren. Wenn man das mit einem Lebensmittelladen vergleicht, in dem man mit Kreditkarte ganz einfach Kekse kaufen kann, sieht man, dass Fintech wirklich nützlich eingesetzt werden könnte — hier wurde diese Möglichkeit aber nicht genutzt
  • Das ist einer der Gründe, warum Cloud-Hosting beängstigend ist. Nicht nur Amazon, auch Azure oder Google Cloud erstatten „normalerweise“. Aber wenn mein Demo-Projekt mit fünf Besuchern pro Woche plötzlich Opfer eines DDoS wird und der Hoster dieses Mal nicht „normalerweise“ reagiert, sondern eine Überweisung verlangt, könnte ich vor dem Bankrott stehen
  • Bei mir sind gerade 25.000 Dollar an Gebühren aufgelaufen. Ich hatte vor langer Zeit die SQS-Data-Plane-Audits aktiviert und tatsächlich einen Echtzeit-Feed für Audit-Events angeschlossen. Das führte dazu, dass für jedes reine Audit-Event wiederum Logging-Events wie in einer Endlosschleife erzeugt wurden. Ein Konto, das fast zehn Jahre lang im Schnitt 2 Dollar pro Tag kostete, sprang plötzlich auf 3.000 Dollar pro Tag, und von AWS kam keinerlei Warnung oder Eingriff
  • Ich frage mich, warum man Amazon hasst, wenn sie 100.000 Dollar erstattet haben. In meinem Fall hat AWS selbst dann immer erstattet, wenn teure Gebühren vollständig mein Fehler waren. Wenn es eine Richtlinie gäbe wie „bei Budgetüberschreitung alles abschalten“, hätten wir vermutlich viele andere Tragödien der Art „Wir wurden DDoS-t, AWS hat alle EC2-Instanzen abgeschaltet und dabei auch meine Daten im temporären Speicher vernichtet“ gesehen
  • „Das ist eine extrem einfache Sache: ein einzeiliges if, das bei Überschreiten des Kontolimits Instanzen abschaltet und den Dienst auf ein statisches Laufwerk dumpt. Sie wollten es einfach nicht — sie wollten ihre Größe nutzen, um den Gewinn auf Kosten der Kunden zu maximieren. Die Leute, die mit Cloud Compute allen das Leben schwer gemacht haben, versuchen jetzt auch noch, bei AI-Kosten dank Marktbeherrschung wirtschaftliche Vorteile herauszuschlagen. Dass Edge Compute heute einfacher geworden ist, liegt daran, dass Leute wegen Krypto zu viel in Festplatten investiert haben. Am Ende belohnt der Markt Blasen und schlechtes Verhalten, statt Vertrauen aufzubauen, und schafft eine Struktur, in der Leute leicht das Spielfeld beherrschen, indem sie Macht missbrauchen. Clevere Schurken mit dieser subtilen Haltung von ‚Du verstehst das einfach nicht! (Ach übrigens, gib noch etwas mehr Geld aus, bevor der Markt kollabiert)‘ sind das größte Problem der Branche. Selbst ein Taxiunternehmen berechnet nicht tausend Dollar dafür, dass es dich nicht ans Ziel bringt. Ich frage mich, wie es Sinn ergeben kann, kein if in einen Server einbauen zu können. Wäre Amazon damit schlechter als ein Taxiunternehmen? Vielleicht ja. Das ist genau der Grund, warum ‚Waymo‘ angefangen hat (vielleicht ein Witz).“
• Ich dachte, es ginge um das Leid von Serverless bei Hosting/Entwicklung/Debugging, aber es ging um explodierende Preise. Da Bandbreitenkosten für mich nie so akut waren, habe ich die meisten Texte dazu eher überflogen, aber dieser hier war interessant — wie ein leerer S3-Bucket eine AWS-Rechnung explodieren lassen kann. Darin geht es darum, dass man anderen Kosten aufbürden kann, indem man nur unauthentifizierte API-Aufrufe gegen deren S3 stellt. Das war neu für mich
  • Soweit ich weiß, wurde kurz nach der Aufmerksamkeit für diesen Blogpost etwas dagegen unternommen: Amazon S3 stellt die Abrechnung für mehrere Fehlercodes ein
  • Eines der echten Probleme in Serverless-Umgebungen ist, dass die Plattform selbst eine intransparente Blackbox ist — was zugleich Teil des Wertversprechens von Serverless ist. Wir haben ein großes Lambda-Backend übernommen, und wenn es interne Plattformprobleme gibt, etwa sporadische Socket-Abbrüche bei der Anbindung an eine Secrets Extension, ist das unglaublich mühsam nachzuverfolgen. Noch schlimmer ist, dass die lokale Testumgebung sich so stark von der realen Deployment-Umgebung unterscheidet. Mit Google Cloud Functions zu Hause für Spielzeugprojekte herumzuspielen funktioniert gut, aber bei echten Projekten würde ich lieber direkt einen HTTP-Server oder Queue-Consumer in einem Container wie ECS betreiben
  • Die Aussage war etwa: „Nehmen wir an, ich erstelle in meiner bevorzugten Region einen leeren privaten S3-Bucket. Zufällig ist bei einem bekannten Open-Source-Tool standardmäßig konfiguriert, Backups in S3 zu speichern, und dort wird als Platzhalter derselbe Bucket-Name verwendet wie bei meinem.“ Ich frage mich, wie oft so etwas in der Praxis wirklich vorkommt — wie häufig Namenskollisionen tatsächlich sind, weiß ich nicht
  • Da kommt einem fast der Gedanke, dass man damit Konkurrenten ausschalten könnte. Deshalb mag ich AWS nicht besonders. Es gibt keinerlei Bemühung, kleine Kunden vor überraschenden Rechnungsschocks zu schützen. Azure ist auch nicht viel besser, hat aber zumindest ein paar Schutzmechanismen
  • Ich hatte auch eher mit einem Beispiel für Cloud-Lock-in gerechnet, bei dem jemand an Serverless, Lambda und DynamoDB gefesselt ist und dadurch gezwungen wird, etwas Großes aufzuziehen, das in Wirklichkeit auch auf einem 20-Dollar-VPS mit sqlite laufen könnte — schade, dass es darum nicht ging
• Der wahre Schmerz bei Serverless ist nicht eine einzelne hohe Rechnung durch ein Ereignis, sondern die jeden Monat langsam anwachsenden Kosten. Man kann Ressourcen sehr leicht erstellen und dann liegen lassen. Dann steigen die Kosten über ein oder zwei Monate hinweg um ein paar tausend Dollar, bis der COO es bemerkt und für das ganze Team Alarmstufe gilt, um die Rechnung wieder unter 10.000 Dollar zu drücken. Danach wiederholt sich alles. Über Jahre hinweg summiert sich das zu mehr Verschwendung als ein einmaliger Geldverlust
  • Das ist praktisch das Geschäftsmodell von AWS. Hat das schon mal jemand das „Planet-Fitness-Modell“ genannt? Anmelden und Geld ausgeben ist extrem einfach, aber das Kündigen oder Abschalten von Zahlungen ist absichtlich mühsam gestaltet
  • Es wirkt, als würden Organisationen aus diesen teuren Abrechnungsphasen überhaupt nichts lernen. Ich frage mich, was genau die fortlaufend steigenden Kosten verursacht hat und ob man das nicht im Vorfeld hätte verhindern können
  • So etwas passiert On-Premises übrigens auch oft. Dann gibt es Server — meist VMs — auf denen ungenutzte Apps weiterlaufen. Natürlich sind auch VM-Kosten nicht null
• Oft ist die Verantwortung unklar. Kunden wollen magische, reibungslose Tools, mit denen man Hardware-Infrastruktur per Mausklick ausrollen kann. Wenn unerfahrene Nutzer etwas falsch konfigurieren und dann riesige Rechnungen entstehen, leidet der Ruf der Cloud-Anbieter, wenn diese einfach alles berechnen; wenn sie Nutzer vorab selektieren und beschränken, verschließen sie damit auch kleinen Entwicklern, die ein Startup versuchen wollen, die Tür. In solchen Fällen frage ich mich philosophisch immer, wer bei einer plötzlichen 10.000-Dollar-Rechnung wie viel zahlen sollte und bis zu welchem Punkt man für versehentliche Kosten verantwortlich sein sollte. Wenn mein Code Ressourcen versehentlich zehnmal ineffizienter nutzt, sollte dann einfach gelten: „Fehlkonfiguration, dein Problem“? Oder sollte es für Kunden egal sein, ob der genutzte Cloud-Dienst AWS und andere Großanbieter sind oder ein kleines Startup mit API-Service?
  • Wie wäre es mit Systemen für Budgetüberschreitungen oder Circuit Breakern, also Ausgabenobergrenzen? Das wirkt nicht wie ein unlösbares Problem
  • Die Antwort ist eigentlich ganz einfach — Budgets setzen
  • Das ist auch einer der Gründe, warum man statt Serverless lieber echte Server verwendet
• Bei Hetzner bekommt man 16TBx2 HDD, 1TBx2 SSD, 64GB RAM und 20TB freien Traffic für 70 Dollar im Monat. Dagegen habe ich auf einer AWS-Micro-Instanz für 1TB Traffic 150 Dollar bezahlt, soweit ich mich erinnere. Das ist einfach nicht nötig
• Zur Geschichte „Ich hatte Cloudflare vor meinen Inhalten, aber ein Hacker fand ein nicht gecachtes Objekt und hat es über 100 Millionen Mal abgerufen. Als ich das blockierte, fand er sogar direkt die Origin-Bucket-Adresse und griff diese an“ frage ich mich, ob so etwas nicht jedem passieren kann. Ich weiß nicht, ob das Durchsickern eines ungecacheten Objekts wirklich ein so schwerer Fehler ist wie Port 22 mit einem schwachen Passwort offen zu lassen, und bei S3-Ressourcen — besonders Bildern — ist es doch normalerweise gerade der Sinn, dass jeder beliebig oft darauf zugreifen kann, oder?
  • Ganz und gar nicht. S3-Buckets sollten unbedingt privat sein, mit Sicherheitsregeln, die nur Zugriffe über das CDN erlauben. Nur so stellt man sicher, dass sämtlicher Traffic tatsächlich durch das CDN läuft
  • Das klingt, als würde jemand damit prahlen, OWASP-Top-10-Schwachstellen offen zu lassen. Access-Control-Einstellungen sind nicht so schwer, wie man denkt, und wenn jemand bei solchen Grundlagen schlampt, ist die Wahrscheinlichkeit hoch, dass er auch anderswo nachlässig ist. Ein System unter so einer Verantwortung würde ich nicht vertrauen
  • Die absolute Grundlage ist, S3-Objekte privat zu halten und mindestens einen CloudFront-Proxy davorzusetzen. Dinge wie Bilder müssen unbedingt durch den Cache gehen
• Für etwas, das „serverless“ genannt wird, läuft in Wirklichkeit immer noch ein Server auf Cloud-Infrastruktur. Grundsätzlich schreibt man Software weiterhin nach dem Client-Server-Modell, und irgendwo muss ein Server laufen, damit Nutzer sie verwenden können. Für mich wäre echte „Serverlosigkeit“ eher Software, die der Nutzer einmal herunterlädt und danach ohne Internet verwenden kann. Oder etwas, das zwar Daten an Server sendet, aber nicht davon abhängt, dass der Entwickler einen bestimmten Ort vorgibt
  • Mit „serverless“ ist im Kern ein Verwaltungssystem gemeint, bei dem Ressourcen (Server) je nach Last automatisch hoch- und herunterskalieren — das ist das Wesentliche. Steigt die Last, gibt es mehr Server, sinkt sie, gibt es weniger. Den vollen Nutzen entfaltet das nur, wenn man die gesamte Code-Struktur effizient an diese Umgebung anpassen kann. Es ist also eine Architektur, die man nur dann einsetzen sollte, wenn man sie wirklich braucht
  • Üblicherweise nennt man so etwas einfach „lokale“ Software. „Serverless“ ist kein besonders guter Name, aber es geht tatsächlich um die Deployment-Struktur eines bestimmten Backends. Es bedeutet nicht, dass die App überhaupt kein Backend hat
  • „Serverless“ ist wie ein „Unternehmen ohne Mitarbeiter“. In Wirklichkeit gibt es natürlich Menschen, die den Dienst erbringen, aber alle arbeiten nur als Auftragnehmer
  • Ein „Server“ ist normalerweise eine einzelne Maschine mit einem bestimmten OS und mehreren Software-Schichten darauf, inklusive Monitoring-Tools, sodass Nutzer auf die Business-Logik zugreifen können. Wenn man Server direkt betreibt, muss man sich um die Wahl des OS, Installation und Updates unterstützender Software, Wiederherstellung bei Ausfällen und alles andere kümmern. Serverless ist ein „Function as a Service“-Modell, bei dem man sich nur um die Business-Logik, also den eigenen Code, kümmern muss. Man muss kein OS auf dem Server installieren und sich auch nicht um Grundsoftware wie einen HTTP-Server kümmern. Updates und Wartung entfallen ebenfalls. Man lädt nur den Code hoch, und er wird bei Aufruf ausgeführt. Das Konzept befreit einen vollständig vom Stress des Serverbetriebs. Deshalb heißt es „serverless“ — Server gibt es zwar, aber man muss sie nicht selbst betreiben
• Mit „serverless“ ist nicht gemeint, dass es tatsächlich keine Server gibt, sondern dass man sie nicht selbst verwalten muss oder nicht wissen muss, auf welchem Server der eigene Code läuft. Eher so: „Hier ist etwas Code, führe ihn bitte jede Stunde aus. Wo das läuft, ist mir egal.“
  • Das Wort mag unangenehm wirken, aber sprachlich ist es kein orwellsches Problem. In 1984 zielte „Neusprech“ darauf ab, Ausdrucksvielfalt abzuschaffen, während „serverless“ eher ein Neologismus ist, um eine neue Kategorie zu benennen. Natürlich kann der Begriff die Existenz von Servern verschleiern, aber ihn präzise als orwellsch zu bezeichnen, passt nicht ganz. Vielleicht könnte man so etwas wie „Servelet“ als „kleinen Server“ sagen
  • Es gibt auch die oft zitierte sarkastische Formulierung: „Es gibt keine Cloud, nur den Computer von jemand anderem“
  • „Serverless“ wirkt am Ende wie die Tech-Bro-Version des früheren Shared Hostings — mit „10.000 % Marge“ und einem Preismodell pro Request
  • Auch „No-Code“-Systeme laufen letztlich auf Code. Sich bei PaaS oder Ähnlichem darüber aufzuregen, dass irgendwo doch Server existieren, wirkt wie eine Ausrede
• Ich habe AWS Serverless verwendet, und lokales Testen war praktisch unmöglich. Für serverless run musste man zwingend AWS-IAM-Rollen verwenden, wodurch dem gesamten Konto weitreichende Berechtigungen offenstanden. Am Ende entstand dadurch das große Problem, dass man faktisch jedes Mal direkt in Produktion testete
  • Ich habe auch mehrere Jahre an Serverless-Projekten gearbeitet, und dass man lokal fast nichts ausführen konnte, war wirklich ein enormer Kostenfaktor. Auch das Debugging dauerte katastrophal lange. Die Tools, die als Ersatz angeboten wurden, waren für reale Projekte fast nutzlos
  • Wenn man die Datei ~/.aws/credentials passend konfiguriert, kann man mit AWS-Security-Keys lokal testen. Ich automatisiere das Lambda-Deployment mit einem makefile und erstelle für jede Lambda eine eigene Custom-IAM-Rolle, wobei ich die Sicherheitsanforderungen in JSON-Dateien verwalte. Die eigentliche Stärke von AWS ist, dass alles über dieselbe API abgewickelt werden kann. Man kann alles programmatisch erstellen und verwalten
  • 1) In einen Stack gepackt in ein separates Entwicklerkonto deployen (kostenlose Staging-Umgebung), 2) lokal mit der offiziell unterstützten Docker-Runtime testen, 3) wie üblich Unit-Tests schreiben, 4) mit Tools wie localstack die Staging-Umgebung auf dem eigenen Rechner emulieren — es gibt so viele Optionen, dass ich nicht verstehe, wie man zu einer derart schlechten Erfahrung kommen kann
  • Das ist ziemlich weit von den Fakten entfernt
• Ich halte den Begriff „serverless“ trotzdem für ein orwellsches Naming, das serverbasierte Systeme eher verkleidet als beschreibt
• Ich kann nicht glauben, dass diese Firmen für 1TB Bandbreite 550 Dollar verlangen. Selbst wenn man einen Server mit garantiertem 10Gb/s-Port mietet, empfinde ich alles über 3 Dollar pro TB als Abzocke. Ich frage mich, wie Serverless rechtfertigen kann, diese Kosten um den Faktor 150 zu erhöhen. Fallen da wirklich Leute drauf herein? Für ein Lese-Wiki, Tech-Dokumentation oder einen Blog reicht auch ein 10-Dollar-VPS oder GitHub Pages völlig aus, und mit etwas vernünftigem Setup sind auch 10.000 gleichzeitige Nutzer kein Problem

[benjamin]

Sind die meisten Menschen, die jetzt zum ersten Mal mit dem Entwickeln anfangen und mithilfe von AI irgendetwas bauen, nicht diejenigen, die ihren Service mit so etwas wie Vercel oder Supabase betreiben?

Aber wenn der Service anfängt zu wachsen, scheinen sie den Preis, den sie dafür zahlen müssen, nicht wirklich durchzurechnen.
Nach dem Motto: Darum kümmern wir uns, wenn es so weit ist.

Die Gründer von Vercel oder Supabase würden dann wohl breit lächelnd zustimmen und sagen: „Genau, genau, darum kann man sich später kümmern!“

Natürlich kann man auch dann noch darüber nachdenken. Wenn man die Fähigkeiten hat, schnell da wieder herauszukommen.
Aber ohne Wissen über Informatik wird das nicht einfach sein.
Es kann leicht passieren, dass man das Geld, das man gerade erst zu verdienen beginnt, vollständig an sie abführt.

Tatsächlich ist genau das es, was gerade passiert.
Mit anderen Worten … da entsteht ein großes Business, das vom Geld der Newbies lebt, die ohne jegliche Informatikkenntnisse loslegen.

Genau deshalb muss man sich weiter tief in die Informatik hineinarbeiten.
Manche geben für einen Service, der gerade erst anfängt, Umsatz zu machen, im Monat 1.000.000 Won aus, während andere denselben Service ganz ohne Kosten betreiben.
Auch die Senkung der Betriebskosten ist eine Fähigkeit. Ist das nicht ein enormer Wettbewerbsvorteil?
Es ist gut, mit AI zu coden, etwas zu bauen und dabei Freude zu empfinden, aber wenn man sich nicht bemüht, in die Tiefe zu gehen, wird man am Ende keinen Unterschied machen können.

https://jeho.page/essay/2025/09/08/sucker-developer.html