Toda arquitetura multicloud nasce, em algum momento, de uma frase quase religiosa dentro de comitês de tecnologia: evitar dependência de um único fornecedor a qualquer custo. Rolando Bonaccorsi, diretor de operações da Vert Analytics, questiona essa premissa quando ela vira dogma, pois o problema não é depender de um provedor, mas depender dele sem entender o preço real dessa escolha, seja qual for a direção tomada.
Vendor lock-in é o termo usado para descrever a dificuldade de migrar de um provedor de nuvem para outro, seja por incompatibilidade técnica de serviços proprietários, seja pelo custo de reescrever aplicações inteiras. A resposta mais comum, adotar arquitetura multicloud para preservar liberdade futura, carrega custos próprios que raramente entram na conta inicial do projeto.
O preço escondido da portabilidade teórica
Construir uma aplicação verdadeiramente portável entre provedores de nuvem geralmente significa evitar serviços gerenciados proprietários, que costumam ser justamente os mais eficientes e baratos de operar. Isso empurra as equipes para soluções mais genéricas, que exigem mais esforço de manutenção interna e, ironicamente, aumentam o custo operacional em nome de uma flexibilidade que talvez nunca seja exercida.
Rolando Bonaccorsi explica que as empresas deveriam calcular o custo real dessa portabilidade antes de adotá-la como princípio absoluto: quanto tempo de engenharia é gasto mantendo compatibilidade entre nuvens, comparado à probabilidade real de uma migração completa acontecer nos próximos anos. Em muitos casos, esse investimento supera em muito o risco que pretende mitigar.
Multicloud por resiliência versus multicloud por ideologia
Existe uma diferença relevante entre adotar múltiplos provedores por razões estratégicas específicas, como redundância geográfica para serviços críticos ou aproveitamento de capacidades especializadas de cada plataforma, e adotar multicloud apenas como resposta genérica ao medo de dependência. A primeira abordagem resolve problemas concretos; a segunda costuma criar complexidade sem retorno proporcional.
Sendo assim, o teste mais honesto para essa decisão é perguntar qual problema específico a arquitetura multicloud resolve, e não apenas qual risco abstrato ela evita. Empresas que respondem com clareza a essa pergunta tendem a fazer escolhas mais econômicas do que aquelas guiadas apenas pelo temor genérico de ficar presas a um único fornecedor.
Governança e visibilidade em ambientes fragmentados
Cada provedor de nuvem traz seu próprio modelo de segurança, faturamento e ferramentas de observabilidade, o que multiplica o esforço de governança quando múltiplas plataformas operam simultaneamente. Sem uma camada unificada de visibilidade, equipes acabam navegando entre painéis distintos para entender o estado real de uma operação distribuída entre provedores.
Sendo especialista em gestão de operações de TI e excelência em serviços, Rolando Bonaccorsi retrata que esse custo de coordenação raramente aparece na planilha inicial de comparação de preços entre nuvens, mas se acumula de forma silenciosa ao longo do tempo, consumindo horas de engenharia que poderiam estar direcionadas a problemas de maior valor para o negócio.
Decisões de arquitetura como decisões de negócio
A escolha entre concentrar operações em um único provedor ou distribuí-las entre vários não deveria ser tomada apenas por equipes técnicas isoladas, sem envolvimento de áreas que entendem o apetite de risco financeiro e operacional da empresa. Decisões de arquitetura em nuvem carregam implicações contratuais, de custo e de continuidade de negócio que ultrapassam a esfera puramente técnica.
Rolando Bonaccorsi defende que essa decisão seja revisitada periodicamente, à medida que a empresa cresce e suas necessidades mudam, em vez de permanecer fixada em uma escolha feita anos atrás sob premissas que talvez já não se apliquem à realidade atual do negócio.
Nem toda dependência de fornecedor é um risco a ser eliminado, assim como nem toda diversificação de provedores é sinônimo de resiliência. A decisão certa depende de um cálculo específico de custo, risco e capacidade operacional que cada empresa precisa fazer para si mesma, e não da aplicação automática de princípios genéricos ouvidos em conferências de tecnologia.
Nessa linha de raciocínio, empresas maduras tratam essa escolha como qualquer outra decisão estratégica de negócio: com dados, cenários concretos e revisão periódica, em vez de dogma fixo. Esse pragmatismo, mais do que qualquer arquitetura específica, costuma ser o que efetivamente protege a operação de decisões caras tomadas por medo, e não por análise real de risco.
