サーバーレスにだまされないでください

• RoRを作ったDHHの文章
• クラウド支持者は、コスト、性能、複雑さなど、あらゆるものが「サーバーレス」に行けば魔法のように解決すると言う
• クラウド/VPSは、大量購入して個別に販売するという原則に従って動く
  • 1000ドルで大きなサーバーを購入し、200ドルで7人に貸し出して月400ドルの利益を得る
  • 7人がサーバーに大きな負荷をかけない、または互いに異なる時間に使うならうまく機能する
  • サーバー全体の容量が必要なら、1000ドルのコンピューターを1400ドルで使うことになる
  • 1年契約で使うなら月1250ドルまで値引きも可能（実質的には年利25%の信用契約）
• サーバーレスも同じだが、サーバーをはるかに細かく分割できる
  • 大型サーバー1台を7人に月200ドルで提供するのではなく、各関数を実行する顧客100人に月20ドルで提供する
  • これで月400ドルの利益ではなく、1000ドルの利益を生む
  • クラウド事業者がサーバーレスを好むのは驚くことではない
• ときどき実行されるいくつかの機能だけが必要なら良い（少なくとも短期的には）
• しかし、コンピューターの機能全体を使い切るレベルなら悲惨
• 同じクロック数に対してより多くの費用を払い、しかもロックインも非常に大きいから
• サーバーレスで「クラウドネイティブ」サービスを使うほど、外に出るのは難しくなる

• 「サーバーレスにだまされないでください。コンピューターの計算サイクル全体が必要なら、そのコンピューターを買わなければならないという事実を変える魔法はありません。独自仕様のサーバーレス構成で始めれば、ロックインから抜け出せないことに気づくでしょう」

• 「クラウドは、ブラックフライデーやクリスマスに莫大な需要があり、それ以外の期間には不要な容量が多かったAmazonのように、利用量の変動が非常に大きい会社や、
  コンピューター全体を所有するほどのビジネスではない会社、あるいはクラウド支出がごく小さく問題にならない初期企業のためのものです。サーバーレスはそれを変えません。」

[secret3056]

バーストタイムのあるサービスかどうかという違いもあります。配達アプリのような場合は、確実にアクセスが集中する時間帯があるので、そのときだけスケールアウトできるクラウドは魅力的です。ですが、トラフィックの99%が固定的なIoT系では、物理サーバーを回したほうがよいこともあります。

[ehlegeth]

サーバーレスの実際の有用性を超えて、あまりにも過度にハイプ化されている面があるため、一度考えてみる価値のある視点を与えてくれるように思います。

• コンピュータ1台以上のリソースが必要な場合でも、サーバーレスソリューションは利益をもたらすのか
• サーバーレスのロックイン

この2つの課題について考えて判断すれば、大きく失敗することはなさそうです。

個人的には、サーバーレスが正しい抽象化なのかについて疑問がありますが、これは時間が証明するだろうと思いますし、サーバーレスのロックイン問題については今後も頭の痛い問題であり、業界全体で解いていかなければならない、成功しやすいとは言えない課題だと思います。

[kyc1682]

お金もないですが、人も時間もなおさら足りないスタートアップにとって、サーバーレスは非常に魅力的な選択肢だと思います

[gcback]

結局のところ、需要と供給に対して合理的な選択ができる領域なので、だまされるとか、だますとかいう話ではないと思います。

市場には、企業規模、業態、サービスの種類に応じて、cloud、on-premise、そして serverless を適切に必要とする企業や人々がいるものです。
サーバー1台に200ドルを払うのが妥当なのか、function を20ドルで使うのかは、結局それぞれの企業の CEO/CTO がよく考えて合理的に決められる事柄だと思います。目先のコストやスケジュールが厳しければ20ドルのほうがよい場合もあるし、少し余裕があるなら200ドル、1000ドルのものが合理的な判断になることもあるでしょう。むしろ需要側の立場では、さまざまな状況に対応する選択肢が増えるのですから、よりよいことではないかと思います。しかも独占的な技術でもなく、大企業同士が激しく競争している市場なのだから、価格は今後も下がっていくのでしょう。

[iolothebard]

専任のインフラエンジニア（DevOps、SRE、プラットフォームエンジニアなど）がいないなら、AWS Fargate や GCP Cloud Run あたりが限界線のようです。container as a service。
もちろん、それにもあれこれ長所と短所はあるでしょうが…

[xguru]

関連して、AWSがLambdaであれだけ多くの料金を取りながら、肝心のランタイム改善はしていないと批判する記事もあります。
https://www.lastweekinaws.com/blog/aws-is-asleep-at-the-lambda-wheel/

• 2020年のre:Inventで、Lambdaユーザーはすでに100万人を超えたと言われているのに…
• Python 3.10は2021年10月にリリースされ、現在はすでに3.11.2まで出ているにもかかわらず、Lambdaランタイムは3.9を使っている。Ubuntu LTSでも3.10を使っている。AWSは1年以上「対応中」
• Goランタイムは古すぎてGravitonをサポートしておらず、Rubyも同様に貧弱

[ehlegeth]

同感です。

Lambdaや他のAWSサービスのプラットフォームアップグレードのサイクルを見ると、機敏だとは感じられず、かなり保守的に進めるか、多くのリソースを投じていないという印象を受けます。おそらく、プラットフォームのバージョンを追加するには多くのテストが必要で、追加によってサポートコストも大きく増えるため、安定性を重視し、プラットフォームのバージョン数を一定範囲内で管理しているからではないか……とは推測できますが。

[xguru]

いつものことですが、DHHはやや強い言い方をする人です。参考程度に見てください（笑）