要約

  • Prosimo は2019年に設立され、2021年のシリーズ A と2022年のシリーズ B で少なくとも5500万ドルを調達した。監査済みの売上データ、評価額、買収価格は公開されていない。
  • AXI は、集中管理されたポリシー、トポロジー、分析機能と、クラウドリソースの検出、アプリケーション接続、セキュリティサービスの挿入を行う分散エッジを統合した。物理的なバックボーンは所有しなかった。
  • 2024年6月に発表された VM-Series 統合の後、Prosimo は2025年2月頃に Palo Alto Networks へ移行した。正確な日付、価格、現在の製品マッピングは確認されていない。
  • 管理は依然として企業、オーケストレーションソフトウェア、クラウドプロバイダー、Palo Alto Networks に分散している。したがって、トポロジー、アクセス権限、ポリシー、ルーティング権限の移植性が重要となる。

ブランドは消えても課題は残った

Prosimo は2026年時点で、積極的に活動する独立系ベンダーとは言えない。公開されている職歴から、創業者と複数の従業員が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、リスク、パフォーマンス、トランザクションテレメトリを組み合わせようとした。この広いコンテキストによって、特定のアプリケーションを接続する、セグメントを分離する、進入ポイントを選択する、選択したトラフィックをファイアウォール経由で送る、といったポリシーが可能になった。価値は新しいファイバー経路ではなく、既存の経路とサービスをどのように構成するかという判断に生まれた。

この違いが“application experience infrastructure”という表現を説明する。この用語は、個々のネットワークオブジェクトではなく、アプリケーションリクエストを中心に据えた。VPC、VNet、サブネット、トランジットハブ、プライベートリンクは、管理の最終目標ではなく、エンドツーエンド経路の構成要素となった。このアプローチは同時に、製品をクラウドネットワーキング、アプリケーションデリバリ、ゼロトラストアクセス、ネットワーク保証、コスト最適化、セキュリティサービス挿入という複数の市場に引き込んだ。

Prosimo とは何だったのか、そして今何が残ったのか

Prosimo は2019年に設立された非公開のクラウドネットワーキングソフトウェア企業で、サンフランシスコ・ベイエリアを拠点としていた。Ramesh Prabagaran 氏は共同創業者兼 CEO、Nehal Bhau 氏は独立時代に共同創業者兼 CTO を務めた。公開プロフィールには Linus Aranha 氏や Pradeep Aragonda 氏も創業またはシニアエンジニアリングの役割で名を連ねているが、具体的な肩書きは日付入りの経歴に依拠すべきである。

メインプラットフォームは Application eXperience Infrastructure（通称 AXI）と呼ばれた。AXI は、ポリシー、トポロジー、分析、オーケストレーションを扱う中央ソフトウェア層と、クラウドリージョン、コロケーション環境、隣接するオンプレミスインフラに配置された分散型 AXI エッジで構成された。後に Prosimo は製品を Full-Stack Cloud Transit として再編し、Network Transit と App Transit が異なる接続クラスをカバーした。AIR はテレメトリを分析して運用インサイトを提供し、Nebula は2024年に対話型インターフェースを追加した。

Prosimo はクラウドキャリアではなかった。全リージョンを結ぶグローバルなファイバーバックボーンを所有していたわけではない。経路には、クラウドプロバイダーのバックボーン、パブリックインターネット、専用線、コロケーションリンク、企業ネットワークが利用された。また Prosimo は、Palo Alto Networks のようなファイアウォールベンダーでもなかった。2024年の統合における役割はリソース検出、セグメンテーション、トラフィック制御であり、深いセキュリティ検査は VM-Series が担った。

買収後、最も正確な表現は「技術的継続性」である。後の統合声明では、マルチクラウドリソースの検出と、イングレス、エグレス、東西方向の検査を目的としたソフトウェアファイアウォールの迅速な展開が強調された。これは Prosimo の主要コンポーネントが存続している証拠だが、過去の AXI カタログ全体、商用パッケージ、サポートモデルがそのまま継承されたわけではない。

SD-WAN の先にある問題

創業チームは大規模ネットワーク、アプリケーションデリバリ、クラウドインフラの経験を持ち寄った。Prosimo は、SD-WAN を企業カテゴリーとして確立した Viptela の創業者・エンジニアコミュニティからも生まれている。しかし次の問題は別の場所にあった。SD-WAN は支社がネットワークやアプリケーションに到達する方法を簡素化できたが、複数のパブリッククラウド内部およびクラウド間の統一された運用モデルを生み出すものではなかった。

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

Prosimo は支社ではなくリクエストを起点とした。重要なのは、ユーザーやワークロードが、許容可能なセキュリティ、パフォーマンス、可用性、コストでアプリケーションにどう到達するかだった。これによりルーティング判断の対象は送信先プレフィックス単体から、ID とアプリケーションの文脈を伴うトランザクションへと移行した。同時に、プラットフォームは通常のルーターよりもはるかに多くの情報を収集・維持しなければならなかった。

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

2019年の創業から2021年の公開ローンチまで

Prosimo は2019年に設立されたが、公開ローンチを発表したのは2021年4月6日である。このとき General Catalyst が主導して2500万ドルのシリーズ A を調達した。投資家は、複数クラウドにわたる一貫したアプリケーション体験を提供する機会だと説明し、創業者が従来の支店接続を超えたカテゴリーを定義しようとした試みと一致していた。

市場投入によって、Prosimo は混雑し未整理なセグメントに参入した。クラウドプロバイダーは独自のネットワークサービスの購入を容易にし、SD-WAN および SASE ベンダーはポリシーをクラウド環境に拡張し、アプリケーションデリバリベンダーはリクエストを最適化し、ネットワークセキュリティ企業はそれを検査できた。Prosimo の主張は、これらの機能をクラウド指向のアーキテクチャで統合し、周辺システムすべてを置き換えると主張しないことにあった。

調達資金は、統合、ソフトウェアエッジ、分析、営業組織、パートナー関係の余地を生んだが、プロダクトマーケットフィットや収益規模、持続可能な差別化を証明するものではなかった。提供された証拠には、監査済みの収益データや年間経常収益、顧客数、評価額の記載はない。資金調達の経緯は投資家の仮説への信頼を示すが、完全な事業実績ではない。

2022年、Prosimo は「応募超過」と表現されたシリーズ B で3000万ドルを調達した。明確に特定された2回のラウンドで、確認できた調達総額は少なくとも5500万ドルである。一部のデータベースは、発表や関連レコードの重複カウントによってより高い数字を示す場合があるため、そのような総額は基礎となるイベントを分解せずに使用すべきでない。

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

AXI アーキテクチャは、集中管理層および分析層と、分散ソフトウェアエッジに機能を配分した。集中層はアプリケーションとネットワークのポリシーを管理し、リソースを検出し、トポロジーを統合し、ID を統合し、テレメトリを分析し、変更を調整した。AXI エッジはワークロードやユーザーの近くに配置され、すべてのパスを遠隔の物理ハブを経由させることなくポリシーを施行できた。

この分離は他のソフトウェア定義システムと似ているが、オブジェクトはクラウド固有でアプリケーション指向だった。コントローラはクラウドアカウントと API へのアクセスを必要とし、エッジはネイティブトランジットサービス、ワークロードネットワーク、プライベートエンドポイント、外部経路との接続を必要とした。プラットフォームの権限は、両方の視点——クラウド上のグローバルポリシーと、関連トラフィック近くでのローカル実行——の組み合わせから生じた。

このアーキテクチャはまた、実用的な展開境界を生み出した。各エッジはクラウドリソースを消費し、高可用性設計を必要とし、更新、監視、保護が必要だった。制御層は、リソースを検出しネットワーク状態を変更するのに十分な権限を持つクレデンシャルを必要とした。顧客は共通のワークフローを得る一方で、可用性と正確性が本番アプリケーションの到達可能性にとってクリティカルな管理システムを追加した。

Prosimo は「自律的クラウドネットワーキング」という言葉を使うことがあった。文書化されているのは自動化、推奨、API 主導のオーケストレーションまでであり、人間のポリシー、クラウドプロバイダーのサービス、基盤となるトランスポートから独立して動作するネットワークは確認されていない。オペレーターは依然としてポリシーを定義し、アクセスを承認し、例外を処理し、結果に責任を負った。

AXI エッジは配置の決断であり、普通のアプライアンスではない

AXI エッジは、クラウド VPC や VNet 内、コロケーション環境、隣接インフラに展開できた。AWS の技術文書は、Transit Gateway 経由でワークロード VPC に接続されたエッジ VPC を示し、オプションのファイアウォールチェーンとリモートユーザーやオンプレミスからのアクセスを伴っていた。この設計は Prosimo の執行ポイントをクラウドトポロジー内に置き、遠隔の企業境界に置かなかった。

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

分散配置によって管理すべき障害ドメインの数は増えた。キャパシティ、ソフトウェアバージョン、クラウドゾーン設計、ルート収束、アクセス権限がリージョンごとに異なりうる。高可用性は2つのインスタンス以上の意味を持ち、コントローラ、クラウドルーティングテーブル、セキュリティサービス、戻り経路も一貫したフェイルオーバー状態を示さねばならなかった。

そのためエッジは、より広範な運用システムの一部だった。その価値は、リソース検出、トポロジー、ポリシー、分析が周囲のクラウド環境と一貫しているかどうかに依存した。スタンドアロンの仮想アプライアンスと見なすことは、Prosimo が販売しようとしたアーキテクチャを見誤ることになる。

アンダーレイネットワークは他者の手に残った

Prosimo はトランスポートを調整したが、アンダーレイネットワークや物理経路を所有しなかった。アプリケーション経路は、AWS や他のクラウドプロバイダーのバックボーン、パブリックインターネット、Direct Connect や ExpressRoute、コロケーション、キャリア接続、企業ネットワークを利用できた。プラットフォームは利用可能な選択肢から選択して調整できたが、それらのプロバイダーのレイテンシー、パケットロス、障害ドメイン、価格モデルを取り除くことはできなかった。

この限界はパフォーマンス主張にとって重要である。コントローラは観測可能なより良い経路を選択したり、イングレスをユーザーに近づけたりできるが、キャリアが停止しないこと、クラウドリージョンが利用可能であり続けること、外部依存が迅速に応答することを保証できない。さらにアプリケーション体験には DNS、サーバー処理、ストレージ、ブラウザの振る舞い、ネットワークコントローラの直接制御外にあるサードパーティサービスも含まれる。

プロプライエタリなバックボーンを持たないことは弱点だけではなかった。Prosimo は企業がすでに支払っているインフラを活用し、クラウドプロバイダーの投資から利益を得ることができた。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 エッジのテレメトリを分析した。AWS の文書によると、ラウンドトリップ時間、処理時間、アプリケーション応答時間、トランザクションタイプ、リスク、ポリシー結果に関する洞察が説明されていた。プラットフォームは、分離されたデバイスカウンターを提示するのではなく、ユーザー、ネットワーク、アプリケーションのデータを相関させることができた。

この相関は既知の運用課題に取り組んだ。遅いトランザクションは、ユーザー経路、エッジ、クラウドバックボーン、セキュリティサービス、またはアプリケーション自体で引き起こされうる。層を横断する視点は、別々のコンソールよりも迅速に原因を絞り込み、経路、配置、リスク、コストに関する推奨を支援できる。

推奨の質は、テレメトリのカバレッジと解釈モデルに依存した。エッジはそれを通過したトラフィックしか観測できなかった。外部アプリケーション依存やプロバイダー内部の状態は見えないままかもしれない。推奨は方向を示しても、原因を証明するとは限らなかった。

テレメトリはガバナンス上の価値も持っていた。過去の観測は、ルートやポリシーがなぜ変更されたかを説明できた。同時に、アプリケーション利用やユーザー行動に関する機密情報を露呈する可能性もあった。公開情報は、買収後の保持やデータガバナンスを完全には記述しておらず、これらは顧客のデューデリジェンス事項として残る。

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

Prosimo の AWS 関連作業は、最も強力な公開技術的証拠を生み出した。同社は AWS Transit Gateway、Cloud WAN、PrivateLink、Marketplace for Containers Anywhere の展開ワークフローをサポートした。AWS は AXI エッジの配置、アプリケーションオンボーディング、ID、セキュリティ、最適化に関するガイダンスを公開した。

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

Marketplace ワークフローは、AXI エッジを承認済みチャネルでパッケージ化することで初期展開のステップを簡素化した。その後のアカウント権限、ルーティング設計、高可用性、キャパシティ、運用に関する作業は残った。Day-Zero 自動化はインストールの手間を減らせても、長期的な管理課題を取り除くわけではない。

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つの別個のイベントを混同するものである。

それでもパートナーシップは橋渡しを生み出した。Prosimo は、自身のルーティングとポリシーシステムがクラウド全体での VM-Series 展開をいかに容易にするかを示せた。Palo Alto Networks は、後に会社が移行する前に、実際の統合の中でその技術を評価できた。公開情報は買収プロセスを記述しておらず、パートナーシップが正式に買収の前段階として設計されたと主張するのは憶測になる。

2025年初頭には創業者と従業員のプロフィールが変わっていた。会社ページには後に買収を示す表記が付された。2025年末、Bhau 氏は技術が Palo Alto Networks 製品に完全に統合されたと説明した。これらを総合すると、これらの資料は買収の結論を支持するが、法的メカニズムは未確定のままである。

この順序は編集上の正確さと顧客にとって重要である。パートナーシップは2つのベンダー、2つのサポート構造、定義された統合境界を意味する。買収はロードマップ、データ、契約、権限を1つの会社に移すことができる。移行はブランド以上のものを変える――たとえ技術的な経路が当初は似ていても。

Nebula は対話型インターフェースを通じてトポロジーグラフにアクセス可能にした

Prosimo は2024年2月、マルチクラウドネットワーキング向けの AI スイートの一部として Nebula を発表した。このアシスタントは、プラットフォームのグラフとテレメトリに表れている重複ネットワーク、コスト、ルート状況、セキュリティポリシー違反、その他の状態について、自然言語で問い合わせられた質問に回答することを目的としていた。

価値ある資産は言語インターフェースそのものではなく、その下にある構造化されたクラウド横断型のコンテキストだった。汎用モデルは、見えないプライベートなルートやセグメントを診断できない。Nebula は、Prosimo がすでに収集していた資産インベントリ、トポロジー、ポリシー、観測データを活用できた。これにより、共通グラフへの先行投資が AIOps にとって意味を持つようになった。

対話型のアクセスは、複雑なデータをより多くのオペレーターに利用可能にしうる。同時に、回答がサポートされていない資産を省略したり、質問を誤解したり、推奨を承認済みのアクションとして扱ったりした場合、誤った信頼を生む可能性もあった。高リスクの変更には、決定論的な制御、権限境界、人間によるレビューが依然として必要だった。

Prosimo は、平均修復時間（MTTR）の60～80％削減、クラウドネットワーキングコストの60％以上削減といった改善可能性を挙げた。これらの数字は製品発表における企業主張であり、提供された証拠には独立した方法論や一般的な妥当性を証明する顧客のベースラインは含まれていない。これらは Prosimo が提案した利点として引用でき、計測された市場の事実ではない。

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

同じ2024年の発表では、Prosimo のアーキテクチャが AI ワークロードに有用であると位置づけていた。分散 AI システムは、プライベートデータアクセス、クラウドとデータセンター間の接続、コンプライアンス管理、アプリケーション挙動を考慮したルーティングを必要とする場合がある。これらの要件は既存の資産、ポリシー、経路モデルに適合していた。

このラベルはアンダーレイネットワークを変えなかった。Prosimo は依然としてクラウドネットワーク、キャリア、顧客インフラに依存していた。同社は GPU コンピュートやモデル開発ソフトウェアを提供しなかった。その可能性のある役割は、分散データとサービスのための接続性とセキュリティ層だった。

AI 向けのポジショニングは、データとサービスがより分散するほどクラウド横断トポロジーの価値が高まるため、戦略的に理解できるものだった。しかしそれは、独立した事業の終了直前に導入されたマーケティングカテゴリーでもあった。資料は、独立した AI 製品収益や具体的な本番展開、検証済みのワークロード結果を実証していない。

永続的な知見は、マルチクラウドテレメトリが機械支援オペレーションの基盤になりうるということである。今日の製品上の問いは、Palo Alto Networks がこのコンテキストを維持したかどうか、そしてその機能をどのようにアクセス可能にしているかである。本稿執筆時点で公開されている情報は完全な回答を提供しない。

ビジネスモデルは Prosimo が所有しないインフラのためのソフトウェアを販売した

Prosimo の独立した事業は、キャリアモデルではなくソフトウェアサブスクリプションおよびサービスモデルだった。顧客は自身の環境に AXI エッジを展開し、クラウドアカウントを制御層に接続した。収益はおそらくライセンスまたはサブスクリプション、サポート、プロフェッショナルサービス、販売パートナー活動から生じたであろうが、具体的な価格や契約指標は提供された証拠の中で公開されていない。

このモデルは自前のファイバーを持たずにスケールできた。ソフトウェアプラットフォームが多数のクラウドリージョンと顧客環境を調整した。しかしこのアーキテクチャから粗利益を結論づけることはできない。プロバイダー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年初頭までに買収者となった。この流れは、ある参加者が自社製品への経路を調整するソフトウェア層を購入するときに、エコシステムの依存が支配関係に変わることを示している。

最低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 Networks のセキュリティ製品の展開を改善するかどうか、そして顧客がその結果生じるプラットフォーム依存を受け入れるかどうかである。

ネイティブクラウドサービスは基盤であると同時に代替手段だった

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 Networks 製品の展開をより容易にすることができる。これはより統合されたユーザー体験を生み出す一方で、サードパーティの検査サービスのサポートに疑問を投げかける可能性がある。

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

統合に関する声明は、イングレス、エグレス、東西方向の検査を強調していた。これは、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 は、失敗した独立ブランドとも、単一のプラットフォームがマルチクラウド問題を解決した証拠とも見なされるべきではない。その永続的な貢献は、クラウド横断型グラフをインフラとして定義したことにある。残された問いは、このグラフが大規模なセキュリティ企業の中で、顧客の信頼を得るのに十分な透明性、移植性、制御可能性を保てるかどうかである。