Lassen Sie sich nicht von Serverless täuschen

• Ein Beitrag von DHH, dem Erfinder von RoR
• Cloud-Fans behaupten, bei Kosten, Performance, Komplexität und allem anderen würden sich die Probleme wie durch Magie lösen, wenn man auf "Serverless" setzt
• Cloud/VPS funktionieren nach dem Prinzip: in großen Mengen einkaufen und einzeln weiterverkaufen
  • Einen großen Server für $1000 kaufen und ihn an 7 Personen für je $200 vermieten, ergibt $400 Gewinn pro Monat
  • Das funktioniert gut, wenn die 7 Personen den Server nicht stark belasten oder ihn zu unterschiedlichen Zeiten nutzen
  • Wer die volle Kapazität des Servers braucht, nutzt einen $1000-Computer für $1400
  • Bei einer Bindung über ein Jahr ist auch ein Rabatt auf $1250 pro Monat möglich (im Grunde ein Kreditvertrag mit 25 % Jahreszins)
• Bei Serverless ist es ähnlich, nur dass der Server viel feiner aufgeteilt werden kann
  • Statt einen großen Server an 7 Personen für $200 pro Monat zu geben, wird er 100 Kunden für je $20 pro Monat pro Funktionsausführung angeboten
  • Jetzt sind es nicht mehr $400 Gewinn pro Monat, sondern $1000
  • Dass Cloud-Anbieter Serverless lieben, ist daher nicht überraschend
• Wenn man nur ein paar Funktionen braucht, die gelegentlich ausgeführt werden, ist das gut (zumindest kurzfristig)
• Wenn man jedoch auf einem Niveau ist, auf dem man die volle Leistung eines ganzen Computers braucht, ist es schrecklich
• Denn man zahlt mehr für denselben Takt und ist gleichzeitig massiv an den Anbieter gebunden
• Je mehr "Cloud-native" Services man bei Serverless nutzt, desto schwerer wird es, wieder herauszukommen

• "Lassen Sie sich nicht von Serverless täuschen. Es gibt keine Magie, die die Tatsache verändert, dass Sie einen Computer kaufen müssen, wenn Sie die gesamten Rechenzyklen dieses Computers brauchen. Wenn Sie mit einer proprietären Serverless-Konfiguration beginnen, werden Sie feststellen, dass Sie dem Lock-in nicht mehr entkommen."

• "Die Cloud ist für Unternehmen gedacht, bei denen der Verbrauch stark schwankt, wie bei Amazon mit enormer Nachfrage an Black Friday/Weihnachten und viel ungenutzter Kapazität im Rest des Jahres, oder für Firmen, die kein Geschäft haben, das den Besitz eines ganzen Computers rechtfertigt, oder für frühe Startups, bei denen die Cloud-Ausgaben so gering sind, dass sie kein Problem darstellen. Serverless ändert daran nichts."

[secret3056]

Es gibt auch den Unterschied, ob es sich um einen Dienst mit Burst-Zeiten handelt oder nicht. Bei Liefer-Apps gibt es eindeutig Stoßzeiten, daher ist eine Cloud, die nur dann skalieren kann, durchaus attraktiv. Aber im IoT-Bereich, wo 99 % des Traffics konstant sind, kann es besser sein, physische Server zu betreiben.

[ehlegeth]

Abgesehen vom tatsächlichen Nutzen von Serverless gibt es wohl auch eine Tendenz, dass das Thema zu stark gehypt wird, daher scheint mir das eine Perspektive zu sein, über die man einmal nachdenken sollte.

• Bringen Serverless-Lösungen auch dann Vorteile, wenn Ressourcen von mehr als einem Computer benötigt werden?
• Der Lock-in von Serverless

Wenn man diese beiden Punkte bedenkt und darauf basierend entscheidet, wird man vermutlich keinen allzu großen Fehler machen.

Persönlich frage ich mich, ob Serverless die richtige Abstraktion ist; ich denke, das wird die Zeit zeigen. Das Lock-in-Problem bei Serverless wird uns meiner Meinung nach weiter Kopfzerbrechen bereiten, und ich halte es für ein schwieriges Problem, das die gesamte Branche gemeinsam lösen muss.

[kyc1682]

Auch wenn Startups kein Geld haben, fehlen ihnen noch viel mehr Menschen und Zeit – deshalb halte ich Serverless für eine äußerst attraktive Option.

[gcback]

Letztlich ist das ein Bereich, in dem rationale Entscheidungen auf Basis von Angebot und Nachfrage möglich sind, daher habe ich nicht das Gefühl, dass hier jemand getäuscht wird oder andere täuscht.

Je nach Unternehmensgröße, Art des Geschäfts und Art des Service gibt es auf dem Markt natürlich Unternehmen und Menschen, die Cloud, On-Premise und Serverless in jeweils passender Form benötigen.
Ob ein Server für 200 Dollar angemessen ist oder ob man lieber eine Function für 20 Dollar nutzt, ist letztlich etwas, das der jeweilige CEO/CTO eines Unternehmens nach Abwägung vernünftig entscheiden kann. Wenn kurzfristig Kosten und Zeit der Engpass sind, können 20 Dollar besser sein; wenn etwas mehr Spielraum da ist, können 200- oder 1000-Dollar-Lösungen die vernünftige Entscheidung sein. Aus Sicht der Nachfrageseite ist es eher von Vorteil, dass es für unterschiedliche Situationen mehr Auswahlmöglichkeiten gibt. Außerdem handelt es sich nicht um eine monopolistische Technologie, sondern um einen Markt, in dem große Unternehmen erbittert konkurrieren, weshalb die Preise weiter sinken.

[iolothebard]

Wenn es keinen dedizierten Infrastruktur-Engineer (deops, sre, platform engineer oder Ähnliches) gibt, scheinen aws fargate oder gcp cloud run ungefähr die Obergrenze zu sein. Container as a Service.
Natürlich hat auch das jeweils seine Vor- und Nachteile, aber ...

[xguru]

Dazu gibt es auch einen Artikel, der AWS dafür kritisiert, dass sie mit Lambda so viel Geld verdienen und trotzdem die Laufzeitumgebung nicht verbessern.
https://www.lastweekinaws.com/blog/aws-is-asleep-at-the-lambda-wheel/

• Auf der re:Invent 2020 hieß es, dass es bereits mehr als 1 Million Lambda-Nutzer gibt..
• Python 3.10 erschien im Oktober 2021, und obwohl inzwischen schon 3.11.2 verfügbar ist, verwendet die Lambda-Runtime weiterhin 3.9. Selbst Ubuntu LTS nutzt 3.10. AWS ist seit über einem Jahr "dran".
• Die Go-Runtime ist so veraltet, dass sie Graviton nicht unterstützt, und bei Ruby sieht es ähnlich mager aus.

[ehlegeth]

Da stimme ich zu.

Wenn man sich den Platform-Upgrade-Zyklus von Lambda oder anderen AWS-Services ansieht, wirkt das auf mich nicht besonders agil, sondern eher sehr konservativ oder so, als würde man dort nicht viele Ressourcen investieren. Vermutlich liegt das daran, dass das Hinzufügen neuer Plattformversionen viele Tests erfordert und sich dadurch auch die Supportkosten deutlich erhöhen würden. Deshalb legt man wohl viel Wert auf Stabilität und hält die Anzahl der Plattformversionen innerhalb eines bestimmten Rahmens ... zumindest ist das meine Vermutung.

[xguru]

Wie immer formuliert DHH ziemlich zugespitzt. Bitte mit diesem Hintergrund lesen. :D