Workloads críticos não cabem em soluções genéricas de cloud pública

A maioria das jornadas para nuvem começa de forma parecida. Primeiro sobem ambientes de teste, aplicações internas, portais menos sensíveis. Tudo flui. Provisionamento rápido, menos hardware para gerenciar, escala quase instantânea. A cloud pública cumpre exatamente o que promete.

O problema aparece quando chega a vez dos sistemas que realmente sustentam o negócio.

Não estamos falando de um site institucional ou de um microsserviço secundário. Estamos falando do banco de dados transacional, do ERP que fecha faturamento, do sistema logístico que não pode parar, do motor financeiro que processa milhares de operações por minuto. É nesse momento que a discussão deixa de ser “agilidade” e passa a ser risco operacional.

Porque esses workloads não aceitam variabilidade. Eles exigem estabilidade quase cirúrgica. E soluções genéricas, compartilhadas e distribuídas globalmente nem sempre entregam esse nível de previsibilidade.

O que caracteriza um workload como crítico?

Workload crítico não é sinônimo de “importante”. É aquele que, se parar por alguns minutos, gera impacto financeiro imediato, quebra de SLA ou exposição regulatória.

Normalmente esses ambientes têm três características técnicas bem claras:

• Consumo constante de recursos;

• Alta sensibilidade a latência;

• Dependência rígida de compliance.

São sistemas 24x7, com uso pesado de CPU, memória e principalmente I/O de disco e rede. Não existem picos esporádicos. Existe carga sustentada o tempo todo.

Esse padrão de uso contrasta com o modelo clássico da nuvem pública, que foi desenhado para elasticidade e compartilhamento massivo de recursos. Quando o workload não varia, o benefício da elasticidade diminui. E quando a latência precisa ser estável em milissegundos, qualquer oscilação vira problema.

Na prática, o que se busca não é “mais escala”, mas previsibilidade de performance.

Leia também: Workloads estáveis e dinâmicos (e o impacto no custo da cloud)

Onde a nuvem pública genérica começa a gerar atrito técnico?

A limitação não está no provedor. Está no modelo.

Cloud pública opera em arquitetura multi-tenant. Recursos físicos são compartilhados entre centenas ou milhares de clientes. Isso aumenta eficiência, mas reduz controle fino. Um vizinho consumindo I/O intensivo pode afetar sua aplicação. Uma rota de rede mais longa pode adicionar milissegundos extras. Uma política de storage padrão pode não entregar a latência necessária para bancos transacionais pesados.

Em workloads comuns, essas variações passam despercebidas. Em sistemas críticos, elas viram incidentes.

Outro ponto sensível é a localização do dado. Empresas de setores regulados precisam saber exatamente onde as informações residem, quem acessa e como são auditadas. Modelos públicos globais nem sempre permitem esse nível de granularidade. Soberania de dados, LGPD, normas financeiras ou de saúde exigem controle direto do ambiente, não apenas contratos de serviço.

E existe ainda a questão do custo. O modelo pay-as-you-go é excelente para cargas variáveis, mas para workloads permanentes e intensivos ele se comporta como um aluguel infinito. Com o tempo, somam-se storage, transferência, snapshots, tráfego de saída. A fatura cresce sem que o consumo aparente mude.

Muitas empresas descobrem isso tarde, quando a conta mensal já virou assunto de diretoria.

O mercado está realmente colocando tudo na nuvem pública?

A percepção comum é que “todo mundo migrou tudo”. Os números mostram algo mais nuançado.

O investimento global em cloud pública continua acelerado e deve ultrapassar US$ 723 bilhões em 2025, segundo o Gartner . Ou seja, a nuvem pública segue essencial.

Mas isso não significa que workloads críticos estão indo no mesmo ritmo. A própria Gartner projeta que 50% das aplicações empresariais críticas permanecerão fora de localizações centralizadas de nuvem pública até 2027 .

Se metade do que é crítico ainda fica fora, não estamos falando de resistência cultural. Estamos falando de adequação técnica.

Essas cargas exigem características que o modelo genérico simplesmente não prioriza.

Private cloud e modelos híbridos resolvem essa equação?

Na prática, o que mais se vê hoje não é um movimento de “voltar para o datacenter tradicional”, mas sim a adoção de arquiteturas híbridas. Parte do ambiente permanece em cloud pública, aproveitando elasticidade e serviços gerenciados. A parte sensível roda em infraestrutura dedicada, com controle total de hardware, rede e localização de dados.

Esse desenho permite ajustar a casa para cada tipo de workload.

Aplicações voláteis escalam na nuvem pública.
Workloads críticos operam em ambientes dedicados, com latência estável, segurança sob medida e custo previsível.

Não é uma escolha ideológica. É engenharia.

Quando a arquitetura respeita o comportamento real das cargas, o resultado costuma ser mais simples de operar, mais barato no longo prazo e, principalmente, mais confiável.

Então qual é a pergunta certa que gestores de infraestrutura deveriam fazer?

Talvez não seja “qual cloud escolher?”. Essa pergunta já nasce enviesada.

A pergunta mais honesta é: onde cada workload performa melhor com o menor risco possível?

Quando a decisão parte do comportamento da aplicação, e não da moda tecnológica, a resposta quase sempre aponta para uma combinação de ambientes.

Cloud pública continua indispensável. Mas tratá-la como destino universal para workloads críticos costuma gerar mais dor do que benefício.

Infraestrutura não é sobre seguir tendência. É sobre garantir que o que sustenta o negócio funcione todos os dias, sem surpresa. E para cargas críticas, previsibilidade ainda vale mais do que elasticidade.