キーポイント

• 数年前から、サーバーレス コンピューティングによって、アプリケーションを実行するための特定の OS が不要な新しい時代が到来すると約束されてきました。 この構造により、多くのスケーラビリティの問題が解決されると言われました。 実際には、すべてが異なります。
• 多くの人がサーバーレスを新しいアイデアと見なしていますが、そのルーツは 2006 年の Zimki PaaS と Google App Engine の出現にまで遡ります。どちらもサーバーレス アーキテクチャを使用しています。
• サーバーレス革命が停滞している理由は、プログラミング言語のサポートの制限からパフォーマンスの問題まで、XNUMX つあります。
• サーバーレス コンピューティングはそれほど役に立たないわけではありません。 全くない。 ただし、サーバーの直接の代替品と見なすべきではありません。 一部のアプリケーションでは、これらは便利なツールになる可能性があります。

サーバーが死んでいます。サーバー万歳！

これはサーバーレス革命の雄叫びです。 過去数年間の業界報道をざっと見ただけでも、従来のサーバー モデルは終わり、数年以内にすべてのサーバーレス アーキテクチャが使用されるだろうと結論付けるのは簡単です。

業界の誰もが知っているように、また私たちの記事でも指摘したように、 サーバーレスコンピューティングの現状、 これは間違っています。 メリットに関する記事がたくさんあるにもかかわらず、 サーバーレス革命、それは決して起こりませんでした。 実際には、 最近の研究によるとこの革命は行き詰まりを感じているのかもしれない。

サーバーレス モデルの期待の一部は確かに実現されていますが、すべてが実現されているわけではありません。 全員ではありません。

この記事では、この状態が発生する理由を見ていきたいと思います。 サーバーレス モデルは特定の明確に定義された状況では依然として有用であるにもかかわらず、サーバーレス モデルの柔軟性の欠如が依然として広範な採用の障壁となっている理由。

サーバーレス コンピューティングの達人が約束したこと

サーバーレス コンピューティングの課題に入る前に、サーバーレス コンピューティングが提供するはずだったものを見てみましょう。 サーバーレス革命の約束 多くの、そして時には非常に野心的なものでした。

この用語に馴染みのない人のために、簡単な定義を示します。 サーバーレス コンピューティングは、通常はリモートでホストされるランタイム環境でアプリケーション (またはアプリケーションの一部) がオンデマンドで実行されるアーキテクチャを定義します。 さらに、サーバーレス システムを自宅でホストすることもできます。 このアーキテクチャには、「従来の」クライアント/サーバー モデルに比べていくつかの重要な利点がある (主張されている) ため、復元力のあるサーバーレス システムの構築は、ここ数年、システム管理者や SaaS 企業にとって大きな懸案事項となってきました。

1. サーバーレス モデルでは、ユーザーは独自のオペレーティング システムを保守したり、特定の OS と互換性のあるアプリケーションを作成したりする必要がありません。 代わりに、開発者は共有コードを作成し、サーバーレス プラットフォームにアップロードして、その実行を監視します。
2. サーバーレス フレームワークのリソースは通常、分単位 (または秒単位) で請求されます。 これは、クライアントが実際にコードを実行した時間に対してのみ料金を支払うことを意味します。 これは、マシンがほとんどの時間アイドル状態であるものの、料金を支払う必要がある従来のクラウド VM と比べて有利です。
3. スケーラビリティの問題も解決されました。 サーバーレス フレームワークのリソースは動的に割り当てられるため、システムは需要の突然の急増に簡単に対処できます。

つまり、サーバーレス モデルは、柔軟で低コスト、スケーラブルなソリューションを提供します。 私たちがこのアイデアをもっと早く思いつかなかったのは驚きです。

これは本当に新しいアイデアですか?

実際、このアイデアは新しいものではありません。 コードが実際に実行されている時間に対してのみユーザーに支払いを許可するという概念は、によって導入されて以来存在しています。 Zimki PaaS 2006 年とほぼ同時期に、Google App Engine が非常によく似たソリューションを提供しました。

実際、現在「サーバーレス」モデルと呼ばれているものは、ほぼ同じものを提供する現在「クラウド ネイティブ」と呼ばれている多くのテクノロジーよりも古いものです。 前述したように、サーバーレス モデルは本質的には、数十年にわたって存在してきた SaaS ビジネス モデルの延長にすぎません。

また、サーバーレスと FaaS アーキテクチャの間には関連性がありますが、サーバーレスは FaaS アーキテクチャではないことも認識する価値があります。 FaaS は本質的にサーバーレス アーキテクチャのコンピューティング中心の部分ですが、システム全体を表すものではありません。

それで、一体何が大騒ぎになっているのでしょうか？ 発展途上国ではインターネットの普及率が急上昇し続けており、同時にコンピューティング リソースの需要も増加しています。 たとえば、電子商取引分野が急速に成長している多くの国には、これらのプラットフォーム上のアプリケーション用のコンピューティング インフラストラクチャがまったくありません。 ここで、有料のサーバーレス プラットフォームが登場します。

サーバーレスモデルの問題

問題は、サーバーレス モデルには問題があるということです。 誤解しないでください。私は、それらがそれ自体が悪いとか、状況によっては一部の企業に大きな価値を提供しないと言っているのではありません。 しかし、サーバーレス アーキテクチャが従来のアーキテクチャをすぐに置き換えるという「革命」の主な主張は決して実現しません。

それが理由です。

プログラミング言語の限定的なサポート

ほとんどのサーバーレス プラットフォームでは、特定の言語で記述されたアプリケーションのみを実行できます。 これにより、これらのシステムの柔軟性と適応性が大幅に制限されます。

サーバーレス プラットフォームは、ほとんどの主要言語をサポートすると考えられています。 AWS Lambda と Azure Functions は、サポートされていない言語でアプリケーションや関数を実行するためのラッパーも提供しますが、これには多くの場合パフォーマンス コストが伴います。 したがって、ほとんどの組織にとって、この制限は通常は大した問題ではありません。 しかし、ここからが問題です。 サーバーレス モデルの利点の XNUMX つは、実行時間に対してのみ料金を支払うため、ほとんど知られていない、ほとんど使用されないプログラムをより安価に使用できることです。 そして、あまり知られていない、めったに使用されないプログラムは、ほとんど知られていない、めったに使用されないプログラミング言語で書かれていることがよくあります。

これは、サーバーレス モデルの重要な利点の XNUMX つを損ないます。

ベンダーバインディング

サーバーレス プラットフォーム、または少なくとも現在の実装方法に関する XNUMX つ目の問題は、通常、それらが運用レベルで互いに類似していないことです。 関数の記述、展開、管理に関しては、実質的に標準化はありません。 これは、あるプラットフォームから別のプラットフォームへの機能の移行には非常に時間がかかることを意味します。

サーバーレス モデルへの移行で最も難しい部分は、通常は単なるコードの断片であるコンピューティング機能ではなく、アプリケーションがオブジェクト ストレージ、ID 管理、キューなどの接続されたシステムとどのように通信するかです。 関数は移動できますが、アプリケーションの残りの部分は移動できません。 これは、約束されている安価で柔軟なプラットフォームとは正反対です。

サーバーレス モデルは新しいものであり、その動作方法を標準化する時間がなかったと主張する人もいます。 しかし、上で述べたように、それらはそれほど新しいものではなく、コンテナなどの他の多くのクラウド テクノロジは、優れた標準の開発と広範な採用のおかげで、すでにはるかに使いやすくなっています。

Производительность

ベンダーが情報を非公開にする傾向があることもあり、サーバーレス プラットフォームのコンピューティング パフォーマンスを測定するのは困難です。 ほとんどの人は、リモートのサーバーレス プラットフォーム上の機能は、いくつかの避けられない遅延の問題を除いて、内部サーバー上の機能と同じくらい高速に実行されると主張しています。

しかし、個々の事実はその逆を示しています。 特定のプラットフォームで以前に実行されていない機能、またはしばらくの間実行されていない機能は、初期化に時間がかかります。 これはおそらく、ベンチマークと同様に、ほとんどのベンダーがデータ移行について教えてくれませんが、コードがアクセスしにくい記憶媒体に移植されているという事実によるものと考えられます。

もちろん、これを回避する方法はいくつかあります。 XNUMX つは、サーバーレス プラットフォームが実行されているクラウド言語に合わせて機能を最適化することですが、これはこれらのプラットフォームが「アジャイル」であるという主張を多少損なうものです。

もう XNUMX つのアプローチは、生産性が重要なプログラムを定期的に実行して最新の状態に保つことです。 もちろん、この XNUMX 番目のアプローチは、プログラムが実行されている時間に対してのみ料金を支払うため、サーバーレス プラットフォームの方が費用対効果が高いという主張とは少し矛盾しています。 クラウド プロバイダーはコールド スタートを減らすための新しい方法を導入していますが、その多くは「スケール トゥ XNUMX」を必要とし、FaaS の本来の価値を損ないます。

コールド スタートの問題は、サーバーレス システムを社内で実行することで部分的に解決できますが、これにはそれなりのコストがかかり、依然として十分なリソースを備えたチームにとってはニッチなオプションです。

アプリケーション全体を実行することはできません

最後に、おそらく、サーバーレス アーキテクチャがすぐには従来のモデルに置き換わらない最も重要な理由は、サーバーレス アーキテクチャは (通常は) アプリケーション全体を実行できないことです。

より正確に言えば、コストの観点から現実的ではありません。 成功したモノリスを、XNUMX つのゲートウェイ、XNUMX のキュー、および XNUMX 個のデータベース インスタンスによって接続された XNUMX 個の機能のセットにするべきではないでしょう。 このため、サーバーレスは新しい開発に適しています。 既存のアプリケーション (アーキテクチャ) はほとんど移行できません。 移行することはできますが、最初から開始する必要があります。

これは、ほとんどの場合、サーバーレス プラットフォームが、コンピューティング集約型のタスクを実行するバックエンド サーバーを補完するものとして使用されることを意味します。 このため、リモート コンピューティングを実行するための総合的な方法を提供する他の XNUMX つのクラウド テクノロジー (コンテナーと仮想マシン) とは大きく異なります。 これは、マイクロサービスからサーバーレスへの移行における課題の XNUMX つを示しています。

もちろん、これが常に問題になるわけではありません。 独自のハードウェアを購入することなく、大規模なコンピューティング リソースを定期的に活用できる機能は、多くの組織に実質的かつ永続的なメリットをもたらします。 しかし、一部のアプリケーションが内部サーバー上に存在し、他のアプリケーションがサーバーレス クラウド アーキテクチャ上に存在する場合、管理は新たなレベルの複雑さになります。

革命万歳?

これらすべての不満にもかかわらず、私はサーバーレス ソリューション自体に反対しているわけではありません。 正直に。 開発者が理解する必要があるのは、特に初めてサーバーレスを検討する場合は、このテクノロジがサーバーを直接置き換えるものではないということです。 代わりに、次のヒントとリソースを確認してください。 サーバーレスアプリケーションの作成 そしてモデルを適用する最適な方法を決定します。

出所： habr.com