Resumo

  • Fundada em 2019, a Prosimo levantou pelo menos 55 milhões de dólares em sua Série A de 2021 e Série B de 2022; receita auditada, valorização e preço de aquisição permanecem desconhecidos.
  • O AXI associava intenção, topologia e análise centrais a nós distribuídos que descobriam ativos de nuvem, conectavam aplicações e inseriam segurança sem possuir a rede física.
  • A integração com o VM-Series anunciada em junho de 2024 precedeu a migração da Prosimo para a Palo Alto Networks por volta de fevereiro de 2025; nenhuma fonte especifica a data, o preço ou o mapeamento atual dos produtos.
  • O controle permanece compartilhado entre empresas, software de orquestração, provedores de nuvem e a Palo Alto Networks; a portabilidade da topologia, das credenciais, das políticas e das rotas torna-se, portanto, o teste decisivo.

A empresa desapareceu antes do problema

Seria incorreto apresentar a Prosimo como um fornecedor independente ativo em 2026. Os percursos 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 da empresa Prosimo está marcada como adquirida, e o ex-diretor técnico Nehal Bhau escreveu posteriormente que sua tecnologia havia sido integrada aos produtos da Palo Alto Networks. Esses elementos estabelecem uma mudança de controle e a continuidade de seu valor técnico. Eles não permitem determinar a data exata de assinatura ou conclusão, a forma jurídica nem o preço da transação.

Essa correção deve abrir a narrativa, pois modifica o tempo gramatical de cada afirmação sobre os produtos. AXI, Network Transit, App Transit, Application-driven Intelligent Results e Nebula eram capacidades da Prosimo documentadas durante o período de independência. Elas não devem ser apresentadas como produtos atuais vendidos separadamente enquanto a Palo Alto Networks não publicar um mapeamento atual dos produtos e do suporte. Após uma aquisição, uma arquitetura histórica pode subsistir como código integrado, serviço compartilhado, módulo ou ativo de engenharia interno; essas situações não são equivalentes.

O desaparecimento da marca não torna o problema obsoleto. As empresas ainda distribuem suas cargas entre a Amazon Web Services, Microsoft Azure, Google Cloud, data centers privados, sites de colocation, plataformas SaaS e usuários remotos. Cada ambiente possui suas próprias rotas, gateways, endpoints privados, controles de identidade, serviços de segurança, cotas e regras de cobrança. Uma empresa pode ser proprietária de todas as suas contas sem dispor de uma visão única do caminho percorrido por uma requisição. A importância da Prosimo reside em sua tentativa de controlar essa visão global.

A aquisição constitui, portanto, o eixo narrativo, e não uma simples nota final. A Prosimo havia construído uma camada de controle transversal capaz de descobrir ativos, interpretar o contexto aplicacional e direcionar o tráfego para serviços de segurança. A Palo Alto Networks apareceu primeiro como parceira técnica cujos firewalls VM-Series podiam ser inseridos nesses caminhos, antes de se tornar proprietária da tecnologia. A fronteira que separava a orquestração do roteamento da inspeção profunda transferiu-se para dentro de uma mesma plataforma de cibersegurança.

O roteamento multicloud é uma batalha pelo contexto

Uma tabela de roteamento pode indicar se um prefixo é alcançável por meio de um próximo salto. Sozinha, ela não consegue explicar qual aplicação o usuário tentava acessar, se o solicitante é confiável, se um serviço de inspeção deve ver o tráfego, se um endpoint privado está disponível, se um caminho de nuvem custa mais que outro ou se a transação falha depois que o pacote chega. As operações multicloud transformam essas perguntas em um problema de controle compartilhado.

A tese da Prosimo era que a autoridade de roteamento deveria se basear em mais do que a alcançabilidade da camada 3. Seu software buscava combinar inventário de nuvem, estado da rede, identidade da aplicação, identidade do usuário, risco, desempenho e telemetria transacional. Esse contexto permitia expressar políticas como conectar uma aplicação definida, isolar um segmento, escolher um ponto de entrada ou direcionar um tráfego selecionado para um firewall. O valor não vinha da invenção de um novo caminho de fibra, mas da decisão sobre como montar caminhos e serviços existentes.

Essa distinção explica a expressão “infraestrutura de experiência de aplicação”. Ela colocava a requisição da aplicação acima de cada objeto de rede. Um VPC, um VNet, uma sub-rede, um hub de trânsito ou um link privado tornava-se um componente de um caminho ponta a ponta, em vez do objeto final de gerenciamento. A abordagem também situava o produto na interseção de vários mercados: rede de nuvem, entrega de aplicações, acesso zero trust, garantia de rede, otimização de custos e inserção de serviços de segurança.

Essa abrangência funcional criava uma oportunidade e uma ambiguidade. Um produto usado por várias equipes pode resolver falhas de coordenação das quais nenhuma equipe é responsável sozinha. Ele também pode ser difícil de avaliar, pois as equipes de rede, segurança, nuvem, aplicações e financeiras não usam os mesmos critérios de sucesso. A Prosimo precisava demonstrar que um modelo transversal melhorava as operações sem se tornar uma nova camada privilegiada cujos erros afetariam todos os ambientes.

O que a Prosimo era — e o que permanece

A Prosimo era uma empresa privada de software de rede em nuvem fundada em 2019 na região da Baía de São Francisco. Ramesh Prabagaran era cofundador e CEO, enquanto Nehal Bhau ocupava o cargo de cofundador e CTO durante o período de independência. Históricos públicos também identificam Linus Aranha e Pradeep Aragonda em funções de fundação ou liderança de engenharia, mas seus títulos precisos devem permanecer vinculados a biografias datadas.

Sua plataforma principal chamava-se Application eXperience Infrastructure, geralmente abreviada como AXI. O AXI combinava uma camada central de software para intenção, topologia, análise e orquestração com AXI Edges distribuídos em regiões de nuvem, ambientes de colocation ou infraestruturas locais adjacentes. A oferta foi posteriormente organizada sob os nomes Full-Stack Cloud Transit, Network Transit e App Transit, suportando diferentes classes de conectividade. O AIR analisava a telemetria e produzia recomendações operacionais; o Nebula adicionou uma interface conversacional em 2024.

A Prosimo não era uma operadora de nuvem. A empresa não possuía um backbone global de fibra conectando todas as regiões. Os caminhos podiam usar os backbones dos provedores de nuvem, a internet pública, circuitos diretos, links de colocation e as redes da empresa. Também não era um fornecedor de firewall no mesmo sentido que a Palo Alto Networks. Na integração de 2024, seu papel era descobrir, segmentar e direcionar; o VM-Series fornecia a inspeção profunda de segurança.

Após a aquisição, a descrição mais prudente é a de um “legado tecnológico”. A declaração posterior sobre a integração destaca a descoberta de ativos multicloud e a implantação mais rápida de firewalls de software para fluxos de entrada, saída e leste-oeste. Isso prova que componentes importantes da Prosimo sobreviveram. Não prova que todo o catálogo histórico do AXI, seu modo de comercialização ou seu modelo de suporte continuaram sem alterações.

O problema que surgiu após o SD-WAN

A equipe fundadora possuía experiência em redes de grande escala, entrega de aplicações e infraestrutura de nuvem. A Prosimo também veio do ecossistema mais amplo de fundadores e engenheiros associados à Viptela, empresa que ajudou a estabelecer o SD-WAN como categoria empresarial. O problema seguinte era diferente. O SD-WAN podia simplificar a relação entre filiais e redes ou aplicações, mas não criava um modelo operacional único 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 externo a ambos, de conectividade privada com um data center e de uma inspeção de segurança posicionada em determinadas fronteiras. Cada dependência pode ser representada por um objeto nativo diferente. A equipe de rede vê prefixos e hubs de trânsito; a equipe de nuvem vê contas e recursos; o proprietário da aplicação vê domínios e transações; a equipe de segurança vê zonas e políticas de inspeção.

A Prosimo partia da requisição, e não da filial. A pergunta útil era como um usuário ou uma carga de trabalho deveria alcançar uma aplicação com um nível aceitável de segurança, desempenho, disponibilidade e custo. Esse enquadramento transformava o objeto do roteamento: do mero prefixo de destino para uma transação portadora de identidade e contexto aplicacional. Também obrigava a plataforma a coletar e manter muito mais informações do que um roteador convencional.

O momento era favorável. AWS, Azure e Google Cloud estavam enriquecendo seus serviços nativos de trânsito e conectividade privada. As empresas podiam construir redes sofisticadas em cada provedor, mas as APIs, objetos e modelos de política permaneciam específicos. A oportunidade da Prosimo era coordenar esses serviços sem forçar cada cliente a substituí-los por um backbone proprietário distinto.

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

A Prosimo foi fundada em 2019, mas seu lançamento público só foi anunciado em 6 de abril de 2021. A General Catalyst liderou uma Série A de 25 milhões de dólares no momento do lançamento. O investidor apresentava a oportunidade como a oferta de uma experiência de aplicação em várias nuvens, alinhada com a intenção dos fundadores de definir uma categoria que fosse além da conectividade clássica de filiais.

O lançamento posicionava a empresa em um mercado denso e ainda mal definido. Os provedores de nuvem facilitavam o consumo de seus próprios serviços de rede. Os fornecedores de SD-WAN e SASE estendiam suas políticas para ambientes de nuvem. Os fornecedores de entrega de aplicações podiam otimizar as requisições, enquanto as empresas de cibersegurança podiam inspecioná-las. A proposta da Prosimo baseava-se na união dessas funções em uma arquitetura orientada à nuvem, sem pretender substituir todo o sistema circundante.

O financiamento permitiu desenvolver integrações, edges de software, análises, uma organização comercial e relacionamentos de parceria. Ele não comprovava a adequação ao mercado, a escala da receita ou uma diferenciação duradoura. Nenhum valor de receita auditada, receita recorrente anual, número de clientes ou valorização foi publicado nos elementos fornecidos. O financiamento mostra o compromisso de investidores com uma tese, não um relato completo do desempenho operacional.

Em 2022, a Prosimo realizou uma Série B de 30 milhões de dólares, descrita como superando as expectativas. A soma das duas rodadas claramente identificadas totaliza pelo menos 55 milhões de dólares. Algumas bases de dados podem mostrar valores maiores quando duplicam anúncios ou registros relacionados; esses totais não devem ser utilizados sem a resolução dos eventos subjacentes.

O AXI posicionava a política acima das nuvens e a execução próxima das cargas

A arquitetura do AXI distribuía o trabalho entre uma camada central de controle e análise e edges de software distribuídos. A camada central detinha a intenção aplicacional e de rede, descobria ativos, montava a topologia, integrava a identidade, analisava a telemetria e orquestrava as mudanças. Os AXI Edges eram implantados próximos às cargas ou aos usuários para aplicar as políticas sem obrigar cada caminho a passar por um hub físico distante.

Essa separação lembra outros sistemas definidos por software, mas os objetos eram específicos da nuvem e cientes das aplicações. O controlador precisava de acesso às contas de nuvem e suas APIs, enquanto o edge precisava se conectar aos serviços nativos de trânsito, às redes de cargas, aos endpoints privados ou aos caminhos externos. A autoridade da plataforma vinha da combinação dessas visões: intenção global acima das nuvens e execução local próxima ao tráfego relevante.

A arquitetura também criava uma fronteira de implantação concreta. Cada edge consumia recursos de nuvem, exigia um projeto de alta disponibilidade e precisava ser atualizado, monitorado e protegido. A camada de controle exigia credenciais com privilégios suficientes para descobrir ativos e modificar o estado da rede. A empresa ganhava um fluxo de trabalho comum, mas adicionava um sistema de gestão cuja disponibilidade e confiabilidade tornavam-se essenciais para a alcançabilidade da produção.

A Prosimo às vezes usava o vocabulário de “rede de nuvem autônoma”. As evidências sustentam a automação, as recomendações e a orquestração por API. Elas não descrevem uma rede independente das políticas humanas, dos serviços dos provedores de nuvem ou do transporte subjacente. Os operadores ainda definiam a intenção, aprovavam acessos, tratavam exceções e permaneciam responsáveis pelo resultado.

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

Um AXI Edge podia ser implantado em um VPC ou VNet de nuvem, um ambiente de colocation ou uma infraestrutura adjacente. O guia técnico da AWS mostrava um VPC de edge conectado aos VPCs de cargas por meio do Transit Gateway, com encadeamento opcional de um firewall e acesso a partir de usuários remotos ou sites locais. A execução da Prosimo situava-se, portanto, na topologia de nuvem, e não em um perímetro empresarial distante.

O posicionamento influenciava mais do que a latência. Determinava o ponto de entrada do tráfego no domínio da política, o backbone de nuvem ou o caminho de internet utilizado, o local da criptografia e da inspeção, bem como a telemetria acessível. Um edge mal posicionado podia criar um desvio ou custo extra; um posicionamento adequado podia encurtar o caminho ou manter o tráfego próximo à carga.

A distribuição multiplicava os domínios de falha. A capacidade, as versões de software, o desenho das zonas de nuvem, a convergência das rotas e as permissões podiam variar entre regiões. A alta disponibilidade não se resumia a duas instâncias: o controlador, as tabelas de roteamento de nuvem, os serviços de segurança e os caminhos de retorno também precisavam concordar sobre o estado de failover.

O edge era, portanto, parte de um sistema operacional mais amplo. Seu valor dependia da coerência entre a descoberta de ativos, a topologia, as políticas, a análise e o ambiente de nuvem. Tratá-lo como um appliance virtual autônomo faria perder de vista a arquitetura que a Prosimo buscava vender.

O transporte subjacente ainda pertencia a terceiros

A Prosimo orquestrava o transporte sem possuir o caminho físico. Uma conexão de aplicação podia usar o backbone da AWS ou de outra nuvem, a internet pública, Direct Connect ou ExpressRoute, um serviço de colocation, um circuito de operadora ou a rede da empresa. A plataforma podia selecionar e orquestrar as opções disponíveis; não podia eliminar a latência, a perda de pacotes, os domínios de falha ou as regras tarifárias criadas por esses provedores.

Essa fronteira é essencial para avaliar as promessas de desempenho. Um controlador pode escolher um caminho melhor observado ou aproximar o ponto de entrada do usuário. Ele não pode garantir que uma operadora não sofrerá uma pane, que uma região de nuvem permanecerá disponível ou que uma dependência externa responderá rapidamente. A experiência de aplicação também inclui DNS, processamento do servidor, armazenamento, comportamento do navegador e serviços de terceiros, fora da autoridade completa do controlador de rede.

A ausência de um backbone proprietário não era apenas uma fraqueza. Permitia que a Prosimo usasse uma infraestrutura já adquirida pelas empresas e se beneficiasse dos investimentos dos provedores de nuvem. A empresa podia alcançar novas regiões sem construir fibra e coordenar sistemas nativos como o AWS Cloud WAN. Em contrapartida, dependia da estabilidade das APIs, cotas, condições comerciais e semânticas específicas de cada provedor.

A proposta, portanto, dizia respeito ao controle operacional, e não à propriedade física. A Prosimo buscava fazer com que underlays heterogêneos funcionassem como um único sistema gerenciado, conservando suas vantagens nativas. A questão de saber se essa abstração reduzia a dependência de fornecedor ou a transferia de lugar dependia da portabilidade das políticas, da topologia e da implantação dos edges.

O Network Transit gerenciava a alcançabilidade dos objetos de rede

O Network Transit concentrava-se em VPCs, VNets, sub-redes, regiões, sites e segmentos. Ele coordenava os serviços nativos de trânsito e os objetos de roteamento para que as equipes pudessem construir a conectividade por meio de um fluxo de trabalho comum, em vez de configurar cada provedor separadamente. O produto atendia à necessidade clássica de rede: uma origem ou um segmento deve alcançar um destino por um caminho autorizado.

Ele não afirmava que as diferenças entre as nuvens haviam desaparecido. AWS, Azure e Google Cloud expõem objetos, cotas e comportamentos de roteamento diferentes. Espaços de endereços sobrepostos, caminhos assimétricos, endpoints privados e limites de serviços ainda exigiam engenharia. A Prosimo podia normalizar operações comuns e exibir as relações, mas os sistemas subjacentes mantinham suas restrições.

O Network Transit também incorporava a segmentação. Domínios de roteamento e políticas podiam separar ambientes ou limitar a alcançabilidade. O controlador precisava entender onde um segmento existia através das nuvens e como os objetos nativos materializavam essa fronteira. Uma política escrita uma única vez ainda podia gerar várias alterações específicas de cada provedor.

O benefício era uma superfície de intenção unificada. O risco residia 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 real dizia o contrário. A reconciliação, a auditoria e a sinalização explícita de falhas eram, portanto, tão importantes quanto o provisionamento inicial.

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

O App Transit estendia o modelo além das sub-redes. Ele podia considerar o domínio da aplicação, a identidade, o tipo de requisição, a saúde transacional, o risco e o desempenho para decidir como um usuário ou uma carga alcançava um serviço. Essa era a tentativa mais clara da Prosimo de se diferenciar de um roteador de nuvem convencional.

A visão aplicacional era útil porque os serviços modernos nem sempre são representados por endereços fixos. Plataformas gerenciadas, endpoints SaaS e componentes distribuídos podem mudar enquanto a identidade do serviço permanece estável. Uma política que faz referência à aplicação ou ao usuário pode durar mais do que uma regra construída apenas com endereços e portas.

O modelo exigia uma 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 direcionar a requisição pelo caminho errado ou aplicar uma regra de segurança incorreta. A abstração aplicacional não eliminava a necessidade de entender o estado da rede; ela acrescentava uma camada semântica acima.

A união do Network Transit e do App Transit reconhecia a coexistência dos dois mundos na empresa. Os sistemas legados, sub-redes privadas e controles de IP permanecem presentes, enquanto as aplicações recentes se baseiam em domínios, identidade e serviços gerenciados. Full-Stack Cloud Transit era o nome dado à operação conjunta desses modelos, sem obrigar um a substituir o outro.

A identidade ampliava a decisão de roteamento e o perímetro de confiança

O acesso ciente das aplicações exigia a integração da identidade. A plataforma podia usar o contexto de um usuário ou de uma carga para decidir se uma conexão deveria ser estabelecida e por qual caminho. Isso sustentava uma política do tipo zero trust na qual a localização não bastava para provar a autorização.

A identidade melhorava a precisão, mas adicionava uma dependência. A política de rota ou de 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 podia falhar porque a autenticação estava indisponível ou um atributo havia mudado, enquanto os roteadores e edges permaneciam saudáveis. O diagnóstico precisava atravessar a fronteira entre rede e gestão de identidades.

O controlador também se tornava um ponto de concentração de informações sensíveis. Ele podia conter topologia, relações aplicacionais, atributos de usuários, sinais de risco e resultados de políticas. Esse conjunto de dados melhorava o diagnóstico e a otimização, mas agravava as consequências de um acesso não autorizado. O menor privilégio, a retenção, a auditoria e a separação de funções eram, portanto, parte da arquitetura, não uma simples administração.

A abordagem da Prosimo ilustra uma evolução mais geral: o roteamento e o acesso dependem cada vez mais da identidade e da semântica aplicacional. Quanto mais contexto uma plataforma enxerga, mais úteis podem ser suas decisões — e mais sua autoridade precisa ser governada com cuidado.

A descoberta de ativos criava o grafo do qual as decisões dependiam

Um controlador transversal não pode governar o que não vê. A Prosimo desenvolvia uma descoberta de ativos de nuvem e mapas representando VPCs, VNets, sub-redes, aplicações, conectividade e relações de segurança. Essas visões serviam para a integração, o projeto, o diagnóstico e a política.

A descoberta era estratégica, pois os ambientes de nuvem evoluem fora dos processos centrais da rede. As equipes de aplicações podem criar contas, redes, endpoints e serviços gerenciados por sua própria automação. Um diagrama feito à mão torna-se obsoleto. Um inventário baseado em APIs pode fornecer um grafo mais atual, mas sua completude ainda depende das contas cobertas, das permissões, dos parsers e das APIs dos provedores.

O grafo não era apenas documental. Ele constituía a estrutura a partir da qual o roteamento, a segmentação, a inserção de serviços e a otimização podiam ser calculados. Se um ativo ou uma dependência faltasse, todas as conclusões construídas sobre ele poderiam ser falsas. A topologia precisava, portanto, de proveniência: data da coleta, conta de origem, regiões cobertas e eventuais falhas de requisição.

Esse grafo também ajuda a explicar a aquisição. A Palo Alto Networks cria valor de segurança quando sabe onde estão as cargas e os caminhos de tráfego. Um sistema capaz de descobrir ativos e modificar rotas reduz a distância entre a compra de um firewall de software e sua correta inserção. A declaração posterior de Nehal Bhau sobre a integração enfatizava justamente a descoberta de ativos e a aceleração da implantação de firewalls de software.

O AIR transformava a telemetria dos edges em recomendações

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

Essa correlação respondia a um problema operacional comum. Uma transação lenta pode ser causada pelo caminho do usuário, pelo edge, pelo backbone de nuvem, por um serviço de segurança ou pela aplicação. Uma visão transversal pode reduzir o tempo de investigação em comparação com consoles separados. Ela também pode apoiar recomendações sobre caminho, posicionamento, risco ou custo.

A qualidade de uma recomendação dependia da cobertura da telemetria e do modelo de interpretação. Um edge só enxergava o tráfego que passava por ele. As dependências externas da aplicação e certas condições internas do provedor podiam permanecer invisíveis. Uma recomendação podia ser útil sem demonstrar a causa raiz.

A telemetria também tinha valor de governança. As observações históricas podiam explicar por que uma rota ou política havia mudado. Elas também podiam expor usos aplicacionais e comportamentos de usuários sensíveis. As informações públicas não fornecem uma descrição completa da retenção ou governança dos dados após a aquisição; essas questões permanecem, portanto, no âmbito da diligência do cliente.

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

Os trabalhos da Prosimo com a AWS constituem as evidências técnicas públicas mais robustas. A empresa se integrou ao AWS Transit Gateway, Cloud WAN, PrivateLink e ao fluxo de trabalho do Marketplace for Containers Anywhere. A AWS publicou um guia sobre o posicionamento dos AXI Edges, integração de aplicações, identidade, segurança e otimização.

O AWS Cloud WAN era particularmente importante. Ele fornecia um backbone nativo e um serviço de segmentação que a Prosimo podia orquestrar em vez de substituir. A arquitetura mostrava o modelo cooperativo: a AWS detinha a rede nativa e a infraestrutura global; a Prosimo trazia a intenção multicloud, o contexto aplicacional, o software de edge e as análises.

O fluxo de trabalho do Marketplace simplificava o primeiro passo, fornecendo o AXI Edge por um canal aprovado. Ele não eliminava o trabalho posterior sobre permissões de contas, desenho de rotas, alta disponibilidade, capacidade e operações. A automação do dia zero pode reduzir o atrito de instalação, mas deixa intacto o problema de controle de longo prazo.

Uma referência nomeada à Flexport apoiava o caso do AWS Cloud WAN nos documentos da empresa. Ela mostra que um cliente empresarial concordava em recomendar a arquitetura, mas não constitui uma auditoria independente da escala, das economias ou da disponibilidade. As citações de clientes devem servir como exemplos de adoção, não como prova universal de desempenho.

Azure e Google Cloud complementavam a promessa multicloud

A Prosimo também oferecia suporte ao Microsoft Azure e ao Google Cloud. Seus documentos mencionavam a orquestração em torno do Azure Virtual WAN e dos objetos de rede e serviço privado do Google Cloud. O objetivo era apresentar um modelo operacional único, deixando a rede nativa de cada provedor no lugar.

O suporte não comprova paridade de funções. As APIs de nuvem amadurecem em ritmos diferentes, e nomes de produtos semelhantes podem ocultar semânticas distintas. Uma rota, um segmento, um endpoint privado ou uma inserção de serviço pode exigir um tratamento específico do provedor. As fontes fornecidas não reconstroem uma matriz de paridade função por função para cada região e versão.

A abstração multicloud é, portanto, um sistema de tradução. Ela pode normalizar a intenção comum e os fluxos de trabalho, mas deve preservar os detalhes que afetam a segurança, o custo e as falhas. Uma plataforma torna-se perigosa quando a interface parece uniforme enquanto as diferenças de implementação são ocultadas dos operadores.

O mesmo princípio vale após a aquisição. A Palo Alto Networks pode usar o grafo comum para posicionar a segurança entre várias nuvens, mas os provedores mantêm o controle dos objetos nativos que materializam o caminho. Possuir a orquestração não significa possuir o underlay da nuvem.

O produto expandiu-se da conexão para o ciclo de vida

Em 2023, a Prosimo descrevia fluxos de trabalho de projeto, construção, diagnóstico e gestão de redes multicloud. O produto ia além de um túnel ou de um gateway. A descoberta de ativos apoiava o projeto; a orquestração criava a conectividade; os mapas e a telemetria auxiliavam no diagnóstico; as políticas e o histórico sustentavam a gestão contínua.

Esse enquadramento ampliava o potencial comprador. Um engenheiro de rede podia explorar a topologia e a análise de caminho; uma equipe de plataforma de nuvem podia integrar contas e serviços; uma equipe de segurança podia revisar a segmentação e a inspeção; uma equipe de migração podia planejar mudanças; uma equipe de FinOps podia examinar as consequências de rota e egress. O valor aumentava quando vários grupos utilizavam as mesmas evidências.

Evidências comuns também podem provocar conflitos de governança. Uma plataforma central pode revelar que a configuração nativa de uma equipe de nuvem difere da política corporativa. A organização precisa decidir qual sistema é a autoridade e quem pode aprovar a correção. O software não resolve sozinho essa questão institucional.

A narrativa do ciclo de vida também reforçava os custos de mudança. Quando um controlador detém o grafo de ativos, as políticas, a telemetria, os posicionamentos de edges e as integrações de automação, substituí-lo exige mais do que mover um circuito. O cliente precisa exportar ou reconstruir seu modelo operacional. A Prosimo vendia uma redução da fragmentação da nuvem enquanto criava a possibilidade de uma dependência do controlador.

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

A Prosimo apresentava uma segmentação das camadas 3 a 7. No nível de rede, os domínios de roteamento e os segmentos determinavam quais sub-redes ou sites podiam se comunicar. Nos níveis superiores, a identidade da aplicação, o contexto do usuário e as propriedades da transação podiam especificar a regra.

Esse modelo podia reduzir a lacuna entre a zona de rede e a política aplicacional. Um serviço de negócios podia ser autorizado enquanto uma alcançabilidade ampla entre sub-redes permanecia bloqueada. Inversamente, um caminho de rede válido podia ser recusado porque a identidade ou o contexto aplicacional falhava.

Isso não transformava a Prosimo em um firewall de próxima geração completo. A integração com a Palo Alto Networks separava as responsabilidades: a Prosimo orquestrava rotas, segmentação e inserção de serviços; o VM-Series realizava a inspeção profunda. A distinção é importante, pois o direcionamento de políticas e a aplicação da segurança falham de maneiras diferentes.

Um segmento só é eficaz se todos os caminhos relevantes forem representados. Uma rota desconhecida, uma exceção nativa ou uma inserção com falha pode contornar o controle. A garantia exige, portanto, comparar a política declarada, o estado do provedor e o tráfego observado, e não confiar apenas na tela do controlador.

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

A segurança de nuvem precisa decidir onde a inspeção ocorre. Firewalls centralizados podem simplificar a política e reduzir o número de instâncias, mas podem criar desvios, concentração e pressões de capacidade. Firewalls distribuídos permanecem próximos das cargas e reduzem certas distorções, mas multiplicam a implantação, as licenças, as atualizações e as operações de política.

A Prosimo apoiava ambos os modelos na integração do VM-Series. A política podia direcionar um tráfego selecionado para um ponto central ou para firewalls distribuídos nos VPCs de aplicação. O controlador atualizava as rotas circundantes, enquanto a Palo Alto Networks fornecia a inspeção.

A arquitetura tornava a orquestração do roteamento valiosa para um fornecedor de segurança. Um firewall de software não protege o tráfego que nunca passa por ele. A descoberta, o posicionamento e as mudanças de rota reduzem o atrito entre a compra de capacidade de segurança e sua inserção em um caminho ativo. Essa é uma razão estratégica plausível para a absorção da tecnologia da Prosimo pela Palo Alto Networks.

Ela também ampliava o raio de impacto do controlador. Uma política incorreta pode contornar a inspeção, criar um loop, produzir roteamento assimétrico ou interromper a aplicação. Verificações de saúde, mudanças em etapas, simulação, auditoria e reversão são necessárias, pois um erro de inserção é ao mesmo tempo um incidente de rede e um incidente de segurança.

A parceria de 2024 não deve ser transformada retroativamente em aquisição

A Prosimo e a Palo Alto Networks anunciaram a integração do VM-Series em 12 de junho de 2024. O comunicado descrevia uma solução técnica e comercial conjunta. Ele não dizia que a Palo Alto Networks havia adquirido a Prosimo. Usar esse anúncio como prova de propriedade confundiria dois eventos distintos.

A parceria, no entanto, criou uma ponte. A Prosimo podia mostrar como seu sistema de rotas e políticas facilitava a implantação do VM-Series em várias nuvens. A Palo Alto Networks podia avaliar a tecnologia em uma integração real antes da transição posterior. As fontes públicas não descrevem o processo de aquisição; afirmar que a parceria constituía formalmente uma etapa preparatória seria especulativo.

No início de 2025, os históricos dos fundadores e funcionários haviam mudado. A página da empresa posteriormente exibiu o status de adquirida. No final de 2025, Bhau declarou que a tecnologia estava totalmente integrada aos produtos da Palo Alto Networks. Esses elementos, em conjunto, sustentam a conclusão de que houve uma aquisição, mas deixam os mecanismos jurídicos não resolvidos.

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 de integração definida. Uma aquisição pode deslocar roteiros, dados, contratos e autoridade para uma única empresa. A transição muda mais do que a marca, mesmo que o caminho técnico pareça inicialmente semelhante.

O Nebula transformava o grafo topológico em interface conversacional

A Prosimo introduziu o Nebula em fevereiro de 2024, dentro de um AI Suite para rede multicloud. O assistente deveria responder em linguagem natural a perguntas sobre redes sobrepostas, custos, integridade das rotas, violações de política de segurança e outras condições representadas no grafo e na telemetria.

O ativo útil não era apenas a interface linguística, mas o contexto multicloud estruturado subjacente. Um modelo genérico não pode diagnosticar uma rota privada ou um segmento que não vê. O Nebula podia se apoiar no inventário, na topologia, nas políticas e nas observações já coletadas. O investimento anterior em um grafo comum tornava-se, assim, relevante para as AIOps.

O acesso conversacional podia tornar dados complexos acessíveis a mais operadores. Ele também podia criar uma falsa confiança se a resposta omitisse um ativo não suportado, entendesse mal a pergunta ou tratasse uma recomendação como uma ação aprovada. Mudanças de alto risco ainda exigiam controles determinísticos, limites de autorização e revisão humana.

A Prosimo reivindicava possíveis melhorias, incluindo uma redução de 60 a 80% no tempo médio de resolução e de mais de 60% no custo da rede de nuvem. Esses números eram afirmações da empresa em um anúncio de produto. Nenhuma metodologia independente ou base de clientes fornecida demonstra que eles se aplicam de forma geral. Eles podem ser citados como benefícios propostos pela Prosimo, não como fatos comprovados do mercado.

As cargas de IA eram um caso de uso, não a prova de um novo mercado

O mesmo anúncio de 2024 apresentava a arquitetura como útil para cargas de inteligência artificial. Sistemas de IA distribuídos podem exigir acesso privado a dados, conexões entre nuvens e data centers, controles de conformidade e roteamento ciente do comportamento aplicacional. Essas necessidades correspondiam ao modelo de ativos, políticas e caminhos já desenvolvido.

O rótulo não mudava o underlay. A Prosimo ainda dependia das redes de nuvem, das operadoras e da infraestrutura dos clientes. A empresa não fornecia computação GPU nem software de desenvolvimento de modelos. Seu papel potencial era a conectividade e a segurança em torno de dados e serviços distribuídos.

O posicionamento de IA era lógico, pois o valor de uma topologia transversal aumenta com a distribuição dos dados e serviços. Também constituía uma categoria de marketing introduzida pouco antes do fim da independência. Os elementos fornecidos não estabelecem receita separada ligada à IA, implantações de produção nomeadas ou resultados auditados.

O ponto duradouro é que a telemetria multicloud pode alimentar operações assistidas por máquina. A questão atual é saber se a Palo Alto Networks reteve esse contexto e como expõe a capacidade. As fontes públicas disponíveis na data de corte não fornecem a resposta completa.

O modelo de negócios vendia software sobre uma infraestrutura de terceiros

A Prosimo operava como uma empresa de software por assinatura e serviços, não como uma operadora. Os clientes implantavam AXI Edges em seus ambientes e conectavam suas contas de nuvem à camada de controle. A receita provavelmente dependia de licenças ou assinaturas, suporte, serviços profissionais e canais, mas os preços e as métricas contratuais exatos não são divulgados nos elementos fornecidos.

O modelo podia crescer sem possuir fibra. Uma plataforma de software podia coordenar muitas regiões e ambientes. No entanto, não é possível deduzir a economia bruta. O suporte às APIs dos provedores, o ciclo de vida dos edges, as integrações de segurança e a implantação empresarial podem ser caros, enquanto os recursos de nuvem consumidos pelos edges podem ser pagos diretamente pelo cliente.

A Prosimo usava marketplaces, parceiros de integração, canais e referências de clientes para alcançar empresas. Essas relações não são equivalentes. Uma presença em marketplace prova um canal de compra e implantação. Uma integração técnica prova que dois sistemas podem funcionar juntos sob condições definidas. Uma citação de cliente fornece uma referência. Nenhuma delas, isoladamente, revela o número de clientes pagantes ou a receita recorrente.

A amplitude da oferta podia dificultar a venda. As equipes de rede, segurança, nuvem e aplicações podiam se beneficiar, mas a propriedade orçamentária podia permanecer difusa. O produto precisava de um comprador disposto a financiar uma camada de controle comum, em vez de deixar cada nuvem e cada equipe operar separadamente.

Parceiros, clientes e investidores ocupavam posições distintas

A Amazon Web Services era ao mesmo tempo fornecedora da infraestrutura subjacente e parceira de integração comercial. Azure e Google Cloud eram ambientes suportados. Os provedores de identidade forneciam o contexto de autenticação. Os firewalls realizavam a inspeção. Serviços de colocation e operadoras podiam hospedar ou conectar os edges. Parceiros de canal podiam projetar e operar as implantações.

A Flexport figurava como referência de cliente nos documentos do AWS Cloud WAN. A referência demonstra o interesse empresarial pela arquitetura, mas os elementos não fornecem a extensão, a duração ou o valor comercial completo da implantação. Ela não deve ser usada como substituto do número total de clientes.

A General Catalyst liderou a Série A e participou da governança como investidora. Investidores ligados à WRVI ou à Celesta apareciam nos documentos, enquanto mensagens posteriores mencionavam outras participações conhecidas, incluindo um nome ligado à BlackRock cujo veículo exato não foi resolvido. Esses elementos indicam uma base de financiamento bem conectada, não uma tabela de capitalização completa.

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

Ao menos 55 milhões de dólares foram levantados; a economia da saída permanece desconhecida

O financiamento verificado inclui uma Série A de 25 milhões de dólares em abril de 2021 e uma Série B de 30 milhões de dólares em 2022, totalizando pelo menos 55 milhões. Nenhuma tabela de capitalização auditada, valorização, dívida ou rodada posterior está disponível nos elementos fornecidos.

A contrapartida da aquisição não foi divulgada ou verificada independentemente. Sem o preço, é impossível qualificar corretamente a operação como prêmio estratégico, compra tecnológica modesta, acqui-hire ou venda em dificuldades. A continuidade da integração apoia a ideia de valor tecnológico, mas não revela o retorno dos investidores ou fundadores.

A receita e a escala da Palo Alto Networks não devem ser atribuídas à Prosimo após a aquisição. A startup deixou de ser observável separadamente, e não há mais receita, lucro ou segmento de clientes autônomo para analisar. Um proprietário maior pode difundir mais a tecnologia, tornando sua economia individual menos visível.

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

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

A Prosimo concorria com plataformas especializadas como Aviatrix e Alkira, fornecedores de redes empresariais e SASE, bem como os serviços nativos da AWS, Azure e Google Cloud. Também enfrentava um modelo interno em que a empresa usa diretamente infraestrutura como código, serviços de trânsito, tabelas de roteamento e firewalls dos provedores. Essas alternativas resolviam porções diferentes do mesmo problema.

Um controlador especializado podia fornecer uma topologia única e um modelo de política único. Um projeto cloud-native podia reduzir a dependência de terceiros e alinhar-se estreitamente a um provedor. Um serviço oferecido por uma operadora podia fornecer o transporte físico. Uma plataforma SASE ou de segurança podia combinar conectividade e imposição de políticas. A engenharia interna podia preservar o controle, ao custo do esforço da equipe e da integração.

A diferenciação da Prosimo reunia trânsito aplicacional e de rede, edges distribuídos, orquestração nativa, topologia, telemetria e inserção de serviços. Essa amplitude também dificultava as comparações. Os compradores precisavam testar as nuvens, rotas, identidades e modelos de segurança que realmente pretendiam usar, em vez de comparar rótulos de categoria.

A aquisição altera o quadro competitivo. A Prosimo não precisa mais vencer como empresa autônoma; sua tecnologia precisa provar valor dentro da Palo Alto Networks. A comparação relevante passa a ser a capacidade da descoberta e orquestração integradas de melhorar a implantação dos produtos de segurança da Palo Alto e a aceitação, pelos clientes, da dependência resultante.

Os serviços nativos das nuvens eram ao mesmo tempo base 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 enfrentava a possibilidade de os clientes utilizarem-nos diretamente.

Essa relação criava uma fronteira móvel. Quando um provedor adicionava roteamento global, segmentação, serviços privados ou política central, algumas funções de terceiros tornavam-se mais fáceis de reproduzir. Ao mesmo tempo, cada novo serviço nativo acrescentava um objeto que o controlador transversal podia descobrir e coordenar. Os avanços das nuvens podiam reduzir parte do valor da Prosimo e, ao mesmo tempo, aumentar a necessidade de tradução entre provedores.

O fator decisivo era tanto organizacional quanto técnico. Uma empresa centrada em uma nuvem e com forte engenharia interna podia preferir ferramentas nativas. Uma empresa multicloud com equipes fragmentadas podia valorizar um plano de controle único. Uma organização regulada podia apreciar uma camada de evidências independente, mas temer a concentração de credenciais e dados.

Nenhuma arquitetura eliminava a dependência do fornecedor. As ferramentas nativas aumentavam a dependência das APIs e semânticas de uma nuvem. Um controlador transversal aumentava a dependência de seu grafo, políticas e edges. A pergunta útil era se a dependência permanecia visível, portátil e adequada ao modelo operacional.

A falha podia estar no controlador, no edge, na API da nuvem, na identidade ou no underlay

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

As falhas parciais são particularmente desafiadoras. Um provedor pode aceitar uma alteração de rota enquanto outro a rejeita. O estado desejado pelo controlador diverge então do estado real. O tráfego pode se tornar assimétrico ou contornar a inspeção. Um sistema confiável precisa de reconciliação, operações idempotentes, mudanças em etapas, estados de erro explícitos e reversão adequada a cada provedor.

As fontes públicas descrevem a arquitetura de disponibilidade e otimização, mas não incluem um estudo independente de injeção de falhas, um registro completo de incidentes ou um resultado universal de nível de serviço. As afirmações de resiliência devem permanecer vinculadas à arquitetura documentada ou a um exemplo de cliente nomeado.

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

As credenciais de nuvem tornavam o controlador uma infraestrutura de gestão crítica

A descoberta e a orquestração exigiam acesso às contas de nuvem. Um inventário somente leitura podia usar permissões limitadas, enquanto as alterações de rotas, segmentos e serviços demandavam autoridade mais elevada. O controlador situava-se, portanto, no plano de gestão privilegiado, mesmo sem possuir as cargas.

O comprometimento de uma credencial podia expor a topologia ou permitir mudanças amplas. Um defeito de software ou um erro de operador podia propagar uma política em várias nuvens. O risco aumentava com a utilidade: quanto mais contas e serviços a plataforma governava, maior o raio de impacto potencial.

As empresas precisavam de papéis de menor privilégio, credenciais separadas para descoberta e escrita, aprovação com múltiplas partes, auditoria completa, rotação, revogação de emergência e um caminho de recuperação independente do controlador. Os documentos públicos não fornecem uma avaliação de segurança independente completa; esses requisitos permanecem, portanto, como controles de implantação necessários, não como garantias verificadas.

O grafo de telemetria era igualmente sensível. Ele podia revelar nomes de aplicações, estrutura da rede, políticas, relações de usuários, integridade das rotas e custos. A governança pós-aquisição deveria especificar onde esses dados são armazenados, quais produtos da Palo Alto Networks podem usá-los e como as permissões dos clientes históricos foram migradas. As fontes públicas não respondem a essas perguntas.

A aquisição transferiu uma camada tida como neutra para uma plataforma de segurança

A posição independente da Prosimo permitia que ela se apresentasse como uma 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 Palo Alto. Isso pode gerar melhor integração e, ao mesmo tempo, levantar questões sobre o suporte a inspeções de terceiros.

A propriedade não prova que a neutralidade desapareceu. Os elementos fornecidos não contêm uma matriz atual de parceiros ou de arquitetura. No entanto, modificam a pergunta a ser feita. Os clientes precisam saber se o controlador permanece aberto a múltiplos fornecedores, se as políticas e a telemetria são exportáveis e se a otimização favorece o portfólio do proprietário.

A declaração de integração enfatizava a inspeção dos fluxos de entrada, saída e leste-oeste. Isso sugere que a topologia e a orquestração se tornaram parte de um sistema de implantação de segurança. Não prova que as funções históricas de App Transit, acesso de usuário, otimização de custos ou cada fluxo de trabalho de rede tenham sobrevivido separadamente.

Esse é um padrão frequente na infraestrutura. Uma startup abstrai um problema de coordenação difícil; um grande fornecedor adquire a abstração porque ela amplia o uso e o controle de seu produto principal. O adquirente obtém um caminho para a implantação. O cliente pode ganhar integração e perder independência de fornecedor.

O mapeamento atual do produto é o principal dado ausente

O dossiê público confirma a aquisição e a integração, mas não fornece uma correspondência completa entre AXI, Network Transit, App Transit, AIR e Nebula e os produtos ou ofertas atuais da Palo Alto Networks. Não publica datas de fim de suporte, procedimentos de migração nem tabela de continuidade funcional.

Essa lacuna impede uma revisão de produto no presente. As descrições históricas explicam o que a Prosimo havia construído e por que isso importava. Elas não dizem quais capacidades estão disponíveis hoje, sob licença ou com suporte. Qualquer recomendação de implantação contemporânea deve basear-se na documentação atual da Palo Alto Networks, não nos anúncios antigos da Prosimo.

A ausência de mapeamento também limita a análise estratégica. A absorção completa do grafo e da orquestração seria diferente de um uso seletivo da descoberta de ativos e do posicionamento de firewall. O primeiro caso criaria um amplo serviço de controle multicloud; o segundo usaria a Prosimo sobretudo para acelerar a implantação de segurança. A declaração do cofundador confirma a continuidade tecnológica sem resolver essa fronteira.

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

Quem controla o roteamento multicloud?

Nenhum ator controla sozinho o caminho completo. A empresa controla a propriedade das contas, a intenção de negócio, o desenho aplicacional e os direitos que concede. Um controlador transversal pode descobrir a topologia, traduzir as políticas, escolher os caminhos e modificar o estado nativo das rotas. As nuvens controlam suas APIs, serviços de trânsito, pontos privados, backbones e muitos domínios de falha. As operadoras e os sites de colocation controlam outras porções. Os serviços de segurança decidem se o tráfego inspecionado é autorizado.

A Prosimo buscou a posição intermediária mais estratégica. Sem possuir o underlay, ela queria possuir o grafo e a tradução das políticas acima. Quem controla essa camada decide quais ativos são visíveis, como os segmentos são representados, onde os edges são posicionados, qual serviço inspeciona o tráfego e qual telemetria é considerada autoritativa. Trata-se de um poder de roteamento prático, mesmo quando a fibra pertence a terceiros.

Após a aquisição, a Palo Alto Networks possui a tecnologia sobrevivente e determina sua integração, modo de comercialização e desenvolvimento. As nuvens permanecem soberanas em seus ambientes, e a empresa pode revogar as credenciais ou escolher outra arquitetura. A saída, no entanto, pode ser custosa se a topologia, as políticas e os fluxos de trabalho se tornaram dependentes do controlador.

A resposta é, portanto, distribuída: a empresa autoriza; o controlador coordena; as infraestruturas subjacentes das nuvens e das operadoras transportam; a plataforma de segurança aplica. A história da Prosimo mostra que a propriedade da camada de coordenação pode mudar sem que nenhuma conta de nuvem ou caminho físico mude de mãos.

Registro principal das fontes

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

A Prosimo capturou uma evolução real da infraestrutura. A unidade das operações de rede desloca-se do dispositivo e do prefixo para a aplicação, a identidade, a dependência de serviço e o grafo de políticas. As APIs nativas tornam o estado da rede programável, enquanto os edges de software distribuídos permitem mover os pontos de aplicação das políticas. Um controlador que enxerga várias nuvens pode coordenar ações que nenhum console isolado consegue realizar sozinho.

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

A aquisição pela Palo Alto Networks torna a questão do controle mais visível. Rede e segurança convergem em torno da inserção de serviços, da descoberta de cargas e da política. Um fornecedor que conhece a topologia e pode modificar as rotas não se limita a inspecionar o tráfego que lhe é apresentado; ele pode ajudar a decidir qual tráfego chega à inspeção e por onde.

A Prosimo, portanto, não deve ser lembrada nem como uma marca autônoma que simplesmente fracassou, nem como prova de que uma plataforma resolveu o multicloud. Sua contribuição duradoura foi definir o grafo transversal como infraestrutura. A questão restante é se esse grafo, agora dentro de uma grande empresa de segurança, permanece suficientemente transparente, portátil e governável para inspirar confiança.