IaaS は優れているが、そうではない: PaaS の復活

開発者は、サービスとしてのプラットフォーム (PaaS) の将来に疑問を投げかけていますが、それには正当な理由があります。彼らの多くは PaaS で成功した製品を構築しましたが、アプリが一定の規模に達すると、さらに多くの製品が必要であることに気付きます。透明性の欠如と独断的なブラックボックス機能のために、パフォーマンスの問題を簡単にデバッグすることはできません。 Web アプリケーション ファイアウォールのように、完全に構成可能なセキュリティとコンプライアンスの制御を実装することはできません。彼らは、プラットフォームが提供する限定されたアドオンに固執しています。永続ストレージ、構成可能な負荷分散、自動スケーリングなどの機能は、存在しないか、PaaS で実際に使用するには制限が多すぎます。

では、開発者は何をするのでしょうか?アプリをサービスとしてのインフラストラクチャ (IaaS) に移植します。

IaaS の方が優れているということではなく、実装の制限がないということです。開発者は、IaaS プロバイダーを使用して必要なものを構築できます。トレードオフは、時間、専門知識、および追加の人員配置の 1 つです。しかし、成功した PaaS アプリを持つほとんどの開発者にとっては問題ありません。開発者は、何かを構築し、プロダクト マーケット フィットを見つけるという困難な部分を既に乗り越えているからです。彼らは、IaaS への移行の学習曲線についてそれほど心配していません。その時点までに、ユーザー ベース、収益、滑走路があるからです。

PaaS が大規模な実行可能なオプションである場合、開発者はアプリを IaaS に移植しない可能性があります。しかし、それは PaaS が IaaS よりも劣っているということを意味するのでしょうか?しそうにない。 PaaS の未来は明るいです。多くの開発者が認識しているよりもはるかに明るいです。実際、私は PaaS がソフトウェア開発の未来を支配すると信じています。市場は、今日の開発者のエクスペリエンスと価値を飛躍的に向上させるために、「開始して拡張するのに最適な」プラットフォームを切望しています。 PaaS は、グローバルにスケーラブルなアプリ配信を確実にサポートしますが、最初にいくつかの課題を克服する必要があります。

IaaS は優れている

IaaS の優れた点は、ほぼ無限の構成とスケーラビリティ オプションが提供されることです。 IaaS プロバイダーは、事実上すべてのユースケースをあらゆる規模でサポートできるように、製品を十分に一般化しています。それは信じられないほど強力で費用対効果が高いです。さらに、IaaS プロバイダーは、採用を促進し、チームを夢中にさせるために、使用クレジットと割引価格を喜んで提供します。

ただし、自分の足で撃たずにスケーラブルな構成を構築することは非常に困難です。不適切な構成変更は壊滅的な結果をもたらす可能性があり、インフラストラクチャに関する深い専門知識がなければ、トラブルシューティングと修復はほぼ不可能です。 (費用のかかるエンタープライズ契約以外では) 利用できるプラットフォーム サポートは事実上なく、IaaS のドキュメントは一貫性がなく、読みにくいことで有名です。また、IaaS コンソールの実際のユーザー エクスペリエンスについても触れないでください。

IaaS に全面的に取り組むということは、IaaS を使用および管理するための高価なインフラストラクチャ チームを構築することを意味します。インフラストラクチャの専門家は、業界で最も需要の高い人材であるだけでなく、独自の成長ニーズを乗り切る方法を知っている適切な人材を見つけることは非常に困難です。これらの複雑さに加えて、より厳しい資金調達環境の現実、チームは「より少ないリソースでより多くのことを行う」ように言われ、IaaS ソリューションの急速な複雑化が進んでいます。チームの仕事は、成長するインフラストラクチャをセットアップして維持することであり、この仕事が「終了」することはありません。

企業が IaaS を使用してたどる典型的な旅は次のようになります。

1. アーキテクチャを決定して実装するために、バックエンドまたはインフラストラクチャの専門エンジニアを 1 ～ 2 人雇います。
2. チームが成長し、離職が発生すると、アーキテクチャが有機的に変化します。
3. 現在インフラストラクチャを維持しているチームは、最初にインフラストラクチャを構築したチームではなくなりました。
4. 何かが壊れたら、直すのは悪夢です。決定が下された理由を誰も覚えておらず、部族の知識が失われ、数か月前に機能していたものが、誰も理解していないため、今では「レガシー」になっています。

資金調達の問題と利用可能なインフラストラクチャ人材の不足の間で、インフラストラクチャとプラットフォームの作業への投資を深めることをお勧めすることは困難です. IaaS の機能はますます複雑になり、PaaS が提供するものと同様に、より高いレベルの抽象化の必要性がますます高まっています。

IaaS は PaaS ができることを望んでいる

IaaS プロバイダーはこれを知っているため、PaaS のような抽象化に投資しています。 Google は、モバイル開発プラットフォームである Cloud Platform とFirebaseを使用して、この点でかなりうまくいっています。 Amazon は抽象化を構築しようとしてきましたが、開発者のエクスペリエンスは…良くありません。それにもかかわらず、 S3 オブジェクトの自動暗号化やAWS Secrets Manager との RDS 統合など、開発者がより良いエクスペリエンスを望んでいる (そしてそれに値する) ことを彼らが理解していることは明らかです。 Azure はApp Serviceを提供するようになりました。これにより、自動スケーリング インフラストラクチャへのデプロイが簡素化されます。

主要なクラウド プロバイダーは、PaaS のようなサービスを提供することで成果を上げていますが、従来のリフト アンド シフト戦略や SF のような「サーバーレス Kubernetes」の空想にも焦点を当てています。彼らは大部分の現金を企業から得ているため、より多くの企業にサービスを提供するために機能開発にバイアスがかかっています。新興企業や中規模企業は、彼らのフィードバックが、高度なインフラストラクチャの専門知識を必要としない、使いやすく構築しやすい PaaS のような環境につながることを望んでいます。

Raman Sharma 氏は次のように述べています。 .そのため、彼らは (当時の AWS のように) IaaS 中心に軸足を移しました。」

言い換えれば、IaaS がそれほど儲からなければ、IaaS は PaaS を行っていたでしょう。彼らはスタートアップにサービスを提供しているのではなく、企業にサービスを提供しています。

IaaS は競争上の優位性ではなく、気を散らすものです

IaaS で構築することは、多くの自由と機会を提供しますが、AWS 認定の管理者に 15 万ドルを費やすか、収益を生み出す機能を構築できる開発者に 15 万ドルを費やすか?

インフラストラクチャについて心配する必要がなければ、開発者を雇うことは簡単です。残念ながら、企業が両方の世界で最悪の事態に陥ることは珍しくありません。15 万ドルの開発者を雇い、すべての DevOps 作業も行うように強制します。それは、費用対効果がはるかに低いです。

PaaS から IaaS に移行する製品チームにも、IaaS から始めてスケールアップする製品チームにも、競争上の優位性はまったくありません。ある時点で、必然的に、高価で経験豊富なクラウド インフラストラクチャ アーキテクトを雇う必要があります。もちろん、私は熟練したクラウド インフラストラクチャ エンジニアに反対するつもりはありませんが、「より少ないリソースでより多くのことを行う」という財務上の圧力が高まっているときは、オーバーヘッドを増やすことにあまり興奮していません。

さらに、仮に私が世界最高のクラウド インフラストラクチャ チームを持っていたとしても、それが私が仮想的に恐れているほどコストがかからなかったとしても、そのチームを持つことの競争上の利点は何ですか?それは実際にビジネスにどのような利点をもたらしますか?正直に言うと、価値を保護する管理者よりも、価値を生み出す開発者の無駄のないチームを望んでいます。はい、IaaS に時間とエネルギーを費やして、永続ディスク、データベースのポイントインタイム リカバリ、構成可能な負荷分散、Blue/Green デプロイ ロジック、および自動スケーリングを取得できますが、ほとんどの開発者はむしろすべてを使用することを保証しますうまく設計されたUIのチェックボックスで利用できます。

明かりをつけ続けることに専念しなければならない時間が増えるほど、製品にお金をかけたいと思っている顧客に優れた機能を提供するために費やす時間が少なくなります.インフラストラクチャの増加、価値の減少。

IaaSの問題を解決するPaaS

そもそも PaaS が存在する主な理由は、IaaS が複雑すぎるためです。開発者は、コードを作成してデプロイしたいと考えています。彼らは、新しいアプリと機能を構築し、市場がどのように反応するかを確認し、反復したいと考えています。そして、彼らはこれを可能な限り少ないハードルで実現したいと考えています。

たとえば、ヘルスケアに焦点を当てた SaaS を構築するために HIPAA 準拠のインフラストラクチャが必要な場合、不完全で複雑なAmazon のリファレンス アーキテクチャから始めて、数週間かけて稼働させることができます。または、Aptible でアプリを数分でスピンアップして、それが HIPAA に準拠していることを確認できます。

同じことが PCI コンプライアンスにも当てはまります。 Stack Overflow と Reddit には、大規模な IaaS クラウドで PCI 準拠のインフラストラクチャを確立して維持するための困難な戦いの例と警告がたくさんあります。または、PCI 準拠の PaaS を見つけて、ファイアウォールの構成に費やす時間をゼロにすることもできます。

問題は、複雑なインフラストラクチャ アーキテクチャと実装から始めることを選択する人は誰もいないということです。多くのオプションがないか、既存の選択肢を認識していないだけです。費用対効果が高く、長期的なスケーリングのニーズに対応できる場合、開発者や製品リーダーは誰でも PaaS を選択します。 PaaS には費用対効果の問題はありませんが、成長するビジネスを長期的にサポートする能力が限界に達しているという問題があります。そうでない場合、PaaS はアプリの開始とスケーリングに簡単に使用できます。

ここで疑問が生じます: すべてが「正常に機能する」、優れたドキュメント、および組み込みのサポートを得るために、持続可能な額の追加料金を支払わない人がいるでしょうか?

PaaS は独自の問題を解決する必要がある

IaaS は、あらゆるユースケースで機能する一般化されたソリューションを提供するという素晴らしい仕事をしてきました。 PaaS はまだそこに到達していません。チームが PaaS から離れてしまう原因となる、機能の不足や難読化があまりにも多くあります。企業が実行する必要があるすべてのアプリをサポートできる単一の PaaS はありません。これは重要な問題です。

さらに、2010 年に PaaS が盛んになり始めて以来、アプリケーション開発パターンも進化してきました。Heroku とその同類は追いついていません。ビジネスに不可欠であるが、PaaS でカバーされていない一般的なエンジニアリング チームの「実行すべき仕事」の一部を以下に示します。

• オブジェクト ストレージ
• イベント駆動型コンピューティング (「サーバーレス」)
• データ ウェアハウス
• NoSQL とグラフ データベース
• イベントデータベース
• データベースを検索

ニーズは明らかに多様です。 PaaS の世界は、単一のタスクでクラス最高の地位を明確に確立した専用プラットフォームで素晴らしい仕事をしてきましたが、ビジネスを可能にする一連の機能をサポートできる PaaS が必要です。

PaaS は、より多様なアプリケーション アーキテクチャをサポートする必要がある

PaaS アプリは、基盤となるインフラストラクチャ プラットフォームのさまざまな機能を利用するためにモノリシックになる傾向があります。ただし、成長する製品は、最終的に依存する一連のマイクロサービスに分割する必要がある可能性があります。

現在、開発者は、マイクロサービス アーキテクチャが PaaS で正しく機能し続けるために、さまざまな工夫をしなければなりません。効率的に機能するには、サービス検出やコンテナへの直接接続などの構造が必要です。これらは、PaaS の世界でネイティブ機能として見つけるのは困難です。

アプリケーションが PaaS が理解できる以上に複雑になると、問題のあるダイナミクスが現れます。これは、開発者が IaaS に移行する大きな理由です。 PaaS がデータ ウェアハウスをサポートできない場合、他のものを PaaS にデプロイしておく理由はほとんどありません。

IaaS ユーザーは PaaS のような抽象化を切望している

企業が PaaS から IaaS に移行すると、逆説的に、複雑さの軽減、優れた開発者エクスペリエンス、優れたドキュメント、予測可能なコストなど、PaaS を優れたものにするものを切望するようになります。今日の「State of DevOps」レポートを読むと、「プラットフォーム エンジニアリング」の動きとその哲学的基盤について知ることができます。

しかし、企業がプラットフォームを再発明する必要はありません。これは、生産性にとって大きなコストです。一流の開発者エクスペリエンスを作成し、進化させることは、それ自体がビジネス ラインになるのに十分な作業です。 Fortune 50 以外の企業にとって、IaaS を介した抽象化の構築による ROI はほとんどまたはまったくない可能性があります (その顧客や株主にとってははるかに少ない)。無意味なビジネス提案です。

PaaS には成長の余地がたくさんあり、私たちは強気です

PaaS は IaaS の多くの問題を解決します。

• インフラストラクチャは気を散らすものであり、競争上の優位性ではありません
• 企業や製品チームは、大きな問題を解決する (またはプラットフォームにアウトソーシングする) ために喜んでお金を払います。
• パフォーマンス、成長、およびスケールのために、構築、実行、および保守のストレスを必要とすべきではありません

私たちは、開発者を窮地に追い込まない汎用 SaaS の機会を見出し、興奮しています。私たちはすでに構築したもの (企業のニーズに合わせて拡張できる、Heroku 以外の最高かつ唯一の PaaS) を利用して、アプリの構築をより簡単かつアクセスしやすいものにしています。

市場がどのように反応することを期待しているか（および私たちがどのように取り組んでいるか）は次のとおりです。

• 自動スケーリングとシンプルな価格設定: Heroku 以外では、PaaS のスケーリングとコストに関する制約を設定することは困難です。これは、PaaS プロバイダーが最初に取り組むべき最も重要な領域です。
• 開発者エクスペリエンスと初めてのユーザー エクスペリエンス: PaaS プロバイダーは、開発者がアプリを迅速に構築して成長させるのを支援することに重点を置いています。これは、Heroku が提供する魔法の感覚を取り戻すための努力という、これまでのイノベーションのほとんどが行われてきた場所です。
• 最新の高レベルの開発者の抽象化をサポート: サードパーティのサーバーレス インフラストラクチャ ソリューション、運用分析、AI、サプライ チェーン セキュリティ、および分散型ソフトウェアをサポートします。
• 最新のユース ケースを提供する: 企業が静的 Web サイト、オブジェクト ストレージなどのエンジニアリング関連のタスクを完了できるようにします。

AWS やその他の IaaS プロバイダーがコンソールに追加するサービスが増えるにつれて、より複雑になることが予想されます。ますます多くの IaaS 顧客が、やがてレガシー クラウド アーキテクチャと開発パラダイムとなるものに依存することになります。これらの企業は必然的に PaaS を求めて自由になり、ユーティリティ IaaS を扱う際の複雑さとフラストレーションを単に回避することさえあります。

最後に、大企業内の小規模で比較的独立したチームの開発者に特に注意を向けて締めくくります。 「構築して実行する」という動きは、PaaS の採用を促進する可能性があります。実際、それはすでに「自分で構築し、自分で実行し、自分で保護する」ものになりつつあります。開発チームがインフラストラクチャに対する責任を負うようになるにつれて、開発チームは独自の DevOps に責任を持つようになります。彼らが管理できることは限られているため、PaaS は魅力的ではありません。 PaaSは必須になるでしょう。

今日、人々は PaaS に対して弱気かもしれませんが、これらのチームが真のエンタープライズ グレードの Heroku の競争相手を要求する日が来ています。プラットフォームがその道を切り開き、Heroku がかつてない速さで普及するでしょう。

2023 年には、Aptible がそのプラットフォームであることを示します。