Кратко

  • Prosimo основана в 2019 году и привлекла не менее 55 млн долларов США в раундах серии A (2021) и серии B (2022). Аудированная выручка, оценка стоимости и цена приобретения не раскрывались.
  • AXI объединяла центральный уровень интентов, топологии и аналитики с распределёнными edge-узлами и обеспечивала обнаружение облачных активов, подключение приложений, вставку средств безопасности и сбор телеметрии без владения физической магистралью.
  • После анонса интеграции с VM-Series в июне 2024 года Prosimo к февралю 2025 года перешла под управление Palo Alto Networks, однако точные дата сделки, цена и соответствие текущим продуктам не раскрыты.
  • Контроль распределён между предприятием, оркестрационным ПО, облачными операторами и Palo Alto Networks. Возможность перенести топологию, учётные данные, политики и права на изменение маршрутов — ключевой критерий для клиентов.

Проблема осталась, даже когда компания потеряла независимость

Представлять Prosimo в 2026 году как действующего независимого вендора было бы неточно. Судя по открытым данным о карьере, основатель и несколько сотрудников перешли в Palo Alto Networks примерно в феврале 2025 года. Страница компании Prosimo помечена как приобретённая, а бывший технический директор 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 и удалёнными пользователями. У каждой среды свои маршруты, шлюзы, приватные эндпоинты, контроль идентичности, сервисы безопасности, лимиты и правила тарификации. Даже владея аккаунтами, компания часто не видит на одном экране, как конкретный запрос перемещается между средами. Значение Prosimo в том, что она попыталась собрать и контролировать эту картину в едином операционном слое.

Поэтому приобретение — не эпилог, а стержень всей статьи. Prosimo создала кросс-облачный слой управления, способный обнаруживать активы, интерпретировать контекст приложений и направлять трафик в сервисы безопасности. Palo Alto Networks сначала выступила технологическим партнёром, встраивающим VM-Series в эти маршруты, а затем стала владельцем технологии. Граница между оркестрацией маршрутизации и глубокой инспекцией переместилась внутрь единой кибербезопасной платформы.

Мультиоблачная маршрутизация — борьба за контекст

Таблица маршрутизации отвечает, достижим ли префикс через тот или иной следующий переход. Но она не объясняет, к какому приложению направлялся пользователь, можно ли доверять отправителю, нужно ли пропускать трафик через сервис инспекции, доступен ли приватный эндпоинт, какой облачный маршрут дороже и не сбоит ли транзакция после прибытия пакета. Мультиоблачная эксплуатация сводит всё это в одну задачу управления.

Prosimo утверждала, что полномочия маршрутизации не должны определяться только достижимостью на уровне L3. Её ПО пыталось соединять реестр облачных активов, состояние сети, идентичность приложений и пользователей, риск, производительность и телеметрию транзакций. Это позволяло выражать политики подключения конкретных приложений, сегментации, выбора точки входа и пропуска выбранного трафика через файрвол. Ценность заключалась не в изобретении новых оптоволоконных маршрутов, а в решении, как комбинировать существующие пути и сервисы.

Это различие объясняет, почему компания использовала термин «application experience infrastructure». Центром управления был не отдельный сетевой компонент, а запрос приложения. VPC, VNet, подсети, транзитные хабы и приватные линки становились не конечными объектами управления, а элементами сквозного маршрута. Такой подход выводил продукт одновременно на несколько рынков: облачный сетевой стек, доставку приложений, zero-trust-доступ, сетевую гарантию, оптимизацию затрат и вставку сервисов безопасности.

Широкий охват создавал и возможности, и неопределённость. Продукт, затрагивающий несколько команд, может решить проблему разобщённости, за которую никто не отвечает напрямую. Но оценка усложняется, потому что у сетевых, security-, облачных, прикладных и финансовых команд разные определения успеха. Prosimo нужно было доказать, что кросс-облачная модель улучшает операции и при этом не превращается в новый привилегированный слой, чья ошибка затрагивает все среды.

Чем была Prosimo и что от неё осталось

Prosimo — частная компания, основанная в 2019 году и занимавшаяся ПО для облачного сетевого взаимодействия; базировалась в заливе Сан-Франциско. В период независимости Ramesh Prabagaran был сооснователем и генеральным директором, Nehal Bhau — сооснователем и техническим директором. В открытых данных о карьере 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 года роль Prosimo — обнаружение, сегментация и направление трафика, а глубокую инспекцию безопасности выполняла VM-Series.

Самая безопасная формулировка после приобретения — «технологическая преемственность». Последующие заявления об интеграции подчёркивали обнаружение мультиоблачных активов и ускорение развёртывания программных файрволов для инспекции входящего, исходящего и east-west трафика. Это свидетельствует о сохранении важных компонентов Prosimo. Но это не доказывает, что прежние продуктовые линейки AXI, коммерческие пакеты и модель поддержки клиентов продолжились в прежнем виде.

Проблема, возникшая после SD-WAN

Основательская команда имела опыт в крупномасштабном сетевом взаимодействии, доставке приложений и облачной инфраструктуре. Prosimo также выросла из широкого круга основателей и инженеров, связанных с Viptela — компанией, сыгравшей большую роль в становлении SD-WAN как корпоративного рынка. Но следующая задача была иной. SD-WAN упрощала подключение филиалов к сети и приложениям, но не создавала единую операционную модель внутри нескольких публичных облаков и между ними.

Мультиоблачное приложение может зависеть от веб-эндпоинта в одной среде, базы данных и управляемых сервисов в другой, внешнего провайдера идентичности, приватного соединения с дата-центром и инспекции безопасности на выбранных границах. Каждая зависимость выражается через разные нативные компоненты. Сетевая команда видит префиксы и транзитные хабы, облачная — аккаунты и объекты ресурсов, владельцы приложений — домены и транзакции, security-команда — зоны и политики инспекции.

Prosimo отталкивалась не от филиала, а от запроса. Вопрос заключался в том, как пользователь или рабочая нагрузка достигает приложения при достаточных условиях безопасности, производительности, доступности и стоимости. Эта рамка расширяла объект маршрутизации с простого префикса назначения до транзакции с идентичностью и контекстом приложения. Соответственно, требовалось собирать и поддерживать гораздо больше информации, чем обычному маршрутизатору.

Рыночная среда тоже способствовала. AWS, Azure и Google Cloud расширяли нативные транзитные сервисы и сервисы приватного подключения. Предприятия могли строить сложные сети внутри каждого облака, но API, объекты и модели политик различались у каждого провайдера. Возможность Prosimo заключалась не в замене их собственной магистралью, а во взаимной координации.

От основания в 2019 году до официального запуска в 2021-м

Prosimo была основана в 2019 году, но объявила о публичном запуске 6 апреля 2021 года. Раунд серии A на 25 млн долларов на тот момент возглавила General Catalyst. Инвестор подчёркивал возможность предоставления качества работы приложений в нескольких облаках, что совпадало с видением основателей, стремившихся определить категорию за пределами традиционного подключения филиалов.

Рынок на момент запуска был переполнен, а границы категорий размыты. Облачные провайдеры делали собственные сетевые сервисы удобнее. Вендоры SD-WAN и SASE расширяли политики в облако, компании доставки приложений оптимизировали запросы, а сетевые security-компании могли их инспектировать. Убедительность Prosimo зависела от того, сможет ли она, не заявляя о замене всего вокруг, соединить эти функции в единой облако-ориентированной архитектуре.

Средства дали возможность строить интеграции, программные edge-узлы, аналитику, продажи и партнёрства. Но они не доказали product-Отрасли и рынки fit, масштаб выручки или устойчивую дифференциацию. В доступных материалах нет аудированной выручки, годового повторяющегося дохода, числа клиентов или оценки. Данные о финансировании показывают лишь, что инвесторы вложили капитал в гипотезу, а не полную картину результатов.

В 2022 году Prosimo завершила раунд серии B на 30 млн долларов, описанный как переподписанный. Сумма двух надёжно подтверждённых раундов — не менее 55 млн долларов. Некоторые базы данных могут задваивать анонсы и связанные записи и показывать более крупные цифры, поэтому их не стоит использовать без проверки по первоисточникам сделок.

AXI помещала политики поверх облака, а исполнение — рядом с рабочими нагрузками

Архитектура AXI разделяла роли между центральным слоем управления и аналитики и распределёнными программными edge-узлами. Центральный слой хранил интенты приложений и сети, обнаруживал активы, собирал топологию, интегрировал идентичность, анализировал телеметрию и оркестрировал изменения. AXI Edge размещался рядом с рабочими нагрузками или пользователями, позволяя применять политики без возврата всех маршрутов в удалённый физический хаб.

Такое разделение похоже на другие программно-определяемые системы, но было облако-специфичным и ориентированным на приложения. Контроллеру требовался доступ к облачным аккаунтам и API, а edge — соединение с нативными транзитными сервисами, сетями рабочих нагрузок, приватными эндпоинтами и внешними маршрутами. Сочетание общего интента поверх облака и локального исполнения рядом с релевантным трафиком создавало новый уровень полномочий.

Одновременно возникли и эксплуатационные границы. Каждый edge потреблял облачные ресурсы, требовал отказоустойчивой архитектуры, обновлений, мониторинга и защиты. Контрольному слою нужны были учётные данные с достаточными правами для обнаружения активов и изменения состояния сети. Предприятия получали общие рабочие процессы, но добавляли новую систему управления, чьи доступность и корректность влияли на рабочую достижимость.

Prosimo иногда использовала термин «автономный облачный сетевой стек». Доказательства подтверждают автоматизацию, рекомендации и API-ориентированную оркестрацию. Это не сеть, работающая независимо от человеческих политик, сервисов облачных провайдеров и нижележащих транспортных маршрутов. Операторы по-прежнему задавали интенты, утверждали доступ, обрабатывали исключения и несли ответственность за результаты.

AXI Edge — не универсальный аппаратный модуль, а решение о размещении

AXI Edge можно было развернуть в облачной VPC или VNet, в среде колокации или рядом с локальной инфраструктурой. В техническом описании AWS показана конфигурация, где edge-VPC подключалась к VPC рабочих нагрузок через Transit Gateway, при необходимости выстраивала цепочку файрволов и обеспечивала доступ удалённых пользователей и локальных площадок. Точка исполнения Prosimo находилась не на удалённой корпоративной границе, а внутри облачной топологии.

Размещение определяло не только задержку, но и то, где трафик входит в домен политик, какой облачной магистралью или интернет-маршрутом он пойдёт, где выполняется шифрование и инспекция и какая телеметрия доступна. Неудачное размещение приводило к крюкам и затратам, удачное — сокращало маршруты и держало трафик рядом с рабочими нагрузками.

Распределённое размещение увеличивало число доменов отказа, которыми нужно управлять. Ёмкость, версии ПО, архитектура облачных зон, сходимость маршрутов и права доступа могли различаться по регионам. Высокая доступность не сводится к запуску двух инстансов: контроллер, таблицы облачных маршрутов, сервисы безопасности и обратные маршруты должны разделять одно состояние фейловера.

Edge был частью более крупной операционной системы. Его ценность зависела от согласованности обнаружения активов, топологии, политик и аналитики с окружающей облачной средой. Если рассматривать его как отдельный виртуальный модуль, теряется архитектура, которую Prosimo пыталась продавать.

Андерлей всегда принадлежал кому-то другому

Prosimo координировала транспортировку, но не владела физическими маршрутами. Путь приложения мог проходить через облачные магистрали (например, AWS), публичный интернет, Direct Connect или ExpressRoute, сервисы колокации, линии операторов связи и корпоративные сети. Можно было выбирать маршруты из доступных вариантов и связывать их между собой, но нельзя устранить задержку, потерю пакетов, домены отказа и правила тарификации каждого оператора.

Эта граница важна при оценке заявлений о производительности. Контроллер может выбрать лучший путь по наблюдениям и приблизить точку входа к пользователю. Но он не гарантирует защиту от сбоев операторов, остановок облачных регионов или задержек внешних зависимостей. Качество работы приложения включает DNS, обработку на сервере, хранилище, работу браузера и сторонние сервисы — всё это вне полных полномочий сетевого контроллера.

Отсутствие собственной магистрали не было лишь слабостью. Оно позволяло использовать инфраструктуру, которую предприятия уже купили, и пользоваться инвестициями облачных провайдеров. Можно было дотянуться до регионов без прокладки оптоволокна и задействовать нативные системы вроде AWS Cloud WAN. Взамен возникала зависимость от стабильности API, лимитов сервисов, коммерческих условий и специфических семантик провайдеров.

Поэтому речь шла не о физическом владении, а об операционном контроле. Prosimo пыталась заставить разнородный андерлей вести себя как единая управляемая система, сохраняя его нативные преимущества. Уменьшила ли эта абстракция зависимость от поставщиков или просто перенесла её в другое место, зависело от переносимости политик, топологии и размещения edge-узлов.

Network Transit отвечала за достижимость между сетевыми объектами

Network Transit работала с VPC, VNet, подсетями, регионами, площадками и сегментами. Вместо индивидуальной настройки каждого провайдера она координировала облачные нативные транзитные и маршрутные конфигурации, чтобы соединения создавались через общий рабочий процесс. Это поддерживало базовое требование классической сети: исходный префикс или сегмент достигает назначения по разрешённому маршруту.

Это не означало, что различия между облаками исчезают. У AWS, Azure и Google Cloud разные объекты, лимиты и поведение маршрутизации. Пересекающиеся адресные пространства, асимметричные маршруты, приватные эндпоинты и специфические ограничения сервисов по-прежнему требовали проектирования. Prosimo могла нормализовать общие операции и визуализировать связи, но ограничения базовых систем оставались.

Network Transit также отвечала за сегментацию. С помощью маршрутных доменов и политик можно было изолировать среды и ограничивать достижимость. Контроллер должен был понимать, где в нескольких облаках находятся сегменты и как нативные конфигурации реализуют границы. Даже единожды выраженная политика могла преобразовываться в несколько изменений у каждого провайдера.

Преимущество — работа с интентами на единой поверхности. Риск — в преобразовании. Если общая политика и облачные конфигурации расходятся, компания может считать сегмент защищённым, тогда как фактическое состояние у провайдера иное. Поэтому сверка, аудит и явное сообщение об ошибках были не менее важны, чем первичная подготовка ресурсов.

App Transit делала объектом маршрутизации приложение

App Transit расширяла модель за пределы подсетей. При определении того, как пользователь или рабочая нагрузка достигает сервиса, использовались домен приложения, идентичность, тип запроса, здоровье транзакции, риск и производительность. Именно здесь Prosimo наиболее явно пыталась показать отличие от классических облачных маршрутизаторов.

Прикладная перспектива имела смысл, поскольку современные сервисы не сводятся аккуратно к фиксированным адресам. Управляемые платформы, SaaS-эндпоинты и распределённые компоненты меняются, а идентификатор приложения сохраняет значение. Политики, ссылающиеся на сервис или пользователя, иногда живут дольше правил, основанных только на адресе и порте.

Эта модель требовала точного обнаружения. Контроллер должен был понимать, какие домены и эндпоинты относятся к приложению, какие зависимости нужны и утверждениям какого провайдера идентичности можно доверять. Устаревшие сопоставления могли направить запрос по неверному маршруту и применить неверные правила безопасности. Прикладная абстракция не устраняла необходимость понимать состояние сети, а добавляла поверх него смысловой слой.

Сочетание Network Transit и App Transit признавало сосуществование двух миров. Легаси-системы, приватные подсети и управление на основе IP остаются, а новые приложения зависят от доменов, идентичности и управляемых сервисов. Full-Stack Cloud Transit — это название продукта для совместной эксплуатации обоих, а не замены одного другим.

Идентичность расширяла решения о маршрутизации и границы доверия

Доступ с учётом приложений требовал интеграции идентичности. Платформа могла использовать контекст пользователя или рабочей нагрузки, чтобы решать, разрешать ли подключение и как его установить. Это поддерживало zero-trust-политики, согласно которым одно лишь местоположение не является достаточным основанием для прав доступа.

Идентичность повышала точность, но создавала новые зависимости. Маршрутные или прикладные политики опирались на провайдера идентичности, его утверждения, состояние сессии и данные групп. Даже при исправных маршрутизаторах и edge-узлах сбой аутентификации или изменение атрибутов могло нарушить сетевой путь. Реагирование на инциденты должно было пересекать границу между сетевыми операциями и управлением идентичностью.

Контроллер становился точкой концентрации чувствительного контекста: топологии, связей приложений, атрибутов пользователей, сигналов риска и результатов политик. Эти данные улучшали диагностику и оптимизацию, но увеличивали последствия несанкционированного доступа. Минимальные привилегии, сроки хранения, аудит и разделение обязанностей были не административным дополнением, а архитектурными требованиями.

Подход Prosimo отражает изменение, происходящее во всей отрасли. Политики маршрутизации и доступа всё сильнее зависят от идентичности и семантики приложений. Чем больше контекста видит платформа, тем полезнее могут быть её решения. Но тем строже нужно контролировать эти полномочия.

Обнаружение активов создавало граф, на котором держались все последующие решения

Кросс-облачный контроллер не может управлять тем, чего не видит. Prosimo разработала обнаружение облачных активов и карты, отображающие VPC, VNet, подсети, приложения, соединения и связи безопасности. Эти представления поддерживали онбординг, проектирование, реагирование на инциденты и политики.

Обнаружение имело стратегическую ценность, поскольку облачные активы меняются вне центральных сетевых процедур. Прикладные команды могут создавать аккаунты, сети, эндпоинты и управляемые сервисы через собственную автоматизацию. Ручные схемы устаревают. API-управляемый реестр активов даёт более свежий граф, но его полнота зависит от охвата аккаунтов, прав, логики парсинга и API провайдеров.

Граф был не просто документом, а структурой данных для вычисления маршрутизации, сегментации, вставки сервисов и оптимизации. Если актив или зависимость отсутствовали, все выводы, построенные на нём, могли оказаться неверными. Поэтому топологии требовалась происхождение: когда собрана, какие аккаунты предоставили данные, какие регионы включены и не было ли ошибок в запросах.

Этот граф объясняет и мотив приобретения. Palo Alto Networks может создавать ценность в области безопасности, если знает, где находятся рабочие нагрузки и маршруты трафика. Система, способная обнаруживать облачные активы и изменять маршруты, сокращает путь от покупки программного файрвола до его правильного развёртывания. Последующее заявление Bhau также акцентировало обнаружение активов и ускорение развёртывания программных файрволов.

AIR превращала edge-телеметрию в операционные рекомендации

Application-driven Intelligent Results (AIR) анализировала телеметрию, собранную AXI Edge. В описании AWS объясняется визуализация времени в обе стороны, времени обработки, времени ответа приложения, типа транзакций, риска и результатов политик. Платформа связывала наблюдения за пользователем, сетью и приложением, а не отдельные счётчики устройств.

Такая корреляция отвечает на типичную эксплуатационную проблему. Причина медленной транзакции может быть в пути пользователя, edge, облачной магистрали, сервисе безопасности или самом приложении. Сквозное представление позволяет быстрее сузить область поиска, чем отдельные консоли, и поддерживает рекомендации по маршрутам, размещению, риску и затратам.

Качество рекомендаций зависело от охвата телеметрии и модели интерпретации. Edge наблюдает только трафик, проходящий через него. Внешние зависимости приложения или внутреннее состояние облачного провайдера могут быть не видны. Рекомендации полезны как ориентир, но не всегда доказывают корневую причину.

Телеметрия имела и управленческую ценность. Прошлые наблюдения помогают объяснить, почему изменились маршруты и политики. В то же время они могут раскрывать чувствительные данные об использовании приложений и поведении пользователей. Публичные материалы не полностью объясняют сроки хранения и контроль данных после приобретения, поэтому это остаётся вопросом должной осмотрительности для клиентов.

AWS дала наиболее ясные свидетельства внедрения

Работа Prosimo с AWS оставила наиболее сильные открытые технические свидетельства. Компания интегрировалась с рабочими процессами развёртывания AWS Transit Gateway, Cloud WAN, PrivateLink и Marketplace for Containers Anywhere. AWS опубликовала технические описания размещения AXI Edge, онбординга приложений, идентичности, безопасности и оптимизации.

Особенно важен был AWS Cloud WAN. Он предоставлял нативную магистраль и сервис сегментации, которыми Prosimo могла оркестрировать, а не заменять. Эта конфигурация иллюстрирует кооперативную модель: AWS владеет нативными сетями и глобальной инфраструктурой, а Prosimo предоставляет кросс-облачные интенты, контекст приложений, edge-ПО и аналитику.

Рабочие процессы 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 описывала рабочие процессы проектирования, построения, реагирования на инциденты и управления мультиоблачными сетями. Продукт вышел за пределы установки туннелей и шлюзов. Обнаружение активов поддерживало проектирование, оркестрация создавала соединения, карты и телеметрия — реагирование на инциденты, а политики и историческое состояние — постоянное управление.

Эта рамка жизненного цикла расширяла круг коммерческих покупателей. Сетевые инженеры могли использовать топологию и анализ маршрутов, облачные платформенные команды — включать аккаунты и сервисы, security-команды — проверять сегментацию и инспекцию, команды миграции — планировать изменения, а FinOps — оценивать влияние маршрутов и исходящего трафика. Чем больше организаций пользовались одними данными, тем выше была ценность платформы.

Общие данные порождают и управленческие конфликты. Центральная платформа может выявить, что нативные настройки облачной команды расходятся с корпоративными политиками. Организация должна решить, какая система является авторитетной и кто утверждает изменения. Один лишь софт не решает этот институциональный вопрос.

Нарратив жизненного цикла усиливал и стоимость перехода. Когда контроллер хранит граф активов, политики, телеметрию, размещение edge-узлов и интеграции автоматизации, его замена становится большей задачей, чем переключение каналов. Клиенту приходится экспортировать операционную модель или перестраивать её. Prosimo продавала снижение облачной фрагментации, но одновременно создавала потенциальную зависимость от контроллера.

Сегментация простиралась от сетевой достижимости до прикладных политик

Prosimo заявляла сегментацию от уровня L3 до L7. На сетевом уровне маршрутные домены и сегменты определяли, какие подсети и площадки могут взаимодействовать. На верхних уровнях правила уточнялись идентичностью приложения, контекстом пользователя и характеристиками транзакций.

Иерархическая модель сокращала разрыв между сетевыми зонами и прикладными политиками. Можно было заблокировать широкую достижимость между подсетями, разрешив лишь конкретные бизнес-сервисы. И наоборот, даже при достижимом сетевом маршруте запрос мог быть отклонён, если идентичность или контекст приложения не подходили.

Это не делало Prosimo полноценным next-generation firewall. В интеграции с Palo Alto Networks в 2024 году обязанности были разделены: Prosimo оркестрировала маршруты, сегментацию и вставку сервисов, а VM-Series выполняла глубокую инспекцию. Это различие важно, поскольку управление маршрутами через политики и применение безопасности дают сбои по-разному.

Сегмент эффективен, только если представлены все связанные маршруты. Неизвестные маршруты, облачные нативные исключения и неудачная вставка сервисов могут обходить задуманный контроль. Поэтому для гарантий нужно сравнивать декларированные политики, фактическое состояние провайдеров и наблюдаемый трафик, а не полагаться только на экран контроллера.

Вставка сервисов связывала управление маршрутами с экономикой файрволов

При проектировании облачной безопасности нужно решить, где выполнять инспекцию. Централизованный файрвол упрощает политики и сокращает число устройств, но может создавать крюки, концентрацию и проблемы масштабирования. Распределённые файрволы размещаются ближе к рабочим нагрузкам и снижают искажение маршрутов, но увеличивают объём развёртывания, лицензирования, обновлений и управления политиками.

В интеграции с VM-Series Prosimo поддерживала обе конфигурации. По политике выбранный трафик можно было направлять в центральную точку инспекции или в файрволы, распределённые по VPC приложений. Palo Alto Networks обеспечивала инспекцию, а контроллер обновлял окружающие маршруты.

Эта архитектура делала оркестрацию маршрутов коммерчески ценной для security-вендоров. Программный файрвол не защищает трафик, который до него не доходит. Обнаружение, размещение и обновление маршрутов снижают операционное трение между покупкой ёмкости безопасности и её включением в рабочие пути. Это правдоподобная стратегическая причина, по которой Palo Alto Networks поглотила технологии Prosimo.

Одновременно расширяется и зона влияния контроллера. Ошибочная политика может обойти инспекцию, создать петли, вызвать асимметричную маршрутизацию и остановить приложение. Сбой вставки сервиса — это одновременно сетевая авария и инцидент безопасности, поэтому нужны проверки работоспособности, поэтапные изменения, симуляции, аудит и откат.

Партнёрство 2024 года нельзя задним числом считать приобретением

12 июня 2024 года Prosimo и Palo Alto Networks объявили об интеграции VM-Series. В анонсе описывалось совместное техническое и коммерческое решение, но не упоминалось приобретение Prosimo компанией Palo Alto Networks. Считать этот анонс доказательством смены собственника — значит смешивать два разных события.

Тем не менее партнёрство стало мостом. Prosimo смогла показать, что её система маршрутов и политик упрощает развёртывание VM-Series в нескольких облаках. Palo Alto Networks смогла оценить технологию через реальную интеграцию до последующей передачи компании. Публичные материалы не описывают процесс приобретения, поэтому утверждать, что партнёрство было задумано как формальная предварительная стадия сделки, — лишь предположение.

К началу 2025 года данные о карьере основателя и сотрудников изменились. Страница компании позже стала помечена как приобретённая. Во второй половине 2025 года Bhau заявил, что технологии полностью интегрированы в продукты Palo Alto Networks. Вместе эти записи поддерживают вывод о приобретении, но юридические детали остаются невыясненными.

Эта последовательность важна и для редакционной точности, и для клиентов. В партнёрстве — два вендора, две линии поддержки и чёткие границы интеграции. При приобретении дорожная карта, данные, контракты и полномочия могут перейти к одной компании. Даже если технические пути изначально похожи, переход меняет не только бренд.

Nebula превращала топологический граф в диалоговый интерфейс

В феврале 2024 года Prosimo представила Nebula как часть AI Suite для мультиоблачного сетевого взаимодействия. Ассистент был спроектирован так, чтобы отвечать на естественно-языковые вопросы о состоянии, выраженном в графе и телеметрии платформы: пересекающиеся сети, затраты, здоровье маршрутов, нарушения политик безопасности и другое.

Ценным активом был не языковой интерфейс сам по себе, а структурированный кросс-облачный контекст под ним. Универсальная модель не может диагностировать невидимые приватные маршруты и сегменты. Nebula могла использовать уже собранные Prosimo реестры активов, топологию, политики и наблюдения. Предшествующие инвестиции в общий граф окупились в AIOps.

Диалоговый доступ открывает сложные данные большему числу операторов. Но если ответы опускают неохваченные активы, неверно понимают вопрос или преподносят рекомендацию как одобренное действие, возникает ложная уверенность. Для высокорисковых изменений по-прежнему требовались детерминированный контроль, границы прав и подтверждение человеком.

Prosimo заявляла о возможности сократить среднее время восстановления на 60–80% и снизить затраты на облачный сетевой стек более чем на 60%. Это корпоративные утверждения из анонсов продуктов. В доступных материалах нет независимой методологии или эталонных клиентских значений, доказывающих всеобщую применимость. Их можно цитировать как заявленные Prosimo выгоды, но нельзя рассматривать как измеренный рыночный факт.

AI-нагрузки были новым сценарием, а не доказательством нового рынка

Тот же анонс 2024 года позиционировал архитектуру Prosimo как полезную для AI-нагрузок. Распределённые AI-системы могут требовать приватного доступа к данным, соединений между облаком и дата-центром, комплаенс-контроля и маршрутизации, отражающей поведение приложений. Это согласуется с существующими активами, политиками и моделями маршрутов.

Смена названия не меняет андерлей. Prosimo по-прежнему зависела от облачных сетей, операторов связи и инфраструктуры клиентов. Она также не предоставляла GPU-вычисления или ПО для разработки моделей. Предполагаемая роль — слой соединений и безопасности вокруг распределённых данных и сервисов.

Позиционирование AI имело стратегическую логику: чем сильнее распределены данные и сервисы, тем ценнее кросс-облачная топология. В то же время это маркетинговая категория, введённая незадолго до прекращения независимого существования компании. В доступных материалах нет отдельной выручки от AI-продукта, именных production-внедрений или аудированных результатов рабочих нагрузок.

Устойчивый тезис в том, что мультиоблачная телеметрия может быть входом для машинно-поддерживаемых операций. Текущий продуктовый вопрос — сохранила ли Palo Alto Networks этот контекст и как предлагает соответствующие функции. Открытые данные по состоянию на срок исследования не дают полного ответа.

Коммерческая модель продавала ПО поверх инфраструктуры, которой Prosimo не владела

В период независимости Prosimo продавала подписки на ПО и услуги, а не работала как оператор связи. Клиенты разворачивали AXI Edge в своих средах и подключали облачные аккаунты к контрольному слою. Выручка, по-видимому, зависела от лицензий или подписок, поддержки, профессиональных услуг и канальной активности, но точные цены и контрактные показатели в открытых материалах не публиковались.

Эта модель позволяла масштабироваться без владения оптоволокном. Одна программная платформа могла координировать множество облачных регионов и клиентских сред. Но из одной лишь архитектуры нельзя вывести структуру валовой прибыли. Поддержка API вендоров, жизненный цикл edge-узлов, интеграции безопасности и сопровождение корпоративных внедрений стоят денег; облачные ресурсы, потребляемые edge, вероятно, оплачивал клиент, а не вендор.

Prosimo выходила на предприятия через облачные маркетплейсы, интеграционных партнёров, каналы продаж и именные клиентские примеры. Это разные виды свидетельств. Размещение в маркетплейсе показывает путь закупки и развёртывания. Техническая интеграция показывает, что две системы можно соединить на определённых условиях. Клиентский комментарий — пример внедрения. Ни одно из них по отдельности не доказывает число платящих клиентов или повторяющуюся выручку.

Широкий охват мог усложнять продажи. Даже если выгоду получали сетевые, security-, облачные и прикладные команды, владелец бюджета не всегда очевиден. Продукту нужен был покупатель, готовый финансировать общий контрольный слой, а не держать облако и команды раздельно.

Партнёры, клиенты и инвесторы занимали разные позиции

Amazon Web Services была одновременно оператором андерлея и интеграционным партнёром для выхода на рынок. Azure и Google Cloud — поддерживаемыми средами. Провайдеры идентичности поставляли контекст аутентификации, файрвол-вендоры — инспекцию. Операторы колокации и связи могли размещать и подключать edge-узлы, а канальные партнёры — проектировать и сопровождать внедрения.

В материалах AWS Cloud WAN Flexport фигурирует как именной клиентский пример. Это свидетельство интереса предприятия к архитектуре, но полный охват внедрения, сроки и коммерческая ценность из открытых материалов неясны. Не следует использовать этот пример как прокси для всей клиентской базы.

General Catalyst возглавила серию A и участвовала в управлении как инвестор. В материалах компании упоминаются инвесторы, связанные с WRVI или Celesta, а в более поздних сообщениях Prosimo — крупное участие, включая названия, связанные с BlackRock, однако точные инвестиционные инструменты исследование не установило. Эти записи указывают на влиятельную базу финансирования, но не являются полной капитальной таблицей.

Самым важным было отношение с Palo Alto Networks: от security-партнёра в 2024 году она к началу 2025 года стала приобретателем. Эта последовательность показывает, как зависимость от одного участника экосистемы превращается в контроль, когда тот покупает программный слой, управляющий путями к его собственным продуктам.

Привлечено не менее $55 млн, но экономика выхода неизвестна

Подтверждённое финансирование — серия A на 25 млн долларов в апреле 2021 года и серия B на 30 млн долларов в 2022 году. Итого не менее 55 млн долларов. В доступных материалах нет аудированной капитальной таблицы, оценки, списка долгов или последующих раундов.

Цена приобретения не раскрыта и независимо не подтверждена. Без цены нельзя ответственно классифицировать сделку как стратегическую премию, ограниченное технологическое приобретение, acqui-hire или продажу из-за трудностей. Продолжающаяся интеграция технологий в продукты свидетельствует о ценности, но не показывает доходность для инвесторов и основателей.

Не следует приписывать Prosimo выручку или рыночный масштаб Palo Alto Networks после приобретения. Когда стартап перестаёт наблюдаться отдельно, нет отдельных продаж, прибыли или клиентских сегментов для анализа. Крупный владелец может шире развернуть технологию, но делает её индивидуальную экономику менее прозрачной.

Отсутствие официального анонса о приобретении само по себе значимо. Клиенты, сотрудники и исследователи обычно получают из такого объявления сроки, поддержку и стратегические причины. В данном случае состояние приходится реконструировать по данным о карьере, пометке на странице компании и поздним заявлениям основателя. Этого достаточно, чтобы исправить представление «независимая компания», но недостаточно, чтобы восстановить детали сделки.

Конкурентами были специализированные платформы, облака и внутренняя инженерия

Prosimo конкурировала со специализированными мультиоблачными сетевыми платформами вроде Aviatrix и Alkira, с корпоративными сетевыми и SASE-вендорами, а также с нативными сервисами AWS, Azure и Google Cloud. Она также конкурировала с моделью самостоятельной разработки, когда предприятия напрямую используют инфраструктуру как код, транзитные сервисы облачных провайдеров, таблицы маршрутизации и файрволы. Каждый вариант решал свою часть одной проблемы.

Специализированный контроллер может дать единую модель топологии и политик для нескольких провайдеров. Облачно-нативное проектирование снижает зависимость от третьих сторон и тесно привязывается к одному провайдеру. Операторские сервисы могут поставлять физическую транспортировку. SASE- или security-платформы объединяют соединения и применение политик безопасности. Внутренняя инженерия сохраняет контроль ценой дополнительных людей и интеграционной работы.

Дифференциация Prosimo — в сочетании транзита приложений и сетей, распределённых edge-узлов, облачно-нативной оркестрации, топологии, телеметрии и вставки сервисов. Эта же широта затрудняла сравнение. Покупателю нужно было тестировать реально используемые облачные сервисы, маршруты, системы идентичности и конфигурации безопасности, а не сравнивать названия категорий.

Приобретение меняет рамку конкуренции. Prosimo больше не нужно побеждать как независимой компании, но её технология должна доказать ценность внутри Palo Alto Networks. Сравнивать следует, улучшает ли интегрированное обнаружение и оркестрация маршрутов развёртывание security-продуктов Palo Alto Networks и готовы ли клиенты принять эту зависимость от платформы.

Облачно-нативные сервисы были и фундаментом, и альтернативой

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN и сетевой стек Google Cloud давали предприятиям мощные нативные варианты. Prosimo зависела от них и одновременно конкурировала с возможностью прямого управления ими клиентом.

Эти отношения создавали подвижную границу. Когда облачные провайдеры добавляли глобальную маршрутизацию, сегментацию, доступ к приватным сервисам и централизованные политики, часть функций третьих сторон становилось проще воспроизвести нативно. В то же время с каждым новым нативным сервисом росло число объектов, которые кросс-облачный контроллер должен обнаруживать и координировать. Прогресс облаков сужал часть ценности Prosimo, но одновременно усиливал потребность в переводе между провайдерами.

Решающим фактором была не только технология, но и организация. Однооблачная компания с сильной внутренней инженерией скорее выберет нативные инструменты. Мультиоблачная компания с разобщёнными командами может оценить единую поверхность управления. Организации в регулируемых отраслях могут предпочесть сторонний слой доказательств, но опасаться привилегированных учётных данных и концентрации данных.

Ни одна архитектура полностью не устраняет зависимость от поставщика. Нативные инструменты усиливают зависимость от API и семантики одного облака. Кросс-облачный контроллер усиливает зависимость от графа, политик и edge-ПО. Полезный вопрос — видна ли эта зависимость, переносима ли она и соответствует ли операционной модели организации.

Сбои могли возникать в контроллере, edge, облачных API, идентичности и андерлее

Распределённая архитектура Prosimo снижала зависимость от единого хаба трафика, но создавала несколько взаимодействующих доменов отказа. Центральный сервис мог остановиться и сохранить устаревшие интенты. Edge мог выйти из строя или оказаться изолированным. Облачные API могли отклонять часть изменений. Провайдер идентичности мог отказать. Андерлей мог потерять ёмкость и пойти по непредусмотренным маршрутам. Встроенный файрвол мог исчерпать ресурсы.

Особенно сложны частичные сбои. Один провайдер может принять обновление маршрутов, другой — отклонить. Тогда целевое состояние контроллера и фактическое состояние облака расходятся. Трафик может пойти по асимметричным путям и обойти инспекцию. Надёжная система требует сверки, идемпотентных операций, поэтапных изменений, явных состояний ошибки и отката с учётом поведения каждого провайдера.

Открытые материалы описывают высокий уровень доступности и оптимизации, но не содержат независимых тестов с внесением сбоев, полных журналов инцидентов или универсальных результатов по уровню сервиса. Поэтому заявления об устойчивости следует связывать с задокументированной архитектурой или внедрениями с названными клиентами.

Приобретение вводит ещё один домен отказа — непрерывность продукта. Клиентам нужно знать, какая консоль, API, edge-образы, модель политик и организация поддержки заменяют прежнюю систему Prosimo. Даже если кодовая интеграция технически успешна, неясность коммерческих и операционных границ оставляет миграционный риск.

Облачные учётные данные делали контроллер частью критической плоскости управления

Обнаружение активов и оркестрация требовали доступа к облачным аккаунтам. Реестр активов только для чтения можно получить с ограниченными правами, но для изменения маршрутов, сегментов и вставки сервисов нужны расширенные права. Поэтому контроллер, даже не владея рабочими нагрузками, оказывался внутри привилегированной плоскости управления.

Компрометация учётных данных могла раскрыть топологию и позволить широкие изменения. Ошибка ПО или оператора могла распространить политики на несколько облаков. Чем полезнее платформа, тем выше риск: чем больше аккаунтов и сервисов под её управлением, тем шире потенциальная зона воздействия.

Предприятиям требовались роли с минимальными привилегиями, разделение учётных данных для обнаружения и изменений, многостороннее утверждение, полный аудит, ротация, экстренный отзыв прав и пути восстановления, не зависящие только от контроллера. В открытых материалах нет полной независимой оценки безопасности, поэтому это не гарантии продукта, а меры контроля, необходимые при внедрении.

Граф телеметрии столь же чувствителен. Он может раскрывать имена приложений, структуру сети, политики, связи пользователей, здоровье маршрутов и паттерны затрат. Контроль после приобретения должен прояснять, где хранятся эти данные, какие продукты Palo Alto Networks имеют к ним доступ и как переведены права прежних клиентов. Открытые данные по состоянию на срок исследования этих вопросов не закрывают.

Приобретение перенесло облачно-нейтральный слой внутрь security-платформы

Будучи независимой, Prosimo позиционировала себя как общий слой поверх облаков и сервисов безопасности. Когда владельцем стала Palo Alto Networks, стимулы изменились. Приобретённая технология может упрощать развёртывание продуктов Palo Alto Networks, таких как VM-Series. Интеграция может улучшиться, но возникают новые вопросы о поддержке сторонних сервисов инспекции.

Само по себе владение не доказывает утрату нейтральности. В открытых материалах нет текущего списка партнёров или архитектуры продукта. Но вопросы, которые стоит задавать клиенту, меняются. Нужно проверять, открыт ли контроллер маршрутов для нескольких security-вендоров, можно ли экспортировать политики и телеметрию и не отдаёт ли оптимизация приоритет продуктовой линейке владельца.

Заявления об интеграции подчёркивали инспекцию входящего, исходящего и east-west трафика. Исходя из этого акцента, топология и оркестрация Prosimo, по-видимому, стали частью системы развёртывания безопасности. Но это не доказывает, что прежние App Transit, пользовательский доступ, оптимизация затрат и все облачные сетевые рабочие процессы сохранились как отдельные функции.

Это повторяющийся сценарий в инфраструктурных отраслях. Стартап абстрагирует сложную задачу координации, а крупная платформенная компания покупает его, потому что абстракция увеличивает использование и контроль над её основными продуктами. Покупатель получает путь развёртывания. Клиент получает интеграцию, но может частично потерять независимость от поставщика.

Таблица соответствия текущим продуктам — главный пробел в информации

Открытые записи подтверждают приобретение и интеграцию, но не показывают полностью, как AXI, Network Transit, App Transit, AIR и Nebula соотносятся с текущими продуктами или SKU Palo Alto Networks. Не опубликованы даты прекращения поддержки прежних продуктов, процедуры миграции и таблица продолжения функций.

Из-за этого пробела невозможен обзор текущих продуктов. Прежние описания показывают, что Prosimo создала и почему это было важно. Но они не показывают, какие функции сейчас доступны, лицензируются и поддерживаются. Для актуальных рекомендаций по внедрению нужны текущие документы Palo Alto Networks, а не прежние анонсы Prosimo.

Отсутствие таблицы соответствия ограничивает и стратегический анализ. Полное поглощение топологического графа и оркестрационного слоя отличается от выборочного использования только для обнаружения активов и размещения файрволов. Первое создаёт широкий сервис мультиоблачного управления, второе в основном ускоряет развёртывание безопасности. Заявление сооснователя подтверждает продолжение технологии, но не проясняет эту архитектурную границу.

Будущие продуктовые документы, руководства по миграции и клиентские примеры снимут большую часть неопределённости. До этого точная формулировка такова: по словам сооснователя, технологии Prosimo интегрированы в продукты Palo Alto Networks, но объём и упаковка не подтверждены.

Кто контролирует мультиоблачную маршрутизацию

Ни один субъект не контролирует весь маршрут. Предприятие управляет владением аккаунтами, бизнес-интентами, дизайном приложений и выдаваемыми учётными данными. Кросс-облачный контроллер может обнаруживать топологию, преобразовывать политики, выбирать маршруты и изменять нативное состояние маршрутизации. Облачные провайдеры управляют API, транзитными сервисами, приватными эндпоинтами, магистралями и множеством доменов отказа. Операторы связи и колокации управляют остальными транспортными участками. Сервисы безопасности решают, пропускать ли проинспектированный трафик.

Prosimo целилась в наиболее стратегически полезную промежуточную позицию. Она не владела андерлеем, но стремилась владеть графом и преобразованием политик над ним. Тот, кто контролирует этот слой, решает, какие активы видны, как выражаются сегменты, где размещены edge-узлы, какие сервисы инспектируют трафик и какая телеметрия считается авторитетной. Даже если оптоволокно принадлежит кому-то другому, это фактическая власть над маршрутизацией.

После приобретения Palo Alto Networks владеет оставшимися технологиями Prosimo и решает, как их интегрировать, упаковывать и развивать. Облачные провайдеры сохраняют суверенитет в своих средах, а предприятия могут отозвать учётные данные и выбрать другую архитектуру. Но если топология, политики и операционные рабочие процессы зависят от контроллера, уход становится дорогим.

Поэтому ответ не абсолютный, а иерархический. Предприятие делегирует полномочия, контроллер координирует, андерлей облаков и операторов транспортирует, а security-платформа применяет политики. История Prosimo показывает, что владение координационным слоем может смениться, даже если владельцы облачных аккаунтов и физических маршрутов не меняются.

Основные источники

Почему Prosimo важна и после приобретения

Prosimo уловила реальное изменение отрасли. Единица сетевой эксплуатации смещается с устройств и префиксов к приложениям, идентичности, зависимостям сервисов и графам политик. Облачно-нативные API делают состояние сети программируемым, а распределённые программные edge-узлы — точку применения политик мобильной. Контроллер, охватывающий несколько облаков, может координировать операции, которые не завершаются в консоли одного облака.

Компания также показала цену такой координации. Общий слой требует привилегированных учётных данных, постоянного сопровождения API, точного обнаружения, семантического преобразования, телеметрии и операционной дисциплины. Он снижает разобщённость, но создаёт новую точку концентрации. Одна и та же система упрощает маршрутизацию и расширяет зону воздействия одной ошибочной команды.

Приобретение Palo Alto Networks сделало проблему контроля нагляднее. Сетевое взаимодействие и безопасность сходятся вокруг вставки сервисов, обнаружения рабочих нагрузок и политик. Security-вендор, знающий топологию и умеющий менять маршруты, не просто инспектирует предъявленный трафик, но участвует в решении, какой трафик и где достигнет инспекции.

Поэтому Prosimo не следует рассматривать ни как провал независимого бренда, ни как доказательство того, что одна платформа решила мультиоблачную проблему. Её долгосрочный вклад — определение кросс-облачного графа как основы. Открытым остаётся вопрос, сохранит ли этот граф, находящийся теперь внутри крупной security-компании, достаточно прозрачности, переносимости и управляемости, чтобы заслужить доверие клиентов.