PaaS、CaaS、FaaS、どれを選ぶべきか？

企業は、コンテナベースのアプリケーション向けのクラウド コンピューティング アーキテクチャを選択する際に、重要な問題と考慮事項を理解する必要があります。

[[319047]]

ハンバーガーを専門とする食料品店に入ることを想像してください。ハンバーガーにはいろいろな種類があり、選択肢はたくさんあるものの、ハンバーガーしかありません。

ハンバーガーシェフなら、ハンバーガーを作るのに必要な牛肉や鶏肉などのタンパク質のほか、チーズ、バンズ、野菜、調味料などの材料を店内で選ぶことができ、ハンバーガーを提供する皿や容器も選ぶことができます。

自分でハンバーガーを作る時間も技術も興味もない場合は、店で買うこともできます。伝統的なメニューに加え、ベジタリアンバーガーなどもございます。キットの指示に従うだけで、おいしいハンバーガーが完成します。

ハンバーガーシェフが突然、昼食前の 2 時間以内に 300 種類のハンバーガーを作らなければならないという通知を受けたとします。さらに、ハンバーガーを作ること以外にも、顧客にサービスを提供して報酬を得るためのプロセスを実装する必要があります。顧客の中には特別注文を希望する人もいれば、少ない注文をする人もいるので注意が必要です。

最後に、昼食時にも健康と安全のチェックが必要なので、何が行われてもそれに従うのがよいでしょう。そして、作業できるのは少数の人員のみであり、彼らにはこの種の業務の経験がほとんどありません。

クラウドバーガーを作る

クラウド コンピューティング アーキテクチャの選択は、ハンバーガー作りの即興に非常に似ており、多くの点ではるかに複雑です。実行するクラウド コンピューティング アーキテクチャを検討する場合、開発者、エンジニア、アーキテクト、IT リーダーは、プラットフォーム、パフォーマンス、規制など、さまざまな考慮事項を考慮する必要があります。

どのクラウド コンピューティング アーキテクチャが顧客に優れたエクスペリエンスを提供し、より高品質の製品を提供するのでしょうか?どちらの方が操作しやすく、納期も守れるでしょうか?サポート、コンプライアンス、セキュリティの問題をより適切に処理できるのはどのパスでしょうか?最後に、どのアプローチが最も低コストで実装できるでしょうか?

エンジニアは Container as a Service (CaaS) オプションを選択してアプリケーションをコンテナ化できます。これは、ハンバーガー シェフが食事を作って調理するのと同じです。そのような専門知識がない場合、PaaS オプションはツール スイートを選択し、指示と制限に従うことに相当します。

Container as a Service (CaaS) も Platform as a Service (PaaS) もニーズに合わないですか?すべてをゼロから構築することも (Infrastructure as a Service)、関数をサーバーレス環境にデプロイすることもできます (Function as a Service)。

Function as a Service (FaaS) は、単一のタスクに応答するように設計されたサーバーレス コンピューティングの一種です。たとえば、Function as a Service (FaaS) を使用すると、ユーザーの認証、テキスト本文のスペルチェック、数学的計算を実行できます。

明らかに、クラウド プラットフォームへのコードのホスティング、構成、管理、およびデプロイには、多くのアーキテクチャ オプションがあります。さまざまな製品を考慮すると、状況はさらに複雑になります。 PaaS オプションには、Azure App Service、AWS Elastic Beanstalk、Google App Engine、Red Hat OpenShift、Salesforce の Heroku などがあります。 Container-as-a-Service (CaaS) ソリューションを検討している場合、Azure、Google、AWS にはそれぞれ独自のマネージド Kubernetes サービスがあり、それぞれに独自の頭字語 (それぞれ EKS、GKE、AKS) があります。さらに、VMware、IBM、Oracle、Rackspace などのオプションもあります。

もちろん、サーバーレスのオプションは他にもたくさんあります。 Azure Serverless には、サーバーレス関数、Kubernetes ポッド、アプリケーション環境が備わっています。 AWS クラウド プラットフォームには現在、より幅広いサーバーレス オプションがあり、サーバーレスをコンピューティング、ストレージ、データ ストレージ、API プロキシなどの機能カテゴリに分類しています。Google Cloud では、BigQuery や AutoML などのサービスを含む、より広範なサーバーレスの定義が採用されています。

CaaS、PaaS、FaaS、サーバーレスに関する重要な考慮事項

これらのさまざまなクラウド コンピューティング アーキテクチャを検討する際には、さらにいくつか留意すべき点があります。

• 対象ユーザー – プラットフォーム アズ ア サービス (PaaS) および機能 アズ ア サービス (FaaS) オプションは、ソリューションの構成を容易にし、継続的インテグレーション (CI)/継続的デリバリー (CID) パイプラインと統合して展開できるようにすることで、まず開発者を対象としています。コンテナは動作環境とプラットフォーム構成をパラメータ化するため、これらのツールは運用スタッフやシステム管理者を対象としていることが多いです。
• 構成可能性と俊敏性 – 通常、Container as a Service (CaaS) は最も構成可能なオプションであり、オペレーターにコンテナ化のプラットフォームと構成を選択する際の柔軟性を提供します。プラットフォーム・アズ・ア・サービス (PaaS) および機能・アズ・ア・サービス (FaaS) オプションは俊敏性に重点を置いており、開発者がコードをより迅速に展開およびテストできるようにします。
• 一部の PaaS ソリューションはロックインされています - PaaS および FaaS ソリューションは設計によって事前に選択されており、プラットフォームの選択と構成オプションによってロックインされています。これらのソリューションは、開発者のニーズ、ベスト プラクティス、目標のパフォーマンス特性に関する設計者の意見に基づいて設計されています。より高い柔軟性や制御性を求めるオペレーターにとって、このようなサービスとしてのプラットフォーム (PaaS) やサービスとしての関数 (FaaS) の導入は困難を伴う可能性があります。
• スキルと学習曲線 – CaaS ソリューションは PaaS や FaaS ソリューションよりも学習曲線が急峻で、より多くのスキルが必要であると一般化するのは妥当です。
• ベンダー ロックイン – Container-as-a-Service (CaaS) ソリューションは Kubernetes 上で開発されることが多く、さまざまなクラウド ホスティング オプション間で移行できます。 Platform as a Service (PaaS) および Function as a Service (FaaS) ソリューションは Kubernetes を基盤として設計できますが、通常は Kubernetes レイヤーをエンドユーザーに公開せず、代わりにより簡素化された構成を提供します。これらの構成は、Platform as a Service (PaaS) および Function as a Service (FaaS) ソリューションに固有のものであり、通常は 1 つのクラウド プラットフォームでのみ実行されるように設計されています。一部の IT リーダーはこの問題を認識しており、単一のクラウド コンピューティング ベンダーに縛られることを当然ながら懸念しています。

研究とプロトタイピングを導くための質問

非常に多くの選択肢に直面すると、一部の企業は最小限の調査とプロトタイプ作成のみを行い、迅速な道を選択します。他の人は、オプションの調査、専門家への相談、信頼性の高い実装のためのオプションの選択に多大な時間、労力、費用を費やします。

どちらのアプローチも、選択肢が多すぎてビジネスが麻痺したり圧倒されたりするよりも優れています。あらゆる組織が技術的優位性を獲得しようとしている変化の激しい世界では、保守的になりすぎて現状維持を続けると、市場機会を阻害するだけです。

そのため、業界の専門家は、選択肢と競争を絞り込むのに役立ついくつかの重要な質問をします。

（1）あなたの組織は、少数のアプリケーションしか実行できない小規模なチームですか？このような場合は、多くの時間と専門知識を投資することなく、必要なプラットフォームのほとんどを事前に構成できる、よりシンプルな PaaS およびサーバーレス オプションを検討する必要があります。 「成功するためにより多くの変更管理サポートを必要とする中小企業や、成熟度、安定性、速度を迅速に高めたいと考えている企業にとって、PaaS は実装と効率性の向上へのより迅速な道筋を提供するため魅力的です」と、AvidXchange のプラットフォーム アーキテクチャ ディレクターである DJ Navarrete 氏はアドバイスしています。

（2）散発的なペイロードがありますが、必要に応じてスケールアップする必要がありますか？範囲はマイクロサービスまたは関数にすることができますが、完全なアプリケーションやデータベースにまで拡張することもできます。これらのユースケースは、使用したリソースに対してのみ料金を支払うサーバーレス コンピューティングに適しています。

（３）企業には、コンテナ、アプリケーション、データベース、オペレーティングシステム、またはインフラストラクチャの特定の基本オプションまたは設定に関する報告を義務付けるコンプライアンス義務または規制基準がありますか？これがサーバーレス オプションを除外する大きな理由だと、Microsoft の Modern Workplace Center of Excellence のセキュリティおよびコンプライアンス アーキテクトである Wayne Anderson 氏は言います。 PCI 規制やその他のコンプライアンス要件は、法務部門や監査人によって、コンピューティング環境のセットアップの証明が必要であると解釈されることがよくあります。

（4）企業は多くの独自プラットフォームやレガシーアプリケーションを活用していますか？このような場合、互換性のある Platform as a Service (PaaS) オプションを見つけるのが難しい場合があります。同時に、コンテナを開発することで、デプロイメントと依存関係の管理を簡素化できます。

（5）複数のクラウドプラットフォームで運用し、さまざまなアプリケーションやデータプラットフォームを運用している大規模な組織や企業の場合、複数のプラットフォームと構成オプションをサポートする柔軟性が向上するため、コンテナを標準化することを選択する場合があります。コンプライアンスが考慮されない場合でも、サーバーレスを検討できます。企業が Kubernetes の幅広いオプションを活用するのに十分なスキルと能力を持っている場合、その企業はサービスとしてのプラットフォーム (PaaS) オプションを避けることができます。 Shopify のように十分な規模と技術スキルを持つ組織は、Kubernetes とコンテナに基づいて独自のプラットフォーム アズ ア サービス (PaaS) を設計することを選択できます。

（6）企業はマイクロサービスを開発し、クラウドベースのマイクロサービスアーキテクチャを標準化していますか？ Mark Heath 氏は、コンテナまたはサービスとしてのプラットフォーム (PaaS) が、コンテナ内での関数のホスティングと同様に、良い選択肢であると示唆しています。 Heath 氏は、サーバーレス関数は構成が簡単でサポートも安価になる可能性がある一方で、コンテナはオンプレミス開発を簡素化し、エンドポイントを保護するためのより多くのオプションを提供できる可能性があると述べています。

（7）クラウドコンピューティングコンサルタントのSarbjeet Johal氏は、プラットフォーム、アプリケーション、サービスのいずれを構築する場合でも、対象者は社内、社外、または顧客志向であると指摘しています。アプリケーションの種類とエンドユーザーの種類を理解することで、企業は将来のニーズを予測できるようになります。 「外部アプリケーションの場合、より多くのアクセス制御を文書化する必要があります。データ量は予想外に増加する可能性があり、外部アプリケーションの寿命は内部アプリケーションよりも長くなる可能性があります」と Johal 氏は述べています。 「サービスまたはプラットフォームが機械消耗品である場合、計測が必要になる可能性があります。」

ロードマップと将来のニーズを予測することで、特定のオプションを推進し、他のオプションを除外するのに役立ちます。選択肢を絞り込んだら、概念実証を行うのが良い方法です。