Resumo

  • A Prosimo foi fundada em 2019 e levantou pelo menos US$ 55 milhões nas séries A de 2021 e B de 2022; receita auditada, avaliação e preço de aquisição não foram divulgados
  • A AXI combinava intenção, topologia e análise centralizadas com nós de borda distribuídos, que descobriam ativos de nuvem, conectavam aplicações e inseriam serviços de segurança sem possuir a infraestrutura física
  • A integração com o VM-Series anunciada em junho de 2024 antecedeu a incorporação da Prosimo à Palo Alto Networks por volta de fevereiro de 2025; a data exata, o preço e o mapa atual de produtos não foram divulgados
  • O controle permanece distribuído entre empresas, software de orquestração, provedores de nuvem e Palo Alto Networks; a portabilidade da topologia, das credenciais, das políticas e da autoridade sobre as rotas é o teste decisivo para os clientes

A marca desapareceu, mas o problema permaneceu

Em 2026, já não é correto descrever a Prosimo como uma fornecedora independente em atividade. Históricos profissionais públicos mostram seus fundadores e vários funcionários ingressando na Palo Alto Networks por volta de fevereiro de 2025. A página corporativa da Prosimo aparece marcada como empresa adquirida, e o ex-diretor de tecnologia Nehal Bhau escreveu posteriormente que a tecnologia havia sido integrada aos produtos da Palo Alto Networks. As evidências mostram uma mudança de controle e a continuidade do valor tecnológico, mas não esclarecem a data exata de assinatura ou fechamento, a forma jurídica ou o preço da transação.

Essa precisão deve aparecer no início porque altera o tempo verbal de todas as afirmações sobre os produtos. AXI, Network Transit, App Transit, Application-driven Intelligent Results e Nebula foram capacidades documentadas da Prosimo durante o período independente. Elas não devem ser apresentadas como produtos atuais vendidos separadamente até que a Palo Alto Networks publique um mapa atualizado de produtos e suporte. Uma arquitetura histórica pode sobreviver a uma aquisição como código incorporado, serviço compartilhado, módulo ou ativo interno de engenharia; essas formas não são equivalentes.

A marca desapareceu, mas o problema subjacente permaneceu. As empresas continuam distribuindo cargas de trabalho entre Amazon Web Services, Microsoft Azure, Google Cloud, data centers privados, instalações de colocation, plataformas de software como serviço e usuários remotos. Cada ambiente possui rotas, gateways, endpoints privados, controles de identidade, serviços de segurança, cotas e regras próprias de cobrança. Uma organização pode ser proprietária de todas as contas e, ainda assim, não dispor de uma visão única de como uma solicitação percorre esses ambientes.

A importância da Prosimo está em sua tentativa de reunir e controlar essa visão operacional.

Por isso, a aquisição é o eixo da narrativa, e não apenas um epílogo. A Prosimo construiu uma camada de controle multicloud capaz de descobrir ativos, interpretar o contexto das aplicações e conduzir o tráfego por serviços de segurança. A Palo Alto Networks apareceu primeiro como parceira técnica, cujos firewalls VM-Series podiam ser inseridos nesses caminhos. Depois, tornou-se proprietária da tecnologia. A fronteira entre a orquestração de rotas e a inspeção profunda passou, assim, para dentro de uma única plataforma de cibersegurança.

O roteamento multicloud é uma disputa pelo contexto

Uma tabela de rotas consegue informar se um prefixo é alcançável por determinado próximo salto. Sozinha, porém, não explica qual aplicação o usuário pretendia acessar, se o solicitante é confiável, se um serviço de inspeção deve ver o tráfego, se existe um endpoint privado, se um caminho em nuvem custa mais que outro ou se a transação está falhando depois que o pacote chega. As operações multicloud transformam essas perguntas em um problema compartilhado de controle.

A tese da Prosimo era que as decisões de roteamento deveriam considerar mais do que a alcançabilidade de Camada 3. Seu software tentou combinar inventário de nuvem, estado da rede, identidade da aplicação, identidade do usuário, risco, desempenho e telemetria de transações. Esse contexto mais amplo permitia expressar políticas como conectar uma aplicação específica, separar um segmento, escolher um ponto de entrada ou encaminhar tráfego selecionado por um firewall. O valor não vinha da invenção de uma nova rota de fibra, mas da decisão sobre como os caminhos e serviços existentes deveriam ser combinados.

Essa distinção explica o uso da expressão “application experience infrastructure”. O termo colocava a solicitação da aplicação acima do componente individual de rede. Uma VPC, VNet, sub-rede, hub de trânsito ou conexão privada passava a ser um elemento de um caminho ponta a ponta, e não o objeto final da gestão. A abordagem também levou o produto a vários mercados ao mesmo tempo: redes em nuvem, entrega de aplicações, acesso zero trust, verificação de rede, otimização de custos e inserção de serviços de segurança.

A amplitude criou oportunidade e ambiguidade. Um produto que alcança várias equipes pode resolver falhas de coordenação que nenhuma delas controla sozinha. Também pode ser difícil de avaliar, porque as áreas de rede, segurança, nuvem, aplicações e finanças usam definições diferentes de sucesso. A Prosimo precisava provar que um único modelo entre nuvens melhorava as operações sem se tornar outra camada privilegiada cujos erros afetassem todos os ambientes.

O que a Prosimo era — e o que permanece

A Prosimo era uma empresa privada de software de redes em nuvem, fundada em 2019 e sediada na região da Baía de São Francisco. Ramesh Prabagaran atuou como cofundador e diretor executivo, enquanto Nehal Bhau foi cofundador e diretor de tecnologia durante o período independente. Históricos públicos também identificam Linus Aranha e Pradeep Aragonda em funções de fundação ou liderança de engenharia, embora seus títulos exatos devam permanecer vinculados a biografias datadas.

Sua principal plataforma era a Application eXperience Infrastructure, abreviada como AXI. Ela utilizava uma camada central de software para intenção, topologia, análise e orquestração, combinada a AXI Edges distribuídos em regiões de nuvem, ambientes de colocation ou infraestrutura local adjacente. Mais tarde, a empresa organizou a oferta como Full-Stack Cloud Transit, com Network Transit e App Transit atendendo classes diferentes de conectividade. O AIR analisava telemetria e produzia insights operacionais; em 2024, o Nebula acrescentou uma interface conversacional.

A Prosimo não era uma operadora de nuvem. Não possuía um backbone mundial de fibra conectando todas as regiões. Os caminhos podiam atravessar backbones dos provedores, a internet pública, circuitos dedicados, links de colocation e redes empresariais. Tampouco era uma fornecedora de firewall no mesmo sentido da Palo Alto Networks. Na integração de 2024, seu papel era descobrir, segmentar e direcionar; o VM-Series fornecia a inspeção aprofundada de segurança.

Depois da aquisição, a descrição mais segura é “linhagem tecnológica”. A declaração posterior de integração destaca a descoberta de ativos multicloud e a implantação mais rápida de firewalls de software para inspeção de entrada, saída e tráfego leste-oeste. Isso comprova que componentes importantes da Prosimo sobreviveram. Não comprova que todo o catálogo histórico da AXI, o empacotamento comercial ou o modelo de suporte ao cliente continuaram sem alterações.

O problema que veio depois da SD-WAN

A equipe fundadora tinha experiência em redes de grande escala, entrega de aplicações e infraestrutura em nuvem. A Prosimo também surgiu do ecossistema mais amplo de fundadores e engenheiros ligado à Viptela, empresa que ajudou a estabelecer a rede de longa distância definida por software como categoria empresarial. O problema seguinte era diferente. A SD-WAN podia simplificar como filiais acessavam redes e aplicações, mas não criava um único modelo operacional dentro e entre várias nuvens públicas.

Uma aplicação multicloud pode depender de um endpoint web em um ambiente, de um banco de dados ou serviço gerenciado em outro, de um provedor de identidade fora dos dois, de conectividade privada com um data center e de inspeção de segurança em limites selecionados. Cada dependência pode aparecer como um componente nativo distinto. A equipe de rede pode enxergar prefixos e hubs de trânsito; a equipe de nuvem, contas e objetos de recurso; o responsável pela aplicação, domínios e transações; e a área de segurança, zonas e políticas de inspeção.

A Prosimo partia da solicitação, não da filial. A questão relevante era como um usuário ou uma carga de trabalho deveria alcançar uma aplicação com níveis aceitáveis de segurança, desempenho, disponibilidade e custo. Essa formulação mudou o objeto do roteamento: de apenas um prefixo de destino para uma transação com contexto de identidade e de aplicação. Também exigiu que a plataforma coletasse e mantivesse muito mais informações do que um roteador convencional.

O momento era favorável. AWS, Azure e Google Cloud ampliavam seus serviços nativos de trânsito e conectividade privada. As empresas podiam construir redes sofisticadas dentro de cada provedor, mas as APIs, os objetos e os modelos de política continuavam específicos de cada um. A oportunidade da Prosimo era coordenar esses serviços, em vez de obrigar todos os clientes a substituí-los por um backbone proprietário separado.

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

A Prosimo foi fundada em 2019, mas só anunciou seu lançamento público em 6 de abril de 2021. A General Catalyst liderou uma Série A de US$ 25 milhões na ocasião. O investidor descreveu a oportunidade como a entrega de experiência de aplicação entre nuvens, alinhando-se ao esforço dos fundadores de definir uma categoria além da conectividade convencional de filiais.

O lançamento colocou a empresa em um mercado cheio e ainda indefinido. Os provedores de nuvem facilitavam o consumo de seus próprios serviços de rede. Fornecedores de SD-WAN e SASE estendiam políticas aos ambientes em nuvem. Empresas de entrega de aplicações podiam otimizar solicitações, enquanto companhias de segurança de rede podiam inspecioná-las. A proposta da Prosimo dependia de reunir essas funções em uma arquitetura orientada à nuvem sem afirmar que substituiria todos os sistemas ao redor.

O financiamento deu espaço para criar integrações, edges de software, análise, uma organização comercial e relações com parceiros. Não comprovou adequação do produto ao mercado, escala de receita ou diferenciação duradoura. As evidências fornecidas não trazem receita auditada, receita recorrente anual, número de clientes nem valuation. O histórico de financiamento mostra o compromisso dos investidores com uma tese, e não um retrato completo do desempenho operacional.

Em 2022, a Prosimo concluiu uma Série B de US$ 30 milhões, descrita como uma rodada com demanda superior à oferta. A soma das duas rodadas claramente identificadas produz um total verificado de pelo menos US$ 55 milhões. Alguns bancos de dados podem exibir valor maior ao duplicar anúncios ou registros relacionados; esses totais não devem ser usados sem a reconciliação dos eventos subjacentes.

A AXI colocou a política acima das nuvens e a execução perto das cargas de trabalho

A arquitetura AXI dividia o trabalho entre uma camada central de controle e análise e edges distribuídos em software. A camada central mantinha a intenção de aplicações e redes, descobria ativos, montava a topologia, integrava identidade, analisava telemetria e orquestrava mudanças. Os AXI Edges eram implantados perto das cargas de trabalho ou dos usuários, para aplicar políticas sem obrigar todo caminho a passar por um hub físico distante.

A separação se assemelhava à de outros sistemas definidos por software, mas os objetos eram específicos da nuvem e incorporavam contexto de aplicação. O controlador precisava de acesso a contas e APIs de nuvem, enquanto o edge necessitava de conectividade com serviços nativos de trânsito, redes de cargas de trabalho, endpoints privados ou caminhos externos. A autoridade da plataforma vinha da combinação dessas duas visões: intenção global acima das nuvens e execução local próxima do tráfego relevante.

A arquitetura também criava uma fronteira prática de implantação. Cada edge consumia recursos de nuvem, exigia desenho de alta disponibilidade e precisava ser atualizado, monitorado e protegido. A camada de controle precisava de credenciais com privilégios suficientes para descobrir ativos e alterar o estado da rede. A empresa ganhava um fluxo de trabalho comum, mas acrescentava um novo sistema de gestão cuja disponibilidade e correção eram importantes para a conectividade de produção.

A Prosimo por vezes usava a linguagem de rede autônoma na nuvem. As evidências sustentam automação, recomendações e orquestração orientada por APIs. Não sustentam uma rede capaz de funcionar independentemente de políticas humanas, serviços dos provedores ou transporte subjacente. Os operadores continuavam definindo intenção, aprovando acesso, resolvendo exceções e respondendo pelo resultado.

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

Um AXI Edge podia ser implantado em uma VPC ou VNet de nuvem, em um ambiente de colocation ou em infraestrutura adjacente. O guia técnico da AWS mostrava uma VPC de edge conectada a VPCs de workloads por meio do Transit Gateway, com encadeamento opcional de firewall e acesso por usuários remotos ou sites locais. O desenho colocava o ponto de execução da Prosimo dentro da topologia da nuvem, e não em um perímetro corporativo distante.

O posicionamento afetava mais do que a latência. Determinava onde o tráfego entrava no domínio de política, qual backbone de nuvem ou caminho de internet utilizava, onde criptografia e inspeção aconteciam e qual telemetria a plataforma podia coletar. Um edge mal posicionado podia criar desvios e custos adicionais; um bem posicionado podia encurtar o caminho ou manter o tráfego perto da carga de trabalho.

A implantação distribuída aumentava o número de domínios de falha a administrar. Capacidade, versões de software, desenho de zonas de nuvem, convergência de rotas e permissões de acesso podiam variar por região. Alta disponibilidade exigia mais que executar duas instâncias: o controlador, as tabelas de rotas, os serviços de segurança e os caminhos de retorno também precisavam concordar sobre o estado de failover.

O edge, portanto, fazia parte de um sistema operacional mais amplo. Seu valor dependia de descoberta de ativos, topologia, política e análise permanecerem consistentes com o ambiente de nuvem ao redor. Tratá-lo como um appliance virtual autônomo perderia a arquitetura que a Prosimo tentava vender.

O underlay sempre pertencia a outra organização

A Prosimo coordenava o transporte, mas não possuía o caminho físico. Uma rota de aplicação podia utilizar o backbone da AWS ou de outro provedor, uma conexão de internet pública, Direct Connect ou ExpressRoute, serviço de colocation, circuito de operadora ou rede empresarial. A plataforma podia selecionar e orquestrar entre as opções disponíveis; não podia eliminar latência, perda de pacotes, domínios de falha ou regras de preço definidas por esses fornecedores.

Essa fronteira importa ao avaliar afirmações de desempenho. Um controlador pode escolher um caminho observado como melhor ou aproximar a entrada do usuário. Não pode garantir que uma operadora não falhará, que uma região de nuvem permanecerá disponível ou que uma dependência externa responderá rapidamente. A experiência da aplicação também inclui DNS, processamento no servidor, armazenamento, comportamento do navegador e serviços de terceiros fora da autoridade total do controlador de rede.

A ausência de um backbone proprietário não era apenas uma fraqueza. Ela permitia à Prosimo utilizar infraestrutura que as empresas já haviam contratado e se beneficiar dos investimentos dos provedores. A empresa podia alcançar regiões sem construir fibra e coordenar sistemas nativos como o AWS Cloud WAN. A contrapartida era a dependência da estabilidade das APIs, limites de serviço, condições comerciais e semântica específica dos provedores.

A reivindicação da plataforma, portanto, tratava de controle operacional, não de propriedade física. Ela tentava fazer underlays heterogêneos funcionarem como um sistema administrado, preservando suas vantagens nativas. Se essa abstração reduzia o lock-in ou apenas o deslocava dependia da portabilidade da política, da topologia e da implantação dos edges.

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

O Network Transit concentrava-se em VPCs, VNets, sub-redes, regiões, sites e segmentos. Coordenava trânsito nativo e componentes de roteamento das nuvens para permitir que as equipes criassem conectividade por um fluxo comum, em vez de configurar cada provedor separadamente. O produto atendia ao requisito convencional de rede: um prefixo ou segmento de origem deve alcançar um destino por um caminho permitido.

Isso não significava que as diferenças entre nuvens desapareciam. AWS, Azure e Google Cloud expõem objetos, limites e comportamentos de rota diferentes. Espaços de endereço sobrepostos, caminhos assimétricos, endpoints privados e limites de serviço específicos ainda exigiam engenharia. A Prosimo podia normalizar operações comuns e mostrar relações, mas os sistemas subjacentes mantinham suas restrições.

O Network Transit também carregava a segmentação. Domínios de rota e políticas podiam separar ambientes ou limitar a alcançabilidade. O controlador precisava entender onde um segmento existia entre nuvens e como os componentes nativos implementavam essa fronteira. Uma política expressa uma única vez ainda podia gerar várias mudanças específicas de provedor.

O benefício era uma superfície unificada de intenção. O risco estava na tradução. Se a política comum e a configuração da nuvem divergissem, a empresa poderia acreditar que um segmento estava protegido quando o estado do provedor dizia o contrário. Reconciliação, auditoria e relato explícito de falhas eram, por isso, tão importantes quanto o fluxo inicial de provisionamento.

O App Transit transformou a aplicação em objeto de roteamento

O App Transit ampliava o modelo além das sub-redes. Podia usar domínio da aplicação, identidade, tipo de solicitação, saúde da transação, risco e desempenho ao decidir como um usuário ou workload alcançaria um serviço. Essa foi a tentativa mais clara da Prosimo de distinguir sua plataforma de um roteador convencional de nuvem.

A visão da aplicação era útil porque serviços modernos nem sempre são representados de forma estável por endereços fixos. Plataformas gerenciadas, endpoints SaaS e componentes distribuídos podem mudar enquanto a identidade da aplicação continua significativa. Uma política que se refere ao serviço ou ao usuário pode ser mais durável que uma regra escrita apenas em torno de endereços e portas.

O modelo exigia descoberta precisa. O controlador precisava saber quais domínios e endpoints pertenciam a uma aplicação, quais dependências eram necessárias e quais afirmações do provedor de identidade eram confiáveis. Um mapeamento desatualizado podia enviar a solicitação pelo caminho errado ou aplicar a regra de segurança incorreta. A abstração da aplicação não eliminava a necessidade de entender o estado da rede; acrescentava outra camada semântica acima dele.

A combinação de Network Transit e App Transit reconhecia que as empresas contêm os dois mundos. Sistemas legados, sub-redes privadas e controles baseados em IP permanecem, enquanto aplicações mais novas dependem de domínios, identidade e serviços gerenciados. Full-Stack Cloud Transit era o nome do produto para operar esses modelos em conjunto, em vez de forçar um a substituir o outro.

A identidade ampliou a decisão de roteamento e a fronteira de confiança

O acesso consciente de aplicações exigia integração de identidade. A plataforma podia usar o contexto de um usuário ou workload para decidir se e como uma conexão seria estabelecida. Isso apoiava uma política no estilo zero trust, na qual localização, sozinha, não era prova suficiente de autorização.

A identidade aumentava a precisão, mas introduzia outra dependência. A política de rota ou aplicação passava a depender do provedor de identidade, de suas afirmações, do estado da sessão e dos dados de grupo. Um caminho de rede podia falhar porque a autenticação estava indisponível ou um atributo havia mudado, mesmo com roteadores e edges saudáveis. A investigação precisava atravessar a fronteira entre operações de rede e de identidade.

O controlador também se tornava um ponto de concentração de contexto sensível. Podia manter topologia, relações entre aplicações, atributos de usuários, sinais de risco e resultados de política. Esse conjunto de dados melhorava diagnóstico e otimização, mas ampliava as consequências de um acesso não autorizado. Privilégio mínimo, retenção, auditoria e separação de funções eram requisitos arquiteturais, não providências administrativas posteriores.

A abordagem da Prosimo ilustra uma mudança mais ampla na infraestrutura. Políticas de roteamento e acesso dependem cada vez mais de identidade e semântica de aplicações. Quanto mais contexto uma plataforma enxerga, mais úteis podem ser suas decisões — e mais cuidadosamente sua autoridade deve ser governada.

A descoberta de ativos criou o grafo do qual todas as decisões seguintes dependiam

Um controlador entre nuvens não pode governar aquilo que não enxerga. A Prosimo desenvolveu descoberta e mapas de ativos que representavam VPCs, VNets, sub-redes, aplicações, conectividade e relações de segurança. Essas visões apoiavam onboarding, projeto, investigação de falhas e política.

A descoberta era estrategicamente importante porque os ambientes de nuvem mudam fora dos fluxos centrais de rede. Equipes de aplicações podem criar contas, redes, endpoints e serviços gerenciados por sua própria automação. Um diagrama mantido manualmente fica desatualizado. Um inventário orientado por APIs pode fornecer um grafo mais atual, embora sua abrangência ainda dependa das contas cobertas, permissões, lógica de interpretação e APIs dos provedores.

O grafo não era apenas documentação. Era a estrutura de dados a partir da qual roteamento, segmentação, inserção de serviços e otimização podiam ser calculados. Se um ativo ou dependência estivesse ausente, todas as conclusões acima dele poderiam estar erradas. A topologia, portanto, precisava de proveniência: quando foi coletada, qual conta a forneceu, quais regiões estavam cobertas e se alguma solicitação falhou.

Esse grafo também ajuda a explicar a aquisição. A Palo Alto Networks pode criar valor de segurança quando sabe onde as cargas de trabalho e os caminhos de tráfego estão. Um sistema que descobre ativos de nuvem e altera rotas reduz a distância entre comprar um firewall de software e posicioná-lo corretamente. A declaração posterior de Bhau sobre a integração destacou especificamente a descoberta de ativos e a implantação acelerada de firewalls de software.

O AIR transformou telemetria de edge em recomendações operacionais

O Application-driven Intelligent Results, ou AIR, analisava a telemetria coletada pelos AXI Edges. O guia da AWS descrevia visibilidade sobre tempo de ida e volta, tempo de processamento, tempo de resposta da aplicação, tipo de transação, risco e resultados de políticas. A plataforma podia correlacionar observações do usuário, da rede e da aplicação, em vez de mostrar contadores isolados de dispositivos.

Essa correlação atacava um problema operacional conhecido. Uma transação lenta pode ser causada pelo caminho do usuário, pelo edge, pelo backbone da nuvem, por um serviço de segurança ou pela própria aplicação. Uma visão entre camadas pode reduzir o campo de investigação mais rapidamente do que consoles separados e também sustentar recomendações sobre caminho, posicionamento, risco ou custo.

A qualidade de uma recomendação dependia da cobertura da telemetria e do modelo usado para interpretá-la. Um edge só podia observar o tráfego que o atravessava. Dependências externas de aplicações e condições internas do provedor podiam permanecer invisíveis. Uma recomendação podia orientar a análise sem, por si só, comprovar a causa raiz.

A telemetria também tinha valor de governança. Observações históricas podiam ajudar a empresa a explicar por que uma rota ou política mudou. Também podiam expor uso sensível de aplicações e comportamento de usuários. O material público não fornece uma descrição completa de retenção ou governança de dados após a aquisição, por isso esses pontos continuam fazendo parte da diligência dos clientes.

A AWS forneceu a implementação pública mais bem documentada

O trabalho da Prosimo com a AWS produziu as evidências técnicas públicas mais fortes. A empresa integrou-se ao AWS Transit Gateway, Cloud WAN, PrivateLink e ao fluxo de implantação do Marketplace for Containers Anywhere. A AWS publicou um guia sobre posicionamento do AXI Edge, onboarding de aplicações, identidade, segurança e otimização.

O AWS Cloud WAN foi especialmente significativo. Fornecia um backbone e um serviço de segmentação nativos da nuvem que a Prosimo podia orquestrar, e não substituir. O arranjo mostrava o modelo cooperativo do produto: a AWS possuía a rede nativa e a infraestrutura global; a Prosimo fornecia intenção entre nuvens, contexto de aplicação, software de edge e análise.

O fluxo do Marketplace simplificava o primeiro passo da implantação ao empacotar o AXI Edge por um canal aprovado. Não eliminava o trabalho posterior de permissões de conta, desenho de rotas, alta disponibilidade, capacidade e operações. A automação do dia zero pode reduzir o atrito de instalação sem resolver o problema de controle de longo prazo.

Uma referência nominal à Flexport sustentava o caso de uso do AWS Cloud WAN nos materiais da empresa. Ela comprova que um cliente empresarial estava disposto a endossar a arquitetura, não uma auditoria independente de escala, economia ou disponibilidade. Depoimentos de clientes devem, portanto, ser usados como exemplos de adoção, não como evidência universal de desempenho.

Azure e Google Cloud completavam a afirmação multicloud

A Prosimo também oferecia suporte a ambientes Microsoft Azure e Google Cloud. Seus materiais descreviam orquestração em torno do Azure Virtual WAN e de componentes de rede e serviços privados do Google Cloud. O objetivo era apresentar um único modelo operacional, mantendo a rede nativa de cada provedor.

A existência de suporte não comprova recursos idênticos entre provedores. APIs de nuvem amadurecem em ritmos diferentes, e nomes de produtos comparáveis podem esconder semânticas distintas. Uma rota, um segmento, um endpoint privado ou a inserção de um serviço pode exigir tratamento específico. As evidências fornecidas não reconstroem uma matriz de equivalência recurso por recurso para cada região e versão.

A abstração multicloud é mais bem entendida, portanto, como um sistema de tradução. Ela pode padronizar intenção e fluxos de trabalho comuns, mas precisa preservar os detalhes que afetam segurança, custo e falhas. Uma plataforma se torna perigosa quando a interface parece uniforme, enquanto as diferenças de implementação ficam escondidas dos operadores.

O mesmo vale após a aquisição. A Palo Alto Networks pode usar o grafo comum para posicionar segurança entre nuvens, mas os provedores continuam controlando os objetos nativos que implementam o caminho. Possuir a camada de orquestração não significa possuir o underlay da nuvem.

O produto se ampliou da conexão para o ciclo de vida

Em 2023, a Prosimo descrevia fluxos para projetar, construir, investigar e administrar redes multicloud. O produto havia ido além do estabelecimento de um túnel ou gateway. A descoberta de ativos apoiava o projeto; a orquestração criava conectividade; mapas e telemetria ajudavam na investigação; política e estado histórico sustentavam a gestão contínua.

Esse enquadramento de ciclo de vida ampliava o grupo de compradores potenciais. Um engenheiro de rede podia usar topologia e análise de caminhos; uma equipe de plataforma em nuvem, integrar contas e serviços; uma equipe de segurança, revisar segmentação e inspeção; uma equipe de migração, planejar mudanças; e a área de FinOps, examinar implicações de rota e egress. O valor aumentava quando vários grupos usavam as mesmas evidências.

Evidência compartilhada também pode criar conflito de governança. Uma plataforma central pode revelar que a configuração nativa de uma equipe de nuvem diverge da política empresarial. A organização precisa decidir qual sistema tem autoridade e quem pode aprovar a correção. O software, por si só, não resolve essa questão institucional.

A narrativa de ciclo de vida também elevava o custo de troca. Quando um controlador guarda o grafo de ativos, políticas, telemetria, posicionamento dos edges e integrações de automação, substituí-lo exige mais do que mover um circuito. O cliente precisa exportar ou reconstruir o modelo operacional. A Prosimo vendia menor fragmentação de nuvem, ao mesmo tempo que criava a possibilidade de dependência do controlador.

A segmentação ia da alcançabilidade de rede à política de aplicação

A Prosimo apresentava segmentação das Camadas 3 a 7. Na camada de rede, domínios de rota e segmentos determinavam quais sub-redes ou sites podiam se comunicar. Nas camadas superiores, identidade da aplicação, contexto do usuário e propriedades da transação refinavam a regra.

O modelo em camadas podia reduzir a distância entre uma zona de rede e uma política de aplicação. Um serviço empresarial poderia ser permitido mesmo quando a alcançabilidade ampla entre sub-redes permanecesse bloqueada. Por outro lado, um caminho de rede alcançável ainda poderia ser negado porque a identidade ou o contexto da aplicação falhou.

Isso não transformava a Prosimo em um firewall de próxima geração completo. A integração de 2024 com a Palo Alto Networks separava responsabilidades: a Prosimo orquestrava rotas, segmentação e inserção de serviços; o VM-Series realizava a inspeção profunda. A distinção importa porque o encaminhamento baseado em políticas e a inspeção de segurança falham de formas diferentes.

Um segmento só é efetivo se todos os caminhos relevantes estiverem representados. Uma rota desconhecida, uma exceção nativa de nuvem ou uma inserção de serviço com falha pode contornar o controle pretendido. A validação exige comparar a política declarada com o estado do provedor e o tráfego observado, em vez de confiar apenas na tela de configuração do controlador.

A inserção de serviços ligou o controle de rotas à economia dos firewalls

O desenho de segurança em nuvem precisa decidir onde a inspeção ocorrerá. Firewalls centralizados podem simplificar a política e reduzir o número de appliances, mas podem criar backhaul, concentração e pressão de escala. Firewalls distribuídos ficam perto das cargas de trabalho e reduzem algumas distorções de caminho, mas multiplicam implantação, licenciamento, atualização e operação de políticas.

A Prosimo oferecia os dois padrões em sua integração com o VM-Series. A política podia encaminhar tráfego selecionado por um ponto central de inspeção ou por firewalls distribuídos nas VPCs das aplicações. O controlador atualizava as rotas ao redor, enquanto a Palo Alto Networks fornecia a função de inspeção.

A arquitetura tornou a orquestração de rotas comercialmente valiosa para um fornecedor de segurança. Um firewall de software não protege tráfego que nunca o alcança. Descoberta, posicionamento e atualização de rotas reduzem o atrito operacional entre comprar capacidade de segurança e inseri-la em um caminho ativo. Essa é uma razão estratégica plausível para a Palo Alto Networks absorver a tecnologia da Prosimo.

Ela também amplia o raio de impacto do controlador. Uma política incorreta pode contornar a inspeção, criar um loop, produzir roteamento assimétrico ou derrubar uma aplicação. Verificações de saúde, mudanças em etapas, simulação, auditoria e rollback são necessários porque uma falha na inserção de serviços é simultaneamente um evento de rede e de segurança.

A parceria de 2024 não deve ser reinterpretada como aquisição

A Prosimo e a 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. Não afirmava que a Palo Alto Networks havia adquirido a Prosimo. Tratar o anúncio como prova de propriedade faria dois eventos distintos parecerem um só.

Ainda assim, a parceria criou uma ponte. A Prosimo podia demonstrar como seu sistema de rotas e políticas facilitava a implantação do VM-Series entre nuvens. A Palo Alto Networks podia avaliar a tecnologia dentro de uma integração real antes da transição corporativa posterior. As evidências públicas não descrevem o processo de aquisição, portanto qualquer afirmação de que a parceria foi desenhada como etapa formal pré-aquisição seria especulativa.

No início de 2025, os históricos de fundadores e funcionários haviam mudado. A página da empresa passou depois a indicar aquisição. No fim de 2025, Bhau afirmou que a tecnologia estava totalmente integrada aos produtos da Palo Alto Networks. Em conjunto, esses registros sustentam a conclusão da aquisição, mantendo sem resposta sua mecânica jurídica.

Essa sequência é importante para a precisão editorial e para os clientes. Uma parceria significa dois fornecedores, duas estruturas de suporte e uma fronteira definida de integração. Uma aquisição pode transferir roadmaps, dados, contratos e autoridade para uma só empresa. A transição muda mais do que a marca, mesmo quando o caminho técnico inicialmente parece semelhante.

O Nebula transformou o grafo de topologia em uma interface conversacional

A Prosimo apresentou o Nebula em fevereiro de 2024 como parte de uma AI Suite para redes multicloud. O assistente foi criado para responder, em linguagem natural, a perguntas sobre redes sobrepostas, custos, saúde de rotas, violações de políticas de segurança e outras condições representadas no grafo e na telemetria da plataforma.

O ativo útil não era a interface de linguagem por si só, mas o contexto estruturado entre nuvens que existia abaixo dela. Um modelo geral não consegue diagnosticar uma rota privada ou um segmento que não enxerga. O Nebula podia recorrer ao inventário de ativos, à topologia, às políticas e às observações que a Prosimo já coletava. Isso tornou o investimento anterior em um grafo comum relevante para AIOps.

O acesso conversacional poderia tornar dados complexos disponíveis a mais operadores. Também poderia criar confiança indevida se a resposta omitisse um ativo não suportado, interpretasse mal a pergunta ou tratasse uma recomendação como ação aprovada. Mudanças de alto risco ainda exigiam controles determinísticos, limites de permissão e revisão humana.

A Prosimo relatou possíveis ganhos, como redução de 60% a 80% no tempo médio de resolução e diminuição superior a 60% nos custos de rede em nuvem. Esses números eram alegações da empresa em um anúncio de produto. Nenhuma metodologia independente ou linha de base de clientes nas evidências fornecidas comprova aplicação geral. Eles podem ser citados como benefício proposto pela Prosimo, não como fato de mercado medido.

As cargas de trabalho de IA eram um novo caso de uso, não a comprovação de um novo mercado

O mesmo anúncio de 2024 apresentava a arquitetura da Prosimo como útil para cargas de trabalho de IA. Sistemas distribuídos de IA podem precisar de acesso privado a dados, conexões entre nuvens e data centers, controles de conformidade e roteamento que reflita o comportamento da aplicação. Esses requisitos eram compatíveis com o modelo já existente de ativos, políticas e caminhos.

O rótulo não mudava o underlay. A Prosimo continuava dependente de redes em nuvem, operadoras e infraestrutura dos clientes. Tampouco fornecia computação de GPU ou software de desenvolvimento de modelos. Seu papel potencial era a camada de conectividade e segurança ao redor de dados e serviços distribuídos.

O posicionamento em IA era estrategicamente coerente, porque o valor da topologia entre nuvens cresce à medida que dados e serviços ficam mais distribuídos. Também era uma categoria de marketing introduzida pouco antes de a empresa deixar de operar de forma independente. As evidências não estabelecem receita separada de produtos de IA, implantações de produção identificadas ou resultados auditados de workloads.

O ponto duradouro é que a telemetria multicloud pode se tornar entrada para operações assistidas por máquinas. A questão atual de produto é se a Palo Alto Networks preservou esse contexto e como expõe a capacidade. As evidências públicas disponíveis no corte da pesquisa não fornecem uma resposta completa.

O modelo comercial dependia de infraestrutura de terceiros

O negócio independente da Prosimo seguia um modelo de software por assinatura e serviços, não um modelo de operadora. Os clientes implantavam AXI Edges em seus ambientes e conectavam contas de nuvem à camada de controle. A receita provavelmente vinha de licenças ou assinaturas, suporte, serviços profissionais e canais, embora preços exatos e métricas contratuais não apareçam nas evidências fornecidas.

O modelo podia crescer sem possuir fibra. Uma plataforma de software podia coordenar muitas regiões e ambientes de clientes. A economia bruta, porém, não pode ser inferida dessa arquitetura. O suporte de engenharia a APIs de fornecedores, o ciclo de vida dos edges, integrações de segurança e implantações empresariais pode ser caro, enquanto os recursos de nuvem consumidos pelos edges podem ser pagos pelo cliente, e não pelo fornecedor.

A Prosimo usava marketplaces de nuvem, parceiros de integração, organizações de canal e referências nominais de clientes para alcançar empresas. Essas relações não são equivalentes. Uma listagem em marketplace comprova um caminho de aquisição e implantação. Uma integração técnica demonstra que dois sistemas podem ser combinados em condições definidas. Um depoimento de cliente oferece uma referência. Nenhum desses elementos, isoladamente, estabelece o número de clientes pagantes ou a receita recorrente.

A amplitude da empresa pode ter aumentado a complexidade de vendas. Equipes de rede, segurança, nuvem e aplicações podiam se beneficiar, mas a responsabilidade orçamentária poderia ser incerta. O produto precisava de um comprador disposto a financiar uma camada comum de controle em vez de permitir que cada nuvem e cada equipe operasse separadamente.

Parceiros, clientes e investidores ocupavam posições diferentes

A Amazon Web Services era simultaneamente provedora de underlay e parceira de integração comercial. Azure e Google Cloud eram ambientes suportados. Provedores de identidade forneciam contexto de autenticação. Fornecedores de firewall entregavam inspeção. Serviços de colocation e operadoras podiam hospedar ou conectar edges. Parceiros de canal podiam projetar e operar implantações.

A Flexport apareceu como referência nominal de cliente no material do AWS Cloud WAN. A referência demonstra interesse empresarial na arquitetura, mas não revela o escopo completo, a duração ou o valor comercial da implantação. Ela não deve ser transformada em representante de toda a base de clientes.

A General Catalyst liderou a Série A e participou da governança por meio de seu envolvimento como investidora. Investidores ligados à WRVI ou à Celesta apareceram em materiais da empresa, e comunicações posteriores da Prosimo citaram outros participantes de destaque, inclusive um nome associado à BlackRock cujo veículo exato não foi esclarecido pela pesquisa. Esses registros sustentam uma base financeira bem conectada, não um quadro completo de capitalização.

A Palo Alto Networks ocupava a relação mais importante. Passou de parceira de segurança em 2024 a adquirente no início de 2025. A sequência mostra como uma dependência do ecossistema pode se tornar uma relação de controle quando um participante compra a camada de software que coordena o caminho até seu produto.

Pelo menos US$ 55 milhões foram captados; a economia da saída continua desconhecida

O histórico de financiamento verificado consiste em uma Série A de US$ 25 milhões em abril de 2021 e uma Série B de US$ 30 milhões em 2022. O total é de pelo menos US$ 55 milhões. As evidências fornecidas não incluem tabela auditada de capitalização, valuation, estrutura de dívida nem rodada posterior.

O valor pago na aquisição não foi divulgado nem verificado de forma independente. Sem preço, não é responsável classificar o resultado como prêmio estratégico, compra modesta de tecnologia, acqui-hire ou venda em dificuldade. A continuidade da integração comprova valor tecnológico; não revela o retorno obtido por investidores ou fundadores.

A receita e a escala de mercado da Palo Alto Networks não devem ser atribuídas à Prosimo depois da aquisição. Quando a startup deixou de ser observável separadamente, não havia receita, lucro ou segmento de clientes autônomo a analisar. Um proprietário maior pode tornar a tecnologia mais amplamente disponível e, ao mesmo tempo, deixar sua economia individual menos visível.

A ausência de um anúncio formal da aquisição é relevante por si só. Clientes, funcionários e pesquisadores normalmente usam esses comunicados para determinar cronologia, suporte e lógica estratégica. Neste caso, o status precisa ser reconstruído a partir de históricos profissionais, do rótulo na página da empresa e de uma declaração posterior do fundador. É suficiente para corrigir a condição da empresa, mas insuficiente para inventar detalhes da transação.

A concorrência vinha de plataformas, nuvens e engenharia interna

A Prosimo competia com plataformas especializadas de redes multicloud, como Aviatrix e Alkira, com fornecedores de redes empresariais e SASE e com serviços nativos de AWS, Azure e Google Cloud. Também competia com um modelo interno no qual a empresa usa infraestrutura como código, serviços de trânsito dos provedores, tabelas de rotas e firewalls diretamente. As alternativas resolviam partes diferentes do mesmo problema.

Um controlador especializado poderia oferecer uma topologia e um modelo de políticas entre provedores. Um desenho nativo de nuvem poderia reduzir a dependência de terceiros e se ajustar de perto a um provedor. Um serviço apoiado por operadora poderia fornecer transporte físico. Uma plataforma SASE ou de segurança poderia combinar conectividade e execução de políticas. A engenharia interna poderia preservar o controle ao custo de pessoal e integração.

A diferenciação da Prosimo era a combinação de trânsito de aplicações e redes, edges distribuídos, orquestração nativa de nuvem, topologia, telemetria e inserção de serviços. A mesma amplitude dificultava a comparação. Os compradores precisavam testar os serviços de nuvem, rotas, sistemas de identidade e padrões de segurança que realmente pretendiam usar, em vez de comparar rótulos de categoria.

A aquisição muda o quadro competitivo. A Prosimo não precisa mais vencer como empresa autônoma, mas sua tecnologia precisa justificar-se dentro da Palo Alto Networks. A comparação relevante passa a ser se descoberta e orquestração integradas melhoram a implantação dos produtos de segurança da Palo Alto e se os clientes aceitam a dependência resultante da plataforma.

Os serviços nativos de nuvem eram fundamento e substituto

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN e os serviços de rede do Google Cloud davam às empresas opções nativas poderosas. A Prosimo dependia desses serviços e concorria com a possibilidade de os clientes operá-los diretamente.

Essa relação criava uma fronteira móvel. À medida que um provedor adicionava roteamento global, segmentação, acesso privado a serviços ou política central, algumas funções de terceiros ficavam mais fáceis de reproduzir nativamente. Ao mesmo tempo, cada novo serviço nativo acrescentava outro objeto que um controlador multicloud podia descobrir e coordenar. O progresso da nuvem podia reduzir uma parte do valor da Prosimo e ampliar a necessidade de tradução entre provedores.

O fator decisivo era tanto organizacional quanto técnico. Uma empresa concentrada em uma única nuvem e com forte engenharia interna poderia preferir ferramentas nativas. Uma organização multicloud com equipes fragmentadas poderia valorizar um único plano de controle. Uma instituição regulada poderia preferir uma camada independente de evidência, mas se preocupar com credenciais privilegiadas e concentração de dados.

Nenhuma arquitetura eliminava o lock-in. Ferramentas nativas aumentavam a dependência das APIs e da semântica de um provedor. Um controlador entre nuvens aumentava a dependência de seu grafo, suas políticas e seu software de edge. A pergunta útil era se a dependência estava visível, era portátil e correspondia ao modelo operacional da organização.

A falha podia ocorrer no controlador, no edge, na API, na identidade ou no underlay

A arquitetura distribuída da Prosimo reduzia a dependência de um único hub de tráfego, mas criava vários domínios de falha interligados. O serviço central poderia ficar indisponível ou manter intenção desatualizada. Um edge poderia falhar ou ficar isolado. Uma API de nuvem poderia rejeitar parte de uma mudança. O provedor de identidade poderia parar. O underlay poderia perder capacidade ou seguir uma rota inesperada. Um firewall inserido poderia esgotar recursos.

A falha parcial é especialmente difícil. Um provedor pode aceitar uma atualização de rota enquanto outro a rejeita. O estado pretendido pelo controlador pode então divergir do estado real da nuvem. O tráfego pode seguir um caminho assimétrico ou contornar a inspeção. Um sistema confiável precisa de reconciliação, operações idempotentes, mudanças graduais, estado de erro explícito e rollback que considere o comportamento de cada provedor.

As evidências públicas descrevem disponibilidade e otimização em alto nível, mas não incluem um estudo independente de injeção de falhas, histórico completo de incidentes ou resultados universais de nível de serviço. Afirmações de resiliência devem permanecer associadas à arquitetura documentada ou a evidências de clientes identificados.

A aquisição introduz outro domínio de falha: continuidade do produto. Os clientes precisam saber qual console, API, imagem de edge, modelo de política e organização de suporte substitui o sistema histórico da Prosimo. Uma integração de código tecnicamente bem-sucedida ainda pode criar risco de migração quando as fronteiras comerciais e operacionais permanecem obscuras.

As credenciais de nuvem colocaram o controlador no plano crítico de gestão

Descoberta de ativos e orquestração exigiam acesso às contas de nuvem. O inventário somente leitura podia usar privilégios limitados, enquanto alterações de rotas, segmentos e inserções de serviço precisavam de autoridade maior. O controlador, portanto, ficava dentro do plano de gestão privilegiado, mesmo sem possuir as cargas de trabalho.

O comprometimento de credenciais poderia expor a topologia ou permitir mudanças amplas. Um defeito de software ou erro operacional poderia propagar políticas entre várias nuvens. O risco crescia com a utilidade da plataforma: quanto mais contas e serviços ela governasse, maior o raio de impacto potencial.

As empresas precisavam de funções de privilégio mínimo, credenciais separadas para descoberta e mudança, aprovação por várias partes, auditoria completa, rotação, revogação de emergência e uma rota de recuperação que não dependesse apenas do mesmo controlador. O material público fornecido não apresenta uma avaliação independente completa de segurança, por isso esses itens permanecem controles necessários de implantação, e não garantias verificadas do produto.

O grafo de telemetria era igualmente sensível. Podia revelar nomes de aplicações, estrutura de rede, políticas, relações de usuários, saúde de rotas e padrões de custo. A governança pós-aquisição deveria esclarecer onde esses dados são armazenados, quais produtos da Palo Alto Networks podem usá-los e como as permissões dos clientes antigos foram migradas. As evidências públicas no corte da pesquisa não respondem a essas perguntas.

A aquisição levou uma camada de controle antes neutra para uma plataforma de segurança

A posição independente permitia à Prosimo apresentar-se como camada comum entre nuvens e serviços de segurança. Quando a Palo Alto Networks se tornou proprietária, os incentivos mudaram. A tecnologia adquirida podia facilitar a implantação do VM-Series e de outros produtos da Palo Alto. Isso pode oferecer melhor integração, ao mesmo tempo que levanta dúvidas sobre o suporte a serviços de inspeção de terceiros.

A propriedade não comprova que a neutralidade desapareceu. As evidências não trazem uma matriz atual de parceiros ou a arquitetura contemporânea do produto. Entretanto, a pergunta do cliente muda. É necessário saber se o controlador de roteamento continua aberto a vários fornecedores de segurança, se políticas e telemetria podem ser exportadas e se a otimização favorece o portfólio do proprietário.

A declaração de integração enfatizou inspeção de entrada, saída e leste-oeste. Esse foco sugere que a topologia e a orquestração da Prosimo passaram a fazer parte de um sistema de implantação de segurança. Não prova que App Transit, acesso de usuários, otimização de custos ou todo fluxo histórico de redes em nuvem sobreviveram como capacidades separadas.

Esse é um padrão comum de infraestrutura. Uma startup abstrai um problema difícil de coordenação; uma empresa de plataforma maior compra a abstração porque ela aumenta o consumo e o controle de seu produto principal. O comprador ganha uma rota para a implantação. O cliente pode ganhar integração e perder alguma independência de fornecedor.

O mapa atual de produtos é a principal lacuna de informação

Os registros públicos confirmam a aquisição e a integração, mas não identifica um mapeamento completo de AXI, Network Transit, App Transit, AIR e Nebula para produtos ou SKUs atuais da Palo Alto Networks. Também não publica prazos de suporte legado, procedimentos de migração ou uma tabela de continuidade recurso por recurso.

Essa lacuna impede uma avaliação atual do produto. Descrições históricas explicam o que a Prosimo construiu e por que importava. Não informam quais capacidades estão disponíveis, licenciadas ou suportadas hoje. Recomendações contemporâneas de implantação precisam se basear na documentação atual da Palo Alto Networks, e não em comunicados arquivados da Prosimo.

O mapa ausente também limita a análise estratégica. A absorção completa do grafo e da camada de orquestração seria diferente do uso seletivo de descoberta de ativos e posicionamento de firewalls. Um resultado criaria um amplo serviço de controle multicloud; o outro utilizaria a Prosimo principalmente para acelerar a implantação de segurança. A declaração do cofundador sustenta a continuidade tecnológica, mas mantém sem resposta essa fronteira arquitetural.

Um documento futuro de produto, guia de migração ou estudo de caso de cliente poderia resolver boa parte da incerteza. Até lá, a formulação precisa é que, segundo um cofundador, a tecnologia da Prosimo foi integrada aos produtos da Palo Alto Networks, enquanto o escopo e o empacotamento não foram verificados.

Quem controla o roteamento multicloud?

Nenhuma parte controla o caminho inteiro. A empresa controla a propriedade das contas, a intenção de negócio, o desenho da aplicação e as credenciais que concede. Um controlador entre nuvens pode descobrir topologia, traduzir políticas, escolher caminhos e alterar o estado de rotas nativas. Os provedores controlam suas APIs, serviços de trânsito, endpoints privados, backbone e muitos domínios de falha. Operadoras e empresas de colocation controlam outras partes do transporte. Serviços de segurança controlam se o tráfego inspecionado será permitido.

A Prosimo buscava a posição intermediária mais útil estrategicamente. Não possuía o underlay, mas tentava possuir o grafo e a tradução de políticas acima dele. Quem controla essa camada pode decidir quais ativos são visíveis, como os segmentos são representados, onde os edges são colocados, qual serviço inspeciona o tráfego e qual telemetria será considerada autoritativa. Isso é poder prático sobre o roteamento, mesmo quando a fibra pertence a outra organização.

Depois da aquisição, a Palo Alto Networks é dona da tecnologia remanescente da Prosimo e determina como ela é integrada, empacotada e desenvolvida. Os provedores continuam soberanos dentro de seus ambientes, e a empresa pode revogar credenciais ou escolher outra arquitetura. A saída pode, contudo, ser cara se topologia, políticas e fluxos operacionais tiverem se tornado dependentes do controlador.

A resposta, portanto, é distribuída por camadas, e não absoluta: a empresa autoriza; o controlador coordena; os underlays de nuvem e operadora transportam; a plataforma de segurança aplica. A história da Prosimo importa porque mostra que a propriedade da camada de coordenação pode mudar sem que uma conta de nuvem ou rota física troque de mãos.

Registro principal de fontes

Por que a Prosimo ainda importa depois da aquisição

A Prosimo capturou uma mudança real de infraestrutura. A unidade de gestão de rede está migrando do dispositivo e do prefixo para a aplicação, a identidade, a dependência de serviços e o grafo de políticas. APIs nativas tornam o estado da rede programável, enquanto edges distribuídos tornam o ponto de aplicação móvel. Um controlador que enxerga várias nuvens pode coordenar ações que nenhum console individual consegue concluir sozinho.

A empresa também expôs o custo dessa coordenação. Uma camada comum precisa de credenciais privilegiadas, manutenção contínua de APIs, descoberta precisa, tradução semântica, telemetria e disciplina operacional. Pode reduzir trabalho fragmentado e criar um novo ponto de concentração. O mesmo sistema que simplifica o roteamento pode ampliar o raio de impacto de uma decisão ruim.

A aquisição pela Palo Alto Networks torna a questão de controle mais visível. Redes e segurança convergem em torno da inserção de serviços, descoberta de workloads e políticas. Uma fornecedora de segurança que conhece a topologia e altera rotas não se limita a inspecionar o tráfego que recebe; pode ajudar a determinar qual tráfego alcança a inspeção e onde isso acontece.

A Prosimo não deve ser lembrada nem como uma marca autônoma fracassada, nem como prova de que uma plataforma resolveu o multicloud. Sua contribuição duradoura foi definir o grafo entre nuvens como infraestrutura. A pergunta restante é se esse grafo, agora dentro de uma companhia maior de segurança, permanece transparente, portátil e governável o suficiente para merecer a confiança dos clientes.