Resumo

  • A Prosimo foi fundada em 2019 e captou pelo menos US$ 55 milhões nas rodadas Série A (2021) e Série B (2022); receita auditada, valuation e preço de aquisição não foram divulgados.
  • O AXI combinava uma camada central de intenção, topologia e análise com bordas distribuídas, descobrindo ativos de nuvem, conectando aplicações, inserindo serviços de segurança e coletando telemetria, sem possuir uma rede de backbone 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; não há data exata, preço ou mapeamento atual de produtos disponível publicamente.
  • O controle permanece distribuído entre a empresa, o software de orquestração, os provedores de nuvem e a Palo Alto Networks; a possibilidade de migrar topologia, credenciais, políticas e permissões de roteamento é o teste mais crítico para os clientes.

A empresa desapareceu, as perguntas não

Descrever a Prosimo como uma fornecedora independente que ainda opera em 2026 não é preciso. Perfis profissionais públicos mostram que seus fundadores e vários funcionários migraram para a Palo Alto Networks por volta de fevereiro de 2025. A página da empresa da Prosimo está marcada como adquirida, e o ex-CTO, Nehal Bhau, afirmou posteriormente que a tecnologia da empresa foi integrada aos produtos da Palo Alto Networks. Essas evidências confirmam a mudança de controle e a continuidade do valor da tecnologia; no entanto, não confirmam a data de assinatura, a data de fechamento, a forma jurídica ou o preço da transação.

Esse fato deve ser declarado no início, pois determina o tempo verbal a ser usado em todas as descrições do produto. O AXI, o Network Transit, o App Transit, o Application-driven Intelligent Results e o Nebula eram capacidades bem documentadas durante a fase independente da Prosimo. Até que a Palo Alto Networks divulgue o mapeamento atual de produtos e suporte, eles não devem ser descritos como produtos ativos que ainda são vendidos de forma independente sob a marca Prosimo.

A arquitetura histórica pode continuar a existir após a aquisição, como código incorporado, serviços compartilhados, módulos de produto ou ativos de engenharia interna, e essas formas não são equivalentes.

O desaparecimento da marca não significa que os problemas subjacentes tenham ficado obsoletos. As empresas ainda distribuem cargas de trabalho entre Amazon Web Services, Microsoft Azure, Google Cloud, data centers privados, provedores de colocation, plataformas SaaS e usuários remotos. Cada ambiente possui seu próprio roteamento, gateways, pontos de extremidade privados, controles de identidade, serviços de segurança, cotas e regras de cobrança. Mesmo sendo proprietária de todas as contas, uma empresa nem sempre possui uma visão unificada de como as solicitações fluem entre esses ambientes.

A importância da Prosimo estava em sua tentativa de dominar essa visão.

Portanto, a aquisição não é uma nota de rodapé, mas o fio condutor de todo o artigo. A Prosimo construiu uma camada de controle entre nuvens que descobria ativos, interpretava o contexto da aplicação e direcionava o tráfego para os serviços de segurança. A Palo Alto Networks apareceu inicialmente como parceira tecnológica, com seus firewalls VM-Series podendo ser inseridos nesses caminhos; depois, tornou-se proprietária da tecnologia. A fronteira que ficava entre a orquestração de roteamento e a inspeção profunda foi movida para dentro da mesma plataforma de segurança de rede.

A disputa pelo roteamento multicloud na verdade é pelo contexto

Uma tabela de roteamento pode responder se um determinado prefixo é acessível por meio de um próximo salto. Mas, por si só, não pode dizer a qual aplicação o usuário deseja acessar, se o solicitante é confiável, se o tráfego deve ser inspecionado, se um ponto de extremidade privado está disponível, se um caminho de nuvem é mais caro ou por que a transação falha mesmo depois que os pacotes chegam. A operação multicloud transforma essas questões em um problema de controle compartilhado.

O julgamento da Prosimo era de que a autoridade de roteamento não pode se basear apenas na alcançabilidade da camada 3. Ela tentou combinar inventário de ativos de nuvem, estado da rede, identidade da aplicação, identidade do usuário, risco, desempenho e telemetria de transações. Esse contexto pode suportar políticas mais específicas: conectar uma aplicação, isolar um segmento, escolher um ponto de entrada ou fazer com que determinado tráfego passe por um firewall. O valor não estava em criar um novo caminho de fibra, mas em decidir como combinar os caminhos e serviços existentes.

Isso também explica por que a Prosimo usava o termo “infraestrutura de experiência de aplicação” (application experience infrastructure). As solicitações de aplicação eram tratadas acima dos objetos de rede individuais; VPCs, VNets, sub-redes, hubs de trânsito ou links privados eram apenas componentes do caminho ponta a ponta, e não o destino do gerenciamento. Essa abordagem também fazia com que o produto se enquadrasse em vários mercados: rede em nuvem, entrega de aplicações, acesso zero trust, garantia de rede, otimização de custos e inserção de serviços de segurança.

A abrangência funcional trazia oportunidades e ambiguidades. Uma plataforma que abrange várias equipes pode resolver falhas de coordenação das quais nenhuma equipe é responsável; mas também é mais difícil de avaliar, porque as equipes de rede, segurança, nuvem, aplicações e finanças usam critérios de sucesso diferentes. A Prosimo precisava provar que o modelo unificado podia melhorar as operações, em vez de se tornar mais uma camada centralizada com altos privilégios que, em caso de erro, afetaria todos os ambientes.

O que exatamente era a Prosimo e o que resta hoje

A Prosimo era uma empresa privada de software de rede em nuvem, fundada em 2019 e sediada na região da baía de São Francisco. Ramesh Prabagaran foi cofundador e CEO durante a fase independente, e Nehal Bhau foi cofundador e CTO. Os perfis públicos também associam Linus Aranha e Pradeep Aragonda à fundação ou à liderança sênior de engenharia, mas suas posições exatas devem ser verificadas em registros com data específica.

A principal plataforma da empresa era a Application eXperience Infrastructure, abreviada como AXI. O AXI gerenciava intenção, topologia, análise e orquestração por meio de uma camada de software centralizada e implantava bordas AXI distribuídas em regiões de nuvem, locais de colocation ou infraestrutura local adjacente. Mais tarde, a empresa reorganizou a estrutura de produtos como Full-Stack Cloud Transit, com o Network Transit e o App Transit lidando com diferentes categorias de conectividade. O AIR analisava a telemetria e gerava insights operacionais; o Nebula foi adicionado em 2024 para interação em linguagem natural.

A Prosimo não era uma operadora de nuvem nem possuía uma rede global de fibra conectando todas as regiões. Os caminhos podiam passar pelo backbone do provedor de nuvem, pela Internet pública, pelo Direct Connect ou ExpressRoute, por links gerenciados, circuitos de operadoras e pela rede corporativa. Ela também não era um fabricante de firewall como a Palo Alto Networks. Na integração de 2024, a Prosimo cuidava da descoberta, segmentação e direcionamento do tráfego, e o VM-Series realizava a inspeção de segurança profunda.

Após a aquisição, a designação mais segura é “linhagem tecnológica”. As declarações posteriores de integração enfatizam a descoberta de ativos multicloud e a aceleração da implantação de firewalls de software no tráfego de entrada, saída e leste-oeste. Isso prova que componentes importantes da Prosimo continuam existindo, mas não prova que todo o catálogo de produtos AXI, a embalagem comercial e os modelos de suporte tenham continuado exatamente como antes.

O novo problema que surgiu depois do SD-WAN

A equipe fundadora tinha experiência em redes de grande escala, entrega de aplicações e infraestrutura de nuvem. A Prosimo também fazia parte de um ecossistema mais amplo de fundadores e engenheiros associados à Viptela, que ajudou a transformar o SD-WAN em uma categoria distinta no mercado corporativo. Mas o problema seguinte era diferente. O SD-WAN pode simplificar a relação entre as filiais e a rede ou as aplicações, mas não cria automaticamente um modelo operacional unificado em várias nuvens públicas.

Uma aplicação multicloud pode depender de um ponto de extremidade web em um ambiente, de um banco de dados ou serviço gerenciado em outro, de um provedor de identidade externo a ambos, de links privados conectando data centers e de inspeções de segurança implantadas em fronteiras específicas. Cada dependência pode ser representada por objetos nativos de nuvem diferentes. As equipes de rede veem prefixos e hubs de trânsito; as equipes de nuvem veem contas e recursos; os responsáveis pelas aplicações veem domínios e transações; as equipes de segurança veem zonas e políticas de inspeção.

A Prosimo partia das solicitações, não das filiais. A verdadeira pergunta era: como um usuário ou carga de trabalho deve acessar uma aplicação com níveis aceitáveis de segurança, desempenho, disponibilidade e custo? Assim, o objeto de roteamento deixava de ser apenas um prefixo de destino e se ampliava para uma transação que carrega identidade e contexto da aplicação. A plataforma também precisava coletar e manter muito mais informações do que um roteador tradicional.

O momento do mercado também era favorável. AWS, Azure e Google Cloud estavam expandindo seus serviços nativos de trânsito e conectividade privada. As empresas podiam construir redes complexas dentro de uma única nuvem, mas as APIs, os objetos e os modelos de política continuavam diferentes. A oportunidade da Prosimo não era substituí-los por um backbone privado, mas orquestrar essas capacidades nativas da nuvem.

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

A Prosimo foi fundada em 2019, mas seu lançamento público oficial ocorreu apenas em 6 de abril de 2021. A General Catalyst liderou a rodada Série A de US$ 25 milhões na ocasião do lançamento. Os investidores descreveram a oportunidade como a entrega de experiência de aplicação em várias nuvens, alinhando-se com o objetivo da equipe fundadora de superar a conectividade de filiais tradicional e criar uma nova categoria.

O mercado no lançamento era ao mesmo tempo concorrido e indefinido. Os provedores de nuvem reduziam as barreiras de uso de seus serviços de rede; os fornecedores de SD-WAN e SASE estendiam políticas para a nuvem; os fornecedores de entrega de aplicações podiam otimizar solicitações; os fornecedores de segurança podiam inspecionar o tráfego. A Prosimo precisava demonstrar que essas capacidades podiam trabalhar juntas em uma arquitetura orientada para a nuvem, sem alegar que substituía todos os sistemas ao redor.

O financiamento deu à empresa a capacidade de desenvolver integrações, bordas de software, sistemas analíticos, equipes comerciais e canais de parceria. Mas o financiamento por si só não prova product-mercados e setores fit, escala de receita ou diferenciação de longo prazo. Os materiais existentes não fornecem receita auditada, receita recorrente anual, número total de clientes ou valuation. O registro de financiamento comprova o investimento dos investidores em uma aposta de mercado, não um boletim operacional completo.

Em 2022, a Prosimo concluiu uma rodada Série B de US$ 30 milhões, descrita como com excesso de demanda. Somando as duas rodadas claramente identificadas, o total verificado é de pelo menos US$ 55 milhões. Alguns bancos de dados podem mostrar valores mais altos devido a anúncios duplicados ou entradas relacionadas; esses números não devem ser usados antes de verificar os eventos subjacentes.

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

A arquitetura do AXI dividia o trabalho entre uma camada central de controle e análise e bordas de software distribuídas. A camada central mantinha a intenção da aplicação e da rede, descobria ativos, montava a topologia, integrava identidades, analisava telemetria e orquestrava mudanças. As bordas AXI eram implantadas próximas às cargas de trabalho ou usuários, de modo que políticas não dependiam de um centro físico distante para execução.

Essa separação é semelhante a outros sistemas definidos por software, mas lida com objetos nativos da nuvem e com semântica de aplicação. O controlador precisa acessar contas e APIs da nuvem; as bordas precisam acessar serviços de trânsito nativos, redes de carga de trabalho, pontos de extremidade privados ou caminhos externos. O poder da plataforma vem da combinação de duas visões: intenção global acima das nuvens e execução local próxima ao tráfego.

A arquitetura também impõe limites operacionais concretos. Cada borda consome recursos da nuvem, exige design de alta disponibilidade e precisa ser atualizada, monitorada e protegida. A camada de controle precisa de permissões suficientes para descobrir ativos e alterar o estado da rede. A empresa ganha um fluxo de trabalho unificado, mas também adiciona um sistema de gerenciamento cuja disponibilidade e correção afetam a alcançabilidade da produção.

A Prosimo às vezes usava a expressão “rede de nuvem autônoma”. As evidências apoiam automação, recomendações e orquestração orientada por API, mas não uma rede que opera independentemente de políticas humanas, serviços de nuvem e transporte subjacente. Os operadores ainda precisam definir intenção, aprovar acesso, lidar com exceções e assumir a responsabilidade pelos resultados.

A borda AXI era uma escolha de localização, não um appliance virtual genérico

As bordas AXI podiam ser implantadas em VPCs ou VNets da nuvem, ambientes gerenciados ou infraestrutura adjacente. Um documento técnico da AWS mostrava uma VPC de borda conectando VPCs de carga de trabalho por meio do Transit Gateway, opcionalmente encadeando firewalls e também acessando sites locais ou usuários remotos. O ponto de execução estava dentro da topologia da nuvem, não em uma fronteira corporativa distante.

A localização afeta mais do que a latência. Ela determina onde o tráfego entra no domínio da política, qual segmento do backbone da nuvem ou da Internet é usado, onde a criptografia e a inspeção ocorrem e qual telemetria a plataforma pode ver. Uma localização inadequada pode causar desvios ou custos; uma localização correta pode encurtar caminhos e manter o tráfego próximo às cargas de trabalho.

A implantação distribuída aumenta os domínios de falha. Capacidade, versão de software, design de zona de disponibilidade, convergência de roteamento e permissões de acesso podem variar entre regiões. Alta disponibilidade não é apenas executar duas instâncias: o controlador, as tabelas de roteamento da nuvem, os serviços de segurança e os caminhos de retorno também precisam ter uma visão consistente do estado de failover.

Portanto, a borda é parte de um sistema operacional maior. Seu valor depende de a descoberta de ativos, a topologia, as políticas e a análise permanecerem consistentes com o ambiente de nuvem ao redor. Vê-la como um appliance virtual independente seria perder a arquitetura que a Prosimo realmente vendia.

O transporte subjacente sempre pertenceu a outros atores

A Prosimo orquestrava o transporte, mas não possuía os caminhos físicos. O tráfego da aplicação poderia usar o backbone da AWS ou de outros provedores de nuvem, a Internet pública, o Direct Connect, o ExpressRoute, conexões gerenciadas, circuitos de operadoras ou a própria rede da empresa. A plataforma podia selecionar e orquestrar entre as opções disponíveis, mas não podia eliminar a latência, a perda de pacotes, os domínios de falha ou as regras de cobrança desses provedores.

Esse limite é importante para entender as promessas de desempenho. O controlador pode escolher um caminho observado como melhor ou colocar o ponto de entrada mais próximo do usuário; mas não pode garantir que a operadora não falhará, que a região da nuvem não sofrerá interrupção ou que as dependências externas responderão sempre rapidamente. A experiência da aplicação também é afetada por DNS, processamento do servidor, armazenamento, comportamento do navegador e serviços de terceiros, que não estão totalmente sob o controle do controlador de rede.

Não possuir um backbone privado não é apenas uma fraqueza. A Prosimo podia aproveitar a infraestrutura que a empresa já havia adquirido e se beneficiar dos investimentos dos provedores de nuvem; podia entrar em mais regiões sem instalar fibra e também orquestrar sistemas nativos como o AWS Cloud WAN. O custo é a dependência da estabilidade das APIs, das cotas de serviço, dos termos comerciais e das semânticas específicas de cada fornecedor.

Assim, a proposta da Prosimo era de controle operacional, não de propriedade física. Ela tentava fazer com que underlays heterogêneos funcionassem sob um modelo de gerenciamento unificado, preservando as vantagens nativas de cada um. Se essa abstração reduz o lock-in ou o transfere para o controlador depende da portabilidade das políticas, da topologia e da implantação das bordas.

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

O Network Transit era voltado para VPCs, VNets, sub-redes, regiões, sites e segmentos. Ele orquestrava hubs de trânsito nativos da nuvem e objetos de roteamento, permitindo que as equipes estabelecessem conexões por meio de um fluxo de trabalho unificado, em vez de operar cada nuvem individualmente. Ele resolvia a necessidade clássica de rede: uma origem ou segmento deve alcançar um destino por um caminho permitido.

Isso não significa que as diferenças entre nuvens desapareciam. AWS, Azure e Google Cloud expõem objetos, cotas e comportamentos de roteamento diferentes. Sobreposição de endereços, caminhos assimétricos, pontos de extremidade privados e restrições de serviço do fornecedor ainda exigem engenharia. A Prosimo podia padronizar operações comuns e mostrar relações, mas os sistemas subjacentes mantinham suas próprias restrições.

O Network Transit também cuidava da segmentação. Domínios de roteamento e políticas podiam isolar ambientes ou restringir a alcançabilidade. O controlador precisava entender como um segmento existia em várias nuvens e como os objetos nativos implementavam essa fronteira. Uma política unificada ainda podia se traduzir em vários conjuntos de mudanças específicas do fornecedor.

A interface de intenção unificada é uma vantagem, mas a tradução é um risco. Se a política comum divergir da configuração real da nuvem, a empresa pode acreditar que um segmento está protegido quando o estado real não está. Conciliação, auditoria e estados de falha explícitos são tão importantes quanto a configuração inicial.

O App Transit transformava a própria aplicação em objeto de roteamento

O App Transit ampliava o modelo das sub-redes para as aplicações. Ele podia decidir como um usuário ou carga de trabalho deve acessar um serviço com base no domínio da aplicação, na identidade, no tipo de solicitação, na saúde da transação, no risco e no desempenho. Essa é uma das diferenças mais claras entre a Prosimo e os roteadores de nuvem tradicionais.

A perspectiva da aplicação é valiosa porque os serviços modernos nem sempre correspondem a endereços estáveis. Plataformas gerenciadas, pontos de extremidade SaaS e componentes distribuídos mudam, mas a identidade da aplicação permanece significativa. Políticas baseadas em serviço ou usuário podem ser mais duradouras do que regras escritas apenas em torno de endereços e portas.

Esse modelo depende de descoberta precisa. O controlador precisa saber quais domínios e pontos de extremidade pertencem a uma aplicação, quais dependências são essenciais e quais declarações do provedor de identidade são confiáveis. Mapeamentos desatualizados podem fazer com que as solicitações tomem caminhos errados ou recebam políticas erradas. A abstração da aplicação não elimina a necessidade de entender o estado da rede, apenas adiciona uma camada semântica sobre ele.

A combinação de Network Transit e App Transit reconhecia que dois tipos de sistemas coexistem nas empresas: cargas de trabalho IP tradicionais e sub-redes privadas ainda existem, enquanto novas aplicações dependem de domínios, identidades e serviços gerenciados. O significado do Full-Stack Cloud Transit era colocar os dois modelos na mesma estrutura operacional, em vez de forçar um a substituir o outro.

A identidade amplia a decisão de roteamento e também a fronteira de confiança

O acesso ciente da aplicação exige integração de identidade. A plataforma podia decidir se uma conexão seria estabelecida e qual caminho usar com base no contexto do usuário ou da carga de trabalho. Isso suporta uma política de zero trust: a localização por si só não é suficiente para provar o direito de acesso.

A identidade aumenta a precisão da política e, ao mesmo tempo, introduz novas dependências. As políticas de roteamento ou de aplicação agora dependem do provedor de identidade, de suas declarações, do estado da sessão e dos dados de grupo. Mesmo que os roteadores e as bordas estejam saudáveis, a indisponibilidade do serviço de autenticação ou a mudança de atributos pode causar falhas no caminho. A solução de problemas deve cruzar as fronteiras operacionais de rede e identidade.

O controlador também centraliza contextos sensíveis. Ele pode armazenar topologia, relações de aplicação, atributos de usuário, sinais de risco e resultados de política. Esses dados ajudam no diagnóstico e na otimização, mas também tornam mais graves as consequências do acesso não autorizado. Privilégio mínimo, períodos de retenção, auditoria e separação de funções são, portanto, requisitos de arquitetura, não tarefas adicionais de gerenciamento.

A Prosimo refletia uma mudança mais ampla na infraestrutura: as decisões de roteamento e acesso dependem cada vez mais da identidade e da semântica da aplicação. Quanto mais contexto a plataforma vê, mais valiosas podem ser as decisões, e mais rigorosa precisa ser a governança de seus privilégios.

A descoberta de ativos constrói o mapa do qual todas as decisões subsequentes dependem

Um controlador entre nuvens não pode governar objetos que não vê. A Prosimo desenvolveu descoberta e mapeamento de ativos de nuvem para representar VPCs, VNets, sub-redes, aplicações, conexões e relações de segurança. Essas visões eram usadas para integração, design, solução de problemas e políticas.

A capacidade de descoberta é importante porque os ambientes de nuvem frequentemente mudam fora dos fluxos de rede centralizados. As equipes de aplicação podem criar contas, redes, pontos de extremidade e serviços gerenciados com sua própria automação. Diagramas mantidos manualmente ficam rapidamente desatualizados. Um inventário orientado por API geralmente é atualizado, mas sua completude ainda depende da cobertura de contas, das permissões, da lógica de resolução e das APIs da nuvem.

Esse mapa não serve apenas para documentação. O roteamento, a segmentação, a inserção de serviços e a otimização podem ser calculados a partir dele. A falta de um ativo ou dependência pode distorcer as conclusões superiores. Portanto, a topologia deve manter informações de origem: quando foi coletada, de qual conta, quais regiões cobre, se houve falhas nas solicitações.

Isso também ajuda a explicar a aquisição. A Palo Alto Networks só pode implantar capacidades de segurança de forma mais eficaz se souber onde estão as cargas de trabalho e os caminhos de tráfego. Um sistema que descobre ativos de nuvem e altera o roteamento pode reduzir a distância entre comprar um firewall de software e colocá-lo na posição correta. A declaração posterior de Bhau enfatiza justamente a descoberta de ativos e a aceleração da implantação de firewalls de software.

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

O Application-driven Intelligent Results (AIR) analisava a telemetria coletada pelas bordas AXI. O documento técnico da AWS mencionava latência de ida e volta, tempo de processamento, tempo de resposta da aplicação, tipo de transação, risco e resultado da política. A plataforma podia correlacionar observações de usuário, rede e aplicação, em vez de exibir apenas contadores isolados de dispositivos.

Essa correlação visa problemas operacionais comuns: uma transação lenta pode vir do caminho do usuário, da borda, do backbone da nuvem, do serviço de segurança ou da própria aplicação. Uma visão entre camadas pode restringir a investigação mais rapidamente do que vários consoles independentes, e também pode oferecer recomendações sobre caminhos, localização, risco e custo.

A qualidade da recomendação depende da cobertura da telemetria e do modelo de interpretação. As bordas veem apenas o tráfego que passa por elas; as dependências externas da aplicação e o estado interno do provedor de nuvem podem não ser visíveis. Portanto, uma recomendação pode ter valor direcional, mas não necessariamente prova a causa raiz.

A telemetria também tem valor de governança. Dados históricos podem explicar por que uma rota ou política mudou, mas também podem expor padrões de uso de aplicações sensíveis e comportamento do usuário. Os materiais públicos não descrevem completamente a retenção de dados e a governança pós-aquisição, portanto essas questões permanecem no escopo da due diligence do cliente.

A AWS forneceu o caso de implementação mais claro nos materiais públicos

A parceria da Prosimo com a AWS gerou as evidências técnicas públicas mais fortes. A empresa integrou-se ao AWS Transit Gateway, ao Cloud WAN, ao PrivateLink e ao Marketplace for Containers Anywhere. A AWS publicou fluxos de posicionamento da borda AXI, acesso à aplicação, identidade, segurança e otimização.

O AWS Cloud WAN é particularmente importante. Ele oferece backbone nativo da nuvem e capacidade de segmentação, e a Prosimo o orquestrava em vez de substituí-lo. A divisão de trabalho é clara: a AWS possui a rede nativa e a infraestrutura global; a Prosimo fornece intenção entre nuvens, contexto de aplicação, software de borda e análise.

O fluxo de trabalho do Marketplace simplificava a implantação do primeiro dia, mas não eliminava questões de permissão de conta, design de roteamento, alta disponibilidade, capacidade e operação de longo prazo. A automação do dia zero pode reduzir o atrito de instalação, mas não substitui a governança contínua.

Os materiais da Prosimo também citavam o depoimento do cliente Flexport, apoiando o caso de uso do AWS Cloud WAN. Isso prova que uma empresa cliente estava disposta a endossar a arquitetura, mas não é uma auditoria independente da escala de implantação, economia ou disponibilidade. Depoimentos de clientes devem ser vistos como exemplos de adoção, e não como prova universal de desempenho.

Azure e Google Cloud completavam a proposta multicloud

A Prosimo também suportava Microsoft Azure e Google Cloud. Os materiais do produto descreviam a orquestração em torno do Azure Virtual WAN e dos objetos de rede e serviços privados do Google Cloud. O objetivo era fornecer um modelo operacional unificado, preservando a rede nativa de cada nuvem.

Suporte não significa equivalência funcional completa. As APIs da nuvem evoluem em ritmos diferentes, e nomes de produtos semelhantes podem ocultar semânticas diferentes. O roteamento, a segmentação, os pontos de extremidade privados ou a inserção de serviços podem exigir tratamento específico do fornecedor. As evidências existentes não reconstroem uma tabela de comparação funcional detalhada cobrindo todas as regiões e versões.

Portanto, a abstração multicloud é mais parecida com um sistema de tradução. Ela pode padronizar intenções e fluxos de trabalho comuns, mas deve preservar as diferenças que afetam a segurança, o custo e a falha. A abstração se torna perigosa quando a interface parece unificada, mas as diferenças de implementação permanecem invisíveis para o operador.

O mesmo vale após a aquisição. A Palo Alto Networks pode usar um mapa unificado para posicionar segurança entre nuvens, mas os provedores de nuvem ainda controlam os objetos nativos que realizam o caminho. Possuir a camada de orquestração não é o mesmo que possuir o underlay da nuvem.

O produto se expandiu da conectividade para todo o ciclo de vida operacional

Em 2023, a Prosimo já descrevia seu produto como suportando fluxos de trabalho completos para projetar, construir, solucionar problemas e gerenciar redes multicloud, e não mais apenas como túneis ou gateways. A descoberta de ativos apoiava o design, a orquestração criava conexões, o mapa e a telemetria eram usados para diagnóstico, e as políticas e o histórico de estado apoiavam o gerenciamento contínuo.

Esse posicionamento ampliava os potenciais compradores. As equipes de rede usavam topologia e análise de caminho; as equipes de plataforma de nuvem integravam contas e serviços; as equipes de segurança inspecionavam segmentação e caminhos de inspeção; as equipes de migração planejavam mudanças; e as equipes de FinOps avaliavam custos de saída e caminhos. Quando várias equipes compartilham a mesma evidência, o valor da plataforma aumenta.

Evidência compartilhada também pode gerar conflitos de governança. Uma plataforma central pode descobrir que a configuração nativa da equipe de nuvem está inconsistente com a política corporativa. 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 do ciclo de vida também eleva os custos de troca. Uma vez que o controlador armazena o mapa de ativos, as políticas, a telemetria, as posições das bordas e as integrações de automação, substituí-lo não é apenas mover linhas, mas exportar ou reconstruir o modelo operacional. A Prosimo, ao resolver a fragmentação da nuvem, também podia criar dependência do controlador.

A segmentação vai da alcançabilidade da camada 3 até a política de aplicação da camada 7

A Prosimo descrevia a segmentação como cobrindo das camadas 3 a 7. Na camada de rede, os domínios de roteamento e os segmentos decidem quais sub-redes ou sites podem se comunicar; nas camadas superiores, a identidade da aplicação, o contexto do usuário e os atributos da transação podem restringir ainda mais as regras.

Esse modelo pode reduzir a distância entre as zonas de rede e as políticas de aplicação. Um serviço de negócios específico pode ser permitido, enquanto a comunicação ampla entre sub-redes permanece bloqueada; inversamente, um caminho de rede, mesmo que alcançável, pode ser negado se a identidade ou o contexto da aplicação não corresponderem.

Isso não transformava a Prosimo em um firewall de próxima geração completo. A integração com a Palo Alto em 2024 deixava clara a divisão: a Prosimo cuidava do direcionamento, da segmentação e da inserção de serviços, e o VM-Series cuidava da inspeção profunda. O direcionamento de políticas e a execução de segurança têm modos de falha diferentes e não devem ser confundidos.

A segmentação só é eficaz quando todos os caminhos relevantes são representados. Rotas desconhecidas, exceções nativas da nuvem ou falhas na inserção de serviços podem contornar o controle. A garantia exige reconciliação entre a política declarada, o estado real da nuvem e o tráfego observado, e não apenas confiar na configuração exibida no console.

A inserção de serviços conecta o controle de roteamento com a economia do firewall

O design de segurança na nuvem precisa decidir onde a inspeção ocorre. Firewalls centralizados podem simplificar políticas e reduzir o número de instâncias, mas podem causar backhauling, concentração de risco e pressão de capacidade. Firewalls distribuídos próximos às cargas de trabalho aumentam a implantação, o licenciamento, a atualização e a operação de políticas.

A integração da Prosimo com o VM-Series suportava ambos os modos. As políticas podiam direcionar tráfego específico para um ponto de inspeção centralizado ou para firewalls distribuídos nas VPCs de aplicação. A Prosimo modificava o roteamento periférico, e a Palo Alto Networks fornecia a inspeção.

Essa arquitetura torna a orquestração de roteamento comercialmente valiosa para os fornecedores de segurança. Um firewall de software não pode proteger o tráfego que nunca passa por ele. A descoberta, o posicionamento e a atualização de roteamento podem reduzir a distância entre comprar uma capacidade de segurança e realmente colocá-la no caminho de produção. Essa é uma das motivações estratégicas plausíveis para a aquisição da tecnologia Prosimo pela Palo Alto Networks.

Ao mesmo tempo, o raio de falha do controlador também se amplia. Uma política errada pode contornar a inspeção, criar loops, causar roteamento assimétrico ou interromper aplicações. Verificações de saúde, mudanças em fases, simulação, auditoria e reversão são necessárias, porque um erro na inserção de serviços é tanto um evento de rede quanto de segurança.

A parceria de 2024 não pode ser retroativamente interpretada como aquisição concluída

A Prosimo e a Palo Alto Networks anunciaram a integração com o VM-Series em 12 de junho de 2024. O anúncio descrevia uma solução técnica e comercial conjunta, sem afirmar que a Palo Alto Networks havia adquirido a Prosimo. Tratar essa parceria como evidência de propriedade confundiria dois eventos distintos.

A parceria certamente construiu uma ponte. A Prosimo podia mostrar como seu sistema de roteamento e políticas simplificava a implantação do VM-Series entre nuvens; a Palo Alto Networks podia avaliar a tecnologia em uma integração real. Os materiais públicos não descrevem o processo de aquisição, portanto não se pode inferir que essa parceria tenha sido uma etapa formal pré-aquisição.

No início de 2025, os perfis dos fundadores e funcionários mudaram; a página da empresa posteriormente exibiu o status de adquirida; no final de 2025, Bhau declarou que a tecnologia estava totalmente integrada. Os três tipos de evidência juntos sustentam a conclusão da aquisição, mas ainda não preenchem os detalhes legais da transação.

Essa linha do tempo também é importante para os clientes. Parceria significa dois fornecedores, dois sistemas de suporte e uma fronteira de integração clara. A aquisição pode mover o roadmap, os dados, os contratos e as permissões para uma única empresa. Mesmo que o caminho tecnológico pareça semelhante, as implicações de governança já mudaram.

O Nebula transformava o mapa topológico em uma interface conversacional

A Prosimo lançou o Nebula em fevereiro de 2024 como parte do AI Suite para redes multicloud. Ele foi projetado para responder, em linguagem natural, a perguntas sobre sobreposição de endereços, custo, saúde do roteamento, violações de política de segurança, todas dependentes do mapa e da telemetria da plataforma.

O ativo realmente valioso não era a interface de linguagem em si, mas o contexto estruturado subjacente. Modelos genéricos não podem diagnosticar rotas privadas que não veem. O Nebula podia invocar os dados de ativos, topologia, políticas e observações que a Prosimo já havia coletado, de modo que o investimento anterior em um mapa unificado se tornasse a base do AIOps.

O acesso conversacional pode permitir que mais operadores usem dados complexos, mas também pode criar falsa confiança: as respostas podem omitir ativos não suportados, interpretar mal as perguntas ou tratar recomendações como ações aprovadas. Mudanças de alto risco ainda exigem controles determinísticos, limites de permissão e revisão humana.

A Prosimo havia alegado que o tempo médio de reparo poderia ser reduzido em 60% a 80% e que os custos de rede em nuvem poderiam cair mais de 60%. Esses números vêm de anúncios de produtos do fornecedor, sem metodologia independente ou linha de base do cliente que comprove sua aplicabilidade geral. Eles podem ser citados como metas propostas pela Prosimo, não como fatos comprovados da indústria.

Cargas de trabalho de IA são um novo caso de uso, não a prova de um novo mercado estabelecido

O mesmo anúncio de 2024 também descrevia a arquitetura da Prosimo como adequada para cargas de trabalho de IA. Sistemas de IA distribuídos podem exigir acesso a dados privados, conectividade entre nuvens e data centers, controles de conformidade e roteamento ciente da aplicação. Esses requisitos se alinham com os modelos existentes de ativos, políticas e caminhos.

O rótulo “IA” não altera o underlay. A Prosimo ainda dependia das redes de nuvem, das operadoras e da infraestrutura do cliente, e não fornecia computação em GPU ou software de desenvolvimento de modelos. Seu papel potencial era fornecer conectividade e segurança em torno de dados e serviços distribuídos.

Esse posicionamento é estrategicamente lógico, porque quanto mais dispersos estiverem os dados e serviços, mais valiosa se torna a topologia entre nuvens; mas também foi uma categoria de marketing introduzida pouco antes de a empresa encerrar sua operação independente. As evidências existentes não mostram receita separada de IA, implantações nomeadas em produção ou resultados auditados.

A conclusão sustentável é que a telemetria multicloud pode servir como entrada para operações assistidas por máquina. A questão hoje é se a Palo Alto Networks reteve esse contexto e como expõe as capacidades aos clientes. Os materiais públicos não respondem completamente.

O modelo de negócios era vender software sobre a infraestrutura de terceiros

O negócio independente da Prosimo era um modelo de assinatura de software e serviços, não um modelo de operadora. Os clientes implantavam as bordas AXI em seus próprios ambientes e conectavam as contas de nuvem à camada de controle. A receita provavelmente vinha de licenciamento ou assinatura, suporte, serviços profissionais e canais, mas os materiais existentes não fornecem preços específicos ou métricas contratuais.

Esse modelo não exigia possuir fibra para escalar. Uma plataforma podia orquestrar um grande número de regiões e ambientes de clientes. Mas não se pode inferir a margem bruta a partir da arquitetura; o suporte contínuo às APIs dos fornecedores, o ciclo de vida das bordas, a integração de segurança e as implantações empresariais podem ser caros, e os recursos de nuvem consumidos pelas bordas podem ser cobrados diretamente do cliente.

A Prosimo utilizava mercados de nuvem, parceiros de integração, canais e casos de clientes para entrar nas empresas. Diferentes relacionamentos não são equivalentes. A listagem no mercado prova que existe um canal de compra e implantação; a integração técnica prova que dois sistemas podem trabalhar juntos sob condições específicas; o depoimento do cliente fornece uma referência. Nenhum deles prova isoladamente o número de clientes pagantes ou a receita recorrente.

A amplitude do produto também podia dificultar a venda. As equipes de rede, segurança, nuvem e aplicações podem se beneficiar, mas a propriedade do orçamento não é clara. A Prosimo precisava de um comprador disposto a pagar por uma camada de controle comum, em vez de deixar cada equipe continuar operando de forma fragmentada.

Parceiros, clientes e investidores desempenham papéis diferentes

A AWS era ao mesmo tempo provedora de infraestrutura subjacente e parceira de integração no mercado; Azure e Google Cloud eram ambientes suportados; provedores de identidade forneciam contexto de autenticação; fabricantes de firewall forneciam inspeção; serviços gerenciados e de operadoras podiam hospedar ou conectar bordas; parceiros de canal podiam projetar e operar implantações.

A Flexport é uma referência de cliente nomeada nos materiais do AWS Cloud WAN. Isso prova o interesse de uma empresa cliente na arquitetura, mas não indica o escopo completo da implantação, a duração ou o valor comercial, e não substitui a escala total de clientes.

A General Catalyst liderou a Série A e participou da governança do investimento. Os materiais da empresa também mencionam investidores associados à WRVI/Celesta, e informações posteriores citam uma participação notável relacionada à BlackRock, mas a pesquisa não conseguiu identificar os veículos de investimento específicos. Essas informações sugerem uma rede de financiamento forte, mas não constituem uma tabela de capitalização completa.

A Palo Alto Networks é o relacionamento mais importante. Ela passou de parceira de segurança em 2024 para adquirente no início de 2025. Esse processo ilustra como, quando um parceiro do ecossistema compra a camada de software de coordenação que leva a seus próprios produtos, a dependência tecnológica se transforma em uma relação de controle.

Financiamento verificado de pelo menos US$ 55 milhões, mas a economia da saída permanece desconhecida

O financiamento confirmado inclui a Série A de US$ 25 milhões em abril de 2021 e a Série B de US$ 30 milhões em 2022. Os materiais existentes não fornecem tabela de capitalização auditada, valuation, acordos de dívida ou financiamento subsequente.

O valor da aquisição não foi divulgado nem verificado de forma independente. Sem o preço, o resultado não pode ser responsavelmente classificado como prêmio estratégico, aquisição de tecnologia comum, aquisição de talentos ou transação de dificuldade. A continuidade da integração da tecnologia indica que ela tem valor, mas não revela o retorno real para investidores e fundadores.

Também não se pode atribuir a receita e o tamanho de mercado da Palo Alto Networks à Prosimo. Após a aquisição, a Prosimo deixou de ser uma unidade econômica observável separadamente; não há receita, lucro ou segmento de clientes independentes para análise. Um proprietário maior pode ampliar o uso da tecnologia, ao mesmo tempo em que torna sua economia individual mais opaca.

A ausência de um anúncio formal de aquisição é, por si só, um fato importante. Normalmente, clientes, funcionários e pesquisadores usam anúncios para avaliar o momento, o suporte e a lógica estratégica. Aqui, o status teve que ser reconstruído a partir de perfis profissionais, do rótulo de status da empresa e de declarações posteriores do cofundador. Isso é suficiente para corrigir a identidade corporativa, mas não para inventar os termos da transação.

A competição vinha de plataformas especializadas, serviços nativos da nuvem e engenharia interna

A Prosimo enfrentava plataformas especializadas de rede multicloud, como Aviatrix e Alkira, fornecedores de rede empresarial e SASE, e os serviços nativos da AWS, Azure e Google Cloud. Também competia com o modelo de construção própria das empresas: usar diretamente infraestrutura como código, serviços de trânsito da nuvem, tabelas de roteamento e firewalls. Diferentes alternativas resolvem partes diferentes do mesmo problema.

Controladores especializados oferecem topologia e política unificadas entre nuvens; o design nativo da nuvem reduz a dependência de terceiros e se aproxima de um único fornecedor; os serviços de operadoras fornecem transporte físico; as plataformas SASE ou de segurança combinam conectividade e execução; a engenharia interna troca custos de pessoal e integração por controle.

O diferencial da Prosimo era a combinação de trânsito de aplicação e rede, bordas distribuídas, orquestração nativa da nuvem, topologia, telemetria e inserção de serviços. A mesma amplitude também dificulta a comparação. Os compradores precisam testar os serviços de nuvem, o roteamento, a identidade e os modelos de segurança que realmente usam, em vez de apenas comparar nomes de categorias.

A aquisição muda o quadro competitivo. A Prosimo não precisa mais vencer como empresa independente; sua tecnologia precisa provar valor dentro da Palo Alto Networks. A comparação principal passa a ser: a descoberta integrada e a orquestração de roteamento melhoram a implantação dos produtos de segurança da Palo Alto, e os clientes aceitam o aumento da dependência da plataforma resultante.

Os serviços nativos da nuvem são tanto base quanto substitutos

O AWS Cloud WAN, o Transit Gateway, o Azure Virtual WAN e as capacidades de rede do Google Cloud oferecem opções nativas poderosas para as empresas. A Prosimo dependia deles, ao mesmo tempo que competia com a alternativa de os clientes os operarem diretamente.

Essa fronteira está em constante movimento. À medida que os provedores de nuvem adicionam roteamento global, segmentação, serviços privados ou políticas centrais, parte da funcionalidade de terceiros se torna mais fácil de replicar nativamente; ao mesmo tempo, cada novo serviço nativo gera novos objetos que precisam ser descobertos e coordenados por um controlador entre nuvens. O avanço da nuvem pode reduzir parte do valor da Prosimo, mas também pode ampliar a necessidade de tradução entre fornecedores.

O fator determinante, novamente, é a capacidade organizacional. Empresas com uma única nuvem e engenharia interna forte podem preferir ferramentas nativas; empresas multicloud com equipes fragmentadas podem precisar de uma camada de controle unificada; organizações reguladas podem valorizar evidências de terceiros, mas se preocupar com a concentração de credenciais e dados.

Nenhuma arquitetura elimina totalmente o lock-in. As ferramentas nativas dependem das APIs e da semântica de uma nuvem específica; os controladores entre nuvens dependem de seu mapa, políticas e bordas. A verdadeira pergunta é: a dependência é transparente, portável e compatível com o modelo operacional da organização.

As falhas podem ocorrer no controlador, nas bordas, nas APIs da nuvem, no sistema de identidade ou na rede subjacente

A arquitetura distribuída reduz a dependência de um único centro de tráfego, mas cria vários domínios de falha que interagem. O serviço central pode ficar indisponível ou manter intenções desatualizadas; as bordas podem falhar ou ficar isoladas; as APIs da nuvem podem rejeitar mudanças parciais; o sistema de identidade pode falhar; o underlay pode degradar ou redirecionar; os firewalls inseridos podem esgotar recursos.

Falhas parciais são especialmente difíceis. Uma nuvem aceita a atualização de roteamento, outra a rejeita, fazendo com que o estado esperado pelo controlador se separe do estado real; o tráfego pode tomar caminhos assimétricos ou contornar a inspeção. Um sistema confiável precisa de reconciliação, operações idempotentes, mudanças em fases, erros explícitos e reversão adaptada a cada fornecedor.

As evidências públicas descrevem alta disponibilidade e arquitetura otimizada em alto nível, mas não há estudos independentes de injeção de falhas, registros completos de incidentes ou resultados de serviço generalizados. Portanto, as conclusões de resiliência devem ser limitadas ao escopo da arquitetura documentada ou das evidências de clientes nomeados.

A aquisição adiciona um novo domínio de falha: a continuidade do produto. Os clientes precisam saber qual console, API, imagem de borda, modelo de política e organização de suporte substituem os sistemas históricos da Prosimo. Mesmo que a integração de código seja tecnicamente bem-sucedida, a falta de clareza nas fronteiras comerciais e operacionais gera risco de migração.

As credenciais de nuvem colocam o controlador dentro do plano de gestão crítico

A descoberta de ativos e a orquestração exigem acesso às contas da nuvem. Um inventário somente leitura pode usar permissões limitadas, mas mudanças de roteamento, segmentação e inserção de serviços exigem permissões mais fortes. Assim, o controlador, embora não possua as cargas de trabalho, está posicionado dentro de um plano de gestão com altos privilégios.

O vazamento de credenciais pode expor a topologia ou permitir mudanças generalizadas; um defeito de software ou erro operacional pode propagar políticas por várias nuvens. Quanto mais contas e serviços a plataforma governar, maior será o raio potencial de falha.

As empresas precisam de funções com privilégio mínimo, usando credenciais separadas para descoberta e gravação, exigindo aprovação por múltiplas pessoas, auditoria completa, rotação, revogação de emergência e mantendo caminhos de recuperação independentes do mesmo controlador. Os materiais públicos não contêm avaliações de segurança independentes completas, de modo que esses são controles de implantação necessários, não garantias verificadas.

O mapa de telemetria é igualmente sensível. Ele pode expor nomes de aplicações, estrutura de rede, políticas, relações de usuário, saúde de roteamento e padrões de custo. A governança pós-aquisição deve esclarecer onde esses dados residem, quais produtos da Palo Alto Networks podem acessá-los e como as permissões históricas dos clientes são migradas. Os materiais públicos ainda não responderam a essas questões.

A aquisição colocou uma camada de controle vista como neutra dentro de uma plataforma de segurança

A Prosimo, quando independente, podia se descrever como uma camada de controle comum entre nuvens e entre serviços de segurança. Com a Palo Alto Networks como proprietária, a estrutura de incentivos mudou. A aquisição da tecnologia pode facilitar a implantação do VM-Series e de outros produtos Palo Alto. Isso pode resultar em integração mais estreita, mas também levanta a questão sobre se os serviços de inspeção de terceiros continuam a receber suporte igual.

A mudança de propriedade não prova que a neutralidade desapareceu. Os materiais existentes não contêm a matriz de parceiros atual ou a arquitetura completa. Mas as perguntas que os clientes precisam fazer mudaram: o controlador continua a suportar vários fornecedores de segurança? As políticas e a telemetria são exportáveis? A lógica de otimização prioriza o portfólio de produtos do proprietário?

A declaração de integração enfatiza a inspeção de entrada, saída e leste-oeste. Isso sugere que a topologia e a orquestração da Prosimo podem se tornar parte do sistema de implantação de segurança, mas não prova que o histórico App Transit, o acesso de usuário, a otimização de custos e todos os fluxos de trabalho de rede em nuvem continuem como funções independentes.

Esse é um padrão comum na infraestrutura: uma startup abstrai um problema complexo de coordenação; uma grande plataforma compra essa camada de abstração para aumentar a implantação e o controle de seus produtos principais. Os clientes podem ganhar melhor integração, mas perdem parte da independência de fornecedor.

O mapeamento atual de produtos é a maior informação ausente

Os registros públicos confirmam a aquisição e a integração, mas não especificam a quais produtos ou SKUs atuais da Palo Alto Networks correspondem o AXI, o Network Transit, o App Transit, o AIR e o Nebula. Também não divulgam o prazo de suporte dos sistemas antigos, o processo de migração ou uma tabela de continuidade funcional detalhada.

Portanto, é impossível fazer uma avaliação de produto no tempo presente. Os materiais históricos podem explicar o que a Prosimo construiu e por que era importante, mas não podem dizer quais capacidades estão disponíveis hoje, como são licenciadas ou por quem são suportadas. Qualquer recomendação de implantação atual deve depender da documentação atual da Palo Alto Networks, e não de anúncios arquivados.

A ausência de mapeamento também limita a análise estratégica. Absorver completamente o mapa topológico e a camada de orquestração é diferente de usar apenas a descoberta de ativos e o posicionamento de firewall. O primeiro pode formar um amplo serviço de controle multicloud; o segundo serve principalmente para acelerar a implantação de segurança. A declaração do cofundador confirma a continuidade da tecnologia, mas não resolve essa fronteira arquitetural.

Documentação futura de produtos, guias de migração ou casos de clientes poderão esclarecer a maioria das questões. Até lá, a formulação precisa é: de acordo com um cofundador, a tecnologia da Prosimo foi integrada aos produtos da Palo Alto Networks, mas o escopo e a embalagem ainda não foram verificados publicamente.

Quem controla o roteamento multicloud?

Nenhuma parte controla sozinha o caminho completo. A empresa controla a propriedade das contas, a intenção de negócio, o design da aplicação e as credenciais concedidas. O controlador entre nuvens pode descobrir a topologia, traduzir políticas, escolher caminhos e modificar o estado de roteamento nativo. Os provedores de nuvem controlam as APIs, os serviços de trânsito, os pontos de extremidade privados, o backbone e uma grande quantidade de domínios de falha; operadoras e serviços gerenciados controlam outras partes do transporte; os serviços de segurança decidem se o tráfego inspecionado é permitido.

A Prosimo buscava a posição intermediária mais estrategicamente valiosa. Ela não possuía o underlay, mas tentava dominar o mapa e a tradução de políticas sobre ele. Quem controla essa camada pode decidir quais ativos são visíveis, como os segmentos são representados, onde as bordas são colocadas, qual serviço inspeciona o tráfego e qual telemetria é considerada autoritativa. Mesmo que a fibra pertença a outros, isso constitui uma autoridade de roteamento real.

Após a aquisição, a Palo Alto Networks é proprietária da tecnologia remanescente da Prosimo e decide sua integração, embalagem comercial e direção de desenvolvimento. Os provedores de nuvem ainda mantêm predominância em seus respectivos ambientes, e a empresa pode revogar credenciais ou escolher outras arquiteturas; mas se a topologia, as políticas e os fluxos de trabalho operacionais dependerem do controlador, os custos de saída podem ser altos.

Portanto, a resposta é em camadas: a empresa autoriza, o controlador coordena, o underlay da nuvem e das operadoras transporta, e a plataforma de segurança executa. A história da Prosimo mostra que, mesmo sem a transferência das contas de nuvem e dos caminhos físicos, a propriedade da camada de coordenação pode mudar.

Principais fontes

Por que a Prosimo pós-aquisição ainda merece atenção

A Prosimo capturou uma mudança real. As unidades de operação de rede estão migrando de dispositivos e prefixos para aplicações, identidades, dependências de serviços e mapas de políticas. As APIs nativas da nuvem tornam o estado da rede programável, e as bordas de software distribuídas tornam a localização da execução móvel. Um controlador que enxerga várias nuvens pode coordenar ações que um único console de nuvem não consegue.

A empresa também expôs o custo da coordenação: uma camada de controle comum exige credenciais de alto privilégio, manutenção contínua de APIs, descoberta precisa, tradução semântica, telemetria e disciplina operacional. Ela pode reduzir o trabalho fragmentado e, ao mesmo tempo, criar novos pontos de concentração; o mesmo sistema que simplifica o roteamento também pode amplificar o impacto de um único erro.

A aquisição pela Palo Alto Networks tornou o problema de controle ainda mais evidente. Rede e segurança estão convergindo em torno da inserção de serviços, da descoberta de cargas de trabalho e das políticas. Um fornecedor de segurança que entende a topologia e pode modificar o roteamento não apenas inspeciona o tráfego que lhe é enviado, mas também ajuda a decidir qual tráfego chega ao ponto de inspeção e onde ele é inspecionado.

Portanto, a Prosimo não deve ser lembrada apenas como uma marca independente que desapareceu, nem como prova de que uma plataforma já resolveu o problema multicloud. Sua contribuição duradoura é ter definido o mapa entre nuvens como infraestrutura. A pergunta que resta é: esse mapa, agora dentro de uma grande empresa de segurança, permanece suficientemente transparente, portável e governável para merecer a confiança dos clientes.