概要

  • Prosimo は2019年に設立され、2021年のシリーズ A と2022年のシリーズ B で少なくとも5,500万米ドルを調達した。監査済み収益、評価額、買収価格は非開示である。
  • AXI は、集中管理されたインテント、トポロジー、分析と分散型のエッジノードを組み合わせ、物理インフラを所有することなく、クラウドアセットの検出、アプリケーションの接続、セキュリティサービスの挿入を実現していた。
  • 2024年6月に発表された VM-Series との統合は、2025年2月頃の Prosimo の Palo Alto Networks への統合に先立つものであり、正確な日付、価格、現在の製品マップは開示されていない。
  • 統制は、企業、オーケストレーションソフトウェア、クラウドプロバイダー、Palo Alto Networks の間に分散されたままである。トポロジー、認証情報、ポリシー、ルートに対する権限の移植性が、顧客にとっての真の試金石となる。

ブランドは消えたが、問題は残った

2026年において、Prosimo を活動中の独立系ベンダーと表現するのはもはや正確ではない。公開されている職歴情報によると、同社の創業者と複数の従業員は2025年2月頃に Palo Alto Networks に入社している。Prosimo の企業ページは買収済みと表示され、元 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 Edge を組み合わせたものだ。後に同社は、この製品を Full-Stack Cloud Transit として整理し、Network Transit と App Transit を異なるクラスの接続性に対応させた。AIR はテレメトリーを分析して運用インサイトを生成し、2024年には Nebula が会話型インターフェースを追加した。

Prosimo はクラウドオペレーターではなかった。すべてのリージョンを接続するグローバルなファイバーバックボーンを所有していなかった。パスは、プロバイダーのバックボーン、パブリックインターネット、専用回線、コロケーションリンク、企業ネットワークを横断する可能性があった。また、Palo Alto Networks と同じ意味でのファイアウォールベンダーでもなかった。2024年の統合において、同社の役割は検出、セグメント化、誘導であり、VM-Series が深層セキュリティインスペクションを提供した。

買収後、最も安全な説明は「技術系統」である。統合後の声明では、マルチクラウドアセットの検出と、イングレス、イグレス、東西トラフィックのインスペクションのためのソフトウェアファイアウォールの迅速な展開が強調されている。これは、Prosimo の重要なコンポーネントが存続していることを証明するものである。歴史的な AXI カタログ全体、商用パッケージング、顧客サポートモデルが変更なく継続されていることを証明するものではない。

SD-WAN の次に来た問題

創業チームは、大規模ネットワーキング、アプリケーションデリバリー、クラウドインフラストラクチャにおける経験を持っていた。Prosimo はまた、Viptela に関連する創業者やエンジニアから構成される、より広範なエコシステムから生まれた。Viptela は、SD-WAN をエンタープライズカテゴリーとして確立するのに貢献した企業である。次なる問題は異なっていた。SD-WAN は支店がネットワークやアプリケーションにアクセスする方法を簡素化できたが、複数のパブリッククラウド内およびクラウド間にわたる単一の運用モデルを生み出すことはできなかった。

マルチクラウドアプリケーションは、ある環境の Web エンドポイント、別の環境のデータベースやマネージドサービス、両方の外部にある ID プロバイダー、データセンターとのプライベート接続、選択された境界でのセキュリティインスペクションに依存する場合がある。それぞれの依存関係は、異なるネイティブコンポーネントとして現れる可能性がある。ネットワークチームはプレフィックスとトランジットハブを見るかもしれない。クラウドチームはアカウントとリソースオブジェクトを見る。アプリケーション担当者はドメインとトランザクションを、セキュリティ担当者はゾーンとインスペクションポリシーを見る。

Prosimo は、支店ではなくリクエストを起点とした。関連する問いは、ユーザーまたはワークロードが、許容可能なセキュリティ、パフォーマンス、可用性、コストのレベルでアプリケーションにどのように到達すべきかということであった。この定式化は、ルーティングの対象を、単なる宛先プレフィックスから ID とアプリケーションコンテキストを含むトランザクションへと変えた。また、従来のルーターよりもはるかに多くの情報をプラットフォームが収集・維持することを要求した。

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

2019年の創業から2021年の公開発表まで

Prosimo は2019年に設立されたが、公開開始を発表したのは2021年4月6日だった。General Catalyst が当時2,500万ドルのシリーズ A を主導した。投資家はこの機会を、クラウド間でのアプリケーションエクスペリエンスの提供と表現し、従来のブランチ接続を超えたカテゴリーを定義しようとする創業者の努力と一致していた。

この発表は、同社を混雑した未定義の市場に位置づけた。クラウドプロバイダーは自社のネットワーキングサービスの利用を容易にしていた。SD-WAN および SASE ベンダーは、ポリシーをクラウド環境に拡張していた。アプリケーションデリバリー企業はリクエストを最適化でき、ネットワークセキュリティ企業はそれらを検査できた。Prosimo の提案は、周囲のすべてのシステムを置き換えると主張することなく、これらの機能をクラウドネイティブなアーキテクチャに集約することにかかっていた。

資金調達は、統合、ソフトウェアエッジ、分析、営業組織、パートナー関係を構築する余地を与えた。それは製品市場適合性、収益規模、持続可能な差別化を証明するものではなかった。提供された証拠には、監査済み収益、年間経常収益、顧客数、評価額は含まれていない。資金調達履歴は、投資家のテーゼへのコミットメントを示すものであり、運用パフォーマンスの完全な姿ではない。

2022年、Prosimo は3,000万ドルのシリーズ B を完了し、需要が供給を上回るラウンドと評された。明確に特定された2つのラウンドを合計すると、少なくとも5,500万ドルが検証済みの調達額となる。一部のデータベースでは、発表や関連記録の重複により、より高い金額が表示される場合があるが、この合計は、基礎となるイベントを照合せずに使用すべきではない。

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

AXI アーキテクチャは、中央制御および分析層と、分散したソフトウェアエッジの間で作業を分割した。セントラル層は、アプリケーションおよびネットワークのインテントを保持し、アセットを検出し、トポロジーを組み立て、ID を統合し、テレメトリーを分析し、変更をオーケストレーションした。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 は、サブネットを超えてモデルを拡張した。ユーザーまたはワークロードがサービスにどのように到達するかを決定する際に、アプリケーションドメイン、ID、リクエストタイプ、トランザクションの健全性、リスク、パフォーマンスを使用することができた。これは、Prosimo が自社のプラットフォームを従来のクラウドルーターと差別化しようとした最も明確な試みだった。

アプリケーションビューが有用だったのは、最新のサービスが必ずしも固定アドレスによって安定的に表現されるとは限らないからだ。マネージドプラットフォーム、SaaS エンドポイント、分散コンポーネントは、アプリケーションのアイデンティティが意味を持ち続ける間にも変化しうる。サービスまたはユーザーを参照するポリシーは、アドレスとポートだけを中心に書かれたルールよりも持続可能かもしれない。

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

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

ID がルーティング決定と信頼境界を拡張した

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

ID は精度を高めたが、別の依存関係を持ち込んだ。ルートまたはアプリケーションポリシーは、ID プロバイダー、その主張、セッション状態、グループデータに依存するようになった。ルーターとエッジが健全であっても、認証が利用できなくなったり、属性が変更されたりしたためにネットワークパスが失敗する可能性がある。調査は、ネットワーク運用と ID 運用の境界を越える必要があった。

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

Prosimo のアプローチは、インフラストラクチャにおけるより広範な変化を示している。ルーティングとアクセスポリシーは、ID とアプリケーションセマンティクスにますます依存するようになっている。プラットフォームがより多くのコンテキストを把握するほど、その判断はより有用になる可能性があるが、同時に、その権限はより慎重に統治されなければならない。

アセット検出が、その後のすべての判断が依存するグラフを作成した

クロスクラウドコントローラーは、見えないものを統治することができない。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 の配置、アプリケーションのオンボーディング、ID、セキュリティ、最適化に関するガイドを公開した。

AWS Cloud WAN は特に重要だった。これは、Prosimo が置き換えるのではなく、オーケストレーションできるクラウドネイティブなバックボーンとセグメンテーションサービスを提供した。この取り決めは、製品の協調モデルを示していた。AWS はネイティブネットワークとグローバルインフラを所有し、Prosimo はクロスクラウドインテント、アプリケーションコンテキスト、ソフトウェアエッジ、分析を提供した。

Marketplace フローは、承認されたチャネルを通じて AXI Edge をパッケージ化することにより、展開の第一歩を簡素化した。アカウント権限、ルート設計、高可用性、キャパシティ、運用のその後の作業を排除するものではなかった。ゼロ日目の自動化は、長期的な制御問題を解決することなく、インストールの摩擦を減らすことができる。

Flexport への名目的な言及は、企業資料における AWS Cloud WAN のユースケースを裏付けていた。これは、企業顧客がアーキテクチャを承認する意思があったことを証明するものであり、規模、経済性、可用性の独立した監査ではない。したがって、顧客の声は、普遍的なパフォーマンスの証拠としてではなく、採用の例として使用されるべきである。

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

Prosimo は、Microsoft Azure と Google Cloud の環境もサポートしていた。資料では、Azure Virtual WAN、Google Cloud のネットワークコンポーネント、プライベートサービスに関するオーケストレーションについて説明していた。目標は、各プロバイダーのネイティブネットワーキングを維持しながら、単一の運用モデルを提示することだった。

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

したがって、マルチクラウド抽象化は、翻訳システムとして理解するのが最も適切である。インテントと一般的なワークフローを標準化できるが、セキュリティ、コスト、障害に影響する詳細事項を保持する必要がある。インターフェースが均一に見えても、実装の違いがオペレーターから隠されている場合、プラットフォームは危険になる。

買収後も同じことが当てはまる。Palo Alto Networks は共通のグラフを使用してクラウド全体にセキュリティを配置できるが、プロバイダーは依然としてパスを実装するネイティブオブジェクトを制御している。オーケストレーション層を所有することは、クラウドアンダーレイを所有することを意味しない。

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

2023年、Prosimo はマルチクラウドネットワークの設計、構築、調査、管理のためのフローについて説明した。製品は、トンネルやゲートウェイの確立を超えて進化していた。アセット検出は設計をサポートし、オーケストレーションは接続を作成し、マップとテレメトリーは調査を支援し、ポリシーと履歴状態は継続的な管理を支えた。

このライフサイクルの枠組みは、潜在的な購入者グループを拡大した。ネットワークエンジニアはトポロジーとパス分析を使用でき、クラウドプラットフォームチームはアカウントとサービスを統合でき、セキュリティチームはセグメンテーションとインスペクションをレビューでき、移行チームは変更を計画でき、FinOps チームはルートとイグレスの影響を調査できた。複数のグループが同じ証拠を使用する場合、価値はさらに高まった。

共有された証拠は、ガバナンスの対立を生み出す可能性もある。中央プラットフォームは、クラウドチームのネイティブ設定が企業ポリシーから逸脱していることを明らかにするかもしれない。組織は、どのシステムが権限を持ち、誰が修正を承認できるかを決定する必要がある。ソフトウェアだけでは、この制度的な問いを解決しない。

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

セグメンテーションはネットワークの到達可能性からアプリケーションポリシーへと広がった

Prosimo は、レイヤー3から7にわたるセグメンテーションを提示した。ネットワーク層では、ルートドメインとセグメントが、どのサブネットまたはサイトが通信できるかを決定した。上位層では、アプリケーション ID、ユーザーコンテキスト、トランザクションプロパティがルールを洗練させた。

この階層化モデルは、ネットワークゾーンとアプリケーションポリシーの間の距離を縮めることができた。たとえサブネット間の広範な到達可能性がブロックされていても、エンタープライズサービスは許可される可能性がある。逆に、到達可能なネットワークパスも、ID またはアプリケーションコンテキストが失敗したために拒否される可能性がある。

これは、Prosimo を本格的な次世代ファイアウォールに変えるものではなかった。2024年の Palo Alto Networks との統合では、責任が分離されていた。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つの別個のイベントを1つに見せてしまうだろう。

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

2025年初頭までに、創業者と従業員の履歴は変化していた。その後、会社のページは買収を示すようになった。2025年末までに、Bhau 氏は技術が Palo Alto Networks の製品に完全に統合されたと述べた。これらの記録を総合すると、買収の完了を裏付けるが、その法的メカニズムは未回答のままである。

このシーケンスは、編集の正確さと顧客にとって重要である。パートナーシップは2つのベンダー、2つのサポート構造、定義された統合境界を意味する。買収は、ロードマップ、データ、契約、権限を単一の企業に移転する可能性がある。この移行は、技術的なパスが最初は似ているように見えても、ブランド以上のものを変える。

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

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

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

会話型アクセスは、複雑なデータをより多くのオペレーターが利用できるようにする可能性がある。しかし、応答がサポートされていないアセットを省略したり、質問を誤解したり、推奨を承認されたアクションとして扱ったりした場合、過度の信頼を生み出す可能性もある。高リスクの変更には、依然として決定的な制御、権限制限、人間によるレビューが必要である。

Prosimo は、平均解決時間の60%～80%の短縮や、クラウドネットワーキングコストの60%超の削減といった潜在的な利益を報告した。これらの数値は、製品発表における企業の主張である。提供された証拠には、独立した方法論や顧客のベースラインが含まれておらず、一般的な適用を裏付けるものではない。これらは、Prosimo が提案した利益として引用することはできるが、測定された市場の事実ではない。

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

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

このラベルはアンダーレイを変えなかった。Prosimo は引き続き、クラウドネットワーク、キャリア、顧客インフラに依存していた。また、GPU コンピューティングやモデル開発ソフトウェアを提供したわけでもなかった。その潜在的な役割は、分散したデータとサービスを囲む接続性とセキュリティの層だった。

AI への位置づけは、クロスクラウドトポロジーの価値がデータとサービスがより分散するにつれて高まるため、戦略的に一貫性があった。しかし、それは同社が独立して運営されなくなる直前に導入されたマーケティングカテゴリーでもあった。証拠は、個別の AI 製品収益、特定された本番展開、監査済みのワークロード結果を確立していない。

永続的なポイントは、マルチクラウドテレメトリーが機械支援運用の入力になり得るということだ。現在の製品課題は、Palo Alto Networks がこのコンテキストを保持しているかどうか、また、その機能をどのように公開しているかである。調査時点で利用可能な公開証拠は、完全な回答を提供していない。

商業モデルはサードパーティのインフラに依存していた

Prosimo の独立したビジネスは、通信事業者モデルではなく、サブスクリプションソフトウェアとサービスのモデルに従っていた。顧客は自社の環境に AXI Edge を展開し、クラウドアカウントを制御層に接続した。収益は、正確な価格設定や契約上の指標は提供された証拠には現れていないものの、ライセンスまたはサブスクリプション、サポート、プロフェッショナルサービス、チャネルから生じていた可能性が高い。

このモデルは、ファイバーを所有することなく成長することができた。ソフトウェアプラットフォームは、多くのリージョンと顧客環境を調整できた。ただし、このアーキテクチャだけから粗利益率を推測することはできない。ベンダーAPI のエンジニアリングサポート、エッジのライフサイクル、セキュリティ統合、エンタープライズ展開にはコストがかかる可能性があり、エッジが消費するクラウドリソースは、ベンダーではなく顧客が支払う可能性がある。

Prosimo は、クラウドマーケットプレイス、統合パートナー、チャネル組織、名目的な顧客リファレンスを使用して企業にリーチした。これらの関係は等価ではない。マーケットプレイスへの掲載は、調達および展開パスを証明する。技術統合は、定義された条件下で2つのシステムが組み合わせ可能であることを示す。顧客の声は参考情報を提供する。これらのいずれも、単独では支払い顧客数や経常収益を確立しない。

同社の広範さは、販売の複雑さを増した可能性がある。ネットワーク、セキュリティ、クラウド、アプリケーションの各チームが恩恵を受ける可能性があるが、予算責任が不確かになることもある。製品は、各クラウドと各チームが別々に運用することを許容するのではなく、共通の制御層に資金を提供する意思のあるバイヤーを必要とした。

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

Amazon Web Services は、アンダーレイプロバイダーであると同時に、商用統合パートナーでもあった。Azure と Google Cloud は、サポートされる環境だった。ID プロバイダーは認証コンテキストを提供した。ファイアウォールベンダーはインスペクションを提供した。コロケーションサービスとキャリアはエッジをホストまたは接続することができた。チャネルパートナーは展開を設計および運用することができた。

Flexport は、AWS Cloud WAN の資料において名目的な顧客リファレンスとして登場した。このリファレンスは、アーキテクチャに対する企業の関心を示しているが、展開の完全な範囲、期間、商業的価値を明らかにするものではない。顧客ベース全体を代表するものとして扱うべきではない。

General Catalyst はシリーズ A を主導し、投資家としての関与を通じてガバナンスに参加した。WRVI または Celesta に関連する投資家が企業資料に登場し、その後の Prosimo のコミュニケーションでは、BlackRock に関連する名前を含む他の著名な参加者を挙げていたが、正確なビークルは調査では明らかにされていない。これらの記録は、十分にネットワーク化された財務基盤を裏付けるものであり、完全な資本構成の全体像ではない。

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

少なくとも5,500万ドルが調達されたが、出口の経済性は不明のままである

検証された資金調達履歴は、2021年4月の2,500万ドルのシリーズ A と、2022年の3,000万ドルのシリーズ B で構成される。合計は少なくとも5,500万ドルである。提供された証拠には、監査済みのキャップテーブル、評価額、負債構造、またはその後のラウンドは含まれていない。

買収で支払われた価格は開示されておらず、独立して検証されてもいない。価格がなければ、結果を戦略的プレミアム、控えめな技術買収、アクハイヤー、または窮境売却と分類することは責任あることではない。統合の継続は技術的価値を証明しているが、投資家または創業者が得たリターンを明らかにするものではない。

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 のネットワークサービスは、企業に強力なネイティブオプションを提供した。Prosimo はこれらのサービスに依存すると同時に、顧客がそれらを直接運用する可能性とも競合した。

この関係は可変的な境界を生み出した。プロバイダーがグローバルルーティング、セグメンテーション、サービスへのプライベートアクセス、または集中ポリシーを追加するにつれて、一部のサードパーティ機能はネイティブで再現しやすくなった。同時に、新しい各ネイティブサービスは、マルチクラウドコントローラーが検出および調整できる別のオブジェクトを追加した。クラウドの進歩は、Prosimo の価値の一部を減少させると同時に、プロバイダー間の翻訳の必要性を高める可能性があった。

決定的な要因は、技術的なものであると同時に組織的なものでもあった。単一のクラウドに集中し、強力な内部エンジニアリングを持つ企業は、ネイティブツールを好むかもしれない。チームが断片化されたマルチクラウド組織は、単一のコントロールプレーンを評価するかもしれない。規制対象の機関は、独立した証拠層を好むかもしれないが、特権的な認証情報とデータの集中を懸念するかもしれない。

どのアーキテクチャもロックインを排除しなかった。ネイティブツールは、単一のプロバイダーの API とセマンティクスへの依存を増大させた。クロスクラウドコントローラーは、そのグラフ、ポリシー、エッジソフトウェアへの依存を増大させた。有用な問いは、依存関係が可視化され、移植可能であり、組織の運用モデルに合致しているかどうかだった。

障害はコントローラー、エッジ、API、ID、アンダーレイで発生する可能性があった

Prosimo の分散アーキテクチャは、単一のトラフィックハブへの依存を減らしたが、相互接続された複数の障害ドメインを生み出した。セントラルサービスが利用できなくなったり、古いインテントを保持したりする可能性がある。エッジが故障したり、隔離されたりする可能性がある。クラウド API が変更の一部を拒否する可能性がある。ID プロバイダーが停止する可能性がある。アンダーレイがキャパシティを失ったり、予期しないルートをたどったりする可能性がある。挿入されたファイアウォールがリソースを使い果たす可能性がある。

部分的な障害は特に困難である。あるプロバイダーがルート更新を受け入れ、別のプロバイダーが拒否する場合がある。コントローラーの意図した状態は、実際のクラウド状態から分岐する可能性がある。トラフィックは非対称パスをたどったり、インスペクションを迂回したりする可能性がある。信頼性の高いシステムには、調整、冪等操作、段階的変更、明示的なエラー状態、各プロバイダーの動作を考慮したロールバックが必要である。

公開証拠は、可用性と最適化について高レベルで説明しているが、独立した障害注入研究、完全なインシデント履歴、普遍的なサービスレベル結果は含まれていない。回復性の主張は、文書化されたアーキテクチャまたは特定された顧客の証拠に紐付けたままにすべきである。

買収は別の障害ドメイン、すなわち製品の継続性をもたらす。顧客は、どのコンソール、API、エッジイメージ、ポリシーモデル、サポート組織が Prosimo の歴史的なシステムに取って代わるのかを知る必要がある。技術的に成功したコード統合でも、商業的および運用上の境界が不明瞭なままであれば、移行リスクを生み出す可能性がある。

クラウド認証情報がコントローラーをクリティカルな管理プレーンに置いた

アセット検出とオーケストレーションには、クラウドアカウントへのアクセスが必要だった。読み取り専用のインベントリは制限された権限を使用できたが、ルート、セグメント、サービス挿入の変更には、より大きな権限が必要だった。したがって、コントローラーは、ワークロードを所有していなくても、特権的な管理プレーン内に位置していた。

認証情報の侵害は、トポロジーを露呈させたり、広範な変更を許可したりする可能性がある。ソフトウェアの欠陥や運用上のミスは、複数のクラウドにわたってポリシーを伝播させる可能性がある。リスクはプラットフォームの有用性とともに増大した。プラットフォームが統治するアカウントとサービスが多ければ多いほど、潜在的な影響範囲は大きくなる。

企業は、最小権限の役割、検出と変更のための個別の認証情報、複数者による承認、完全な監査、ローテーション、緊急時の取り消し、同じコントローラーだけに依存しないリカバリパスを必要とした。提供された公開資料には、完全な独立したセキュリティ評価が含まれていないため、これらの項目は検証された製品保証ではなく、必要な展開制御のままである。

テレメトリーグラフも同様に機密性が高かった。アプリケーション名、ネットワーク構造、ポリシー、ユーザー関係、ルートの健全性、コストパターンが明らかになる可能性がある。買収後のガバナンスは、これらのデータがどこに保存され、どの Palo Alto Networks 製品がそれを使用できるか、以前の顧客権限がどのように移行されたかを明確にする必要がある。調査時点の公開証拠はこれらの質問に答えていない。

買収は、以前は中立的だった制御層をセキュリティプラットフォームにもたらした

独立した立場により、Prosimo はクラウドとセキュリティサービス間の共通層として自らを提示することができた。Palo Alto Networks が所有者になったとき、インセンティブは変化した。買収された技術は、VM-Series および他の Palo Alto 製品の展開を促進することができる。これにより、より良い統合が提供される可能性がある一方で、サードパーティのインスペクションサービスのサポートに関する疑問が生じる。

所有権は、中立性が消えたことを証明するものではない。証拠には、現在のパートナーマトリックスや現代の製品アーキテクチャは含まれていない。しかし、顧客の質問は変わる。ルーティングコントローラーが複数のセキュリティベンダーに対してオープンなままかどうか、ポリシーとテレメトリーをエクスポートできるかどうか、最適化が所有者のポートフォリオを優先するかどうかを知る必要がある。

統合声明は、イングレス、イグレス、東西トラフィックのインスペクションを強調した。この焦点は、Prosimo のトポロジーとオーケストレーションが、セキュリティ展開システムの一部になったことを示唆している。App Transit、ユーザーアクセス、コスト最適化、または歴史的なクラウドネットワーキングフロー全体が個別の機能として存続していることを証明するものではない。

これは、インフラストラクチャにおける一般的なパターンである。スタートアップが困難な調整問題を抽象化し、より大きなプラットフォーム企業が、そのコア製品の消費と制御を増やすために抽象化を購入する。買い手は展開へのルートを獲得する。顧客は統合を得るかもしれないが、ベンダー独立性の一部を失うかもしれない。

現在の製品マップが主な情報ギャップである

公開記録は買収と統合を確認しているが、AXI、Network Transit、App Transit、AIR、Nebula を現在の Palo Alto Networks の製品または SKU に完全にマッピングするものは特定されていない。また、レガシーサポートのタイムライン、移行手順、機能ごとの継続性テーブルも公開されていない。

このギャップは、現在の製品評価を妨げている。歴史的な説明は、Prosimo が何を構築し、なぜ重要だったかを説明している。今日どの機能が利用可能で、ライセンス供与され、サポートされているかは知らせない。現代の展開に関する推奨事項は、アーカイブされた Prosimo のリリースではなく、現在の Palo Alto Networks のドキュメントに基づく必要がある。

欠落したマップはまた、戦略的分析を制限する。グラフとオーケストレーション層の完全な吸収は、アセット検出とファイアウォール配置の選択的な使用とは異なるだろう。一方の結果は、広範なマルチクラウド制御サービスを生み出し、もう一方は主にセキュリティ展開を加速するために Prosimo を使用する。共同創業者の声明は技術的な継続性を裏付けているが、このアーキテクチャ上の境界は未回答のままにしている。

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

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

単一の当事者がパス全体を制御しているわけではない。企業はアカウントの所有権、ビジネスインテント、アプリケーション設計、付与する認証情報を制御する。クロスクラウドコントローラーは、トポロジーを検出し、ポリシーを翻訳し、パスを選択し、ネイティブルーティング状態を変更できる。プロバイダーは、API、トランジットサービス、プライベートエンドポイント、バックボーン、多くの障害ドメインを制御する。キャリアとコロケーションプロバイダーは、トランスポートの他の部分を制御する。セキュリティサービスは、インスペクションされたトラフィックを許可するかどうかを制御する。

Prosimo は、戦略的に最も有用な中間ポジションを追求した。アンダーレイは所有していなかったが、その上のグラフとポリシー翻訳を所有しようとした。この層を制御する者は、どのアセットが可視化されるか、セグメントがどのように表現されるか、エッジがどこに配置されるか、どのサービスがトラフィックを検査するか、どのテレメトリーが権威あるものと見なされるかを決定できる。これは、ファイバーが他の組織に属していても、ルーティングに対する実質的な権力である。

買収後、Palo Alto Networks は Prosimo の残りの技術を所有し、それがどのように統合、パッケージ化、開発されるかを決定する。プロバイダーは自社の環境内で主権を保持し、企業は認証情報を取り消したり、別のアーキテクチャを選択したりできる。ただし、トポロジー、ポリシー、運用フローがコントローラーに依存するようになった場合、離脱にはコストがかかる可能性がある。

したがって、答えは絶対的なものではなく、層ごとに分散されている。すなわち、企業が認可し、コントローラーが調整し、クラウドとキャリアのアンダーレイが転送し、セキュリティプラットフォームが実施する。Prosimo の物語が重要なのは、クラウドアカウントや物理ルートが所有者を変えずに、調整層の所有権が変更され得ることを示しているからだ。

主な情報源記録

買収後も Prosimo が依然として重要な理由

Prosimo は、実際のインフラストラクチャの変化を捉えた。ネットワーク管理の単位は、デバイスとプレフィックスから、アプリケーション、ID、サービス依存関係、ポリシーグラフへと移行している。ネイティブ API はネットワーク状態をプログラム可能にし、分散エッジは適用ポイントを移動可能にする。複数のクラウドを認識するコントローラーは、単一のコンソールでは単独で完了できないアクションを調整することができる。

同社はまた、この調整のコストも露呈させた。共通層には、特権的な認証情報、継続的な API の維持、正確な検出、意味的な翻訳、テレメトリー、運用規律が必要である。断片化された作業を減らすことができる一方で、新たな集中点を生み出す可能性がある。ルーティングを簡素化する同じシステムが、悪い判断の影響範囲を拡大する可能性もある。

Palo Alto Networks による買収は、制御の問題をより可視化している。ネットワークとセキュリティは、サービス挿入、ワークロード検出、ポリシーを中心に融合しつつある。トポロジーを認識し、ルートを変更するセキュリティベンダーは、受信したトラフィックを検査するだけにとどまらず、どのトラフィックがインスペクションに到達し、どこでそれが起こるかを決定するのを支援できる。

Prosimo は、失敗した独立ブランドとしても、あるプラットフォームがマルチクラウドを解決した証拠としても記憶されるべきではない。その永続的な貢献は、クロスクラウドグラフをインフラストラクチャとして定義したことである。残された問いは、現在ではより大規模なセキュリティ企業の内部にあるこのグラフが、顧客の信頼に値するほど透明性が高く、移植可能で、統治可能であり続けるかどうかである。