クラウドとコンテナがアプリケーションサービスの分散化を推進する方法

• アプリケーションは、場所から配信インフラストラクチャをサポートするフォームファクターまで、あらゆる決定を推進します。 組織の 55% は、アプリケーションのニーズと要件に基づいてクラウドを選択します。 40% は、アプリに適したフォームファクターを選択できるようにしたいと考えています。 (アプリケーション配信の現状 2018)
• クラウドとマイクロサービスアーキテクチャがアプリを分割して配布するにつれて、共有インフラストラクチャはメリットではなく負担となり、資本コストと運用コストが増加します。 
• コスト、構成、アップグレードは、アプリごとのアプリケーション サービスを使用してアプリごとのアーキテクチャをサポートする上で重要な要因です。
• 最新のアプリとアーキテクチャをサポートするには、アプリケーションサービスに対するアプリごとのアプローチが必要です。

過去数年間、Amazon、Microsoft、Google などのクラウド プロバイダーが、アプリケーション サービスに対する企業のニーズに応えるために共同で取り組んできました。

今日のクラウド マーケットプレイスには、セキュリティ (Web アプリケーション ファイアウォールなど) だけでなくパフォーマンス (キャッシュ)、さらには ID 管理にも対応したアプリケーション サービスが数多く存在し、その数は増え続けています。 これは驚くことではありません。 企業は、アプリをより高速かつ安全に動作させるために、平均 16 種類の異なるアプリケーション サービスに依存しています。 その数は毎年増え続けています。 企業はクラウドのスピードのためにそれらを犠牲にするつもりはありません。

その点で、アプリケーション サービスは顧客とクラウド プロバイダーの両方に影響を与えています。 しかし、それは一方通行ではありません。 クラウド、そしてますますコンテナも、アプリケーション サービスとその提供方法に大きな影響を与えています。  

企業組織がプライベート (オンプレミス) クラウドへの投資とコンテナの実験を続けるにつれ、アプリケーション サービスを提供する従来のモデルが必ずしも適切ではないことがわかってきました。

ほとんどのネットワークと同様に、アプリケーション サービスは長い間、スケーラブルで信頼性の高いハードウェアによってサポートされるプラットフォーム (多くの場合、アプリケーション配信コントローラーまたは略して ADC と呼ばれます) を介して提供されてきました。 これらのデバイスは、高可用性とスケーラビリティを実現するように設計されており、数百のアプリケーションを同時にサポートできます。 ネットワークであれアプリケーションであれ、共有インフラストラクチャにはコスト面でのメリットが長い間ありました。 資本コストと運用コストを複数のアプリケーションに分散することは理にかなっています。

それが実現できなかった場所にアプリやアーキテクチャが登場するまでは。

よりアプリケーションに適したアプローチを必要とするアプリやアーキテクチャが増えています。 たとえば、現代のマイクロサービスでは、単一のアプリケーション用のアプリケーション サービスを展開するための、高速でスケーラブルかつ手頃な価格のプラットフォームが求められています。

共有サービス プラットフォームでは、意図的に設計されたアプリごとのプラットフォームのようにその需要を満たすことはできません。 それには次の 3 つの理由があります。

1. 料金。 12 人乗りのバンを使用するのが自分だけなら、わざわざそのバンを購入する人はいないでしょう。 余分なスペースを確保するには、初期費用と運用費用がかかります。 適切な状況（および適切なアプリケーション）では、共有インフラストラクチャによってアプリケーションあたりのコストが削減され、財務上および運用上の大きなメリットが得られます。 しかし、単一のアプリケーションのみをサポートしようとすると、価値は追加されずに費用だけが加算されます。
2. 構成。最新のアプリとアーキテクチャは、頻繁な更新を念頭に置いて開発および展開されています。 同じスケジュールではない 8 つの他のアプリとプラットフォームを共有している場合、何か問題が発生してアプリケーションに影響が出ると、他のアプリは少々不満を抱くかもしれません。 言うまでもなく、構成の数が増え、構成が大きくなると、構成を再読み込みまたは変更する必要があるたびに、それらの構成を読み取って検証するのにかかる時間も長くなります。
3. アップグレード。 Bob がその共有プラットフォームをアップグレードしたいのに、あなたがアップグレードしたくない場合は、どちらが勝つでしょうか? ボブが勝って、それがアプリケーションを壊した場合、誰も勝者にはなりません。  共有インフラストラクチャのアップグレードは恐ろしい提案となる可能性があります。 また、最新バージョンへの構成の更新やアップグレード (または移行) に追加の時間がかかる可能性があり、これは問題 1 に戻り、コストが増大する可能性があります。

単一のアプリケーションのみをサポートするように意図的に設計されたアプリケーション サービス プラットフォームの必要性 (および需要) があります。 責任を単一のアプリケーションに減らすことで、構成のサイズ (および複雑さ) が削減され、アップグレードの失敗による影響範囲が単一のアプリケーションに限定され、取得と運用の両方のコストが削減されます。

クラウド、コンテナ、マイクロサービスのためです。 DevOps とデジタル経済により、組織はより迅速かつ頻繁に成果を出すことができるようになります。

アプリケーションとアーキテクチャは変化しています。 環境は変化しています。 つまり、アプリケーション サービスとその配信メカニズムも変更する必要があります。