PaaSの一般的な用途

　PaaSが企業にとってメリットになるかどうかを判断するために最初に把握すべきことがある。PaaSベンダーが提供する機能の種類と、チームでそうした機能を広く活用する方法だ。

アプリケーションの市場投入までの時間を短縮

　アプリケーション開発では、最初の構想から最終リリースに至るまで多くの手順を踏む必要がある。こうした手順の多くは特定のアプリケーション固有のものだ。一方、全てのアプリケーション開発者が実行しなければならない共通かつ繰り返しのタスクも多い。PaaSを使用すると、アプリケーションの市場投入までの時間が計画的に短縮される。維持管理やメンテナンスのタスクを自動化したり、場合によっては完全に排除したりして実現する。このようなタスクには、CI（継続的インテグレーション）／CD（継続的デリバリー）パイプラインのセットアップ、ドメインネームシステム（DNS）設定の構成、アプリケーション用ストレージのリソース調整（プロビジョニング）などがある。

運用コストモデルへの移行

　従来のオンプレミス型アプリケーションの開発では設備投資が予算の大半を占めていた。アプリケーションを実装（ホスト）するためのハードウェアや機器をチームで購入して管理し、最終的に減価償却する必要があった。それに対して、クラウドホスティングではこれらの支出が設備投資から経常運用費に変わる。

　この変化には長所も短所もある。1つのメリットは管理者が一部の運用コストを徹底的に削減できることだ。これには実際の人件費から追加インフラコストまで含まれる。また、アプリケーションの需要に合わせて拡大縮小されるコスト構造を導入することも可能になる。

インフラ管理の削減

　前述のように、PaaSは拡張性の高いインフラを管理する負担の軽減に役立つ。PaaSでは負荷分散、拡張、さらには新しい依存関係サービスのプロビジョニングに伴う複雑さが抽象化される。これらのタスクには開発者ではなく、PaaSベンダーが対処することになる。

新しいツールやクラウドサービスへのアクセスを提供

　これまでに述べたことに加え、最先端の開発ツールにアクセスできるようになることがPaaSの重要なセールスポイントになっている。小規模チームや独立系開発者にとっては特に魅力的だ。規模の大きな組織の場合、真の価値は新しいテクノロジーの導入に伴う管理を減らせることにある。例えば、CIパイプラインを確立するには、従来の方法だと新しいサーバを起動してプロビジョニングし、ネットワーク経路を更新して、ファイアウォールを解除する必要があるだろう。PaaSではこれらのタスクがネイティブに処理されるため、中間業者が実質不要になる。

　さらに、PaaSでは新しいプログラミング言語や、コンテナやサーバレス機能のような新しいテクノロジーがサポートされる。そのため、成長を促すための手段がより多くもたらされる可能性がある。銀行業や製造業など、技術進歩が比較的遅い業界内では特にそうだろう。それも、ビジネスのやり方を大きく変える必要はない。

　必然的に、クラウドホスティングベンダーを利用すると、そのベンダーの他のクラウドサービスにもアクセスしやすくなる。例えば、単純にオブジェクトストレージの基盤やデータベースサービスに対し、1つの認証方式でアクセスできる、というわけではなく、クラウドホスティングするアプリケーションとサービスの統合が大幅に単純化できる可能性がある。

PaaSの欠点

　メリットはあるものの、PaaSは全てのアプリケーションに最適なわけではない。セキュリティから可用性まで、他のアプリケーションホスティング手法との比較でPaaSを評価する際に開発チームが考慮しなければならない課題は幾つかある。

　PaaSに共通する一部の欠点や問題には次のようなものがある。

セキュリティとコンプライアンスのリスク

　PaaSソフトウェアは一般的にパブリックのマルチテナント環境で利用できる。つまり、複数のエンドユーザーが同じ基盤となるリソースを共有する。多くのアプリケーションではあまり問題にならないが、が、機密データが多数含まれていたり、厳格なコンプライアンス要件があったりするアプリケーションでは、マルチテナントのリスクが大きくなる可能性がある。この場合、PaaSの選択と構成に関して企業ではより精力的な取り組みが必要になるかもしれない。

高騰するコスト

　PaaSは確かにコストを削減する機会を提供する。だが、大規模アプリケーションは適切に管理されていないと運用コストが非常に高くなることがある。一般に、PaaS環境でアプリケーションを運用するコストはその規模に直接関係する。そのため、アプリで運用や拡張する必要のあるリソースに常に留意しなければならない。

ベンダーロックイン

　PaaSベンダーには独自の構成要件がある。そのため別のベンダーへの移行が難しい。はっきり言って、PaaSではベンダーロックインをほぼ避けられない。

　多くの場合、ベンダーはPaaS基盤が包括的になるように設計している。そのため、開発者は自分が選んだ開発基盤の機能が制約になると感じることがある。つまり、データベースのテクノロジーからサポートされる言語まで、あらゆる要素がアプリケーションの設計方法や構築方法に影響しかねない。必要な機能がサポートされていなければ、気に入っているベンダーを除外せざるを得なくなることもあり得る。

サービスの可用性

　どのクラウドサービスにも伴うリスクとして、可用性に対する制御が小さくなることがよく知られている。だが、PaaS環境ではこのリスクの影響をさらに受けやすい恐れがある。前述したベンダーロックインの問題があるためだ。例えば、従来の仮想環境でアプリケーションをホストする場合、負荷分散を利用してさまざまなベンダー間で冗長性を維持する仕組み（フェイルオーバーメカニズム）を確立することは比較的たやすい。だがPaaSの場合、チームで使えるツールセットが、ベンダー独自の、そして多くの場合は専用のものに限られる。そのため、こうしたプロセスが難しいものになる。