Resumo

  • A Prosimo foi fundada em 2019 e captou pelo menos US$ 55 milhões nas rodadas de financiamento Série A de 2021 e Série B de 2022; dados de receita auditados e informações sobre avaliação e preço de aquisição permanecem não divulgados
  • O AXI combinava políticas centrais, topologia e análise com Edges distribuídos que capturavam recursos de nuvem, conectavam aplicações e inseriam serviços de segurança, sem possuir o backbone físico
  • Após a integração da VM-Series anunciada em junho de 2024, a transição da Prosimo para a Palo Alto Networks ocorreu por volta de fevereiro de 2025; a data exata, o preço e o mapeamento atual do produto não são comprovados
  • O controle continua distribuído entre empresas, software de orquestração, provedores de nuvem e a Palo Alto Networks; portanto, é crucial se a topologia, as credenciais de acesso, as políticas e as prerrogativas de roteamento permanecem portáteis

A marca desapareceu, o problema permaneceu

Em 2026, a Prosimo não pode mais ser descrita como um fornecedor ativo e independente. Perfis profissionais públicos mostram que os fundadores e vários funcionários se transferiram para a Palo Alto Networks por volta de fevereiro de 2025. O perfil corporativo da Prosimo está marcado como adquirido, e o ex-Chief Technology Officer Nehal Bhau escreveu posteriormente que a tecnologia havia sido integrada aos produtos da Palo Alto Networks. As evidências indicam uma mudança de controle e um valor técnico contínuo. Não comprovam a data exata de assinatura ou fechamento, nem a forma jurídica ou o preço da transação.

Essa classificação deve vir no início, pois altera o tempo verbal de qualquer afirmação sobre o produto. AXI, Network Transit, App Transit, Application-driven Intelligent Results e Nebula eram funcionalidades documentadas da Prosimo durante sua fase independente. Não devem ser apresentadas como produtos ainda comercializados separadamente, enquanto a Palo Alto Networks não publicar um mapeamento atual de produtos e suporte. Uma arquitetura histórica pode, após uma aquisição, persistir como código incorporado, serviço compartilhado, módulo ou ativo de engenharia interno; essas formas não são equivalentes.

O desaparecimento da marca não torna o problema subjacente obsoleto. As empresas continuam distribuindo cargas de trabalho entre Amazon Web Services, Microsoft Azure, Google Cloud, datacenters privados, locais de colocation, plataformas de Software as a Service e usuários remotos. Cada ambiente possui rotas, gateways, endpoints privados, controles de identidade, serviços de segurança, cotas e regras de cobrança próprios. Uma empresa pode ser proprietária das contas e, ainda assim, não ter uma visão unificada de como uma solicitação transita entre os ambientes.

A importância da Prosimo reside na tentativa de reunir essa visão em uma camada de controle comum.

A aquisição constitui, portanto, o núcleo da narrativa, e não apenas um epílogo. A Prosimo construiu uma camada de controle multinuvem capaz de detectar recursos, avaliar o contexto da aplicação e direcionar o tráfego através de serviços de segurança. A Palo Alto Networks inicialmente atuou como parceira técnica, cujos firewalls VM-Series podiam ser inseridos nesses caminhos. Posteriormente, a Palo Alto Networks adquiriu a tecnologia. Com isso, a fronteira entre a orquestração de roteamento e a inspeção profunda de segurança se deslocou para uma única plataforma de cibersegurança.

No roteamento multinuvem, o contexto é decisivo

Uma tabela de roteamento pode responder se um prefixo é alcançável via um determinado próximo salto. Sozinha, ela não explica qual aplicação um usuário pretendia acessar, se o solicitante é confiável, se um serviço de inspeção precisa ver o tráfego, se um endpoint privado está disponível, se um caminho na nuvem é mais caro que outro ou se uma transação falha após a entrega do pacote. A operação multinuvem transforma essas perguntas em um problema de controle comum.

A tese da Prosimo era que as decisões de roteamento deveriam se basear em mais do que a alcançabilidade na camada 3. O software tentava combinar inventário de nuvem, estado da rede, identidade da aplicação, identidade do usuário, risco, desempenho e telemetria de transações. Esse contexto mais amplo permitia políticas que conectassem uma aplicação específica, isolassem um segmento, escolhessem um ponto de entrada ou direcionassem tráfego selecionado através de um firewall. O valor não vinha de um novo caminho de fibra, mas da decisão de como compor caminhos e serviços existentes.

Essa diferença explica a expressão "application experience infrastructure". O termo colocava a solicitação da aplicação no centro, não o objeto de rede individual. Uma VPC, uma VNet, uma sub-rede, um hub de trânsito ou um link privado tornava-se um componente de um caminho ponta a ponta, não o último objeto de gerenciamento. A abordagem também posicionava o produto em múltiplos mercados: redes na 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 amplitude gerava oportunidades e imprecisão. Um produto que toca várias equipes pode resolver problemas de coordenação pelos quais nenhuma equipe isolada se sente responsável. No entanto, é mais difícil de avaliar, porque equipes de rede, segurança, nuvem, aplicações e finanças definem sucesso de maneiras diferentes. A Prosimo precisava demonstrar que um modelo multinuvem melhorava as operações sem criar mais uma camada privilegiada cujas falhas afetassem todos os ambientes.

O que era a Prosimo e o que restou

A Prosimo era uma empresa privada de software de redes na nuvem, fundada em 2019 na área da baía de São Francisco. Ramesh Prabagaran foi cofundador e Chief Executive Officer, enquanto Nehal Bhau atuou como cofundador e Chief Technology Officer durante a fase independente. Perfis públicos também mencionam Linus Aranha e Pradeep Aragonda em funções de fundação ou liderança de engenharia; no entanto, seus títulos exatos devem ser vinculados a biografias datadas.

A plataforma principal chamava-se Application eXperience Infrastructure, geralmente abreviada como AXI. O AXI utilizava uma camada central de software para políticas, topologia, análise e orquestração, além de Edges AXI distribuídos em regiões de nuvem, ambientes de colocation ou infraestrutura on-premises adjacente. Posteriormente, a Prosimo estruturou a oferta como Full-Stack Cloud Transit, com Network Transit e App Transit cobrindo diferentes classes de conectividade. O AIR analisava telemetria e fornecia insights 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 passar pelos backbones dos provedores de nuvem, pela internet pública, por conexões diretas, links de colocation e redes corporativas. A Prosimo também não era um fornecedor de firewall no mesmo sentido que a Palo Alto Networks. Seu papel na integração de 2024 era a descoberta de recursos, segmentação e direcionamento de tráfego; a VM-Series realizava a inspeção profunda de segurança.

Após a aquisição, "continuidade tecnológica" é a descrição mais precisa. A declaração posterior de integração destacou a descoberta de recursos multinuvem e a implantação mais rápida de firewalls de software para inspeção de entrada, saída e leste-oeste. Isso comprova que componentes importantes da Prosimo persistem. Não comprova que todo o catálogo histórico do AXI, a embalagem comercial ou o modelo de suporte tenham sido mantidos inalterados.

O problema depois do SD-WAN

A equipe fundadora trouxe experiência em redes de grande escala, entrega de aplicações e infraestrutura de nuvem. A Prosimo também surgiu do ecossistema mais amplo de fundadores e engenheiros da Viptela, a empresa que ajudou a estabelecer o SD-WAN como categoria empresarial. O problema seguinte, no entanto, estava em outro lugar. O SD-WAN podia simplificar como as filiais alcançavam redes e aplicações, mas não criava um modelo operacional unificado dentro e entre múltiplas nuvens públicas.

Uma aplicação multinuvem pode depender de um endpoint web em um ambiente, um banco de dados ou serviço gerenciado em outro, um provedor de identidade externo, uma conexão de data center privado e inspeção de segurança em pontos selecionados. Cada dependência pode aparecer como um objeto nativo diferente. A equipe de rede vê prefixos e hubs de trânsito; a equipe de nuvem vê contas e objetos de recursos; o responsável pela aplicação vê domínios e transações; a equipe de segurança vê zonas e políticas de inspeção.

A Prosimo começava pela solicitação, não pela filial. O ponto crucial era como um usuário ou carga de trabalho deveria alcançar uma aplicação com segurança, desempenho, disponibilidade e custo aceitáveis. Isso deslocava o objeto da decisão de roteamento do prefixo de destino isolado para uma transação com contexto de identidade e aplicação. Ao mesmo tempo, a plataforma precisava coletar e manter muito mais informações do que um roteador convencional.

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

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

A Prosimo foi fundada em 2019, mas só anunciou seu lançamento público em 6 de abril de 2021. A General Catalyst liderou uma Série A de US$ 25 milhões. O investidor descreveu a oportunidade como oferecer uma experiência de aplicação consistente em múltiplas nuvens; isso correspondia à tentativa dos fundadores de definir uma categoria além da conectividade tradicional de filiais.

O lançamento no mercado introduziu a empresa em um segmento densamente povoado e ainda não esclarecido. Os provedores de nuvem facilitavam o consumo de seus próprios serviços de rede. Fornecedores de SD-WAN e SASE estendiam políticas para ambientes de nuvem. Fornecedores de entrega de aplicações podiam otimizar solicitações, empresas de segurança de rede podiam inspecioná-las. O argumento da Prosimo baseava-se em conectar essas funções em uma arquitetura orientada para a nuvem, sem afirmar substituir cada sistema circundante.

O financiamento criou espaço para integrações, edges de software, análises, uma organização de vendas e relacionamentos com parceiros. Não comprovou product-mercados e setores fit, dimensão de receita ou diferenciação duradoura. As evidências fornecidas não contêm dados de receita auditados, nem informações sobre Receita Recorrente Anual, número de clientes ou avaliação. O histórico de financiamento mostra confiança dos investidores numa tese, não o desempenho operacional completo.

Em 2022, a Prosimo fechou uma Série B de US$ 30 milhões, descrita como excesso de demanda. As duas rodadas claramente identificadas totalizam um financiamento verificado de pelo menos US$ 55 milhões. Alguns bancos de dados podem mostrar um valor mais alto se contarem anúncios ou registros relacionados em duplicidade; esses totais não devem ser usados sem desagregar os eventos subjacentes.

AXI estabeleceu políticas sobre as nuvens e execução próxima às cargas de trabalho

A arquitetura AXI distribuía tarefas entre uma camada central de controle e análise e edges de software distribuídos. A camada central gerenciava políticas de aplicação e rede, descobria recursos, consolidava a topologia, integrava identidade, analisava telemetria e orquestrava mudanças. Os Edges AXI eram posicionados próximos às cargas de trabalho ou usuários para que as políticas fossem aplicadas sem forçar cada caminho a passar por um hub físico remoto.

A separação se assemelha a outros sistemas definidos por software, mas os objetos eram específicos da nuvem e orientados à aplicação. O controlador precisava de acesso a contas de nuvem e APIs, enquanto o Edge precisava de conectividade com serviços de trânsito nativos, redes de carga de trabalho, endpoints privados ou caminhos externos. A autoridade da plataforma surgia da combinação de ambas as visões: políticas globais acima das nuvens e execução local próxima ao tráfego relevante.

A arquitetura também criava uma fronteira prática de implantação. Cada Edge consumia recursos de nuvem, exigia design de alta disponibilidade e precisava ser atualizado, monitorado e protegido. A camada de controle precisava de credenciais com privilégios suficientes para descobrir recursos e alterar o estado da rede. O cliente ganhava um fluxo de trabalho comum, mas acrescentava um sistema de gerenciamento cuja disponibilidade e correção eram críticas para a alcançabilidade das aplicações produtivas.

A Prosimo às vezes usava o termo "autonomous cloud networking". São comprovadas automação, recomendações e orquestração baseada em API. Não é comprovada uma rede que opere independentemente de políticas humanas, serviços dos provedores de nuvem ou do transporte subjacente. Os operadores continuavam definindo políticas, aprovando acessos, tratando exceções e assumindo a responsabilidade pelo resultado.

Um Edge AXI era uma decisão de posicionamento, não um appliance comum

Um Edge AXI podia ser implantado em uma VPC ou VNet da nuvem, em um ambiente de colocation ou em infraestrutura adjacente. A documentação técnica da AWS mostrava uma Edge VPC conectada via Transit Gateway a VPCs de carga de trabalho, com encadeamento opcional de firewall e acesso de usuários remotos ou locais on-premises. O design posicionava o ponto de execução da Prosimo dentro da topologia da nuvem, não em um perímetro corporativo remoto.

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

O posicionamento distribuído aumentava o número de domínios de falha a gerenciar. Capacidade, versões de software, design de zonas de nuvem, convergência de rotas e direitos de acesso podiam variar por região. Alta disponibilidade significava mais do que duas instâncias: o controlador, as tabelas de roteamento da nuvem, os serviços de segurança e os caminhos de retorno também precisavam formar um estado de failover consistente.

O Edge era, portanto, parte de um sistema operacional mais amplo. Seu valor dependia de que a descoberta de recursos, a topologia, as políticas e as análises permanecessem consistentes com o ambiente de nuvem circundante. Vê-lo como um appliance virtual autônomo é perder a arquitetura que a Prosimo queria vender.

A rede subjacente permaneceu em mãos alheias

A Prosimo coordenava o transporte, mas não possuía a rede subjacente nem o caminho físico. Um caminho de aplicação podia usar o backbone da AWS ou de outro provedor de nuvem, a internet pública, Direct Connect ou ExpressRoute, colocation, uma conexão de operadora ou uma rede corporativa. A plataforma podia escolher entre opções disponíveis e orquestrá-las; não podia eliminar latência, perda de pacotes, domínios de falha ou modelos de preço desses provedores.

Esse limite é crucial para afirmações de desempenho. Um controlador pode escolher um caminho observavelmente melhor ou aproximar a entrada do usuário. Não pode garantir que uma operadora não falhe, que uma região de nuvem permaneça disponível ou que uma dependência externa responda rapidamente. A experiência da aplicação também inclui DNS, processamento do servidor, armazenamento, comportamento do navegador e serviços de terceiros fora do controle direto do controlador de rede.

A falta de um backbone proprietário não era apenas uma fraqueza. A Prosimo podia usar infraestrutura que as empresas já pagavam e se beneficiar dos investimentos dos provedores de nuvem. Podia alcançar regiões sem construir fibra própria e coordenar sistemas nativos como o AWS Cloud WAN. O preço era a dependência da estabilidade das APIs, cotas de serviço, condições comerciais e semântica específica do provedor.

A pretensão da plataforma era, portanto, controle operacional, não propriedade física. Ela deveria unificar underlays heterogêneos em um sistema gerenciado, preservando suas vantagens nativas. Se a abstração reduzia o lock-in ou apenas o deslocava, dependia da portabilidade de políticas, topologia e implantação de Edge.

Network Transit regulava a alcançabilidade entre objetos de rede

O Network Transit concentrava-se em VPCs, VNets, sub-redes, regiões, locais e segmentos. Coordenava objetos nativos de trânsito e roteamento na nuvem para que as equipes pudessem construir conectividade por meio de um fluxo de trabalho comum, em vez de configurar cada provedor separadamente. O produto atendia ao requisito de rede convencional: um prefixo ou segmento de origem deve alcançar um destino por um caminho permitido.

Isso não afirmava que as diferenças entre nuvens desapareciam. AWS, Azure e Google Cloud fornecem objetos, cotas e comportamentos de roteamento diferentes. Espaços de endereçamento sobrepostos, caminhos assimétricos, endpoints privados e limites específicos de cada provedor ainda exigiam engenharia. A Prosimo podia normalizar operações comuns e mostrar relacionamentos; os sistemas subjacentes mantinham suas próprias restrições.

O Network Transit também realizava 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 de nuvens e como os objetos nativos implementavam a fronteira. Uma política formulada uma vez ainda podia desencadear várias alterações específicas do provedor.

A vantagem era uma superfície unificada para definição de políticas. O risco estava na tradução entre o modelo comum e as configurações nativas da nuvem. Se a política comum e a configuração da nuvem divergissem, a empresa poderia considerar um segmento protegido enquanto o estado do provedor indicasse o contrário. A reconciliação, auditoria e mensagens de erro claras eram, portanto, tão importantes quanto o fluxo de trabalho inicial de provisionamento.

App Transit tornou a aplicação o objeto da decisão de roteamento

O App Transit expandia o modelo para além das sub-redes. Ele podia incorporar domínio da aplicação, identidade, tipo de solicitação, estado da transação, risco e desempenho na decisão sobre como um usuário ou carga de trabalho alcançava um serviço. Essa era a tentativa mais clara da Prosimo de diferenciar a plataforma de um roteador de nuvem convencional.

A visão da aplicação era útil porque os serviços modernos nem sempre são representados de forma limpa por endereços fixos. Serviços gerenciados, endpoints SaaS e componentes distribuídos podem mudar, enquanto a identidade da aplicação permanece significativa. Uma política que referencia um serviço ou usuário pode ser mais estável do que uma regra baseada apenas em endereços e portas.

O modelo exigia um mapeamento preciso. O controlador precisava saber quais domínios e endpoints pertenciam a uma aplicação, quais dependências eram necessárias e em quais asserções do provedor de identidade se podia confiar. Um mapeamento desatualizado poderia direcionar uma solicitação pelo caminho errado ou aplicar a regra de segurança incorreta. A abstração da aplicação não eliminava a necessidade de entender o estado da rede; apenas acrescentava outra camada semântica.

A combinação de Network Transit e App Transit reconhecia que ambos os mundos coexistem nas empresas. Sistemas legados, sub-redes privadas e controles baseados em IP permanecem, enquanto aplicações mais novas dependem de domínios, identidade e serviços gerenciados. Full-Stack Cloud Transit era o nome do produto para a operação conjunta desses modelos, não para a substituição de um pelo outro.

Identidade ampliava a decisão de roteamento e a fronteira de confiança

O acesso orientado à aplicação exigia integração de identidade. A plataforma podia usar o contexto do usuário ou da carga de trabalho para decidir se e como uma conexão deveria ser estabelecida. Isso apoiava uma política Zero Trust, na qual apenas a localização não constituía prova suficiente de autoridade.

A identidade aumentava a precisão e criava outra dependência. A política de roteamento ou de aplicação passava a depender do provedor de identidade, suas asserções, o estado da sessão e os dados de grupo. Um caminho de rede podia falhar devido à indisponibilidade da autenticação ou a um atributo alterado, mesmo que roteadores e Edges funcionassem corretamente. A solução de problemas precisava cruzar a fronteira entre operação de rede e identidade.

O controlador também se tornava um ponto de concentração de contexto sensível. Ele podia armazenar topologia, relacionamentos de aplicações, atributos de usuário, sinais de risco e resultados de políticas. Esse conjunto de dados melhorava o diagnóstico e a otimização, mas ampliava as consequências de um acesso não autorizado. Privilégio mínimo, retenção, auditoria e segregação de funções eram, portanto, requisitos arquiteturais, não acréscimos administrativos.

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

A descoberta de recursos criou o grafo do qual todas as decisões subsequentes dependeram

Um controlador multinuvem não pode gerenciar o que não vê. A Prosimo desenvolveu descoberta de ativos na nuvem e mapas para VPCs, VNets, sub-redes, aplicações, conectividade e relacionamentos de segurança. Essas visões apoiavam o onboarding, design, solução de problemas e políticas.

A coleta era estrategicamente importante porque as paisagens de nuvem mudam fora dos fluxos de trabalho centrais de rede. As equipes de aplicações podem criar contas, redes, endpoints e serviços gerenciados por meio de sua própria automação. Diagramas mantidos manualmente tornam-se obsoletos. Um inventário baseado em API pode gerar um grafo mais atualizado, mas sua integridade depende da cobertura de contas, permissões, lógica de análise e APIs do provedor.

O grafo não era apenas documentação. Era a estrutura de dados a partir da qual o roteamento, a segmentação, a inserção de serviços e a otimização eram calculados. Se faltasse um recurso ou dependência, todas as conclusões superiores poderiam estar erradas. A topologia, portanto, precisava de metadados de proveniência: momento da coleta, conta de origem, regiões cobertas e solicitações com falha.

O grafo também ajuda a explicar a aquisição. A Palo Alto Networks pode criar valor adicional de segurança se souber onde estão as cargas de trabalho e os caminhos de tráfego. Um sistema que descobre recursos de nuvem e pode alterar rotas encurta o caminho entre a compra de um firewall de software e seu posicionamento correto. Bhau posteriormente destacou explicitamente a descoberta de recursos e a implantação acelerada de firewalls de software.

AIR extraía recomendações operacionais da telemetria dos Edges

Application-driven Intelligent Results, ou AIR, analisava a telemetria dos Edges AXI. A documentação da AWS descrevia insights sobre tempo de ida e volta, tempo de processamento, tempo de resposta da aplicação, tipo de transação, risco e resultado de política. A plataforma podia correlacionar dados de usuário, rede e aplicação, em vez de apresentar contadores de dispositivos isolados.

Essa correlação atacava um problema operacional conhecido. Uma transação lenta pode ser causada no caminho do usuário, no Edge, no backbone da nuvem, no serviço de segurança ou na própria aplicação. Uma visão entre camadas pode restringir a busca mais rapidamente do que consoles separados e 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 via apenas o tráfego que o atravessava. Dependências externas da aplicação e estados internos do provedor podiam permanecer invisíveis. Uma recomendação podia indicar a direção sem provar a causa.

A telemetria também tinha valor de governança. Observações históricas podiam explicar por que uma rota ou política havia mudado. Ao mesmo tempo, podiam revelar informações sensíveis sobre o uso da aplicação e o comportamento do usuário. O material público não descreve completamente a retenção e a governança de dados após a aquisição; esses pontos permanecem parte da due diligence dos clientes.

AWS forneceu a implementação documentada mais clara

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

O AWS Cloud WAN era particularmente significativo. Ele fornecia um backbone nativo da nuvem e um serviço de segmentação que a Prosimo podia orquestrar em vez de substituir. Essa arquitetura demonstrava o modelo cooperativo: a AWS possuía a rede nativa e a infraestrutura global; a Prosimo fornecia políticas multinuvem, contexto de aplicação, software de Edge e análise.

O fluxo do Marketplace simplificava a etapa inicial de implantação ao empacotar o Edge AXI por meio de um canal aprovado. O trabalho posterior em permissões de conta, design de roteamento, alta disponibilidade, capacidade e operação permanecia. A automação do dia zero pode reduzir o esforço de instalação sem eliminar o problema de controle de longo prazo.

Uma referência nominal da Flexport apoiava o caso de uso do AWS Cloud WAN em material corporativo. Ela comprova que um cliente empresarial apoiava publicamente a arquitetura, mas não é uma auditoria independente de escopo, economia ou disponibilidade. Os depoimentos de clientes devem, portanto, servir como exemplos de adoção, e não como prova geral de desempenho.

Azure e Google Cloud completavam a oferta multinuvem

A Prosimo também oferecia suporte ao Microsoft Azure e ao Google Cloud. O material do produto descrevia a orquestração do Azure Virtual WAN, bem como objetos de rede e serviço privado do Google Cloud. O objetivo era um modelo operacional comum, enquanto a rede nativa de cada provedor permanecia intacta.

O suporte a essas plataformas não prova funcionalidades idênticas. As APIs de nuvem amadurecem em ritmos diferentes, e nomes de produtos comparáveis podem ocultar semânticas distintas. Rotas, segmentos, endpoints privados e inserção de serviços podiam exigir tratamento específico do provedor. As evidências disponíveis não permitem uma matriz completa de comparação funcional para todas as regiões e releases.

A abstração multinuvem é melhor entendida, portanto, como um sistema de tradução. Ela pode padronizar políticas e fluxos de trabalho comuns, mas deve preservar os detalhes que afetam segurança, custos e falhas. Uma plataforma se torna arriscada quando a superfície parece uniforme e as diferenças de implementação permanecem ocultas dos operadores.

O mesmo se aplica após a aquisição. A Palo Alto Networks pode usar o grafo comum para posicionar controles de segurança em várias nuvens, mas os provedores de nuvem continuam controlando os objetos nativos que implementam o caminho. A propriedade da camada de orquestração não cria propriedade da infraestrutura subjacente da nuvem.

O produto evoluiu de conectividade para um modelo de ciclo de vida

Até 2023, a Prosimo descrevia fluxos de trabalho para projeto, construção, solução de problemas e operação de redes multinuvem. O produto ia além da configuração de túneis ou gateways individuais. A descoberta de recursos apoiava o design; a orquestração criava conectividade; mapas e telemetria ajudavam na solução de problemas; políticas e estados históricos apoiavam o gerenciamento contínuo.

A perspectiva de ciclo de vida ampliava o círculo de potenciais compradores. Engenheiros de rede podiam usar topologia e análise de caminho; equipes de plataforma de nuvem, integrar contas e serviços; equipes de segurança, verificar segmentação e inspeção; equipes de migração, planejar mudanças; equipes de FinOps, examinar impactos de roteamento e saída. O valor da plataforma aumentava quando vários grupos acessavam a mesma base de dados.

Uma base de dados comum pode gerar conflitos de governança. Uma plataforma central pode mostrar que a configuração nativa de uma equipe de nuvem diverge da política corporativa. A organização precisa decidir qual sistema é autoritativo e quem aprova a correção. O software sozinho não resolve essa questão institucional.

O modelo de ciclo de vida também aumentava os custos de troca. Se um controlador gerencia o grafo de ativos, as políticas, a telemetria, o posicionamento dos Edges e as integrações de automação, sua substituição exige mais do que alternar uma conexão. O cliente precisa exportar ou reconstruir o modelo operacional. A Prosimo prometia reduzir a fragmentação da nuvem e, ao mesmo tempo, criava a possibilidade de uma dependência do controlador.

Segmentação ia de alcançabilidade de rede até política de aplicação

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

O modelo em camadas podia reduzir a lacuna entre zona de rede e política de aplicação. Um serviço de negócios podia ser permitido, embora a alcançabilidade ampla entre sub-redes permanecesse bloqueada. Inversamente, um caminho de rede alcançável podia ser negado se a identidade ou o contexto da aplicação não correspondessem.

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

Um segmento só é eficaz se todos os caminhos relevantes forem representados. Uma rota desconhecida, uma exceção nativa da nuvem ou uma falha na inserção de serviço podem contornar o controle pretendido. A segurança, portanto, exigia a comparação da política declarada com o estado real no provedor de nuvem e o tráfego observado; apenas a visão de configuração do controlador não era suficiente.

Inserção de serviço conectava o controle de roteamento à economia dos firewalls

Ao projetar a segurança na nuvem, é preciso decidir onde a inspeção ocorre. Firewalls centralizados podem simplificar políticas e reduzir o número de appliances, mas geram backhaul, concentração e pressão de escala. Firewalls distribuídos permanecem mais próximos das cargas de trabalho e reduzem distorções de caminho, mas multiplicam a implantação, o licenciamento, as atualizações e a operação de políticas.

A Prosimo apoiava ambos os padrões na integração com a VM-Series. As políticas podiam direcionar tráfego selecionado através de um ponto de inspeção central ou por firewalls distribuídos nas VPCs de aplicação. O controlador atualizava as rotas circundantes, enquanto a Palo Alto Networks fornecia a função de inspeção.

Isso tornava a orquestração de roteamento comercialmente valiosa para um fornecedor de segurança. Um firewall de software não pode proteger o tráfego que nunca o alcança. A descoberta de recursos, o posicionamento e as alterações de roteamento reduzem o esforço para inserir a capacidade de segurança adquirida em um caminho ativo. Essa é uma razão estratégica plausível para a Palo Alto Networks adquirir a tecnologia da Prosimo.

Ao mesmo tempo, ampliava-se o raio de impacto do controlador. Uma política defeituosa podia contornar a inspeção, criar loops, causar roteamento assimétrico ou desativar uma aplicação. Verificações de saúde do sistema, mudanças graduais, simulação, auditoria e rollback são necessários porque uma falha na inserção de serviço é simultaneamente um evento de rede e de segurança.

A parceria de 2024 não deve ser considerada retrospectivamente como uma aquisição

A Prosimo e a Palo Alto Networks anunciaram a integração da VM-Series em 12 de junho de 2024. O comunicado descrevia uma solução técnica e comercial conjunta. Não afirmava que a Palo Alto Networks havia adquirido a Prosimo. Quem trata o anúncio como prova de propriedade está fundindo dois eventos distintos.

A parceria, no entanto, criou uma ponte. A Prosimo pôde demonstrar como seu sistema de roteamento e política facilitava a implantação da VM-Series em várias nuvens. A Palo Alto Networks pôde avaliar a tecnologia em uma integração real antes da posterior transição da empresa. As evidências públicas não descrevem o processo de aquisição; afirmar que a parceria foi formalmente planejada como etapa preliminar à aquisição seria especulação.

No início de 2025, os perfis dos fundadores e funcionários haviam mudado. A página da empresa posteriormente exibia um aviso de aquisição. No final de 2025, Bhau declarou que a tecnologia havia sido totalmente integrada aos produtos da Palo Alto Networks. Em conjunto, esses documentos apoiam a conclusão de aquisição e deixam em aberto os mecanismos legais.

A 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 transferir roadmaps, dados, contratos e autoridade para uma única empresa. A transição muda mais do que a marca, mesmo que o caminho técnico inicialmente pareça semelhante.

Nebula tornou o grafo de topologia acessível por meio de uma interface de diálogo

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

O ativo valioso não era a interface de linguagem em si, mas o contexto estruturado multinuvem subjacente. Um modelo genérico não pode diagnosticar uma rota ou segmento privado que não enxerga. O Nebula podia usar o inventário de ativos, a topologia, as políticas e as observações que a Prosimo já coletava. Isso tornava o investimento anterior em um grafo comum relevante para AIOps.

O acesso baseado em diálogo podia tornar dados complexos mais acessíveis a mais operadores. Ao mesmo tempo, podia criar falsa confiança se uma resposta omitisse um ativo não suportado, interpretasse 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 mencionou possíveis melhorias, como redução de 60% a 80% no Tempo Médio de Resolução e mais de 60% de redução nos custos de rede na nuvem. Esses números eram alegações da empresa em um anúncio de produto. As evidências disponíveis não contêm uma metodologia independente nem uma linha de base do cliente que comprove validade geral. Podem ser citados como benefícios propostos pela Prosimo, não como fatos de mercado medidos.

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

O mesmo anúncio de 2024 apresentava a arquitetura da Prosimo como útil para cargas de trabalho de IA. Sistemas distribuídos de IA podem exigir acesso a dados privados, conexões entre nuvens e datacenters, controles de conformidade e um roteamento que considere o comportamento da aplicação. Esses requisitos se encaixavam no modelo existente de ativos, políticas e caminhos.

A designação não alterava a rede subjacente. A Prosimo permanecia dependente das redes de nuvem, operadoras e infraestrutura do cliente. A empresa não fornecia computação GPU nem software de desenvolvimento de modelos. Seu possível papel era a camada de conectividade e segurança para dados e serviços distribuídos.

O posicionamento de IA era estrategicamente compreensível, porque o valor de uma topologia multinuvem aumenta com dados e serviços mais distribuídos. Ao mesmo tempo, era uma categoria de marketing introduzida pouco antes do fim da operação independente. Os registros não comprovam receitas separadas de produtos de IA, implantações produtivas nominalmente documentadas ou resultados de carga de trabalho auditados.

A constatação duradoura é que a telemetria multinuvem pode se tornar uma base para operações apoiadas por máquina. A questão atual do produto é se a Palo Alto Networks preservou esse contexto e como torna a funcionalidade acessível. As informações publicamente disponíveis na data de corte não fornecem uma resposta completa.

O modelo de negócios vendia software para infraestrutura que a Prosimo não possuía

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 Edges AXI em seus ambientes e conectavam contas de nuvem à camada de controle. As receitas provavelmente provinham de licenças ou assinaturas, suporte, serviços profissionais e atividades de parceiros de distribuição; preços específicos e métricas contratuais não foram divulgados nas evidências disponíveis.

O modelo podia escalar sem uma rede de fibra própria. Uma plataforma de software coordenava muitas regiões de nuvem e ambientes de clientes. No entanto, não se pode deduzir margens brutas a partir dessa arquitetura. O suporte de engenharia para APIs de 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 pelo Edge possivelmente eram pagos pelo cliente, não pelo fornecedor.

A Prosimo usava marketplaces de nuvem, parceiros de integração e distribuição, e referências nominais de clientes para alcançar compradores empresariais. Esses relacionamentos não são equivalentes. Uma listagem no marketplace comprova um caminho de aquisição e implantação. Uma integração técnica comprova que dois sistemas podem ser combinados sob condições definidas. Uma citação de cliente fornece uma referência. Nenhum deles, por si só, comprova o número de clientes pagantes ou receitas recorrentes.

A amplitude da oferta pode ter aumentado a complexidade de vendas. Equipes de rede, segurança, nuvem e aplicações podiam se beneficiar, mas a responsabilidade orçamentária possivelmente não era clara. O produto precisava de um patrocinador que financiasse uma camada de controle comum, em vez de financiar operações separadas para cada nuvem e equipe.

Parceiros, clientes e investidores cumpriam papéis diferentes

A Amazon Web Services era, ao mesmo tempo, provedora de infraestrutura subjacente e parceira de entrada no mercado. Azure e Google Cloud eram ambientes suportados. Provedores de identidade forneciam contexto de autenticação, enquanto fornecedores de firewall realizavam a inspeção. Serviços de colocation e operadoras podiam hospedar ou conectar Edges. Parceiros de distribuição podiam projetar e operar implantações.

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

A General Catalyst liderou a Série A e estava envolvida na governança por meio de seu papel de investidora. Investidores ligados à WRVI ou Celesta apareceram em material da empresa; comunicações posteriores da Prosimo mencionaram participação adicional proeminente, incluindo uma designação ligada à BlackRock, cujo veículo de investimento exato permaneceu em aberto na pesquisa. Esses documentos mostram uma base de financiamento bem conectada, não uma tabela de capitalização completa.

A Palo Alto Networks assumiu a posição mais consequente: de parceira de segurança em 2024, tornou-se a compradora até o início de 2025. A sequência mostra como uma dependência de ecossistema se transforma em relação de controle quando um participante compra a camada de software que coordena o caminho para seu produto.

Pelo menos US$ 55 milhões foram captados; o resultado econômico da venda da empresa permanece desconhecido

O financiamento verificado consiste em uma Série A de US$ 25 milhões em abril de 2021 e uma Série B de US$ 30 milhões em 2022. O total é de pelo menos US$ 55 milhões. As evidências fornecidas não contêm uma tabela de capitalização auditada, nem informações sobre avaliação, estrutura de dívida ou rodadas de financiamento posteriores.

O preço de aquisição não foi divulgado nem confirmado de forma independente. Sem o preço, não se pode classificar responsavelmente o resultado como prêmio estratégico, aquisição modesta de tecnologia, acqui-hire ou venda forçada. A integração contínua do produto comprova valor tecnológico, mas não revela o retorno para investidores ou fundadores.

A receita e a posição de mercado da Palo Alto Networks não devem ser atribuídas à Prosimo após a aquisição. Assim que a startup deixou de ser observável separadamente, não havia mais um segmento independente de receita, lucro ou clientes para analisar. Um proprietário maior pode tornar a tecnologia mais amplamente disponível e, ao mesmo tempo, tornar sua importância econômica independente 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 anúncios para determinar o momento, o suporte e a justificativa estratégica. Aqui, o status precisa ser reconstruído a partir de perfis profissionais, uma marcação na página da empresa e uma declaração posterior do fundador. Isso é suficiente para corrigir o status da empresa, não para inventar detalhes da transação.

Concorrência vinha de plataformas, nuvens e desenvolvimento interno

A Prosimo competia com plataformas especializadas de rede multinuvem como Aviatrix e Alkira, com fornecedores de redes empresariais e SASE, bem como com serviços nativos da AWS, Azure e Google Cloud. Também competia com um modelo faça você mesmo, no qual as empresas usam Infraestrutura como Código, serviços de trânsito do provedor, tabelas de roteamento e firewalls diretamente. As alternativas resolviam cada uma partes diferentes do mesmo problema.

Um controlador especializado podia oferecer um modelo de topologia e políticas entre provedores. Um design nativo da nuvem podia reduzir a dependência de terceiros e ser fortemente adaptado a um provedor. Um serviço baseado em operadora podia fornecer transporte físico. Uma plataforma SASE ou de segurança podia unir conectividade e aplicação. O desenvolvimento interno podia preservar o controle, mas aumentava os custos de pessoal e integração.

A diferenciação da Prosimo estava na combinação de trânsito de aplicação e rede, Edges distribuídos, orquestração nativa da nuvem, topologia, telemetria e inserção de serviços. Essa mesma amplitude dificultava as comparações. Os compradores precisavam testar os serviços de nuvem, rotas, sistemas de identidade e padrões de segurança específicos que pretendiam usar, em vez de comparar nomes de categorias.

A aquisição altera o quadro competitivo. A Prosimo não precisa mais se afirmar como fornecedora independente, mas sua tecnologia precisa provar seu valor dentro da Palo Alto Networks. O ponto decisivo é se a descoberta integrada de recursos e a orquestração de roteamento melhoram a implantação dos produtos de segurança da Palo Alto Networks e se os clientes aceitam a dependência de plataforma resultante.

Serviços nativos da nuvem eram base e substituto

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN e serviços de rede do Google Cloud ofereciam às empresas opções nativas poderosas. A Prosimo dependia desses serviços e, ao mesmo tempo, competia com seu uso direto pelos clientes.

Essa relação criava uma fronteira móvel. Se um provedor de nuvem adicionasse roteamento global, segmentação, acesso privado a serviços ou políticas centralizadas, algumas funções de terceiros podiam ser replicadas nativamente com mais facilidade. Ao mesmo tempo, cada novo serviço nativo adicionava mais um objeto que um controlador multinuvem podia descobrir e coordenar. Os avanços dos provedores de nuvem podiam reduzir parte do valor da Prosimo e, simultaneamente, aumentar a necessidade de tradução entre provedores.

O fator decisivo era tanto organizacional quanto técnico. Uma empresa que opera em uma única nuvem, com forte engenharia interna, podia preferir ferramentas nativas. Uma empresa multinuvem, com equipes fragmentadas, podia preferir um plano de controle comum. Uma organização regulada podia preferir uma camada independente de controle e evidência, ao mesmo tempo em que temia credenciais privilegiadas e concentração de dados.

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

Falhas podiam ocorrer no controlador, no Edge, nas APIs de nuvem, no sistema de identidade ou na rede subjacente

A arquitetura distribuída da Prosimo reduzia a dependência de um hub de tráfego, mas criava vários domínios de falha interagentes. O serviço central podia falhar ou conter políticas desatualizadas. Um Edge podia falhar ou ficar isolado. Uma API de nuvem podia rejeitar parte de uma alteração. O provedor de identidade podia falhar. A rede subjacente podia perder capacidade ou tomar um caminho inesperado. Um firewall inserido podia esgotar recursos.

Falhas parciais são especialmente difíceis. Um provedor pode aceitar uma alteração de roteamento enquanto outro a rejeita. Então, o estado pretendido pelo controlador diverge do estado real da nuvem. O tráfego pode fluir de forma assimétrica ou contornar a inspeção. Um sistema confiável precisa de reconciliação, operações idempotentes, alterações graduais, estados de falha claramente sinalizados e um rollback que considere o comportamento de cada provedor.

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

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

Credenciais de nuvem tornavam o controlador parte da camada de gerenciamento crítica

A descoberta de ativos e a orquestração exigiam acesso a contas de nuvem. Um inventário somente leitura podia operar com permissões limitadas; alterações em rotas, segmentos e inserção de serviços exigiam permissões mais amplas. O controlador, portanto, situava-se na camada de gerenciamento privilegiada, embora não possuísse as cargas de trabalho.

Uma comprometimento das credenciais podia expor a topologia ou permitir alterações abrangentes. Um bug de software ou erro operacional podia propagar políticas por várias nuvens. O risco crescia com a utilidade da plataforma: quanto mais contas e serviços ela pudesse gerenciar, maior o raio de impacto potencial.

As empresas precisavam de funções com privilégio mínimo, credenciais separadas para descoberta e alteração, aprovação por múltiplas partes, auditorias completas, rotação, revogação de emergência e um caminho de recuperação que não dependesse exclusivamente do mesmo controlador. O material público não contém uma avaliação de segurança independente completa; esses pontos permanecem, portanto, como controles de implantação necessários, e não como garantias verificadas do produto.

O grafo de telemetria era igualmente sensível. Ele podia revelar nomes de aplicações, estrutura de rede, políticas, relacionamentos de usuários, estado de rotas e padrões de custo. A governança pós-aquisição deve esclarecer onde os dados são armazenados, quais produtos da Palo Alto Networks podem acessá-los e como as permissões dos clientes existentes foram migradas. O estado público não responde a essas perguntas.

A aquisição moveu uma camada neutra em relação à nuvem para uma plataforma de segurança

A posição independente da Prosimo permitia que a empresa se posicionasse como uma camada comum sobre nuvens e serviços de segurança. Com a Palo Alto Networks como proprietária, os incentivos mudaram. A tecnologia adquirida podia facilitar a implantação da VM-Series e de outros produtos da Palo Alto Networks. Isso pode criar uma experiência de uso mais integrada e levantar questões sobre o suporte a serviços de inspeção de terceiros.

A propriedade não prova que a neutralidade desapareceu. Os registros não contêm uma matriz de parceiros atual nem uma arquitetura de produto atual. No entanto, alteram a pergunta que os clientes devem fazer. É preciso verificar se o controlador de roteamento permanece aberto a múltiplos fornecedores de segurança, 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 de entrada, saída e leste-oeste. Isso sugere que a topologia e a orquestração da Prosimo se tornaram parte de um sistema de fornecimento de funções de segurança. Não prova que a funcionalidade histórica de App Transit, o acesso de usuários, a otimização de custos ou todos os fluxos de trabalho de rede na nuvem persistam como capacidades separadas.

Esse é um padrão comum em infraestrutura. Uma startup abstrai um problema difícil de coordenação; um grande fornecedor de plataforma compra a abstração porque ela aumenta o uso e o controle de seu produto principal. O comprador ganha um caminho mais rápido para a implantação. O cliente pode ganhar integração e perder parte de sua independência de fornecedor.

O mapeamento atual do produto é a maior lacuna de informação

As informações publicamente disponíveis confirmam a aquisição e a integração, mas não contêm um mapeamento completo de AXI, Network Transit, App Transit, AIR e Nebula para produtos ou SKUs atuais da Palo Alto Networks. Também faltam prazos de suporte legado, procedimentos de migração e uma comparação funcional para a continuidade do produto.

Essa lacuna impede uma avaliação do produto no presente. As descrições históricas explicam o que a Prosimo construiu e por que era importante. Não dizem quais funcionalidades estão disponíveis, licenciadas ou suportadas hoje. As recomendações atuais de implantação devem se basear na documentação atual da Palo Alto Networks, e não em comunicados arquivados da Prosimo.

A falta de mapeamento também limita a análise estratégica. Uma aquisição completa do grafo de topologia e da camada de orquestração seria diferente do uso seletivo da descoberta de ativos e do posicionamento de firewall. O primeiro resultaria em um amplo serviço de controle multinuvem; o último usaria a Prosimo principalmente para acelerar a implantação de funções de segurança. A declaração do fundador apoia a continuidade da tecnologia e deixa essa fronteira arquitetural em aberto.

Um documento de produto futuro, um guia de migração ou um estudo de caso de cliente poderia eliminar grande parte da incerteza. Até lá, a formulação precisa é: segundo um cofundador, a tecnologia da Prosimo foi integrada aos produtos da Palo Alto Networks; o escopo e a embalagem do produto não são verificados.

Quem controla o roteamento multinuvem?

Nenhuma parte controla o caminho inteiro. A empresa possui as contas, define os objetivos de negócio e o design da aplicação e concede as credenciais. Um controlador multinuvem pode capturar a topologia, traduzir políticas, escolher caminhos e alterar o estado das rotas nativas. Os provedores de nuvem controlam APIs, serviços de trânsito, endpoints privados, o backbone e muitos domínios de falha. Operadoras e provedores de colocation controlam outras partes do transporte. Os serviços de segurança decidem se o tráfego inspecionado é permitido.

A Prosimo ambicionava a posição intermediária estrategicamente mais útil. Não possuía a rede subjacente, mas buscava o controle sobre o grafo e a tradução de políticas sobrejacente. Quem controla essa camada pode decidir 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. Isso é controle operacional sobre o roteamento, mesmo que a fibra pertença a outro.

Após a aquisição, a Palo Alto Networks detém a tecnologia remanescente da Prosimo e determina como ela é integrada, empacotada e desenvolvida. Os provedores de nuvem permanecem soberanos em seus ambientes; a empresa pode revogar credenciais ou escolher outra arquitetura. A saída, no entanto, pode ser cara se a topologia, as políticas e os fluxos de trabalho operacionais se tornaram dependentes do controlador.

A resposta é, portanto, estratificada e não absoluta: a empresa autoriza; o controlador coordena; as redes subjacentes da nuvem e das operadoras transportam; a plataforma de segurança impõe. A história da Prosimo mostra que a propriedade da camada coordenadora pode mudar sem que uma conta de nuvem ou um caminho físico mude de dono.

Lista de fontes central

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

A Prosimo capturou uma mudança real na infraestrutura. O objeto da operação de rede está se deslocando 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 da nuvem tornam o estado da rede programável; os Edges de software distribuídos tornam o ponto de imposição móvel. Um controlador com visão multinuvem pode coordenar ações que nenhum console de uma única nuvem consegue realizar sozinho.

A empresa também demonstrou os custos dessa coordenação. Uma camada comum exige credenciais privilegiadas, manutenção contínua de APIs, descoberta precisa, tradução semântica, telemetria e disciplina operacional. Ela pode reduzir o trabalho fragmentado e criar um novo ponto de concentração. O mesmo sistema que simplifica o roteamento pode, ao mesmo tempo, 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 na inserção de serviços, descoberta de cargas de trabalho e controle de políticas. Um fornecedor de segurança que conhece a topologia e pode alterar rotas não apenas inspeciona o tráfego que lhe é apresentado; ele pode ajudar a determinar qual tráfego chega à inspeção e por onde.

Portanto, a Prosimo não deve ser considerada uma marca independente fracassada, nem uma prova de que uma única plataforma resolveu o problema multinuvem. Sua contribuição duradoura foi definir o grafo multinuvem como infraestrutura. A questão remanescente é se esse grafo, dentro de uma grande empresa de segurança, permanece suficientemente transparente, portátil e auditável para merecer a confiança dos clientes.