要約

  • Prosimo は2019年に設立され、2021年のシリーズ A と2022年のシリーズ B で少なくとも5500万ドルを調達した。監査済み収益、評価額、買収価格は非公開。
  • AXI は、物理バックボーンを所有せずに、インテント、トポロジー、集中分析、クラウド資産を検出しアプリケーションを接続しセキュリティサービスを挿入する分散エッジを統合した。
  • 2024年6月に発表された VM-Series 統合は、2025年2月頃の Prosimo の Palo Alto Networks への移行に先行した。買収日、価格、現在の製品ロードマップはどの情報源でも特定されていない。
  • 制御は企業、オーケストレーションソフトウェア、クラウドプロバイダー、Palo Alto Networks に分散されたままだ。そのため、トポロジー、データ、ポリシー、ルーティング権限の可搬性が顧客にとっての重要な試金石となる。

企業が消えても問題は消えない

Prosimo を2026年時点で独立した稼働中のベンダーとして正確に説明することはできない。公開プロフィールによると、創業者と多くの従業員が2025年2月頃に Palo Alto Networks に移籍している。企業のアイデンティティは「買収済み」とラベル付けされており、元 CTO の Nehal Bhau 氏は後に、同社の技術が Palo Alto Networks 製品に統合されたと記している。証拠は支配権の変化と技術的価値の持続を裏付けるが、契約署名日やクロージング日、法的な取引形態、価格は特定できない。

最初にこの修正を述べる必要があるのは、製品に関するすべての主張の時制を変えるからだ。AXI、Network Transit、App Transit、Application-driven Intelligent Results、Nebula は、独立的な存続期間中に Prosimo にドキュメント化された機能だった。Palo Alto Networks が現行の製品とサポートのロードマップを公表していない限り、これらを現在も個別に販売されている製品として提示すべきではない。買収後も歴史的なアーキテクチャは、統合コード、共有サービス、ソフトウェアモジュール、社内のエンジニアリング資産として存続する可能性がある。これらの結果は同等ではない。

ブランドの消滅は根本的な問題を時代遅れにするわけではない。企業は依然としてワークロードを Amazon Web Services、Microsoft Azure、Google Cloud、プライベートデータセンター、コロケーション施設、SaaS プラットフォーム、リモートユーザーに分散させている。各環境には独自のパス、ゲートウェイ、エンドポイント、ID 管理、セキュリティサービス、クォータ、課金ルールがある。企業はアカウントを所有していても、リクエストがそれらの間をどのように流れるかについて統一された可視性を持たない。Prosimo の重要性は、その可視性を獲得しようとした点にある。

したがって、買収はストーリーの結末ではなく背骨を形成する。Prosimo は、資産を検出し、アプリケーションコンテキストを解釈し、トラフィックをセキュリティサービスへルーティングできるクラウド横断的な制御層を構築した。Palo Alto Networks はまず、そのパスに自社の VM-Series ファイアウォールを挿入できる技術パートナーとして現れ、次にその技術の所有者となった。ルーティング調整とディープインスペクションの境界線は、単一のサイバーセキュリティプラットフォームの中に移動した。

マルチクラウドルーティングはコンテキストを巡る闘い

ルーティングテーブルは、特定のプレフィックスが特定のネクストホップで到達可能かどうかを答えることができる。しかしそれだけでは、ユーザーがどのアプリケーションにアクセスしようとしていたのか、リクエスト元が信頼できるか、検査サービスがトラフィックを見るべきか、プライベートエンドポイントが利用可能か、あるクラウドパスが別のパスより高価か、パケットが到着した後にトランザクションが失敗するかどうかは説明できない。マルチクラウド運用はこれらの問いを共有制御の問題に変える。

Prosimo の説は、ルーティング権限はレイヤー3の到達可能性を超えた情報に基づくべきだというものだった。そのソフトウェアは、クラウドインベントリ、ネットワーク状態、アプリケーション ID、ユーザーID、リスク、パフォーマンス、トランザクションテレメトリを収集しようとした。この広いコンテキストにより、特定のアプリケーションを接続する、セグメントを隔離する、入口ポイントを選択する、選択されたトラフィックをファイアウォール経由でルーティングする、といったポリシーを表現できた。価値は新しい光ファイバーパスを発明することではなく、既存のパスとサービスをどのように組み立てるかを決定することにあった。

この区別が、同社が「アプリケーション体験アーキテクチャ」という用語を使った理由を説明する。それはアプリケーションリクエストを個々のネットワークコンポーネントの上に置いた。VPC、VNet、サブネット、トランジットハブ、プライベートリンクは、エンドツーエンドパスのコンポーネントとなり、管理の最終対象ではなかった。このアプローチはまた、製品をクラウドネットワーキング、アプリケーションデリバリ、ゼロトラストアクセス、ネットワークアシュアランス、コスト最適化、セキュリティサービス挿入といった複数の市場に同時に位置づけた。

この広さは機会と曖昧さの両方を生み出した。複数のチームにまたがる製品は、単独のチームが所有しない調整上の障害を解決できる。しかし、ネットワーキング、セキュリティ、クラウド、アプリケーション、財務の各チームが成功の定義を異にするため、評価が難しくなる。Prosimo は、単一のクラウド横断的なモデルが、エラーが全環境に影響を与える別の特権層になることなく、運用を改善することを示さなければならなかった。

Prosimo とは何であり、何が残ったのか

Prosimo は、2019年に設立されサンフランシスコ・ベイエリアを拠点とする、プライベートなクラウドネットワーキングソフトウェア企業だった。Ramesh Prabagaran 氏が共同創業者兼 CEO、Nehal Bhau 氏が共同創業者兼 CTO として独立期間中に在籍した。公開記録では Linus Aranha 氏や Pradeep Aragonda 氏も創業もしくは上級エンジニアリングの役割で特定されているが、正確な肩書きは日付付きの経歴に紐付けるべきである。

主要プラットフォームは Application eXperience Infrastructure、略称 AXI だった。AXI は、クラウドリージョンやコロケーション環境、近接するオンプレミスインフラに分散した AXI Edge インスタンスとともに、インテント、トポロジー、分析、オーケストレーションのための集中化されたソフトウェア制御層を使用した。その後、同社はこの提供内容を Full-Stack Cloud Transit という名称で構成し、Network Transit と App Transit が異なる接続カテゴリに対応した。AIR はテレメトリを分析して運用インサイトを提供し、Nebula は2024年に対話型インターフェースを追加した。

Prosimo はクラウドトランスポート事業者ではなかった。全リージョンを接続するグローバルな光ファイバーバックボーンを所有していなかった。パスは、クラウドプロバイダーのバックボーン、公共インターネット、Direct Connect 回線、コロケーション相互接続、またはエンタープライズネットワークを経由できた。また、Palo Alto Networks と同じ意味でのファイアウォールベンダーでもなかった。2024年の統合におけるその役割は、検出、セグメンテーション、ルーティングであり、VM-Series が深いセキュリティ検査を実行した。

買収後は、「技術系統」という説明が最も安全だ。統合に関する後の声明は、マルチクラウド資産の検出と、イングレス、エグレス、イーストウェストトラフィックを検査するためのソフトウェアファイアウォール展開の加速を強調している。これは、Prosimo の重要なコンポーネントが生き残っている証拠であり、歴史的な AXI カタログ全体、商業パッケージ、または顧客サポートモデルが変化なく継続していることの証拠ではない。

SD-WAN の後に来た問題

創業チームは、ワイドエリアネットワーキング、アプリケーションデリバリ、クラウドインフラの経験を持ち寄った。Prosimo はまた、SD-WAN をエンタープライズカテゴリーとして確立するのに貢献した Viptela に関連する、より広範な創業者・エンジニアのエコシステムから生まれた。しかし、次の問題は異なっていた。SD-WAN は支店のネットワークやアプリケーションへのアクセスを合理化したが、複数のパブリッククラウド内およびそれらをまたいで単一の運用モデルを作り出すものではなかった。

マルチクラウドアプリケーションは、ある環境のウェブエンドポイント、別の環境のデータベースまたはマネージドサービス、そのどちらでもないアイデンティティプロバイダー、データセンターへのプライベート接続、選択された境界でのセキュリティ検査に依存しうる。それぞれの依存関係は異なるネイティブオブジェクトで表現され得る。ネットワークチームはプレフィックスとトランジットハブを見るかもしれない。クラウドチームはアカウントとリソースオブジェクトを見る。アプリケーションオーナーはドメインとトランザクションを見る。セキュリティチームはゾーンと検査ポリシーを見る。

Prosimo は支店ではなくリクエストから始めた。問題は、ユーザーまたはワークロードが、許容できるセキュリティ、パフォーマンス、可用性、コストの範囲内でアプリケーションに到達するにはどうすべきか、だった。この枠組みは、ルーティングの主題を宛先プレフィックス単体から、ID とアプリケーションコンテキストを伴うトランザクションへと変えた。また、プラットフォームに対して、従来のルーターが必要とするよりもはるかに多くの情報を収集し維持することを義務付けた。

タイミングは好都合だった。AWS、Azure、Google Cloud は、ネイティブなトランジットサービスとプライベート接続を拡張していた。企業は各プロバイダー内で高度なネットワークを構築できたが、API、オブジェクト、ポリシーモデルは各プロバイダーに固有のままだった。Prosimo の機会は、各顧客にそれを別個のプライベートバックボーンで置き換えさせるのではなく、それらのサービスを調整することにあった。

2019年の創業から2021年のパブリックローンチまで

Prosimo は2019年に設立されたが、2021年4月6日までパブリックローンチを発表しなかった。General Catalyst がローンチと同時に2500万ドルのシリーズ A ラウンドを主導した。投資家はその機会を、クラウドを越えたアプリケーション体験の提供という観点から説明しており、これは創業者が従来の支店接続を超えたカテゴリーを定義しようとした試みと一致する。

このローンチは、同社を混雑し境界が不安定な市場に置いた。クラウドプロバイダーは自社のネットワーキングサービスの利用を容易にしていた。SD-WAN や SASE ベンダーはポリシーをクラウド環境に拡張していた。アプリケーションデリバリ企業はリクエストを最適化でき、ネットワークセキュリティ企業はそれを検査できた。Prosimo の主張は、周辺のシステムすべてを置き換えるとは主張せずに、これらの機能をクラウドネイティブアーキテクチャに統合することに依存していた。

資金調達は、統合、ソフトウェアエッジ、分析、商業組織、パートナー関係を構築する余裕を与えた。しかし、それは製品市場適合性、収益規模、持続可能な差別化を証明するものではなかった。提供された証拠には、監査済み収益、ARR、顧客数、評価額は含まれていない。資金調達記録は、投資家がテーゼにコミットしたことを示すものであり、完全な営業成績を示すものではない。

2022年、Prosimo は3000万ドルのシリーズ B ラウンドを完了し、これはオーバーサブスクライブと表現された。明確に帰属する2つのラウンドを合計すると、少なくとも5500万ドルの文書化された総額になる。一部のデータベースは、発表や関連レコードが重複しうるため、より大きな数字を示すことがある。そのような合計は、基礎となるイベントを調整せずに使用すべきではない。

AXI はポリシーをクラウドの上に置き、実行をワークロードの近くに置いた

AXI アーキテクチャは、集中化された制御・分析層と分散されたソフトウェアエッジに作業を分割した。制御層はアプリケーションとネットワークの意図を保持し、資産を検出し、トポロジーを組み立て、アイデンティティを関連付け、テレメトリを分析し、変更を調整した。AXI Edge はワークロードまたはユーザーの近くに展開され、ポリシーを適用するためにすべてのパスが遠隔の物理ハブに戻ることを要求しなかった。

この分離は他のソフトウェア定義システムに似ていたが、オブジェクトはクラウドアウェアでアプリケーションアウェアだった。コントローラーはクラウドアカウントと API へのアクセスを必要とし、エッジはネイティブトランジットサービス、ワークロードネットワーク、プライベートまたは外部パスに接続する必要があった。プラットフォームの権限は、クラウドを越えたグローバルな意図と、関連するトラフィックの近くでのローカルな実行という2つの可視性を収集することから生じた。

このアーキテクチャはまた、現実的な展開境界を作り出した。各エッジはクラウドリソースを消費し、高可用性設計を必要とし、更新、監視、保護される必要があった。制御層は、資産を検出しネットワーク状態を変更するのに十分な権限を持つクレデンシャルを必要とした。企業は共有ワークフローを得たが、その可用性と健全性が本番アクセスに影響を与える新しい管理システムを追加した。

Prosimo は時折「自律的クラウドネットワーキング」という言葉を使った。証拠は、人間のポリシー、クラウドプロバイダーのサービス、または基盤となるトランスポートから独立して動作するネットワークではなく、自動化、推奨、API 駆動の調整をサポートする。オペレーターは依然として意図を定義し、アクセスを承認し、例外を処理し、結果に責任を負った。

AXI Edge は汎用仮想アプライアンスではなく、ロケーションの決定だった

AXI Edge は、クラウド VPC や VNet、コロケーション環境、または近接インフラに展開できた。AWS テクニカルウォークスルーでは、Transit Gateway を介してワークロード VPC に接続されたエッジ VPC が示され、ファイアウォールチェイニングやリモートユーザーまたはオンプレミスサイトからのアクセスが可能だった。この設計は、Prosimo の実行ポイントを遠隔の企業境界ではなく、クラウドトポロジーの中に配置した。

場所はレイテンシー以上に影響した。それは、トラフィックがポリシードメインに入る場所、どのクラウドバックボーンまたはインターネットパスを使用するか、暗号化と検査がどこで行われるか、プラットフォームがどのテレメトリを収集できるかを決定した。配置が悪いエッジは迂回やコストを生み、適切に配置されたエッジはパスを短縮し、トラフィックをワークロードの近くに保つことができる。

分散展開は、管理すべき故障ドメインの数を増やした。容量、ソフトウェアバージョン、クラウドリージョン設計、パスの近接性、アクセス許可はリージョンごとに異なりうる。高可用性には2つのインスタンスを実行する以上のことが必要である。コントローラー、ルートテーブル、セキュリティサービス、リターンパスがフェイルオーバー状態に合意しなければならない。

したがって、エッジはより広範な運用システムの一部だった。その価値は、資産発見、トポロジー、ポリシー、テレメトリが周囲のクラウド環境と一貫性を保つかどうかに依存していた。それを独立した仮想アプライアンスとして扱うと、Prosimo が販売しようとしたアーキテクチャを見逃す。

基盤は常に他者が所有していた

Prosimo はトランスポートを調整したが、物理パスを所有していなかった。アプリケーションパスは、AWS や別のクラウドプロバイダーのバックボーン、公共のインターネット接続、Direct Connect や ExpressRoute、コロケーションサービス、キャリア回線、エンタープライズネットワークを使用できた。プラットフォームは利用可能な選択肢を選択し調整できたが、それらの所有者によって生み出されるレイテンシー、パケットロス、障害ドメイン、または料金体系を取り除くことはできなかった。

この境界はパフォーマンスの主張を評価する際に重要である。コントローラーは、観測されたより良いパスを選択したり、入口点をユーザーの近くに移動させたりできる。しかし、トランスポートが停止しないこと、クラウドリージョンが利用可能であり続けること、または外部の依存関係が迅速に応答することを保証できない。アプリケーション体験には、コントローラーの完全な管理外にある DNS、サーバー処理、ストレージ、ブラウザの動作、サードパーティサービスも含まれる。

独自のバックボーンがないことは弱点だけではなかった。それにより Prosimo は、企業が既に購入したインフラストラクチャを使用し、クラウドプロバイダーの投資を活用することができた。ファイバーを敷設することなくリージョンに到達し、AWS Cloud WAN のようなネイティブシステムを調整できた。トレードオフは、各プロバイダーの API の安定性、サービスクォータ、商業条件、およびセマンティクスへの依存だった。

したがって、プラットフォームの主張は物理的な所有権ではなく、運用上の制御に関するものだった。それは、異種の基盤を、それらのネイティブなメリットを維持しながら、単一の管理されたシステムのように動作させようとした。その抽象化がロックインを減らすのか、単に移動させるのかは、ポリシー、トポロジー、エッジ展開の可搬性にかかっている。

Network Transit はネットワークオブジェクト間の到達可能性に対処した

Network Transit は、VPC、VNet、サブネット、リージョン、サイト、セグメントに焦点を当てた。チームが各プロバイダーを個別に設定するのではなく、共有ワークフローを通じて接続を構築できるように、クラウドネイティブのトランジットサービスとルートを調整した。これは伝統的なネットワーキング要件に応えるものだった。送信元のプレフィックスまたはセグメントが、許可されたパスを経由して宛先に到達しなければならない。

これは、クラウド間の違いが消えたという主張ではなかった。AWS、Azure、Google Cloud は、異なるオブジェクト、クォータ、ルーティング動作を提供する。重複するアドレス空間、非対称ルート、プライベートエンドポイント、プロバイダー固有のサービス境界は依然としてエンジニアリングを必要とした。Prosimo は一般的な操作を統一し関係を表示できたが、基盤となるプラットフォームは制約を保持した。

Network Transit はセグメンテーションも含んでいた。ルーティングドメインとポリシーは環境を分離したりアクセスを制限したりできた。コントローラーは、セグメントがクラウドを越えてどこに存在するか、そしてネイティブオブジェクトがその境界をどのように実施するかを理解する必要があった。一度設定されたポリシーは、複数のプロバイダー固有の変更に変換されうる。

利点は統一されたインテント面だった。リスクは変換にあった。共有ポリシーがクラウドの実際の設定から逸脱した場合、企業はセグメントが保護されていると信じる一方で、プロバイダーの状態はそうでない可能性がある。したがって、調整、監査、明示的な障害報告は、初期のプロビジョニングワークフローと同じくらい重要だった。

App Transit はアプリケーションをルーティング対象オブジェクトにした

App Transit はモデルをサブネットを超えて拡張した。それは、ユーザーまたはワークロードがサービスにどのように到達するかを決定する際に、アプリケーションドメイン、アイデンティティ、リクエストタイプ、トランザクションヘルス、リスク、パフォーマンスを使用できた。これは、従来のクラウドルーターからプラットフォームを差別化するための、Prosimo による最も明確な試みだった。

アプリケーションの可視性が役立つのは、現代のサービスが常にきれいに静的アドレスにマッピングされるとは限らないからだ。マネージド・プラットフォーム、SaaS エンドポイント、分散コンポーネントは、アプリケーションのアイデンティティが意味を持ち続ける一方で、シフトする可能性がある。サービスやユーザーを参照するポリシーは、アドレスとポートだけで書かれたルールよりも長く存続しうる。

このモデルには正確な検出が必要だった。コントローラーは、どのドメインとエンドポイントがアプリケーションに属するか、どの依存関係が必要か、どのアイデンティティプロバイダーの要求が信頼できるかを知る必要があった。古いマッピングは、リクエストを間違ったパスに送ったり、誤ったセキュリティルールを適用したりする可能性がある。アプリケーション抽象化は、ネットワーク状態を理解する必要性を排除せず、その上に別のセマンティックレイヤーを配置するだけだった。

Network Transit と App Transit の組み合わせは、企業内部に2つの世界が存在することを認識していた。レガシーシステム、プライベートネットワーク、IP ベースの制御が維持される一方、新しいアプリケーションはドメイン、アイデンティティ、マネージドサービスに依存する。Full-Stack Cloud Transit は、一方が他方を置き換えるように強制するのではなく、両方のモデルを一緒に運用するための製品名だった。

アイデンティティはルーティング決定と信頼境界を拡張した

アプリケーションアウェアなアクセスにはアイデンティティ統合が必要だった。プラットフォームは、ユーザーまたはワークロードのコンテキストを使用して、接続を確立するかどうか、またどのように確立するかを決定できた。これは、場所だけでは権限の十分な証拠にならない、ゼロトラストスタイルのポリシーをサポートした。

アイデンティティは精度を向上させたが、別の依存関係を追加した。パスやアプリケーションのポリシーは、アイデンティティプロバイダー、その要求事項、セッション状態、グループデータに依存するようになった。ルーターとエッジが健全でも、認証が利用できなかったり属性が変更されたりしたために、パスが失敗する可能性がある。根本原因の特定は、ネットワーク操作とアイデンティティ操作の境界を越える必要があった。

コントローラーはまた、機密性の高いコンテキストの集中ポイントとなった。トポロジー、アプリケーションの関係、ユーザー属性、リスクシグナル、ポリシー結果を保持する可能性があった。これにより診断と最適化は改善されたが、不正アクセスの結果も大きくなった。したがって、最小権限、保持、監査、職務分掌は、後付けの管理項目ではなく、アーキテクチャ上の要件だった。

Prosimo のアプローチは、インフラストラクチャにおけるより広範な転換を示している。ルーティングとアクセスポリシーは、ますますアイデンティティとアプリケーションのセマンティクスに依存するようになっている。プラットフォームがより多くのコンテキストを見るほど、その決定はより有用になり、その権限はより正確なガバナンスを必要とする。

資産発見は後続のすべての決定が依存するグラフを作成した

クラウド横断的なコントローラーは、見えないものを管理できない。Prosimo は、VPC、VNet、サブネット、アプリケーション、接続性、セキュリティ関係を表すクラウド資産の発見とマップを開発した。これらの可視性は、オンボーディング、設計、トラブルシューティング、ポリシーを支えた。

発見は戦略的に重要だった。なぜなら、クラウド環境は中央のネットワーキングワークフローの外で変化するからだ。アプリケーションチームは、独自の自動化によってアカウント、ネットワーク、エンドポイント、マネージドサービスを作成できる。手動の図は古くなる。API ベースのインベントリはより新しいマッピングを提供できるが、その完全性はアカウントのカバー範囲、許可、解析ロジック、およびプロバイダーの API に依存する。

マップは単なるドキュメントではなかった。それは、ルーティング、セグメンテーション、サービス挿入、最適化の決定が計算されるデータ構造だった。資産や依存関係が欠落している場合、その上のすべての結果が間違っている可能性がある。そのため、トポロジーは明確な来歴を必要とした。いつ取得されたか、どのアカウントが提供したか、どのリージョンがカバーされているか、リクエストが失敗したかどうか。

この図は買収の説明にも役立つ。Palo Alto Networks は、ワークロードがどこに存在し、トラフィックパスがどのようになっているかを知っている場合に、セキュリティ価値を創造できる。資産を検出しパスを変更するシステムは、ソフトウェアファイアウォールの購入とその正しい場所への配置との間の距離を短縮する。Bhau 氏の後の声明は、特に資産発見とソフトウェアファイアウォール展開の加速に焦点を当てていた。

AIR はエッジテレメトリを運用推奨に変換した

Application-driven Intelligent Results、略称 AIR は、AXI Edge が収集したテレメトリを分析した。AWS のウォークスルーでは、往復時間、処理時間、アプリケーション応答時間、トランザクションタイプ、リスク、ポリシー結果の可視性が説明されていた。プラットフォームは、別々のデバイスカウンターを表示するのではなく、ユーザー、ネットワーク、アプリケーションの観測結果を相関させることができた。

この相関は、よく知られた運用上の問題に対処した。遅いトランザクションの原因は、ユーザーパス、エッジ、クラウドバックボーン、セキュリティサービス、またはアプリケーション自体である可能性がある。クロスレイヤー可視性は、別々のダッシュボードよりも速く診断を絞り込むことができ、パス、場所、リスク、コストに関する推奨をサポートできた。

推奨の品質は、テレメトリのカバレッジとその解釈に使用されるモデルに依存した。エッジは通過するトラフィックだけを見た。外部のアプリケーション依存関係やプロバイダー内部の状態は見えないままになる可能性があった。推奨は方向性としては有用でありながら、根本原因を証明できない可能性があった。

テレメトリはガバナンス上の価値も持っていた。過去の観測結果は、企業がパスやポリシーが変更された理由を説明するのに役立つ可能性がある。また、機密性の高いアプリケーションの使用状況やユーザーの行動を明らかにする可能性もある。公開コンテンツは、買収後の保持やデータガバナンスの全体像を示していないため、これらの質問は顧客のデューデリジェンスの一部として残る。

AWS が最も明確な文書化された実装を提供した

Prosimo の AWS との取り組みは、最も強力な公開技術的証拠を生み出した。同社は、AWS Transit Gateway、Cloud WAN、PrivateLink、および Marketplace for Containers Anywhere の展開パスと統合した。AWS は、AXI Edge の配置、アプリケーションオンボーディング、アイデンティティ、セキュリティ、最適化を説明するウォークスルーを公開した。

AWS Cloud WAN は特に重要だった。これは、Prosimo が置き換えるのではなく調整できる、ネイティブのクラウドバックボーンおよびセグメンテーションサービスを提供した。この配置は協力的な製品モデルを示した。AWS がネイティブネットワークとグローバルファブリックを所有し、Prosimo がクラウド横断的な意図、アプリケーションコンテキスト、ソフトウェアエッジ、分析を提供した。

Marketplace パスは、認証されたチャネルに AXI Edge をパッケージ化することで、最初の展開ステップを簡素化した。しかし、アカウント許可、パス設計、高可用性、容量、運用に関するその後の作業を排除するものではなかった。Day-0 自動化は導入の摩擦を減らすことができるが、長期的な制御問題は残る。

Flexport への名前付き言及は、同社のコンテンツ内で AWS Cloud WAN のユースケースとして示された。これは、企業顧客がアーキテクチャを推奨する意思があるという証拠であり、展開規模、節約額、または可用性に関する独立した監査ではない。したがって、顧客の引用は採用の例として使用すべきであり、一般的なパフォーマンスの証拠として使用すべきではない。

Azure と Google Cloud がマルチクラウドの主張を完成させた

Prosimo は Microsoft Azure と Google Cloud 環境もサポートしていた。その資料では、Azure Virtual WAN、Google Cloud の VPC ネットワーク、プライベートサービスオブジェクトに関する調整が説明されていた。目標は、各プロバイダーのネイティブネットワークを所定の位置に保ちながら、単一の運用モデルを提供することだった。

サポートの存在は、プロバイダー間で機能が同一であることを証明するものではない。クラウド API は異なる速度で成熟し、類似した製品名は異なるセマンティクスを隠す可能性がある。パス、セグメント、プライベートエンドポイント、サービス挿入は、プロバイダー固有の処理を必要とする場合があった。提供された証拠は、すべてのリージョンとバージョンにおける各機能の同等性マトリックスを再構築していない。

したがって、マルチクラウド抽象化は翻訳システムとして最もよく理解される。それは意図と共有ワークフローを統一できるが、セキュリティ、コスト、障害に影響を与える詳細を保存しなければならない。プラットフォームは、統一された表面が実装の違いをオペレーターから隠してしまう場合に危険になる。

同じことが買収後にも当てはまる。Palo Alto Networks は、クラウド全体のセキュリティ態勢を描くために共有グラフを使用するかもしれないが、クラウドプロバイダーは依然としてパスを実施するネイティブオブジェクトを制御している。オーケストレーション層の所有権は、クラウド基盤の所有権を生み出さない。

製品は接続性からライフサイクルへと拡大した

2023年までに、Prosimo はマルチクラウドネットワーキングの設計、構築、トラブルシューティング、管理のためのワークフローを説明していた。製品は単一のトンネルやゲートウェイを作成することを超えていた。資産発見が設計を支え、オーケストレーションが接続を作成し、マップとテレメトリがトラブルシューティングを支え、ポリシーと履歴状態が継続的な管理を支えた。

ライフサイクルフレームワークは商業的な購買層を拡大した。ネットワークエンジニアはトポロジーとパス分析を使用できた。クラウドプラットフォームチームはアカウントとサービスをオンボードできた。セキュリティチームはセグメンテーションと検査をレビューできた。移行チームは変更を計画できた。FinOps チームはパスとエグレスコストへの影響を調査できた。複数のグループが同じグラウンドトゥルースを使用するにつれて、プラットフォームの価値は増大した。

共有グラウンドトゥルースはガバナンスの対立も生み出す可能性があった。中央プラットフォームは、クラウドチームの設定が企業ポリシーと異なることを明らかにするかもしれない。企業は、どのシステムが情報源であり、誰が修正を承認するかを決定しなければならない。ソフトウェアだけでは、この組織的な質問を解決できない。

ライフサイクルストーリーはまた、切り替えコストを引き上げた。コントローラーが資産、ポリシー、テレメトリ、エッジ配置、自動化統合のグラフを保持する場合、その交換には回線の移動以上のことが必要となる。顧客は運用モデルをエクスポートするか再構築しなければならない。Prosimo はクラウドの断片化を減らすと同時に、コントローラーへの依存の可能性を生み出した。

セグメンテーションはネットワークアクセスからアプリケーションポリシーへと拡張された

Prosimo はレイヤー3からレイヤー7のセグメンテーションを提供した。ネットワークレベルでは、ルーティングドメインとセグメントが、どのネットワークやサイトが接続できるかを定義した。より高いレイヤーでは、アプリケーション ID、ユーザーコンテキスト、トランザクションプロパティがルールを精緻化した。

多層モデルは、ネットワークゾーンとアプリケーションポリシーの間のギャップを減らすことができた。ビジネスサービスは許可される一方で、ネットワーク間の広範なアクセスはブロックされたままになる可能性がある。逆に、到達可能なパスでも、アイデンティティやアプリケーションコンテキストが失敗したために拒否される可能性がある。

これは Prosimo をフル機能の次世代ファイアウォールに変えたわけではない。2024年の統合は責任を分離した。Prosimo がパス、セグメンテーション、サービス挿入を調整し、VM-Series が深い検査を実行した。この区別は重要である。なぜなら、ポリシールーティングとセキュリティ強制は異なる方法で失敗するからだ。

セグメントは、関連するすべてのパスが表現されている場合にのみ有効である。未知のパス、ネイティブクラウドの例外、または失敗したサービス挿入は、意図された境界を迂回する可能性がある。したがって、保証には、宣言されたポリシーをプロバイダーの状態と観測されたトラフィックと比較することが必要であり、コントローラーの設定画面だけを信頼することではない。

サービス挿入はパス制御をファイアウォール経済と結びつけた

クラウドのセキュリティ設計は、検査がどこで行われるかを決定しなければならない。集中型ファイアウォールはポリシーを簡素化し、アプライアンスの数を減らすことができるが、迂回、集中、容量圧迫を生み出す可能性がある。分散型ファイアウォールはワークロードの近くに留まり、一部のパス歪みを減らすが、展開、ライセンス、アップグレード、ポリシー運用が増倍する。

Prosimo は VM-Series 統合において両方のモードをサポートした。ポリシーは、選択されたトラフィックを集中検査ポイントまたはアプリケーション VPC 内の分散ファイアウォールにルーティングできた。コントローラーは周囲のパスを更新し、Palo Alto Networks が検査機能を提供した。

このアーキテクチャは、パス調整をセキュリティベンダーにとって商業的に価値あるものにした。ソフトウェアファイアウォールは、そこに到達しないトラフィックを保護しない。検出、配置、パス更新は、セキュリティ機能の購入とそれをライブパスに挿入することの間の摩擦を減らす。これが、Palo Alto Networks が Prosimo の技術を吸収したことの妥当な戦略的理由である。

それはまた、コントローラーの影響範囲を拡大した。ポリシーエラーは、検査を迂回したり、ループを作成したり、非対称ルーティングを生み出したり、アプリケーションを停止させたりする可能性がある。ヘルスチェック、段階的変更、シミュレーション、監査、ロールバックが必要である。なぜなら、サービス挿入の失敗はネットワークイベントであると同時にセキュリティイベントだからだ。

2024年のパートナーシップは買収日と混同すべきではない

Prosimo と Palo Alto Networks は、2024年6月12日に VM-Series 統合を発表した。声明は共同の技術的および商業的ソリューションを説明しており、Palo Alto Networks が Prosimo を買収したとは述べていない。この発表を所有権の証拠として扱うことは、2つの別個のイベントを混同することになる。

しかし、パートナーシップは橋を架けた。Prosimo は、自社のパス・ポリシーシステムが VM-Series のクラウド横断的な展開をどのように容易にするかを示すことができた。Palo Alto Networks は、後の企業移行の前に、実際の統合の中で技術を評価できた。公開証拠は買収プロセスを説明していないため、パートナーシップが正式な買収前段階として設計されたと言うことは推測のままである。

2025年初頭までに、創業者と従業員の記録が変わった。会社のページは後に買収済みとラベル付けされた。2025年後半、Bhau 氏は技術が Palo Alto Networks 製品に完全に統合されたと述べた。これらの記録は合わせて買収の結果を裏付けるが、法的メカニズムは未解決のままである。

このシーケンスは編集上の正確さと顧客にとって重要である。パートナーシップは2つのベンダー、サポート体制、既知の統合ポイントを意味する。買収はロードマップ、データ、契約、権限を1つの企業に移転する可能性がある。技術的なパスが最初は似ていても、移行は名前以上に多くのものを変える。

Nebula はトポロジーグラフを対話型インターフェースに変えた

Prosimo は、マルチクラウドネットワーキング向け AI Suite の一部として、2024年2月に Nebula アシスタントを導入した。このアシスタントは、相互接続、コスト、パス正常性、セキュリティポリシー違反、およびプラットフォームのグラフとテレメトリで表現されるその他の状態について、自然言語の質問に答えるように設計されていた。

有用な資産は言語インターフェースそのものではなく、その下にある構造化されたクラウド横断的なコンテキストだった。汎用モデルは、見ることのできないプライベートパスやセグメントを診断できない。Nebula は、Prosimo が既に収集していた資産インベントリ、トポロジー、ポリシー、観測結果を活用できた。これにより、共有マップへの以前の投資が AIOps に関連するものとなった。

対話型アクセスは、複雑なデータをより多くのオペレーターに開く可能性がある。一方で、回答が裏付けのない原始データを省略したり、質問を誤解したり、推奨を承認されたアクションとして扱ったりした場合、誤った信頼を生み出す可能性もある。リスクの高い変更には、依然として決定論的なガードレール、権限境界、人間によるレビューが必要だった。

Prosimo は、平均解決時間（MTTR）を60～80%短縮し、クラウドネットワーキングコストを60%以上削減するなどの潜在的な利益を挙げた。これらは製品発表において同社が主張した数字である。証拠は、それらが広く適用可能であることを示す独立した方法論や顧客ベースラインを提供していない。これらは Prosimo が提案した利益として引用できるが、測定された市場の事実としては引用できない。

AI ワークロードは新しいユースケースであり、新しい市場の証拠ではなかった

同じ2024年の発表は、Prosimo のアーキテクチャを AI ワークロードのコンテキストに位置づけた。分散システムは、プライベートデータアクセス、クラウドとデータセンター間の接続、コンプライアンス制御、アプリケーションの動作を反映するルーティングを必要とする可能性がある。これらの要件は、同社の既存の資産・ポリシー・パスモデルと一致していた。

ラベルは基盤を変えなかった。Prosimo は依然としてクラウドネットワーク、トランスポートプロバイダー、顧客インフラに依存しており、GPU コンピューティングやモデル開発ツールを提供しなかった。その潜在的な役割は、分散したデータとサービスを取り巻く接続性とセキュリティ層だった。

AI ポジショニングは戦略的に理にかなっていた。なぜなら、クラウド横断的なトポロジーの価値は、データとサービスが広く分散するほど上昇するからだ。しかしそれはまた、同社の独立的な運営が終了する直前に導入されたマーケティングカテゴリーでもあった。証拠は、独立した AI 製品収益、名前付きの本番展開、または監査済みのワークロード結果を証明していない。

持続的なポイントは、マルチクラウドテレメトリが機械支援運用への入力になり得るということだ。現在の質問は、Palo Alto Networks がこのコンテキストを保持したかどうか、そしてその機能をどのように提示するかである。カットオフ時点での公開証拠は完全な回答を提供していない。

ビジネスモデルは、所有していないインフラの上でソフトウェアを販売した

独立していた Prosimo のビジネスは、トランスポートモデルではなく、ソフトウェアサブスクリプションとサービスだった。顧客は自らの環境に AXI Edge を展開し、クラウドアカウントを制御層に接続した。収益はおそらくライセンスまたはサブスクリプション、サポート、プロフェッショナルサービス、チャネルに依存していたが、正確な価格設定と契約指標は提供された証拠では公開されていない。

このモデルは光ファイバーを所有せずにスケールできた。単一のソフトウェアプラットフォームが、多くのリージョンと複数の顧客環境を調整できる。しかし、アーキテクチャだけからユニットエコノミクスを推論することはできない。プロバイダーAPI、エッジのライフサイクル、セキュリティ統合、エンタープライズ展開のサポートにはコストがかかる可能性があり、一方でエッジが消費するクラウドリソースの料金はベンダーではなく顧客が支払う。

Prosimo はクラウドマーケットプレイス、インテグレーションパートナー、販売チャネル、名前付きの顧客参照を使用して企業にリーチした。これらの関係は同等ではない。マーケットプレイスリストは購入と展開のパスを証明する。技術統合は、特定の条件下で2つのシステムが連携できることを証明する。顧客の証言は参照を提供する。単独では、有料顧客数や経常収益を証明するものではない。

同社の広さは販売を複雑にした可能性がある。ネットワーキング、セキュリティ、クラウド、アプリケーションチームが利益を得るかもしれないが、予算の所有権は不明確なままだった。製品には、各クラウドとチームを別々に動作させるのではなく、共有制御層に資金を提供する意思のあるバイヤーが必要だった。

パートナー、顧客、投資家は異なる立場を占めた

Amazon Web Services は、基盤プロバイダー、統合パートナー、そして市場開拓を同時に務めた。Azure と Google Cloud はサポート環境だった。アイデンティティプロバイダーは認証コンテキストを提供し、ファイアウォールベンダーは検査を提供し、コロケーションプロバイダーやキャリアはエッジをホストまたは接続でき、チャネルパートナーは展開を設計および運用できた。

Flexport は、AWS Cloud WAN 資料内で名前付きの顧客参照として登場した。この参照は企業のアーキテクチャへの関心を証明するが、展開の全範囲、期間、または商業的価値を開示していない。それを顧客ベース全体の知識の代用にすべきではない。

General Catalyst がシリーズ A を主導し、投資家としてガバナンスに参加した。WRVI または Celesta に関連する投資家が会社資料に登場し、後の通信では追加の著名な名前が言及され、その中には BlackRock に関連する名前も含まれていたが、正確な投資事業体は確定されていない。記録は、十分に接続された資金調達基盤の存在を裏付けるが、完全な所有権テーブルを裏付けるものではない。

Palo Alto Networks が最も重要な関係を占めた。それは2024年のセキュリティパートナーから、2025年初頭までに買収者へと移行した。このシーケンスは、ある当事者が自社製品へのパスを調整するソフトウェア層を購入するときに、エコシステムの依存関係がどのように制御関係に変わるかを示している。

少なくとも5500万ドルが調達され、出口経済は不明

文書化された資金調達記録は、2021年4月のシリーズ A で2500万ドル、2022年のシリーズ B で3000万ドルで構成される。合計は少なくとも5500万ドルである。証拠には、監査済みの所有権テーブル、評価額、負債スケジュール、またはその後のラウンドは含まれていない。

買収対価は発表されておらず、独自に検証されていない。価格がなければ、結果を戦略的プレミアム、限定的な技術買収、チーム獲得、またはストレス下の売却として責任を持って分類することはできない。継続的な統合は技術的価値を裏付けるが、投資家や創業者のリターンを明らかにしない。

Palo Alto Networks の収益または時価総額を買収後に Prosimo に帰属させるべきではない。スタートアップが独立したユニットとして見えなくなるまでに、分析すべき個別の収益、利益、または顧客セグメントは存在しなかった。より大きな所有者は技術をより広く普及させる一方で、その個別経済の可視性を低下させる可能性がある。

公式の買収発表がないこと自体が重要である。顧客、従業員、研究者は通常、そのような発表をタイミング、サポート、戦略的根拠を確定するために使用する。ここでは、ケースを経歴、会社ページのラベル付け、後の創業者の声明から再構築しなければならない。これは会社のステータスを修正するには十分だが、取引の詳細を発明するには十分ではない。

競争はプラットフォーム、クラウド、社内エンジニアリングから来た

Prosimo は、Aviatrix や Alkira のようなマルチクラウドネットワーキング専用プラットフォーム、エンタープライズネットワーキングおよび SASE ベンダー、AWS、Azure、Google Cloud のネイティブサービスと競合した。また、企業が Infrastructure as Code、トランジットサービス、ルートテーブル、ファイアウォールを直接使用するセルフビルドモデルとも競合した。代替案は同じ問題の異なる部分に対処した。

専用コントローラーは、プロバイダー全体で単一のトポロジーとポリシーモデルを提供できる。単一クラウド内のネイティブ設計は、サードパーティ依存を減らし、プロバイダーにより密接にフィットする可能性がある。キャリア支援サービスは物理トランスポートを提供できる。SASE またはセキュリティプラットフォームは、接続性と強制を統合できる。社内エンジニアリングは、スタッフと統合の負担を代償に制御を維持する。

Prosimo の差別化は、アプリケーションとネットワークのトランジット、分散エッジ、クラウドネイティブ調整、トポロジー、テレメトリ、サービス挿入を組み合わせたことだった。その同じ広さが比較を困難にした。購入者は、カテゴリ名を比較するのではなく、実際のクラウドサービス、パス、ID システム、使用するセキュリティパターンでテストする必要があった。

買収は競争の枠組みを変える。Prosimo はもはや独立企業として勝つ必要はないが、その技術は Palo Alto Networks 内で価値を証明しなければならない。関連する比較は次のようになる。統合された発見とパス調整は Palo Alto のセキュリティ製品の展開を改善するか、そして顧客は結果として得られるプラットフォーム依存を受け入れるか？

ネイティブクラウドサービスは基盤であり代替案でもあった

AWS Cloud WAN、Transit Gateway、Azure Virtual WAN、Google Cloud VPC ネットワークは、企業に強力なネイティブオプションを提供した。Prosimo はこれらに依存し、顧客がそれらを直接運用する可能性と競争した。

この関係は変動する境界を設定した。プロバイダーがグローバルルーティング、セグメンテーション、プライベートアクセス、または集中ポリシーを追加するたびに、サードパーティの機能の一部をネイティブに再現することが容易になった。同時に、新しいネイティブサービスはそれぞれ、クラウド横断的コントローラーが発見して調整できる別のオブジェクトを追加した。クラウドの進歩は Prosimo の価値の一部を縮小する一方で、プロバイダー間の翻訳の必要性を拡大する可能性がある。

決定的な要因は、技術的であると同時に組織的だった。単一のクラウドにコミットし強力な社内エンジニアリングを持つ企業は、ネイティブツールを好むかもしれない。断片化されたチームを持つマルチクラウド企業は、単一の制御面を評価するかもしれない。規律ある組織は、特権クレデンシャルとデータ集中を懸念しながら、サードパーティのガイダンス層を好むかもしれない。

ロックインを排除したアーキテクチャはなかった。ネイティブツールは、単一のプロバイダーの API とセマンティクスへの依存を増大させた。クラウド横断的コントローラーは、そのグラフ、ポリシー、ソフトウェアエッジへの依存を増大させた。有用な質問は、依存が可視的で、可搬性があり、企業の運用モデルと整合しているかどうかだった。

障害はコントローラー、エッジ、クラウド API、アイデンティティ、基盤で発生しうる

分散アーキテクチャは単一のトラフィックハブへの依存を減らしたが、相互作用する障害ドメインを生み出した。中央システムが停止するか、古い意図を保持する可能性がある。エッジが故障するか、隔離される可能性がある。クラウド API が変更の一部を拒否する可能性がある。アイデンティティプロバイダーが応答しなくなる可能性がある。基盤が容量を失うか、予期しないパスを取る可能性がある。挿入されたファイアウォールがリソースを使い果たす可能性がある。

部分的な障害は特に困難である。あるプロバイダーはルート更新を受け入れ、別のプロバイダーは拒否する可能性がある。その場合、コントローラーの意図した状態と実際のクラウド状態が分岐する。トラフィックは非対称ルートを取るか、検査をバイパスする可能性がある。信頼できるシステムは、調整、安全に反復可能な操作、段階的変更、明示的なエラー状態、各プロバイダーの動作を考慮したロールバックを必要とする。

公開証拠は可用性と最適化を高いレベルで説明しているが、独立したフォールトインジェクション研究、完全なインシデントログ、または公開サービス結果は含まれていない。したがって、回復力の主張は、文書化されたアーキテクチャまたは名前付き顧客の証拠に紐付けられなければならない。

買収は、製品の継続性という別の障害ドメインを追加する。顧客は、歴史的な Prosimo システムに代わるパネル、API、エッジイメージ、ポリシーモデル、サポート先を知る必要がある。技術的に成功したコード統合でも、商業的および運用上の境界が不明確な場合、移行リスクを抱える可能性がある。

クラウドクレデンシャルはコントローラーをクリティカルな管理面の一部にした

資産発見と調整にはクラウドアカウントへのアクセスが必要だった。読み取り専用インベントリは狭い権限で運用できたが、パス、セグメント、サービス挿入の変更にはより強力な権限が必要だった。したがって、コントローラーはワークロードを所有していなくても、特権管理面の内側に座っていた。

クレデンシャルの侵害は、トポロジーを露呈させたり、広範な変更を許可したりする可能性がある。ソフトウェアの欠陥やオペレーターのエラーは、複数のクラウドにポリシーを拡散させる可能性がある。リスクはプラットフォームの有用性とともに増大する。管理するアカウントとサービスが増えるほど、潜在的な影響範囲も広がる。

企業は、最小権限ロール、発見と変更のための別個のクレデンシャル、多者承認、完全な監査、ローテーション、緊急取消し、コントローラー自体に依存しないリカバリパスを必要とした。公開資料は完全な独立したセキュリティ評価を提供していないため、これらは必要な展開制御であり、実証済みの製品保証ではない。

テレメトリグラフも機密性が高かった。アプリケーション名、ネットワークアーキテクチャ、ポリシー、ユーザー関係、パス正常性、コストパターンを明らかにする可能性があった。買収後のガバナンスは、これらのデータがどこに保存されるか、どの Palo Alto Networks 製品がそれらを使用できるか、古い顧客権限がどのように移行されたかを明確にしなければならない。カットオフ時点の公開証拠はこれらの質問に回答していない。

買収はクラウド中立層をセキュリティプラットフォームに移行させた

Prosimo の独立した立場は、クラウドとセキュリティサービス全体にわたる共有層として自らを提示することを可能にした。Palo Alto Networks が所有者になると、インセンティブが変わった。買収された技術は、VM-Series や他の Palo Alto 製品の展開を容易にする可能性がある。これにより統合は改善されるが、サードパーティの検査サービスのサポートに関する疑問が生じる。

所有権は中立性の消滅を証明しない。証拠は現在のパートナーマトリックスや現代の製品アーキテクチャを提供していない。しかし、それは顧客が尋ねるべきことを変える。パスコントローラーは複数のセキュリティベンダーに開かれたままか、ポリシーとテレメトリはエクスポート可能か、最適化はオーナーのポートフォリオを優先するか？

統合声明はイングレス、エグレス、イーストウェスト検査に焦点を当てていた。これは、Prosimo のトポロジーと調整がセキュリティ展開システムに入ったことを示唆する。しかし、歴史的な App Transit、ユーザーアクセス、コスト最適化、またはすべてのクラウドネットワーキングワークフローが別個の機能として存続したことを証明するものではない。

これはインフラストラクチャにおけるおなじみのパターンである。スタートアップが困難な調整問題を抽象化し、より大きなプラットフォームがその抽象化を購入する。なぜならそれが、コア製品の消費と制御を増やすからだ。買収者は展開経路を得る。顧客は統合を得るが、ベンダーからの独立性をいくらか失う可能性がある。

現在の製品ロードマップが最大の欠落事実である

公開記録は買収と統合を確認するが、AXI、Network Transit、App Transit、AIR、Nebula から現在の Palo Alto Networks 製品または販売単位への完全なマッピングは指定していない。レガシーサポート終了日、移行手順、機能ごとの継続性スケジュールも公開されていない。

このギャップは現在形での製品レビューを妨げている。歴史的な説明は、Prosimo が何を構築しなぜ重要だったかを説明できるが、バイヤーに今日どの機能が利用可能、ライセンス可能、サポートされているかを伝えない。現在の展開アドバイスは、アーカイブされた Prosimo のデータシートではなく、現在の Palo Alto Networks のドキュメントに依存しなければならない。

欠落したマップは戦略的分析も制約する。グラフと調整層の完全な吸収は、資産発見とファイアウォール配置の選択的使用とは異なる。前者は広範な制御サービスを生み出し、後者は Prosimo を主にセキュリティ展開を加速するために使用する。創業者の声明は技術の継続を支持するが、このアーキテクチャ上の境界を未解決のまま残す。

その後の製品ドキュメント、移行ガイド、または顧客事例が、不確実性の多くを解決する可能性がある。それまでは、正確な表現は、共同創業者によると Prosimo の技術は Palo Alto Networks 製品に統合されたが、範囲とパッケージングは検証されていない、というものである。

マルチクラウドルーティングを制御するのは誰か？

単一のエンティティがパス全体を制御しているわけではない。企業は、アカウントの所有権、ビジネス意図、アプリケーション設計、付与するクレデンシャルを制御する。クラウド横断的コントローラーは、トポロジーを発見し、ポリシーを変換し、パスを選択し、ネイティブルーティング状態を変更できる。クラウドプロバイダーは、API、トランジットサービス、プライベートエンドポイント、バックボーン、および多くの障害ドメインを制御する。トランスポート事業者とコロケーションプロバイダーは、トランスポートの他の部分を制御する。セキュリティサービスは、検査されたトラフィックを許可するかどうかを決定する。

Prosimo は最も有利な中間地点を求めた。それは基盤を所有していなかったが、その上のグラフとポリシー翻訳を所有しようとした。その層を制御する者は、どの資産が見えるか、セグメントがどのように表現されるか、エッジがどこに配置されるか、どのサービスがトラフィックを検査するか、どのテレメトリが参照として扱われるかを決定できる。これは、ファイバーが他者によって所有されている場合でも、ルーティングに対する実用的な権限である。

買収後、Palo Alto Networks は存続する技術を所有し、それをどのように統合、パッケージ化、進化させるかを決定する。クラウドプロバイダーは自らの環境内で主権を持ち続け、企業はクレデンシャルを取り消すか、別のアーキテクチャを選択できる。しかし、トポロジー、ポリシー、ワークフローがコントローラーに依存するようになった場合、出口は高くつく可能性がある。

答えは絶対的ではなく多層的である。企業が委任し、コントローラーが調整し、クラウドとトランスポート層が運び、セキュリティプラットフォームが実施する。Prosimo のストーリーが重要なのは、クラウドアカウントや物理パスの所有権を変えることなく、調整層の所有権が変わり得ることを示しているからだ。

主要ソース記録

買収後も Prosimo が重要である理由

Prosimo はインフラストラクチャにおける真の転換を捉えた。ネットワーキングの運用単位は、デバイスとプレフィックスから、アプリケーション、アイデンティティ、サービス依存関係、ポリシーグラフへと移行している。クラウド API はネットワーク状態をプログラム可能にし、分散エッジは強制ポイントを移動可能にする。複数のクラウドを認識するコントローラーは、単一のクラウドパネルだけでは完了できないアクションを調整できる。

同社はまた、その調整のコストを明らかにした。共有層は、特権クレデンシャル、継続的な API メンテナンス、正確な検出、意味変換、テレメトリ、運用規律を必要とする。それは断片化された作業を減らす一方で、新たな集中ポイントを作り出す可能性がある。同じシステムがルーティングを簡素化し、誤った決定の影響範囲を拡大する可能性がある。

Palo Alto Networks の買収は、制御の質問をより鮮明にする。ネットワーキングとセキュリティは、サービス挿入、ワークロード発見、ポリシーを中心に収束している。トポロジーを認識しパスを変更するセキュリティベンダーは、自身に提示されたトラフィックを単に検査するだけでなく、どのトラフィックが検査され、どこで検査されるかを決定するのに役立つ。

したがって、Prosimo は失敗した独立ブランドとしても、単一のプラットフォームがマルチクラウドを解決した証拠としても記憶されるべきではない。その永続的な貢献は、クラウド横断的グラフをインフラストラクチャとして定義したことである。残る問題は、そのグラフがより大きなセキュリティ企業に入った後も、顧客の信頼を得るのに十分な透明性、可搬性、ガバナンスを維持しているかどうかである。