Resumo

  • A Prosimo foi fundada em 2019 e captou ao menos US$ 55 milhões em rodadas Série A (2021) e Série B (2022). As receitas auditadas, a avaliação e o preço de aquisição não foram divulgados.
  • O AXI combinava uma camada centralizada de intenção, topologia e análise com pontos de borda distribuídos, permitindo descoberta de ativos em nuvem, conexão de aplicações, inserção de segurança e coleta de telemetria sem possuir uma infraestrutura física de backbone.
  • Após o anúncio da integração com o VM-Series em junho de 2024, a Prosimo passou para o controle do Palo Alto Networks por volta de fevereiro de 2025, mas a data exata da aquisição, o preço e a correlação com os produtos atuais não foram esclarecidos.
  • O controle está distribuído entre a empresa, o software de orquestração, os provedores de nuvem e o Palo Alto Networks. A possibilidade de migrar topologia, credenciais, políticas e permissões de alteração de rotas é um fator crítico para os clientes.

A perda da independência empresarial não eliminou os problemas

Já não é preciso descrever a Prosimo em 2026 como um fornecedor independente ativo. Os históricos profissionais públicos mostram que os fundadores e vários funcionários migraram para o Palo Alto Networks por volta de fevereiro de 2025. A página da empresa indica que foi adquirida, e o ex-CTO Nehal Bhau posteriormente afirmou que a tecnologia foi integrada aos produtos do Palo Alto Networks. Essas evidências comprovam a transferência de controle e o aproveitamento do valor técnico, mas não revelam a data exata do acordo, o fechamento da transação, a forma jurídica nem o preço.

É necessário colocar essa correção no início porque todos os tempos verbais das descrições de produto mudam. O AXI, o Network Transit, o App Transit, o Application-driven Intelligent Results e o Nebula estão documentados como funcionalidades da Prosimo em sua fase independente. A menos que o Palo Alto Networks publique uma tabela de equivalência com produtos e suporte atuais, não se deve escrever sobre eles como se fossem produtos vigentes disponíveis separadamente.

A arquitetura histórica pode persistir após a aquisição na forma de código incorporado, serviços compartilhados, módulos ou ativos de engenharia interna, mas já não se encontra no mesmo estado.

O desaparecimento da marca não significa que os problemas subjacentes tenham sumido. As empresas continuam distribuindo cargas de trabalho entre Amazon Web Services, Microsoft Azure, Google Cloud, data centers privados, pontos de colocation, SaaS e usuários remotos. Cada um possui rotas, gateways, pontos de extremidade privados, controles de identidade, serviços de segurança, limites e regras de cobrança próprios. Mesmo sendo donas das contas, as empresas às vezes não conseguem visualizar em uma única tela como uma requisição transita entre ambientes.

A relevância da Prosimo reside justamente na tentativa de reunir essa visão geral e controlá-la a partir de uma única camada operacional.

Portanto, a aquisição não é um epílogo, mas o eixo que percorre todo o artigo. A Prosimo construiu uma camada de controle multi-nuvem capaz de descobrir ativos, interpretar contexto de aplicações e direcionar tráfego para serviços de segurança. O Palo Alto Networks surgiu primeiro como parceiro tecnológico, inserindo firewalls VM-Series nesse caminho, e depois se tornou proprietário da tecnologia. A fronteira que separava a orquestração de rotas da inspeção profunda moveu‑se para dentro de uma única plataforma de cibersegurança.

O roteamento multi-nuvem é uma competição por contexto

Uma tabela de rotas pode informar se um prefixo é alcançável por meio de outro próximo salto. Mas, sozinha, não explica para qual aplicação o usuário tentava ir, se o requisitante é confiável, se o tráfego precisa passar por serviços de inspeção, se há um ponto de extremidade privado disponível, qual rota de nuvem é mais cara ou se a transação está falhando após a chegada do pacote. A operação multi-nuvem agrupa todas essas questões em um único problema de controle.

A proposta da Prosimo era que a autoridade de roteamento não deveria ser definida apenas pela alcançabilidade de Camada 3. Seu software procurava combinar inventário de ativos em nuvem, estado da rede, identidade da aplicação, identidade do usuário, risco, desempenho e telemetria transacional. Com isso, era possível expressar políticas como conexão de aplicações específicas, isolamento de segmentos, escolha de pontos de entrada e encaminhamento de tráfego selecionado para firewalls. O valor não estava em inventar novos caminhos de fibra óptica, mas em decidir como combinar os caminhos e serviços já existentes.

Essa diferença explica por que a empresa usava a expressão “infraestrutura de experiência de aplicação” (application experience infrastructure). O centro da gestão não eram os componentes de rede individuais, e sim a demanda da aplicação. VPCs, VNets, sub-redes, hubs de trânsito e Private Links deixam de ser a unidade final de gestão e passam a ser peças de um caminho de ponta a ponta. Com essa filosofia, o produto entrava simultaneamente em vários mercados: rede em nuvem, distribuição de aplicações, acesso zero trust, garantia de rede, otimização de custos e inserção de serviços de segurança.

O amplo escopo gerava tanto oportunidade quanto ambiguidade. Um produto que abrange múltiplas equipes pode resolver descoordenações que ninguém assume isoladamente. Por outro lado, a avaliação é difícil porque as equipes de rede, segurança, nuvem, aplicações e finanças definem sucesso de maneiras diferentes. A Prosimo precisava demonstrar que seu modelo multi-nuvem melhorava as operações sem se tornar uma nova camada privilegiada cujos erros se propagariam para todos os ambientes.

O que foi a Prosimo e o que restou dela

A Prosimo era uma empresa de capital fechado fundada em 2019 e sediada na região da Baía de São Francisco, especializada em software de rede em nuvem. Durante sua fase independente, foi liderada por Ramesh Prabagaran (cofundador e CEO) e Nehal Bhau (cofundador e CTO). Registros públicos de carreira também mencionam Linus Aranha e Pradeep Aragonda em funções de fundação ou engenharia sênior, mas os títulos exatos devem ser alinhados com fontes datadas.

A plataforma principal chamava-se Application eXperience Infrastructure (AXI). O AXI combinava uma camada central de software responsável por intenção, topologia, análise e orquestração com pontos de borda AXI distribuídos, instalados em regiões de nuvem, ambientes de colocation ou infraestrutura on-premises adjacente. Mais tarde, os produtos foram organizados sob o nome Full-Stack Cloud Transit, em que o Network Transit e o App Transit tratavam de diferentes tipos de conectividade. O AIR analisava a telemetria para fornecer recomendações operacionais, e em 2024 o Nebula acrescentou uma interface conversacional.

A Prosimo não era uma operadora de nuvem. Não possuía um backbone global de fibra óptica conectando todas as regiões. Os caminhos podiam passar pelos backbones dos provedores de nuvem, pela internet pública, por circuitos dedicados, conexões de colocation e redes corporativas. Tampouco era um fornecedor de firewall no mesmo sentido que o Palo Alto Networks. Na integração de 2024, o papel da Prosimo era descobrir, segmentar e direcionar, enquanto a inspeção profunda de segurança ficava a cargo do VM-Series.

Após a aquisição, a expressão mais segura é “linhagem técnica”. As declarações posteriores de integração enfatizam a descoberta de ativos multi-nuvem e a aceleração da implantação de firewalls de software para inspeção de ingresso, egresso e tráfego leste-oeste. Isso comprova que componentes importantes da Prosimo permaneceram, mas não prova que a linha de produtos AXI, os pacotes comerciais e o modelo de suporte ao cliente tenham continuado como antes.

O problema que surgiu depois do SD-WAN

A equipe fundadora trazia experiência em redes de grande escala, distribuição de aplicações e infraestrutura de nuvem. A Prosimo também nasceu dentro da ampla rede de fundadores e engenheiros ligados à Viptela, que teve papel relevante na consolidação do SD-WAN como segmento de mercado empresarial. No entanto, o problema seguinte era diferente. O SD-WAN podia simplificar a conexão de filiais à rede e às aplicações, mas não criava um modelo operacional único dentro e entre múltiplas nuvens públicas.

Uma aplicação multi-nuvem pode depender de um ponto de extremidade web em um ambiente, de um banco de dados ou serviço gerenciado em outro, de provedores de identidade externos a ambos, de conexões privadas para data centers e de inspeção de segurança em perímetros selecionados. Cada dependência é representada por componentes nativos diferentes. A equipe de rede enxerga prefixos e hubs de trânsito; a equipe de nuvem, contas e objetos de recurso; o dono da aplicação, domínios e transações; a equipe de segurança, zonas e políticas de inspeção.

A Prosimo partia da demanda, e não da filial. A pergunta era como um usuário ou carga de trabalho podia chegar à aplicação com segurança, desempenho, disponibilidade e custo adequados. Esse quadro ampliava o objeto do roteamento — de um simples prefixo de destino para uma transação com identidade e contexto de aplicação. Em compensação, exigia coletar e manter muito mais informações do que um roteador tradicional.

O ambiente de mercado também ajudava. AWS, Azure e Google Cloud expandiam seus serviços nativos de trânsito e conectividade privada. As empresas conseguiam construir redes sofisticadas dentro de cada nuvem, mas as APIs, os objetos e os modelos de política variavam de provedor para provedor. A oportunidade da Prosimo não estava em substituir esses serviços por um backbone próprio, mas em coordená-los entre si.

Da fundação em 2019 ao lançamento público em 2021

A Prosimo foi fundada em 2019, mas anunciou seu lançamento público apenas em 6 de abril de 2021. A rodada Série A de US$ 25 milhões foi liderada pela General Catalyst. O investidor destacou a oportunidade de proporcionar experiência de aplicação em múltiplas nuvens, um discurso alinhado com a visão dos fundadores de definir um campo que ia além da conectividade tradicional de filiais.

Na época do lançamento, o mercado já estava concorrido e com fronteiras pouco definidas. Os provedores de nuvem tornavam mais fácil usar seus próprios serviços de rede. Fornecedores de SD-WAN e SASE estendiam políticas para a nuvem, empresas de distribuição de aplicações otimizavam requisições, e companhias de segurança de rede podiam inspecioná-las. O poder de convencimento da Prosimo dependia de conseguir unir essas capacidades em uma arquitetura voltada para a nuvem, sem prometer substituir tudo o que existia ao redor.

Os recursos financeiros deram margem para construir integrações, bordas de software, análise, equipes de vendas e parcerias. Mas não provaram adequação do produto ao mercado, escala de receita ou diferenciação sustentável. As fontes não apresentam receitas auditadas, receita recorrente anual, número de clientes nem avaliação da empresa. Os registros de captação mostram que investidores alocaram capital numa hipótese, não um retrato completo do desempenho.

Em 2022, a Prosimo concluiu uma Série B descrita como “com excesso de demanda”, no valor de US$ 30 milhões. Somando as duas rodadas confirmadas, o total captado chega a pelo menos US$ 55 milhões. Algumas bases de dados podem exibir valores maiores por duplicarem anúncios ou registros vinculados; essas cifras não devem ser usadas sem conferir as transações originais.

O AXI colocava a política acima da nuvem e a execução perto da carga de trabalho

A arquitetura do AXI dividia as funções entre uma camada central de controle e análise e bordas de software distribuídas. A camada central mantinha a intenção de aplicação e rede, descobria ativos, montava a topologia, integrava identidades, analisava telemetria e orquestrava mudanças. Os pontos de borda AXI eram posicionados próximos às cargas de trabalho ou aos usuários, evitando que todo o tráfego precisasse passar por hubs físicos remotos para aplicar políticas.

Essa separação lembra outros sistemas definidos por software, mas era voltada especificamente para nuvem e sensível ao contexto da aplicação. O controlador precisava acessar contas e APIs de nuvem, enquanto as bordas precisavam conectar-se a serviços nativos de trânsito, redes de carga de trabalho, pontos de extremidade privados e rotas externas. A combinação de uma intenção global acima das nuvens com execução local próxima ao tráfego relevante criava autoridade como plataforma.

Ao mesmo tempo, impunha restrições de implementação. Cada borda consumia recursos de nuvem, exigia alta disponibilidade e demandava atualização, monitoramento e proteção. A camada de controle precisava de credenciais com privilégios suficientes para descobrir ativos e alterar o estado da rede. A empresa ganhava fluxos de trabalho comuns, mas adicionava um novo sistema de gestão cuja disponibilidade e correção afetavam o alcance da produção.

A Prosimo às vezes usava a expressão “rede autônoma em nuvem”. As evidências sustentam automação, recomendações e orquestração baseada em API, mas não uma rede que operasse de forma independente da política humana, dos serviços dos provedores de nuvem ou dos caminhos de transporte subjacentes. Os operadores continuavam definindo intenções, aprovando acessos, tratando exceções e se responsabilizando pelos resultados.

O AXI Edge não era um appliance genérico, mas uma decisão de posicionamento

O AXI Edge podia ser implantado em VPCs ou VNets de nuvem, em ambientes de colocation ou em infraestrutura adjacente. Guias técnicos da AWS mostravam configurações em que a VPC de borda se conectava às VPCs de carga de trabalho via Transit Gateway, encadeava firewalls quando necessário e permitia acesso de usuários remotos ou de locais on-premises. O ponto de execução da Prosimo era inserido dentro da topologia de nuvem, e não em uma borda corporativa distante.

A posição não afetava apenas a latência, mas definia onde o tráfego entrava no domínio da política, qual backbone de nuvem ou rota de internet era usado, onde a criptografia e a inspeção ocorriam e qual telemetria podia ser coletada. Um posicionamento inadequado gerava desvios e custos; um bom posicionamento encurtava caminhos e mantinha o tráfego próximo das cargas de trabalho.

A distribuição ampliava o número de domínios de falha a gerenciar. Capacidade, versão de software, desenho de zonas de nuvem, convergência de rotas e direitos de acesso podiam variar por região. A alta disponibilidade não se alcançava apenas mantendo duas instâncias ativas; o controlador, as tabelas de rotas da nuvem, os serviços de segurança e os caminhos de retorno também precisavam compartilhar o mesmo estado de failover.

A borda, portanto, fazia parte de um sistema operacional maior. Seu valor dependia de que a descoberta de ativos, a topologia, a política e a análise estivessem alinhadas com o ambiente de nuvem ao redor. Tratá-la como um appliance virtual isolado faria perder de vista a arquitetura que a Prosimo buscava vender.

O underlay sempre pertenceu a terceiros

A Prosimo orquestrava o transporte, mas não possuía os caminhos físicos. As rotas de aplicação podiam usar backbones de nuvem como os da AWS, internet pública, Direct Connect ou ExpressRoute, serviços de colocation, circuitos de operadoras e redes corporativas. Ela podia escolher e coordenar entre as opções disponíveis, mas não eliminava a latência, a perda de pacotes, os domínios de falha nem as regras de cobrança que cada provedor impunha.

Esse limite é relevante ao avaliar alegações de desempenho. O controlador podia escolher uma rota observavelmente melhor e aproximar o ponto de entrada do usuário, mas não podia garantir a prevenção contra falhas de operadoras, interrupções em regiões de nuvem ou atrasos em dependências externas. A experiência da aplicação também envolvia DNS, processamento do servidor, armazenamento, comportamento do navegador e serviços de terceiros, todos fora da autoridade plena do controlador de rede.

Não ter um backbone próprio não era apenas uma fraqueza. Permitia usar a infraestrutura que as empresas já haviam adquirido e se beneficiar dos investimentos dos provedores de nuvem. Dava para alcançar regiões sem instalar fibra óptica e coordenar sistemas nativos como o AWS Cloud WAN. Em troca, criava dependência da estabilidade das APIs, dos limites de serviço, das condições comerciais e da semântica específica de cada provedor.

Portanto, a promessa residia no controle operacional, não na propriedade física. A Prosimo tentava fazer com que vários underlays heterogêneos se comportassem como um único sistema de gestão, preservando suas vantagens nativas. Se essa abstração reduzia o lock-in ou apenas o transferia para outro lugar dependia da portabilidade da política, da topologia e do posicionamento das bordas.

O Network Transit tratava da alcançabilidade entre objetos de rede

O Network Transit lidava com VPCs, VNets, sub-redes, regiões, locais e segmentos. Orquestrava configurações nativas de trânsito e roteamento em cada provedor para que as conexões pudessem ser criadas por meio de um fluxo de trabalho comum, em vez de configurações isoladas. Ajudava na necessidade básica de redes tradicionais: fazer com que um prefixo de origem ou segmento alcançasse um destino por um caminho permitido.

Não se alegava que as diferenças entre nuvens desapareceriam. AWS, Azure e Google Cloud possuem objetos, limites e comportamentos de rota distintos. Espaços de endereçamento sobrepostos, rotas assimétricas, pontos de extremidade privados e restrições específicas de cada provedor ainda exigiam desenho. A Prosimo normalizava operações comuns e dava visibilidade sobre os relacionamentos, mas as limitações intrínsecas dos sistemas subjacentes permaneciam.

O Network Transit também cuidava da segmentação. Domínios de rota e políticas permitiam isolar ambientes e restringir a alcançabilidade. O controlador precisava entender onde os segmentos existiam em várias nuvens e como as configurações nativas implementavam esses limites. Uma política expressa uma vez podia ser traduzida em várias alterações, uma para cada provedor.

A vantagem era tratar a intenção em uma única superfície. O risco estava na tradução. Se a política comum e as configurações de nuvem divergissem, a empresa poderia acreditar que os segmentos estavam protegidos enquanto o estado real dos provedores era diferente. Por isso, reconciliação, auditoria e relatórios explícitos de falha eram tão importantes quanto o provisionamento inicial.

O App Transit transformava a aplicação no objeto do roteamento

O App Transit ampliava o modelo para além das sub-redes. Ao decidir como um usuário ou carga de trabalho alcançaria um serviço, podia considerar domínio da aplicação, identidade, tipo de requisição, sanidade transacional, risco e desempenho. Era o ponto em que a Prosimo procurava se diferenciar mais claramente dos roteadores de nuvem tradicionais.

O enfoque na aplicação fazia sentido porque os serviços modernos raramente se resumem a endereços fixos. Plataformas gerenciadas, pontos de extremidade SaaS e componentes distribuídos mudam, mas o identificador da aplicação pode manter o significado. Políticas que referenciam um serviço ou usuário tendem a durar mais do que regras baseadas apenas em endereço e porta.

Esse modelo exigia descoberta precisa. O controlador precisava saber quais domínios e pontos de extremidade pertenciam a uma aplicação, que dependências eram necessárias e em quais provedores de identidade confiar. Mapeamentos desatualizados poderiam enviar requisições para caminhos errados e aplicar regras de segurança incorretas. A abstração da aplicação não eliminava a necessidade de compreender o estado da rede; apenas adicionava uma camada semântica acima dela.

A combinação de Network Transit e App Transit reconhecia que as empresas convivem com dois mundos. Sistemas legados, sub-redes privadas e controles baseados em IP persistem, enquanto novas aplicações dependem de domínios, identidades e serviços gerenciados. O nome Full-Stack Cloud Transit representava a intenção de operar ambos juntos, em vez de substituir um pelo outro.

A identidade expandia as decisões de roteamento e os limites de confiança

O acesso sensível à aplicação exigia integração de identidade. A plataforma podia usar contexto de usuário ou carga de trabalho para decidir se a conexão era permitida e como estabelecê-la. Isso sustentava políticas de zero trust, em que a localização, sozinha, não bastava como prova de autorização.

A identidade aumentava a precisão, mas criava novas dependências. Políticas de rota ou de aplicação passavam a depender de provedores de identidade, de suas afirmações, do estado da sessão e de informações de grupo. Roteadores e bordas podiam funcionar perfeitamente, e ainda assim uma falha de autenticação ou uma mudança de atributo poderia derrubar os caminhos de rede. A resposta a incidentes precisava cruzar as fronteiras entre operação de rede e operação de identidade.

O controlador também se tornava um ponto de concentração de contexto sensível. Podia armazenar topologia, relações de aplicação, atributos de usuário, sinais de risco e resultados de políticas. Esses dados melhoravam diagnóstico e otimização, mas ampliavam o impacto de um acesso indevido. Privilégio mínimo, política de retenção, auditoria e segregação de funções eram requisitos arquitetônicos, não apenas complementos burocráticos.

A abordagem da Prosimo refletia uma mudança mais ampla na infraestrutura: políticas de roteamento e de acesso dependem cada vez mais de identidade e semântica de aplicação. Quanto mais contexto a plataforma enxerga, mais úteis podem ser suas decisões — e mais rigorosa precisa ser a governança sobre essa autoridade.

A descoberta de ativos criava o grafo que sustentava todas as decisões seguintes

Um controlador multi-nuvem não pode governar o que não vê. A Prosimo desenvolveu descoberta e mapeamento de ativos em nuvem, representando VPCs, VNets, sub-redes, aplicações, conexões e relações de segurança. Essas visões sustentavam o onboarding, o desenho, a resposta a incidentes e as políticas.

A descoberta tinha valor estratégico porque os ativos de nuvem mudam fora dos procedimentos centrais de rede. As equipes de aplicação podem criar contas, redes, pontos de extremidade e serviços gerenciados por meio de suas próprias automações. Diagramas manuais tornam-se obsoletos. Um inventário baseado em API pode gerar um grafo mais atualizado, mas sua completude depende do escopo das contas, das permissões, da lógica de análise e das APIs dos provedores.

O grafo não era mera documentação, e sim a estrutura de dados para calcular roteamento, segmentação, inserção de serviços e otimização. Faltando um ativo ou uma dependência, qualquer conclusão construída sobre ele poderia estar errada. Por isso, a topologia exigia procedência: quando foi coletada, qual conta a forneceu, quais regiões inclui e se as requisições foram bem-sucedidas.

Esse grafo também ajuda a explicar o motivo da aquisição. O Palo Alto Networks pode gerar valor de segurança quando sabe onde estão as cargas de trabalho e os caminhos de tráfego. Um sistema capaz de descobrir ativos em nuvem e alterar rotas reduz a distância entre comprar firewalls de software e posicioná-los corretamente. As declarações posteriores de Bhau também enfatizaram especificamente a descoberta de ativos e a aceleração da implantação de firewalls de software.

O AIR convertia a telemetria das bordas em recomendações operacionais

O Application-driven Intelligent Results (AIR) analisava a telemetria coletada pelo AXI Edge. Documentos da AWS descrevem visualizações de tempo de ida e volta (RTT), tempo de processamento, tempo de resposta da aplicação, tipo de transação, risco e resultado de políticas. A plataforma conseguia correlacionar observações de usuário, rede e aplicação, em vez de contadores isolados de equipamentos.

Essa correlação responde a problemas operacionais comuns. Uma transação lenta pode ser causada pelo caminho do usuário, pela borda, pelo backbone de nuvem, por um serviço de segurança ou pela própria aplicação. Uma visão entre camadas permite restringir a investigação mais rapidamente do que com consoles separados e pode gerar recomendações sobre rotas, posicionamento, risco e custo.

A qualidade das recomendações dependia da abrangência da telemetria e do modelo interpretativo. As bordas só observavam o tráfego que passava por elas; dependências externas ou estados internos dos provedores de nuvem podiam permanecer invisíveis. As recomendações eram úteis como direção, mas não necessariamente provavam a causa raiz.

A telemetria também trazia valor de governança. Observações antigas ajudavam a explicar por que rotas e políticas haviam sido alteradas. Ao mesmo tempo, podiam expor padrões sensíveis de uso de aplicações e comportamento de usuários. Como os materiais públicos não descrevem completamente a política de retenção nem a governança dos dados após a aquisição, esses permanecem itens de diligência para os clientes.

A AWS forneceu a evidência de implementação mais clara

Os trabalhos da Prosimo com a AWS deixaram a evidência técnica pública mais robusta. A empresa integrou-se ao AWS Transit Gateway, Cloud WAN, PrivateLink e aos fluxos de implantação do Marketplace for Containers Anywhere. A AWS publicou guias técnicos descrevendo o posicionamento do AXI Edge, onboarding de aplicações, identidade, segurança e otimização.

O AWS Cloud WAN foi particularmente importante. Ele oferecia um backbone nativo de nuvem e serviços de segmentação que a Prosimo podia orquestrar sem precisar substituí-los. Essa configuração ilustra um modelo de colaboração: a AWS detinha a rede nativa e a infraestrutura global, enquanto a Prosimo fornecia intenção multi-nuvem, contexto de aplicação, software de borda e análise.

Os fluxos do Marketplace empacotavam o AXI Edge por um canal aprovado, simplificando a implantação inicial. No entanto, restavam permissões de conta, desenho de rota, alta disponibilidade, capacidade e operação. A automação do “dia zero” reduzia o atrito de entrada, mas não eliminava os desafios de controle de longo prazo.

O caso da Flexport, mencionado em materiais da AWS Cloud WAN, apoiava esse caso de uso. Trata-se de evidência de que um cliente empresarial endossou a arquitetura, não de uma auditoria independente sobre escala de implantação, economia ou disponibilidade. Depoimentos de clientes devem ser tratados como exemplos de adoção, e não como prova universal de desempenho.

Azure e Google Cloud completavam a promessa multi-nuvem

A Prosimo também suportava ambientes Microsoft Azure e Google Cloud. Os materiais do produto descreviam a orquestração em torno do Azure Virtual WAN, da rede do Google Cloud e de configurações de serviços privados. O objetivo era preservar as redes nativas de cada provedor enquanto se oferecia um único modelo operacional.

A existência de suporte não garante funcionalidades idênticas entre provedores. As APIs de nuvem amadurecem em ritmos diferentes, e nomes de produto semelhantes podem ter semântica distinta. Rotas, segmentos, pontos de extremidade privados e inserção de serviços podem exigir tratamento específico por provedor. As fontes disponíveis não permitem reconstruir uma tabela de equivalência funcional que cubra todas as regiões e versões.

Assim, a abstração multi-nuvem é melhor compreendida como um sistema de tradução. Ela pode normalizar intenções e fluxos de trabalho comuns, mas precisa preservar os detalhes que afetam segurança, custo e falhas. Quando a tela se unifica mas as diferenças de implementação ficam ocultas do operador, a plataforma se torna perigosa.

O mesmo vale após a aquisição. O Palo Alto Networks talvez consiga usar um grafo comum para posicionar segurança em várias nuvens, mas os objetos nativos que implementam as rotas continuam sob controle dos provedores de nuvem. Ser dono da camada de orquestração não significa ser dono do underlay de nuvem.

O produto expandiu da conectividade para o ciclo de vida

Até 2023, a Prosimo já descrevia fluxos de trabalho para projetar, construir, solucionar problemas e gerenciar redes multi-nuvem. O produto ia além de estabelecer túneis e gateways. A descoberta de ativos alimentava o desenho; a orquestração criava as conexões; mapas e telemetria sustentavam a resposta a incidentes; políticas e estado histórico davam suporte à gestão contínua.

Essa visão de ciclo de vida ampliava o perfil dos compradores. Engenheiros de rede podiam usar topologia e análise de rota; equipes de infraestrutura de nuvem incorporavam contas e serviços; times de segurança verificavam segmentação e inspeção; times de migração planejavam mudanças; times de FinOps examinavam o impacto de rotas e egresso. Quanto mais organizações usavam as mesmas evidências, mais valiosa a plataforma se tornava.

Evidências compartilhadas também geram conflitos de governança. Uma plataforma central pode revelar que as configurações nativas das equipes de nuvem divergem das políticas corporativas. As organizações precisam decidir qual sistema é considerado autoritativo e quem autoriza correções. O software sozinho não resolve esse desafio institucional.

A narrativa do ciclo de vida também aumentava os custos de troca. Quando um controlador detém o grafo de ativos, as políticas, a telemetria, as implantações de borda e as integrações de automação, substituí-lo exige muito mais do que mover circuitos. O cliente precisaria exportar ou reconstruir seu modelo operacional. Ao vender a redução da fragmentação de nuvem, a Prosimo também criava a possibilidade de dependência do controlador.

A segmentação ia da alcançabilidade de rede até a política de aplicação

A Prosimo anunciava segmentação das Camadas 3 a 7. Na camada de rede, domínios de rota e segmentos definiam quais sub-redes e locais podiam se comunicar. Nas camadas superiores, a identidade da aplicação, o contexto do usuário e as características transacionais refinavam as regras.

O modelo em camadas podia reduzir a distância entre zonas de rede e políticas de aplicação. Enquanto se bloqueava a alcançabilidade ampla entre sub-redes, era possível permitir apenas serviços de negócio específicos. Ou, inversamente, um caminho de rede podia ser alcançável, mas negado por falta de identidade ou contexto de aplicação.

Isso não transformava a Prosimo num firewall de próxima geração completo. Na integração com o Palo Alto Networks em 2024, as responsabilidades foram divididas: a Prosimo orquestrava rotas, segmentação e inserção de serviços, enquanto o VM-Series realizava a inspeção profunda. A distinção é importante porque o controle de rota por política e a imposição de segurança falham de maneiras diferentes.

Um segmento só é efetivo quando todos os caminhos relevantes estão representados. Rotas desconhecidas, exceções nativas de nuvem ou falhas na inserção de serviços podem contornar os controles pretendidos. Por isso, a garantia exige comparar política declarada, estado do provedor e tráfego observado — não apenas confiar na tela do controlador.

A inserção de serviços conectava o controle de rota à economia de firewall

No desenho de segurança em nuvem, é preciso decidir onde inspecionar. Firewalls centralizados simplificam a política e reduzem o número de instâncias, mas podem gerar desvios, concentração e pressão de escala. Firewalls distribuídos ficam perto das cargas de trabalho e reduzem distorções de rota, mas aumentam implantação, licenciamento, atualização e operação de políticas.

A integração com o VM-Series permitia que a Prosimo suportasse ambas as configurações. Políticas podiam enviar tráfego selecionado para um ponto central de inspeção ou para firewalls distribuídos nas VPCs de aplicação. O Palo Alto Networks fornecia a capacidade de inspeção, enquanto o controlador atualizava as rotas ao redor.

Essa arquitetura tornou a orquestração de rota comercialmente valiosa para um fornecedor de segurança. Firewalls de software não podem proteger tráfego que não chega até eles. Descoberta, posicionamento e atualização de rota reduzem o atrito operacional entre comprar capacidade de segurança e inseri-la em caminhos de produção. Esse é um motivo estratégico plausível para o Palo Alto Networks ter incorporado a tecnologia da Prosimo.

Ao mesmo tempo, o raio de influência do controlador se expandia. Uma política errada poderia contornar a inspeção, criar loops, gerar roteamento assimétrico ou derrubar aplicações. Falhas na inserção de serviços são tanto incidentes de rede quanto de segurança, exigindo verificações de sanidade, mudanças graduais, simulação, auditoria e rollback.

Não se deve retroagir a parceria de 2024 à data da aquisição

A Prosimo e o Palo Alto Networks anunciaram a integração com o VM-Series em 12 de junho de 2024. O comunicado descrevia uma solução técnica e comercial conjunta, mas não mencionava a aquisição da Prosimo pelo Palo Alto Networks. Considerar esse anúncio como prova de propriedade seria confundir dois eventos distintos.

Ainda assim, a parceria serviu de ponte. A Prosimo pôde demonstrar que seu sistema de rota e política facilitaria a implantação do VM-Series em várias nuvens. O Palo Alto Networks pôde avaliar a tecnologia por meio de uma integração real antes da posterior migração empresarial. Como as fontes públicas não descrevem o processo de aquisição, afirmar que a parceria foi desenhada como etapa formal pré-aquisição seria especulação.

No início de 2025, os históricos profissionais dos fundadores e funcionários já haviam mudado. A página da empresa passou a exibir o status de adquirida. No final de 2025, Bhau declarou que a tecnologia estava totalmente integrada aos produtos do Palo Alto Networks. O conjunto desses registros sustenta a conclusão de que houve aquisição, mas os trâmites legais permanecem não revelados.

Essa sequência importa tanto para a precisão editorial quanto para os clientes. Em uma parceria, há dois fornecedores, dois regimes de suporte e fronteiras de integração claras. Em uma aquisição, o roadmap, os dados, os contratos e a autoridade podem migrar para uma única empresa. A trajetória técnica pode até ser parecida no início, mas a transição muda mais do que apenas a marca.

O Nebula transformava o grafo de topologia em uma interface conversacional

A Prosimo anunciou o Nebula em fevereiro de 2024 como parte do AI Suite para redes multi-nuvem. O assistente foi projetado para responder perguntas em linguagem natural sobre o estado representado no grafo e na telemetria da plataforma, como redes sobrepostas, custos, sanidade de rotas e violações de políticas de segurança.

O ativo valioso não era a interface de linguagem em si, mas o contexto multi-nuvem estruturado que a alimentava. Modelos genéricos não conseguem diagnosticar rotas privadas ou segmentos que não enxergam. O Nebula se beneficiava do inventário, da topologia, das políticas e das observações que a Prosimo já coletava. O investimento prévio em um grafo comum viabilizou o AIOps.

O acesso conversacional pode abrir dados complexos para mais operadores. Por outro lado, se o assistente omitir ativos não suportados, interpretar mal uma pergunta ou tratar recomendações como operações aprovadas, pode gerar falsa confiança. Mudanças de alto risco continuaram exigindo controle determinista, limites de autoridade e confirmação humana.

A Prosimo sugeriu que o tempo médio de recuperação poderia cair entre 60% e 80% e que os custos de rede em nuvem poderiam ser reduzidos em mais de 60%. Essas são alegações da empresa em anúncios de produto. As fontes disponíveis não trazem metodologia independente nem parâmetros de cliente que comprovem aplicabilidade geral. Podem ser citadas como benefícios projetados, mas não como fatos de mercado medidos.

Cargas de trabalho de IA eram um novo caso de uso, não prova de novo mercado

No mesmo anúncio de 2024, a arquitetura da Prosimo também foi posicionada como útil para cargas de trabalho de IA. Sistemas de IA distribuídos podem exigir acesso privado a dados, conectividade entre nuvens e data centers, controles de conformidade e roteamento que reflita o comportamento da aplicação — tudo alinhado com os modelos de ativo, política e rota já existentes.

Mudar o nome não altera o underlay. A Prosimo continuava dependente de redes de nuvem, operadoras de telecomunicações e infraestrutura do cliente. Tampouco oferecia computação em GPU ou software de desenvolvimento de modelos. O papel vislumbrado era uma camada de conectividade e segurança ao redor de dados e serviços distribuídos.

Havia uma lógica estratégica nesse posicionamento, já que quanto mais dados e serviços se distribuem, mais valiosa se torna uma topologia multi-nuvem. Ao mesmo tempo, tratava-se de uma categoria de marketing introduzida pouco antes do fim da operação independente da empresa. As fontes não mostram receita de produto de IA isolada, implantações nomeadas em produção nem resultados de carga de trabalho auditados.

O argumento duradouro é que a telemetria multi-nuvem pode alimentar operações assistidas por máquina. A questão atual de produto é se o Palo Alto Networks reteve esse contexto e como está oferecendo as funcionalidades. As evidências públicas disponíveis na data de corte da pesquisa não fornecem uma resposta completa.

O modelo comercial vendia software sobre infraestrutura que não lhe pertencia

Em sua fase independente, a Prosimo era um negócio de assinaturas de software e serviços, não uma operadora. Os clientes implantavam o AXI Edge em seus próprios ambientes e conectavam contas de nuvem à camada de controle. A receita provavelmente vinha de licenças ou assinaturas, suporte, serviços profissionais e atividades de canal, embora preços e indicadores contratuais exatos não estejam nas fontes.

Era um modelo que podia escalar sem possuir fibra óptica. Uma única plataforma de software podia coordenar muitas regiões de nuvem e ambientes de cliente. No entanto, não se pode inferir a estrutura de margem bruta somente a partir da arquitetura. Manter compatibilidade com APIs de fornecedores, gerir o ciclo de vida das bordas, integrar segurança e apoiar a adoção empresarial geravam custos, e os recursos de nuvem consumidos pelas bordas provavelmente eram pagos pelo cliente, não pelo fornecedor.

A Prosimo alcançava empresas por meio de marketplaces de nuvem, parceiros de integração, canais de venda e casos de cliente nomeados — que não são evidências equivalentes. Uma listagem em marketplace indica um caminho de compra e implantação; uma integração técnica mostra que dois sistemas podem ser combinados em condições definidas; um depoimento de cliente é um exemplo de adoção. Nenhum desses itens, isoladamente, comprova o número de clientes pagantes ou a receita recorrente.

A amplitude de escopo pode ter aumentado a complexidade de vendas. Embora equipes de rede, segurança, nuvem e aplicações pudessem se beneficiar, o dono do orçamento nem sempre era claro. O produto exigia um comprador disposto a financiar uma camada de controle comum, em vez de deixar cada equipe operar sua nuvem separadamente.

Parceiros, clientes e investidores ocupavam posições diferentes

A Amazon Web Services era ao mesmo tempo provedora de underlay e parceira de integração para go-to-mercados e setores. Azure e Google Cloud eram ambientes suportados. Provedores de identidade forneciam contexto de autenticação; fornecedores de firewall, inspeção. Operadoras de colocation e telecom prestavam locais para implantar e conectar bordas; parceiros de canal podiam projetar e operar as implantações.

Nos materiais do AWS Cloud WAN, a Flexport aparecia como caso de cliente nomeado. Trata-se de evidência de que uma empresa se interessou pela arquitetura, mas o escopo total da implantação, a duração e o valor comercial não estão nas fontes. Não se deve usá-la como indicador representativo de toda a base de clientes.

A General Catalyst liderou a Série A e participou da governança como investidora. As fontes mencionam investidores ligados a WRVI ou Celesta, e comunicações posteriores da Prosimo citam participação de nomes ligados ao BlackRock, mas o veículo de investimento exato não foi resolvido na pesquisa. Esses registros indicam uma base de capital influente, mas não uma tabela de capitalização completa.

A relação mais importante foi com o Palo Alto Networks. De parceiro de segurança em 2024, tornou-se adquirente até o início de 2025. Essa sequência ilustra como uma dependência de ecossistema pode se transformar em relação de controle quando o comprador adquire a camada de software que coordena os caminhos para seus produtos.

Captou ao menos US$ 55 milhões, mas a economia da saída permanece desconhecida

As captações confirmadas são: US$ 25 milhões na Série A em abril de 2021 e US$ 30 milhões na Série B em 2022, totalizando pelo menos US$ 55 milhões. As fontes não apresentam tabela de capitalização auditada, avaliação, relação de dívidas ou rodadas adicionais.

A contrapartida da aquisição não foi divulgada nem verificada de forma independente. Sem preço, não é possível classificar responsavelmente o resultado como prêmio estratégico, aquisição limitada de tecnologia, aquisição de talentos ou venda motivada por dificuldades financeiras. O fato de a tecnologia ter continuado integrada aos produtos indica valor, mas não revela retorno para investidores ou fundadores.

Receitas ou tamanho de mercado do Palo Alto Networks pós-aquisição não devem ser atribuídos à Prosimo. Quando a startup deixa de ser observável separadamente, não há receita, lucro ou segmentos de cliente independentes para analisar. Um grande proprietário pode implantar a tecnologia amplamente, mas também torna sua economia individual menos visível.

A própria ausência de um anúncio formal de aquisição carrega significado. Clientes, funcionários e pesquisadores normalmente extraem desses anúncios datas, suporte e motivações estratégicas. Aqui, o status precisou ser reconstruído a partir de históricos profissionais, do status da página da empresa e de declarações posteriores dos fundadores. É evidência suficiente para corrigir a descrição de empresa independente, mas insuficiente para fabricar detalhes da transação.

Os concorrentes eram plataformas especializadas, nuvem e engenharia interna

A Prosimo competia com plataformas especializadas de rede multi-nuvem como Aviatrix e Alkira, com fornecedores de SD-WAN e SASE, e com os serviços nativos da AWS, Azure e Google Cloud. Também disputava com modelos internos em que as empresas utilizavam diretamente IaC, serviços de trânsito dos provedores de nuvem, tabelas de rota e firewalls. Cada alternativa resolvia uma parte diferente do mesmo problema.

Controladores especializados podem oferecer um único modelo de topologia e política para vários provedores. O desenho nativo de nuvem reduz dependências de terceiros e pode ser ajustado de forma mais próxima a um único provedor. Serviços de operadoras trazem transporte físico; plataformas SASE ou de segurança integram conectividade e imposição de segurança. A engenharia interna mantém o controle, mas eleva o esforço de pessoal e integração.

A diferenciação da Prosimo estava na combinação de Network Transit e App Transit, borda distribuída, orquestração nativa de nuvem, topologia, telemetria e inserção de serviços. A mesma amplitude dificultava as comparações. Os compradores precisavam testar os serviços de nuvem, as rotas, os sistemas de identidade e as configurações de segurança que realmente usavam, em vez de comparar nomes de categorias.

A aquisição muda o quadro competitivo. A Prosimo não precisava mais vencer como empresa independente, mas sua tecnologia precisava gerar valor dentro do Palo Alto Networks. A comparação passa a ser se a descoberta e a orquestração de rotas integradas melhoram a implantação dos produtos de segurança do Palo Alto Networks, e se os clientes aceitam essa dependência de plataforma.

Os serviços nativos de nuvem eram tanto alicerce quanto alternativa

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN e a rede do Google Cloud ofereciam às empresas opções nativas poderosas. A Prosimo dependia deles ao mesmo tempo que competia com a possibilidade de os clientes os operarem diretamente.

Essa relação criava uma fronteira móvel. À medida que os provedores de nuvem adicionavam roteamento global, segmentação, acesso a serviços privados e políticas centrais, algumas funcionalidades de terceiros se tornavam mais fáceis de reproduzir nativamente. Ao mesmo tempo, cada novo serviço nativo aumentava o número de objetos que um controlador multi-nuvem precisava descobrir e coordenar. O avanço da nuvem podia reduzir parte do valor da Prosimo e, simultaneamente, ampliar a necessidade de tradução entre provedores.

O fator decisivo não era apenas técnico, mas organizacional. Empresas fortemente ancoradas em uma única nuvem e com engenharia interna robusta tendiam a preferir ferramentas nativas. Empresas multi-nuvem com equipes fragmentadas podiam valorizar uma superfície de controle unificada. Organizações em setores regulados podiam preferir uma camada de evidência de terceiros, embora se preocupassem com credenciais privilegiadas e concentração de dados.

Nenhuma arquitetura elimina completamente o lock-in. Ferramentas nativas aumentam a dependência das APIs e da semântica de uma única nuvem. Controladores multi-nuvem aumentam a dependência do grafo, das políticas e do software de borda. A pergunta útil não era se há dependência, mas se ela é visível, portável e compatível com o modelo operacional da organização.

Falhas podiam ocorrer no controlador, nas bordas, nas APIs de nuvem, na identidade e no underlay

A arquitetura distribuída da Prosimo reduzia a dependência de um único hub de tráfego, mas criava múltiplos domínios de falha que interagiam entre si. Os serviços centrais podiam parar ou reter intenções desatualizadas. As bordas podiam falhar ou ficar isoladas. As APIs de nuvem podiam recusar parte das mudanças. Provedores de identidade podiam ficar indisponíveis. O underlay podia perder capacidade ou tomar caminhos inesperados. Os firewalls inseridos podiam esgotar recursos.

Falhas parciais eram especialmente difíceis: um provedor podia aceitar uma atualização de rota enquanto outro a recusava, gerando divergência entre o estado intencional do controlador e o estado real da nuvem. O tráfego poderia passar por rotas assimétricas e contornar a inspeção. Um sistema confiável precisava de reconciliação, operações idempotentes, mudanças graduais, estados de erro explícitos e rollback que considerasse o comportamento de cada provedor.

As evidências públicas descrevem alta disponibilidade e otimização em alto nível, mas não incluem testes independentes de injeção de falhas, registros completos de incidentes ou resultados universais de nível de serviço. Por isso, alegações de resiliência devem ser vinculadas à arquitetura documentada ou a implantações com nomes de clientes.

A aquisição introduz outro domínio de falha: a continuidade do produto. Os clientes precisam saber quais consoles, APIs, imagens de borda, modelos de política e organizações de suporte substituirão os antigos sistemas da Prosimo. Mesmo que a integração de código seja tecnicamente bem-sucedida, o risco de migração permanece se as fronteiras comerciais e operacionais não estiverem claras.

Credenciais de nuvem tornavam o controlador parte de um plano de gestão crítico

A descoberta de ativos e a orquestração exigiam acesso a contas de nuvem. Um inventário somente leitura podia ser obtido com permissões limitadas, mas alterar rotas, segmentos e inserção de serviços exigia privilégios mais altos. O controlador, portanto, situava-se dentro de um plano de gestão privilegiado, mesmo sem ser dono das cargas de trabalho.

Credenciais comprometidas poderiam expor a topologia e permitir mudanças amplas. Um bug de software ou um erro do operador podia propagar políticas para várias nuvens. Quanto mais útil a plataforma, maior o risco: quanto mais contas e serviços ela puder gerenciar, maior o raio potencial de impacto.

As empresas precisavam de papéis com privilégio mínimo, separação de credenciais de descoberta e de mudança, aprovação por múltiplas pessoas, auditoria completa, rotação, revogação de emergência e caminhos de recuperação que não dependessem exclusivamente do mesmo controlador. Como as fontes públicas não incluem avaliações de segurança independentes completas, esses são controles de implantação necessários, e não garantias do produto.

O grafo de telemetria é igualmente sensível. Pode revelar nomes de aplicações, estrutura de rede, políticas, relações de usuários, sanidade de rotas e padrões de custo. A governança pós-aquisição deveria esclarecer onde esses dados são armazenados, a quais produtos do Palo Alto Networks têm acesso e como as antigas permissões dos clientes foram migradas. As evidências públicas disponíveis na data de corte não respondem a essas questões.

A aquisição moveu uma camada neutra de nuvem para dentro de uma plataforma de segurança

Como empresa independente, a Prosimo podia se posicionar como uma camada comum que atravessava serviços de nuvem e segurança. Com o Palo Alto Networks como proprietário, os incentivos mudam. A tecnologia adquirida pode facilitar a implantação de produtos como o VM-Series. A experiência integrada pode melhorar, mas surgem novas perguntas sobre o tratamento de serviços de inspeção de terceiros.

A propriedade, sozinha, não comprova perda de neutralidade, e as fontes não trazem a lista atual de parceiros nem a arquitetura de produto. No entanto, o que os clientes precisam perguntar muda: se o controlador de rota permanece aberto a múltiplos fornecedores de segurança; se políticas e telemetria podem ser exportadas; se a otimização privilegia o portfólio do proprietário.

As declarações de integração enfatizaram inspeção de ingresso, egresso e leste-oeste. Esse foco sugere que a topologia e a orquestração da Prosimo se tornaram parte de um sistema de implantação de segurança, mas não prova que o antigo App Transit, o acesso de usuários, a otimização de custos e todos os fluxos de rede em nuvem tenham permanecido como funcionalidades separadas.

Esse é um padrão recorrente em infraestrutura. Uma startup abstrai um problema difícil de coordenação; um grande fornecedor de plataforma a adquire porque essa abstração pode aumentar o uso e o controle de seus produtos principais. O comprador ganha um caminho de implantação; os clientes ganham integração, mas podem perder parte da independência de fornecedor.

A maior lacuna de informação é a tabela de equivalência de produtos atuais

Os registros públicos confirmam a aquisição e a integração, mas não mostram completamente como o AXI, o Network Transit, o App Transit, o AIR e o Nebula correspondem aos produtos ou SKUs atuais do Palo Alto Networks. Datas de fim de suporte, procedimentos de migração e tabelas de continuidade funcional também não foram publicadas.

Essa lacuna impede uma análise de produto atual. As descrições históricas mostram o que a Prosimo construiu e por que era relevante, mas não indicam quais funcionalidades estão disponíveis, licenciadas e suportadas hoje. Qualquer aconselhamento atual de adoção precisa se basear na documentação atual do Palo Alto Networks, não em anúncios antigos da Prosimo.

A falta de uma tabela de equivalência também limita a análise estratégica. A absorção total do grafo de topologia e da camada de orquestração é diferente do uso seletivo apenas para descoberta de ativos e posicionamento de firewall. O primeiro criaria um amplo serviço de controle multi-nuvem; o segundo, principalmente aceleraria a implantação de segurança. As declarações dos cofundadores apoiam a continuidade técnica, mas não resolvem essa fronteira arquitetônica.

Documentação futura de produto, guias de migração e casos de cliente poderão esclarecer grande parte da incerteza. Até lá, a formulação precisa é que, segundo os cofundadores, a tecnologia da Prosimo foi integrada aos produtos do Palo Alto Networks, mas o escopo e o empacotamento permanecem não verificados.

Quem controla o roteamento multi-nuvem

Nenhum ator isolado controla o caminho completo. A empresa detém a propriedade das contas, a intenção de negócio, o desenho da aplicação e as credenciais que concede. O controlador multi-nuvem pode descobrir topologia, traduzir políticas, escolher rotas e alterar o estado de roteamento nativo. Os provedores de nuvem controlam APIs, serviços de trânsito, pontos de extremidade privados, backbones e muitos domínios de falha. Operadoras de telecom e colocation gerenciam outros trechos de transporte. Os serviços de segurança decidem se o tráfego inspecionado é permitido.

A Prosimo mirou a posição intermediária mais estratégica: sem possuir o underlay, procurava possuir o grafo e a tradução de políticas acima dele. Quem controla essa camada decide quais ativos são visíveis, como os segmentos são expressos, onde as bordas são posicionadas, quais serviços inspecionam o tráfego e qual telemetria é considerada autoritativa. Embora a fibra óptica pertença a terceiros, isso equivale a autoridade prática de roteamento.

Após a aquisição, o Palo Alto Networks detém a tecnologia remanescente da Prosimo e decide sobre integração, empacotamento e desenvolvimento. Os provedores de nuvem mantêm soberania dentro de seus ambientes, e as empresas podem revogar credenciais e escolher outras arquiteturas. No entanto, se a topologia, as políticas e os fluxos de trabalho operacionais se tornarem dependentes do controlador, a saída se torna cara.

Portanto, a resposta não é absoluta, mas hierárquica. A empresa autoriza, o controlador coordena, os underlays de nuvem e operadoras transportam, e as plataformas de segurança impõem política. A história da Prosimo mostra que a propriedade da camada de coordenação pode mudar, mesmo quando a posse das contas de nuvem e dos caminhos físicos permanece inalterada.

Principais fontes

Por que a Prosimo continua relevante após a aquisição

A Prosimo capturou uma mudança real na infraestrutura. A unidade de operação de rede está se deslocando de equipamentos e prefixos para aplicações, identidades, dependências de serviços e grafos de políticas. APIs nativas de nuvem tornam o estado da rede programável; bordas de software distribuídas permitem reposicionar o ponto de imposição de política. Um controlador com visão de múltiplas nuvens pode coordenar operações que um único console de nuvem não consegue completar sozinho.

A empresa também revelou o custo dessa coordenação. Uma camada comum exige credenciais privilegiadas, manutenção contínua de APIs, descoberta precisa, tradução semântica, telemetria e disciplina operacional. Enquanto reduz trabalho fragmentado, também cria um novo ponto de concentração. O mesmo sistema que simplifica o roteamento pode ampliar o raio de impacto de uma única decisão errada.

A aquisição pelo Palo Alto Networks tornou o problema de controle mais visível. Rede e segurança estão convergindo em torno de inserção de serviços, descoberta de cargas de trabalho e política. Um fornecedor de segurança que conhece a topologia e pode alterar rotas deixa de apenas inspecionar o tráfego que lhe é apresentado; ele pode influenciar qual tráfego chega à inspeção e por onde.

Portanto, a Prosimo não deve ser vista como uma marca independente que fracassou, nem como prova de que uma única plataforma resolveu o multi-nuvem. Sua contribuição duradoura foi ter definido o grafo multi-nuvem como uma plataforma. A questão que permanece é se esse grafo, agora dentro de uma grande empresa de segurança, consegue manter transparência, portabilidade e governabilidade suficientes para merecer a confiança dos clientes.