Nuvem não é compra de servidor

Muita migração “para a nuvem” é um lift-and-shift com fatura em dólar. As mesmas três VMs, o mesmo deploy na sexta, o mesmo pedido de capacidade “para os próximos três anos”. O provedor mudou. O estilo de decisão não.

Nuvem não é um item a mais no portfólio de TI. Quando funciona, vira o modo como você dimensiona, experimenta e paga. Se o processo de compra, o orçamento anual e o medo de desligar máquina continuam iguais, você não adotou nuvem. Mudou de bairro e levou os móveis.

Previsibilidade contra elasticidade

TI tradicional pede certeza: tamanho da caixa, valor do contrato, prazo do projeto. Licitação e RFP funcionam quando o objeto é um produto com borda clara — o firewall, o storage da marca X. Plataforma de nuvem não tem borda clara. O catálogo muda. O que você precisa no ano que vem talvez ainda não tenha nome.

Encaixar elasticidade num número fixo de orçamento é pedir para alguém correr na frente do carro com uma bandeira. O mecanismo existe para subir e descer. Um teto anual que assume 12 meses no pico paga o pico 12 vezes. Um teto que assume a média e explode no Black Friday também não é estratégia: é surpresa.

A pergunta útil deixa de ser “quantos servidores eu preciso até 2026?” e passa a ser “com que velocidade a carga sobe e desce, e o que eu faço em cada direção?”. Isso é olhar a primeira derivada, não só o estoque de máquinas.

A primeira derivada da carga

No modelo antigo, o servidor custa um valor absoluto: cinquenta mil na nota. Na nuvem, custa uma taxa: três dólares por hora, um milhão de requests, um gigabyte transferido. A linguagem muda de estoque para fluxo. Consumo no lugar de orçamento engessado. Velocidade de entrega no lugar de data única. Gastos por mês no lugar de headcount congelado como único botão.

Se o consumo de recurso sobe, o faturamento deveria subir junto — ou você está pagando experimentação, o que também pode ser correto, desde que seja explícito. Comprar 1x e vender 2x é troca. Comprar 2x e vender o mesmo 1x é problema de gestão, não de instância.

Empresas digitais não são as que têm mais logo de cloud no slide. São as que tratam experimentação como custo a reduzir pelo aprendizado rápido. A nuvem barateia o experimento se você desliga o que não serviu. VM eterna de um piloto de 2019 é o oposto: capex disfarçado de opex.

flowchart TD
  A[Demanda] --> B{Olhar estoque ou fluxo?}
  B -->|Estoque| C[Comprar capacidade]
  C --> D[Ocioso ou curto]
  B -->|Fluxo| E[Medir a derivada]
  E --> F[Sobe: replica]
  E --> G[Desce: reduz]
  F --> H[Custo acompanha receita]
  G --> I[Experimento que termina]
  classDef ouro fill:#FBF5E4,stroke:#C9A227,color:#0B1F18,stroke-width:1.4px
  classDef verde fill:#F3FAF7,stroke:#1E7A57,color:#0B1F18,stroke-width:1.4px
  classDef fim fill:#14513B,stroke:#0F3328,color:#FBFAF6,stroke-width:1.4px
  class A,B ouro
  class C,E,F,G verde
  class D,H,I fim

Produto, plataforma e o hábito de controlar

A maior parte do que TI compra é produto: serve a um propósito, compara-se em planilha, encaixa no processo atual. Nuvem é plataforma. Você não “casa o requisito com a feature” e encerra a aquisição. Você ajusta o modo de operar à plataforma — identidade, rede, observabilidade, IAM, conta por time.

Controle prévio (tudo precisa de ticket para existir) luta com transparência posterior (tudo que existe é visível e tem dono). Nuvem aumenta a transparência: tag, bill, CloudTrail, política. Usar transparência para ver e corrigir costuma cumprir compliance melhor do que o portão que atrasa o time e é contornado com cartão pessoal.

Resiliência também muda de ênfase. O datacenter tradicional compra redundância cara e espera não usar. A nuvem favorece automação: instância some, o grupo sobe outra; zona falha, o balanceador tira de rota. Redundância continua existindo, mas o valor está no reconstitui, não no ferro em espera que ninguém testa.

Hábito antigo	Hábito de nuvem	Se você não muda
Capacidade para 3 anos	Capacidade para o próximo pico	Paga o pico o ano inteiro
Servidor com nome	Imagem e grupo	Pet na nuvem, mesmo risco
Orçamento absoluto	Consumo e taxa	Elasticidade na gaveta
Controle na entrada	Transparência na operação	Shadow IT com cartão
Redundância parada	Automação que recria	DR de papel

Mudar de país e levar o mesmo dia a dia

A analogia é grosseira e boa: mudar para outro país e insistir no horário, na comida e nas regras do bairro antigo. Era melhor ter mudado só de rua. Lift-and-shift pode ser etapa. Como destino, é aluguel de datacenter com complexidade extra — IAM, conta, suporte, câmbio.

Estilo de nuvem aparece em decisões pequenas. Time pode subir um ambiente de teste na terça e apagar na quinta? O custo do experimento cabe no cartão do time ou precisa de projeto semestral? Quando a carga cai à meia-noite, alguma coisa realmente desliga? Se as três respostas forem não, a fatura vai ensinar o que o slide não ensinou.

Isso não pede fé. Pede instrumento: tag obrigatória de dono, alerta de orçamento, política de desligar staging, preferência por serviço gerenciado onde o fardo operacional não gera vantagem. EC2 continua válido. Carrinho cheio de EC2 como primeira resposta não é nuvem; é compra de servidor com API.

Três perguntas para a próxima decisão

1. Estou pagando por estoque (máquina ligada) ou por fluxo (uso real)?
2. Se a demanda dobrar na sexta e cair no domingo, o que o sistema faz sozinho?
3. Se o experimento falhar, em quanto tempo o custo vai a zero?

A terceira é a mais honesta. Nuvem que não consegue ir a zero não é elástica. É capex parcelado. O valor da plataforma está nas opções futuras: crescer sem esperar o fornecedor, encolher sem processo de desfazimento de três meses, tentar um caminho sem fingir certeza de cinco anos.

Servidor continua existindo, inclusive na AWS. O que não deveria sobreviver é o hábito de comprá-lo como se o mundo não tivesse derivada.

A nuvem não apaga a necessidade de entender o programa. Em C One e no restante da Programming One, o caminho é o mesmo: o que o processo faz, o que o sistema cobra, o que a conta só multiplica.

Leia também: AWS EC2: o que está por trás da instância e Escalabilidade vertical e horizontal.