Momento Japan サーバーレス・テクノロジーは10年以上の歴史がある。多くの企業が採用しているが、最近のいくつかの出来事から、その将来性について懐疑的な見方が浮上しています。
サーバーレスは死んだ。サーバーレス万歳！
サーバーレスはまだ重要か？いいえ。
サーバーレスが誕生して10年が経つが、次はどこに向かうのだろうか？
最近、サーバーレスに関する好奇心をそそるフレーズや記事が技術系メディアにいくつか登場しました。
私は、物事やトレンドがピークに達した後、下降していくことには同意するが、最近の懸念がどのように、なぜ、どこから生まれたのか理解するのに苦労しています。
この記事は、ここ数年のサーバーレスについての私の見解と、サーバーレスの方向性について述べたものです。
注意：次のようなトピックがあり、長い読み物です
・2つのイベント
・サーバーレスとは何か？
・高まるサーバーレスのフェーズ
・企業のテクノロジー事情
・サーバーレスは主流か？
ほぼ1年違いの2つの出来事
現代のハイテク産業の進化と拡大のスピードは天文学的であり、それは私たちが地球とともに毎日自転しているよりも速く感じられます。このスピードでは、小さな混乱がすぐに巻き添えを食ってしまいます。
最近のテクノロジーは非常にデリケートになっています。技術スタックを選び、何十年も、あるいは永遠にそれを使い続ける時代は終わったのです。
採用、マイグレーション、リファクタリング、非推奨は、今やチームの日常会話の一部です。恥ずかしいことではありません。これが現代のエンジニアリングチームが変化に対処する方法なのです。
現代の技術の脆弱性を考えると、AWSの大海原でサーバーレスのボートを揺るがした2つの出来事があります。
・昨年のプライム・ビデオの話
・サーバーレス・デベロッパー・アドボケイト（DA）チームの最近の再編成
これらの出来事によって技術勧告が意見を揺るがし、サーバーレス万歳ソングを歌うことになったのかどうかを探ってみましょう。
悪名高いプライム・ビデオ・ストーリー
これらのフレーズに聞き覚えはないでしょうか？
自分の足を撃つ。
自分のゴールを決める。
自分で墓穴を掘る。
それこそが、2023年3月に発表されたプライム・ビデオの、マイクロサービスからモノリスへという言葉足らずの記事がAWSにしたことです。私は、アマゾンのいつも慎重な編集の手から、どのようにしてこの記事が抜け落ちたのか、全く分かりません。
あの記事の意図は明らかです。残念なことに、メディアは責任のなすり合いと自己利益のためにこの記事を大げさに取り上げてしまいました。
しかし、私はその話の中に2つの重要なことを見つけた。
質問 なぜコストと規模の計算を誤ったのか？
すべての専門知識とAWSのWell-Architected Frameworkがそばにあるのに、オリジナルのPrime Videoソリューションのアーキテクチャー・ブレーンが、構築前にコストとスケーリングの限界を考慮しなかったのはなぜでしょうか？
平均的なサーバーレスチームでも、コスト分析やホットスポットの特定は、エンジニアがソリューション設計を行う際に行う基本的なことの一部です。
プライム・ビデオはこれらを見逃し、テクノロジーが責任を負わされました。
丸い穴に四角い釘をはめようとするなら、それは技術の問題ではなく、人間の愚かさだ。
レッスン リファクタリングとアーキテクチャの進化
プライム・ビデオのチームは間違いに気づいたとき、再アーキテクトして必要な変更を加ましえた。現代のチームは、リファクタリングしてアーキテクチャを進化させることをためらうべきではありません。
これは誰にとっても良い教訓です。
しかし、だからといって、すべてのマイクロサービスをモノリスにリファクタリングしなければならないわけではない。問題はそこではありません。
リファクタリングされたプライムビデオのソリューションには、コンテナとマネージドサーバーレスサービスが含まれ、調和がとれています。
サーバーレスDAチームの解散
デベロッパー・アドボカシー（DA）はインパクトのある役割です。DAは技術コミュニティと密接な関係にあるため、その地位、役割、責任に変更があれば、業界に憶測が広がります。
AWSを去る友人たちを見るのは悲しいが、それは必ずしもAWSのテクノロジーの抜本的な変化とは関係ありません。
次のセクションで見るように、AWSは最も人気があり、広く消費されているサーバーレス・ビルディング・ブロックを持っています。彼らの顧客に対する執着心を考えれば、AWSがこれを危うくすることはないでしょう。
AWSにおける継続的な技術調整
しばらくAWSの戦略を観察していれば、以下のような技術提携の兆候に気づいたはずです。
・イベント・ドリブン・アーキテクチャーの推進 現在も進められています。アーキテクチャのコンセプトとして、サーバーレスとコンテナワークロードの橋渡しを行います
・コミュニティリレーションの融合 AWSのコンピュートコミュニティリレーションチームは、サーバーレスコミュニティとコンテナコミュニティへのサービスを担当しています
・サーバーレス・コンテナ Lambda上で重いワークロードを実行する需要が限界を超えるにつれ、適切なジョブに対して適切なサービスを選択する自由奔放なアプローチが主流になりつつあります
・Better togetherのスローガン サーバーレスとコンテナを受け入れる。今後、AWSやサーバーレスの集まりでこのキャッチフレーズを耳にすることがあるでしょう。
だから、信号はそこにあったのに、ほとんどの人は気づきませんでした。
問題は、この技術提携がサーバーレスにどのような影響を与えるかです。
サーバーレスの原点を確認した上で、これを探っていきます。
では、そもそもサーバーレスとは何なのか？
まず、これらの事実をお読みください：
アマゾン・シンプル・キュー・サービス（SQS）ベータ版は2004年にリリースされた。
Amazon Simple Storage Service (S3)は2006年にリリースされた。
グーグル・アップ・エンジン（GAE）は2008年にリリースされた。
サーバーレスという言葉が最初に登場したのは2012年。
2014年にAWS Lambdaがサービスイン。
Amazon API Gatewayが利用可能になったのは2015年。
マイク・ロバーツ氏の記事「Serverless Architectures」によると、サーバーレスという言葉が最初に使われたのは2012年頃のようだ。
あなたがSQSやS3をよく知っているとして、それらをサーバーレス・サービスと考えるでしょうか？
・もしそうなら、サーバーレスという言葉が生まれる前から存在していたことになる！
・そうでないなら、何と呼ぶのだろう？(フル）マネージドサービス？
(初期の）サーバーレスという勘違い
広く受け入れられているサーバーレスのコンセプトは、サービスを利用する際にサーバーを管理する必要がないという事実に基づいています。
サーバーのことを考えずにアプリケーションを構築し、実行する。- AWS
上記はサーバーレスの最もわかりやすい定義です。
しかし、サーバーレスの概念は、AWS Lambda-マネージドサービスとしてのコンピュート、Function as a Service (FaaS)として知られるもののリリースで一転した。
FaaSは、ネットワーク境界の設定、サーバーのプロビジョニング、パッチ適用、スケーリング、ロードバランシングなどの苦痛からエンジニアを解放しました。簡単さと高速化は、業界に魅惑的な成果をもたらしました。
サーバーレスの黎明期には、すべてのエンジニアがラムダハンマーを持ち歩き、あらゆる問題を関数で解決しているように感じられました！
FaaSが一夜にして人気を博したことで、当時はほとんど耳にすることのなかったサーバーレスという言葉が、勘違いされた正体とともに広まった： サーバーレス＝FaaSなのだ！
サーバーレスの定義（と期待）の出現
サーバーレスが受け入れられ、業界での採用が増えるにつれて、サーバーレスとFaaSをどのように差別化するかについての理解が深まりました。
誰もがサーバーレスに取り組んだ経験から、サーバーレスの定義を急ぎました！その理由は主に2つありました。
1.サーバーレス技術を誰にでも理解できるようにする。
2.AWSや他のクラウドプロバイダーが注目するサーバーレスのガードレールを提案する。
サーバーレスの初期の定義について学ぶには、2019年のServerless Days MilanでJeremy Dalyの素晴らしい講演「Stop calling everything serverless」を見ることをお勧めします。
AWS Lambda（FaaS）やその他のマネージドサービスの影響を受け、定義やガードレールは暗黙のうちに、以下のコアな考え方を含む非公式なサーバーレス仕様をまとめました。
・ペイ・パー・ユース（後にペイ・パー・ユースとストレージとなる）
・スケール・トゥ・ゼロ
・サーバー管理不要
上記に違反したサーバーレスタグを持つクラウドサービスは、業界で議論の的となりました。
Serverless Auroraの早期リリースは、ゼロにスケールしなかったため、コミュニティではサーバーレスかどうかを問う議論になった。
このサニティチェックは、サーバーレスタグが付いた新しいマネージドサービスがリリースされるたびに行われる。
最近のAmazon OpenSearchのServerlessタグ付き亜種も、厳格な従量課金の範疇に収まらないため、騒動を引き起こした。
業界で普遍的に合意されたサーバーレスの仕様がないことは、クラウドプロバイダーから何が出てくるかを誰もコントロールできないことを意味します。
サーバーレスの変化（成長段階）
サーバーレス・サービスの命名規則は依然として混乱や対立、批判の原因となっているが、業界のサーバーレス採用は急速に進んでいます。
アーキテクチャの原則や実装パターンにあまり注意を払わないまま、多くのチームが無害な単一目的のLambda関数を利用して、あらゆることを実現しました。そしてLambda関数の数は天文学的に爆発しました。
管理不能な量のラムダ関数が爆発的に増えたことで、3つの主な問題が発生しました。
1.絡み合ったLambdaのピンボールアーキテクチャ
2.場合によっては高額のクラウド料金
3.関数の疲労
業界ではしばしばサーバーレスの複雑さが騒がれます。記事「サーバーレスの導入は難しい？」という記事で、その理由をいくつか取り上げました。
もともと複雑な技術もある。そして、私たちは技術によって複雑さを作り出す。
しかし、この機能疲労は、エキサイティングなサーバーレス・ムーブメントにつながりました！
機能なきパラダイム
機能が増えればメンテナンスも大変になる コードは負債なのです。そこで、カスタムコードを減らし（Lambda関数など）、ローコードを考え、コードレス・パターンを使うことが推奨フレーズになりました。
それは新しいことではありません。私は2019年にファンクションレスについて書いたし、カンファレンスでも話してきました。
このように、サーバーレスになってから数年のうちに、すべてを関数でやらなければならないという強迫観念は、多くのことを関数なしでやることに変わりました！
いくつかのネイティブサービス統合パターンが進化するにつれて、エンジニアはビジネスロジックを実装する革新的な方法を探すことを学びました。
サービス統合を新たな領域へと導いたのは、2つのソフトウェアパターンと2つのAWSサービスでした。
・Amazon EventBridge によるサービスの振り分け
・AWS Step Functionsによるサービスオーケストレーション
この2つは、AWSのサーバーレスにさらなる変化をもたらす土台となるでしょう！
分散型アーキテクチャーの普及
分散アーキテクチャは目新しいものではないが、サーバーレスには、リソースの接続性、クロスアカウントアクセス、ドメイン境界の違反などに関する開発上の課題がいくつかありました。
サービスの振付師としてのAmazon EventBridgeと、ビジネス・ワークフローのオーケストレーターとしてのAWS Step Functionsによって、サーバーレス・マイクロサービスを構築する新しい方法が生まれました。
API Destinations、Task Tokens、SDK integration、HTTP Endpointなどの機能により、エンジニアはオーケストレーションを配布し、組織内の非サーバーレス技術スタックと対話する手段を手に入れました。
非同期通信とイベント駆動アーキテクチャは、サーバーレスの主流になろうとしていました。業界はワーナー・ヴォーゲルス博士のような偉大な人物の承認を必要としており、ワーナーがAWS re: Invent 2022の基調講演で行ったのはまさにそれでした！
世界は非同期。世界はイベント・ドリブンなのだ – ヴェルナー・ヴォーゲルス博士、アマゾン・ドット・コムCTO
より多くのコンピューティング・パワーへの継続的な需要
サーバーレスですべてを行うという排他性は、従来は豊富なCPUやGPUパワーを持つ常時稼働のコンテナに依存していた多くのユースケースが、サーバーレスの世界でマッチするものを見つけなければならなかったことを意味します。
エフェメラルな性質を持つFaaSには限界があります。Lambdaはリソースのパワーと持続時間を向上させたとはいえ、組織における耐久性のある高負荷のコンピューティング・ニーズにはかなわないし、今後もかなわないでしょう。
中間点を見つけるために、AWS Lambdaはより多くのメモリ、Elastic File System (EFS)、コンテナ・イメージ・オプションなどの変更を受けました。
必然的に、現在の価格モデルでは、大容量の状況でラムダにより多くのパワーを与えることは、ただ一つのこと、つまりコスト増を意味します！
AWSの製品チームは、（ここでは紹介できないが）いくつかの改善点を評価しているが、このような業界の絶え間ない要求は、技術的な会話における包括性を開いています。
The right tool for the right job.
競争、需要、純度のバランスを取るという、常に困難な行為
多くのAWSサービスがクラウドの世界でトップレベルにある一方で、サービスのネーミングは決してAWSの強みではありません。いや、AmazonやAWSの接頭辞の話をしているのではない！それはまた別の機会に。
競争と業界の注目を集める緊急性から、サービス（またはその亜種）を意図的にサーバーレスと呼ぶことは、多くの人を悩ませる行為となっています。
サーバーレスは十分に進化しているので、このようなネーミングのトリックは必要ありません。サービスの能力に忠実であることは、コミュニティの多くの人々を幸せにします。
しかし、既存の非サーバーレス・サービスが、オンデマンド・スケーリングや従量課金などのサーバーレス特性を提供するように進化すると、その境界線はしばしば曖昧になります。
サービス名の他に、AWSがどこに向かっているのか（と私は考えている）を理解し、AWSの組織変更に対する答えを見つけ、サーバーレスの将来を考えるには、まず典型的な企業における技術の広がりを見る必要があります。
生態系とは、植物、動物、その他の生物、そして気象や景観が一体となって生命の泡を形成している地理的地域のことである。- ナショナルジオグラフィック
相互接続されたテクノロジー・エコシステム
サーバーレスはテクノロジーのエコシステムだ！
Serverless Development on AWS（O’Reilly、2024年）は、サーバーレスをテクノロジー・エコシステムと呼び、自然の生態系と関連づけている。生きている部分と生きていない部分を含む地球の生態系のように、サーバーレスのエコシステムには技術的な要素と非技術的な要素が含まれます。
サーバーレス・エコシステムでは、S3、SQS、EventBridge、Lambda、Step Functionsなどのマネージド・クラウド・サービスが基本的な構成要素となります。サーバーレスアプリケーションは、これらのビルディングブロックとその特性を使って構成します。
インフラストラクチャー定義を使って配線し、クラウドプラットフォーム（イネーブラ）で運用します。
エコシステムの非技術的要素であるビジネス利害関係者のためのソリューションを構築するエンジニア。
企業の世界におけるさまざまな要求
企業には、異なる責任と能力を持つ複数の部分、すなわちドメインがあり、それらは異なるテクノロジーを要求します。
・顧客からの問い合わせに効率的に対応する。
・予測されるトラフィック・パターンと予測されないトラフィック・パターンを処理する。
・大量のデータの取り込み
・データサイエンスと機械学習（ML）モデルの実行
・複数のカテゴリーのデータの分類と保存
・企業資産の保護と顧客データの保護
・チームが高速フローを実現するためのプラットフォームとツールの提供
・誇大広告であろうとなかろうと、GenAI LLMのためにスペースを割り当てること
・などなど
サーバーレスはほとんどのことに対応できます、一部のユースケースやワークロードは、サーバーレスが提供できる以上の機能を必要とします。
このような要件を理解し、評価することは、プライム・ビデオ・チームの失敗を避けるために不可欠です。ベストなものを受け入れること。丸い穴に四角い釘をはめ込もうとする人にならないこと！
書籍『Serverless Development on AWS』（O’Reilly、2024年）では、サーバーレスに対する企業の準備状況を評価する章に、「Assessing Workloads for Serverless Suitability（サーバーレスに適したワークロードの評価）」というセクションがあり、サーバーレスの適性に関するいくつかのユースケースについて論じている。
以下は、書籍『Serverless Development on AWS』からの引用である。
サーバーレスファースト思考でサーバーレステクノロジーの適合性を評価する場合、サーバーレスを最初のテクノロジー選択として考える。これは、サーバーレス・マストという考え方で他のテクノロジーを排除するという意味ではない。
依存と接続のテクノロジー
企業では、さまざまなテクノロジー・エコシステムが多様なビジネス機能をサポートしており、サーバーレスもそのひとつです。
エコシステムのアナロジーを企業のテクノロジー・ランドスケープに当てはめると、サーバーレス、コンテナ、オンプレムなど、さまざまなテクノロジーのエコシステムが形成されていることに気づくでしょう。
多くの組織は、競争力を高めるために複数のエコシステムを必要としています。効果的であるためには、これらのテクノロジーは、自然界のつながった生態系のように協力し合わなければなりません。テクノロジー・エコシステムは互いに補完し合います。
簡単な例を挙げよう：
ある企業のドメインがデータ分析／科学だとします。サーバーレス・エコシステムはデータを取り込み、保存します。コンテナエコシステムは大量のデータを処理し、アルゴリズムとデータサイエンスモデルを実行します。
そしてサーバーレス・エコシステムは、これらのモデルの出力を処理し、データを準備して他のビジネス・ドメイン（および他のテクノロジー・エコシステム）に提供します。
しかし、これらの分散型エコシステムはどのように連携しているのでしょうか？
実績のある業界のパターンと慣行を採用することによってです！
・同期および非同期通信
・イベント駆動型アーキテクチャ
・オーケストレーション
・コレオグラフィー
・などなど
AWSのクラウド戦略は、このような技術的なコネクションを業界向上のために機能させることが急務です（と私は考えています）。
サーバーレスへの情熱が我々をここまで導いた。実用性が私たちを導いてくれるだろう。
サーバーレスの主流と繁栄
この背信的な世界では、真実も嘘もありません。すべては、それを見るクリスタルの色によって決まります。- ペドロ・カルデロン・デ・ラ・バルカ
サーバーレスのリーチを理解するには（あるいはその欠如を理解するには）、AWSやサーバーレスをテーマにしたカンファレンスをスキップして、より一般的なテクノロジー・カンファレンスで聴衆に話を聞けばいいのです。
サーバーレスは、クラウドでさえも、いくつかの業界分野では前例のないことです。
AWSやサーバーレスのような緊密な技術コミュニティの一員であることで、私たちは学び、共有し、要求し、批判し、自分たちが熱中していることを伝道します。私たちは、このコミュニティのエコシステムの変化に対して感情的に脆弱になります。
しかし、私たちは総合的かつ長期的な視点から技術を見るべきです。
サーバーレスの恩恵をまだ受けていないほとんどの組織にとって、サーバーレスはまだ重要ではない。
AWSは今後もマネージド・サービスを充実させていく
先に述べたように、マネージド・サービスはサーバーレスの構成要素です。
SQSは、20年という長い年月を経てもなお、新しい機能や特徴を提供し続けています。
FaaSを含む多くのコアサーバーレスサービスは、統合をサポートし、観測可能性を向上させ、費用対効果を確保し、持続可能性を促進するなどの機能で常に更新されています。
この勢いが衰えることはないでしょう。
AWSは今後も新しいサーバーレスサービスを発表し続けるだろう
AWSコミュニティの関係者は、AWS Wishlistsの長いリストを知っている。顧客と密接に協力し、AWS HeroesやCommunity Buildersを通じて意見を集め、AWSは必要に応じて新しいサービスを立ち上げます。
サービス名は業界全体の議論になるかもしれないが、改善の余地は常にあります！
サーバーレスエコシステムはクラウドプロバイダーの外で進化する
我々が気づいているかどうかにかかわらず、サーバーレス・エコシステムは主要なクラウドプラットフォームの外側で成長しています。
業界は、FaaS、キャッシュ、データストア、エッジコンピューティング、GenAI/LLMなど、いくつかの新しいサービスの開発と採用に成功している。
例えば、Momento Cacheはクラウド機能を活用して、業界にシームレスなサーバーレス・キャッシュ・ソリューションを提供しています。
Infrastructure from Code（IfC）のようなエキサイティングな新しいコンセプトは、サーバーレスがサーバー管理から解放されたように、サーバーレスに未分化の重労働をもたらしました。
ジェレミー・ダリーとAmptのチームは、サーバーレスの上で業界がどのように革新しているかを示す一例です。
サーバーレスの業界導入は成熟とともに進む
多くの人が言っているように、サーバーレスを手に入れようとする最初の狂気の（ゴールド）ラッシュは終わりました。サーバーレス上で100種類の画像変換ソリューションを構築するという初期の興奮は、もはやエキサイティングなものではありません。
しかし、だからといってサーバーレスが終わったとは言えません！
いくつかの企業がサーバーレスを採用するにつれ、チームはかつてないスピードでビジネス機能を構築することに忙殺されるようになりました。その経験とともに
・より良い開発者ツール
・より良いアーキテクチャ・パターンとプラクティス
・より良い価格設定モデル
・より良い観測可能性オプション
・その他
が生まれ続けています。
これらは、成長する生態系を大切にするコミュニティの証であり、放棄ではありません。
サーバーレス・ファーストの意味は、サーバーレス・マストを意味するものではないが、今では業界でよく理解されています。
進化するテクノロジーは変化を受け入れる。サーバーレスも同じだ。
私はサーバーレスについていくつかの記事を書き、いくつかの講演を行ってきました。業界の多くの人たちと同じように、私はサーバーレス・エコシステムや特定のテクノロジーだけですべてのビジネス・ニーズに対応できるわけではないことを常に認識しています。
エコシステムの例えのように、サーバーレスは他のテクノロジーやエコシステムと連携し、より優れたビジネス価値をもたらすでしょう。
これがAWSの目指すところであり、サイロを壊し、Better Togetherという新しいスローガンを掲げてテクノロジーを包括的にすることです！
サーバーレスはすでに始まっている…
5年ほど前、ジェフ・バーとのオンラインチャットで、サーバーレスを超えるクラウドの次の進化が始まっているのか知りたくなりました。
ジェフは思慮深く答えた。「シーン、我々はサーバーレスを始めたばかりだ。」
10年以上にわたって採用され、成長してきたことで、私たちは胸を張ってそう言えるようになりました。
サーバーレスはすでに始まっている！
もはや相棒ではなく、メインストリームです。
テクノロジー・エコシステム間の透明性が高まれば、より多くのパートナーシップと相互尊重が生まれ、適切な仕事に適切なツールが普及するようになるでしょう。
サーバーレスはみんなのものです！
10年以上にわたり、サーバーレスは進化してきました。
私は以前、「サーバーレスはみんなのもの」という記事を書き、コミュニティのキャッチフレーズに共鳴して、サーバーレスが企業に適していることを主張しました。
サーバーレスの採用の難しさについて議論されるようになったとき、私は「サーバーレスの採用は難しいのか」という記事で答え、MomentoのAWS re: Invent 2023パーティーの美しいテーマ「Believe in Serverless」で締めくくった！
だから
サーバーレスは死んでいない
サーバーレスは業界にとって重要
サーバーレスのエコシステムは進化している
サーバーレスには数十年の先がある
サーバーレスは、それを信じるすべての人のためにここにある！
サーバーレスのおとぎ話はどうだろう？
まだ終わってはいない。物語は新たなエキサイティングな章で続いていく！
タイトル画像は、私のブログ「サーバーレス採用」からの修正版です： コストはまだ主な要因か？