Em 2021, o conselho de uma indústria de componentes aprovou a saída do datacenter próprio e a migração integral do ambiente para a nuvem pública, com a promessa de trocar investimento pesado em hardware por uma despesa mensal previsível. Três anos depois, a fatura havia mais que dobrado sem que a produção tivesse crescido na mesma proporção, e nenhum diretor conseguia explicar, linha a linha, o que justificava cada degrau de aumento.
Esse padrão se repete com frequência incômoda em empresas de todos os portes e setores. A maioria migrou por lotes, empurrada pelo fim de um contrato de datacenter, pela renovação de um parque de servidores ou por uma urgência de continuidade, antes que qualquer critério econômico explícito definisse qual carga de trabalho pertence a qual lugar. A decisão foi tomada pela ocasião, e o preço da ocasião aparece anos depois, quando mover qualquer coisa já se tornou caro.
Este estudo propõe uma matriz de cinco critérios, perfil de consumo, gravidade e volume de dados, tolerância a latência, exigência regulatória e custo real de saída, para classificar cada carga entre nuvem pública, nuvem privada, colocation (espaço em datacenter de terceiros onde a empresa mantém equipamento próprio) e infraestrutura local. O objetivo não é eleger um modelo vencedor, e sim entregar ao gestor um método defensável diante do conselho, do orçamento e do plano de continuidade.
O prêmio de elasticidade que a maioria paga sem usar
O preço da nuvem pública embute um prêmio de elasticidade, a capacidade de ampliar ou reduzir capacidade em minutos sem comprar equipamento. Esse prêmio se paga sozinho em cargas sazonais, campanhas comerciais, fechamentos contábeis e ambientes de teste que existem por poucas semanas. Ele vira desperdício silencioso quando aplicado a um ERP (sistema integrado de gestão empresarial) que varia menos de 15% de carga ao longo do ano, a uma base histórica de produção consultada de forma esporádica ou a servidores de arquivos cujo crescimento é linear e conhecido.
O segundo mecanismo é físico e nenhum contrato o resolve: latência, o atraso entre um comando e sua resposta. Um MES (Manufacturing Execution System, sistema que coordena ordens, apontamentos e qualidade no chão de fábrica) que dialoga com controladores de linha tolera pouquíssimo atraso e passa a depender por inteiro da estabilidade do link da planta. Quando esse link oscila por vinte minutos, a linha não desacelera, ela para, e o prejuízo se mede em ordens sem apontamento, lotes sem rastreabilidade e turnos perdidos. Medir o custo por hora de indisponibilidade costuma mudar a conversa mais do que qualquer planilha de infraestrutura.
Como montar a matriz de decisão
O ponto de partida é um inventário econômico das cargas, construído com dados reais de consumo de doze a dezoito meses. Para cada sistema relevante, registre a variação entre pico e vale, o volume de dados associado, a sensibilidade a latência, a exigência regulatória aplicável e a estimativa de custo de saída. Cargas cujo pico supera três vezes o vale tendem a justificar a nuvem pública; cargas planas, com grande volume e pouca variação, tendem a custar menos em nuvem privada ou colocation, onde a empresa compra capacidade dedicada e previsível.
O segundo passo é a disciplina de avaliação. Exija comparações em janela de trinta e seis meses que incluam egresso, licenciamento, custo de rede, esforço de migração e parada planejada, porque comparações mensais escondem exatamente o que encarece a decisão. Peça o plano de saída por escrito antes de assinar a entrada, com prazo estimado, volume de dados e formato de exportação. E trate a estratégia de backup e recuperação de desastres como parte da matriz, já que o local onde o dado vive e o local de onde ele volta precisam ser decisões conscientes e testadas.
Cinco perguntas que todo gestor deveria fazer
1. Quais cargas da nossa operação têm consumo estável e previsível e, por isso, pagam caro por uma elasticidade que raramente acionam? 2. Quanto custaria retirar nossos dados de onde eles estão, considerando taxas de saída, tempo de migração e parada operacional? 3. Que processos não toleram a latência ou a dependência de link que a nuvem pública impõe, e o que acontece com a produção quando esse link oscila? 4. Nossa fatura de nuvem é revisada com a disciplina de um contrato de fornecimento crítico, com responsável nomeado e meta de custo por unidade de negócio? 5. Se o orçamento de infraestrutura precisasse cair 18% no próximo ciclo, saberíamos dizer em menos de uma semana quais cargas realocar e qual seria o impacto operacional de cada movimento?
Quais cargas da nossa operação têm consumo estável e previsível e, por isso, pagam caro por uma elasticidade que raramente acionam?
Poucas empresas respondem a isso com números, embora a informação esteja disponível: os painéis de consumo do próprio provedor mostram, carga por carga, a distância entre pico e média. O exercício costuma revelar um padrão previsível, com sistemas de gestão, bases históricas e servidores de arquivos operando em utilização quase constante enquanto são cobrados por um modelo desenhado para variação intensa.
A consequência é orçamentária e imediata. Em horizontes de três anos, cargas planas tendem a custar bem menos em capacidade dedicada do que em consumo elástico, e essa diferença, aplicada apenas às cinco maiores cargas, com frequência financia sozinha o projeto de reposicionamento. O gestor que chega ao conselho com essa lista ordenada por economia potencial deixa de discutir preferência técnica e passa a discutir alocação de capital.
Quanto custaria retirar nossos dados de onde eles estão, considerando taxas de saída, tempo de migração e parada operacional?
Esse número quase nunca foi levantado, e sua ausência é o que transforma uma escolha reversível em dependência permanente. O cálculo tem quatro componentes, a taxa de egresso sobre o volume total, as horas de engenharia para redesenhar integrações, o período de operação em paralelo entre ambientes e a janela de parada necessária para o corte final.
Conhecer esse valor muda a posição da empresa mesmo quando a decisão é permanecer onde está. Um gestor que sabe quanto custaria sair negocia renovações com argumento concreto, estabelece limite para o crescimento de volume em cada plataforma e evita que novas cargas aumentem, por inércia, o preço de uma eventual mudança futura.
Que processos não toleram a latência ou a dependência de link que a nuvem pública impõe, e o que acontece com a produção quando esse link oscila?
A resposta começa por um mapa honesto dos processos que param quando a conexão degrada. Em ambientes industriais, isso normalmente inclui execução de manufatura, coleta de apontamentos, sistemas de visão e balanças integradas; em outros setores, aparece em atendimento, faturamento e expedição, todos dependentes de resposta em tempo real para não travar a fila física de pessoas ou mercadorias.
O critério prático é simples de enunciar e desconfortável de aplicar: o que interrompe a geração de receita quando a rede oscila deve permanecer fisicamente perto de onde a receita é gerada. Uma linha parada por algumas horas costuma consumir, em margem perdida, mais do que a economia anual obtida ao centralizar aquele sistema na nuvem pública, e esse confronto de números pertence ao conselho, não à equipe de infraestrutura.
Nossa fatura de nuvem é revisada com a disciplina de um contrato de fornecimento crítico, com responsável nomeado e meta de custo por unidade de negócio?
Contratos de matéria-prima, energia e logística têm dono, meta e revisão periódica, enquanto a fatura de nuvem costuma ser tratada como conta de utilidade pública, aprovada sem análise porque ninguém se sente autorizado a questioná-la. O primeiro movimento corretivo é nomear um responsável com mandato explícito para reduzir custo sem degradar serviço, e um ciclo fixo de revisão com participação financeira e técnica.
O segundo movimento é adotar uma métrica de custo por unidade de negócio, como custo de infraestrutura por ordem de produção, por nota emitida ou por cliente ativo. Essa métrica separa crescimento legítimo de desperdício acumulado, porque uma fatura que sobe 22% enquanto a produção sobe 25% conta uma história muito diferente de uma fatura que sobe na mesma proporção com volume estagnado.
Se o orçamento de infraestrutura precisasse cair 18% no próximo ciclo, saberíamos dizer em menos de uma semana quais cargas realocar e qual seria o impacto operacional de cada movimento?
A velocidade da resposta revela se existe um mapa ou apenas um histórico de decisões acumuladas. Sem matriz, cortes orçamentários viram redução linear aplicada a todos os ambientes, prática que penaliza igualmente o que sustenta receita e o que apenas consome recursos, e que costuma ser revertida meses depois ao custo de um incidente.
Com a matriz pronta, o gestor possui uma sequência priorizada por economia e risco, na qual cada movimento já tem destino, prazo e impacto estimados. Essa capacidade de resposta, mais do que o valor economizado em si, é o que transforma a área de tecnologia em interlocutora confiável na mesa de decisão, porque demonstra domínio sobre as consequências operacionais de cada escolha financeira.
Perguntas frequentes
Retirar cargas da nuvem pública significa abandonar a estratégia de nuvem?
Não. Reposicionar cargas é um ajuste de alocação, no qual cada sistema passa a ocupar o modelo que melhor atende seu perfil de consumo, latência e regulação. A maioria das empresas maduras opera em desenho híbrido, mantendo elasticidade onde ela é usada de fato e capacidade dedicada onde o consumo é estável e previsível.
Como calcular o custo real de sair de um provedor de nuvem pública?
O cálculo soma quatro elementos: a taxa de egresso aplicada ao volume total de dados, as horas de engenharia para redesenhar integrações, o período de operação simultânea entre os dois ambientes e a janela de parada necessária para o corte definitivo. Empresas que levantam esse número antes de acumular volume preservam liberdade de negociação nas renovações contratuais.
Quais cargas costumam permanecer bem posicionadas na nuvem pública?
Cargas com variação intensa de demanda, como ambientes de desenvolvimento e teste, processamento analítico por períodos curtos, aplicações voltadas a picos sazonais de venda e cópias de segurança armazenadas em região geograficamente distante. Nesses casos, a elasticidade contratada é efetivamente utilizada e o prêmio pago se converte em economia real.
Para submeter o posicionamento das suas cargas a esse crivo antes do próximo ciclo orçamentário, converse com a Zamak em um Diagnóstico Estratégico de TI sem compromisso.