サーバーレス革命が行き詰まっている理由

キーポイント



  • ここ数年、サーバーレスコンピューティングは、アプリケーションを実行するための特定のOSがなくても、新しい時代の到来を告げるものであると約束されてきました。そのような構造は多くのスケーラビリティの問題を解決すると言われました。実際、すべてが異なります。

  • 多くの人がサーバーレステクノロジーを新しいアイデアと見なしていますが、そのルーツは、サーバーレスアーキテクチャを使用するZimkiPaaSとGoogleAppEngineが導入された2006年にさかのぼることができます。

  • プログラミング言語のサポートの制限からパフォーマンスの問題まで、サーバーレス革命が行き詰まっている理由は4つあります。

  • サーバーレスコンピューティングはそれほど役に立たないわけではありません。どういたしまして。ただし、サーバーの直接の代替と見なすべきではありません。一部のアプリケーションでは、これらは便利なツールになります。


サーバーは死んでいます、サーバーは長生きします!



これは、サーバーレス革命の達人たちの戦いの叫びです。過去数年間の業界の報道を一目見れば、従来のサーバーモデルは廃止されており、数年後にはすべてサーバーレスアーキテクチャを使用することになると簡単に結論付けることができます。



業界の誰もが知っているように、またサーバーレスコンピューティング状態に関する記事でも指摘したように、これは当てはまりません。サーバーレス革命のメリットに関する多くの記事にもかかわらず、それは実現しませんでした。実際、最近の研究は、この革命が行き詰まっている可能性があること示唆しています。



サーバーレスモデルの約束のいくつかは間違いなく実現されていますが、すべてではありません。全員ではありません。



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



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



サーバーレスコンピューティングの問題に入る前に、彼らが何を提供しなければならなかったかを見てみましょう。サーバーレス革命の約束は数多くあり、時には非常に野心的でした。



この用語に慣れていない人のために、ここに簡単な定義があります。サーバーレスコンピューティングは、通常はリモートでホストされるランタイム環境で、アプリケーション(またはアプリケーションの一部)がオンデマンドで実行されるアーキテクチャを定義します。さらに、サーバーレスシステムをホストできます。過去数年間、復元力のあるサーバーレスシステムの構築は、sysadminおよびSaaS企業にとって最大の関心事でした。これは、このアーキテクチャが「従来の」クライアント/サーバーモデルに比べていくつかの重要な利点を提供するためです。



  1. , , . , .

  2. ( ). , , . VM, , .

  3. . , .


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



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



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



実際、現在「サーバーレス」モデルと呼ばれているものは、現在「ネイティブクラウド」と呼ばれている多くのテクノロジーよりも古く、ほとんど同じものを提供します。前述のように、サーバーレスモデルは、基本的に、数十年前から存在しているSaaSビジネスモデルの単なる拡張です。



サーバーレスモデルはFaaSアーキテクチャではありませんが、2つの間に接続があることも認識しておく価値があります。FaaSは本質的にサーバーレスアーキテクチャのコンピューティング指向の部分ですが、システム全体を表すわけではありません。



それで、すべての騒ぎは何ですか?さて、開発途上国でのインターネット普及の速度が急上昇し続けるにつれて、コンピューティングリソースの需要も同時に増大しています。たとえば、急速に成長しているeコマースセクターを持つ多くの国には、これらのプラットフォーム上のアプリケーション用のコンピューティングインフラストラクチャがありません。これが有料のサーバーレスプラットフォームの出番です。



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



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



それが理由です。



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



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



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



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



ベンダーバインディング



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



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



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



パフォーマンス



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



しかし、いくつかの事実はそうではないことを示唆しています。以前に特定のプラットフォームで実行されていない関数、またはしばらく実行されていない関数は、初期化に時間がかかります。これはおそらく、コードがアクセスしにくいストレージメディアに移植されたためですが、ベンチマークの場合と同様に、ほとんどのベンダーはデータ転送について説明していません。



もちろん、これを回避する方法はいくつかあります。 1つは、サーバーレスプラットフォームが実行されているクラウド言語の機能を最適化することですが、これは、これらのプラットフォームが「柔軟」であるという主張をいくらか弱体化させます。



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



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



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



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



より正確には、費用対効果は高くありません。成功したモノリスは、8つのゲートウェイ、40のキュー、および1ダースのデータベースインスタンスによってリンクされた4ダースの関数のセットに変換されるべきではありません。このため、サーバーレスは新しい開発に適しています。既存のアプリケーション(アーキテクチャ)はほとんど移行できません。移行することはできますが、最初から始める必要があります。



これは、ほとんどの場合、サーバーレスプラットフォームを使用して、計算量の多いタスクのバックエンドサーバーを補完することを意味します。これは、リモートコンピューティングを実行するための包括的な方法を提供する他の2つの形式のクラウドコンピューティング、コンテナ、および仮想マシンとは大きく異なります。これは、マイクロサービスからサーバーレスシステムに移行する際の課題の1つを示しています。



もちろん、これは必ずしも問題ではありません。独自のハードウェアを購入せずに大量のコンピューティングリソースを定期的に使用できることで、多くの組織に真の永続的なメリットをもたらすことができます。ただし、一部のアプリケーションが内部サーバーでホストされ、他のアプリケーションがサーバーレスクラウドアーキテクチャでホストされている場合、管理は新たなレベルの複雑さを帯びています。



革命は長生きしますか?



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



All Articles