A Falácia da Migração para a Cloud: Porque o 'Lift and Shift' Custa Mais

A ilusão da poupança na cloud

Segundo a Gartner, a despesa global em cloud pública vai ultrapassar 1 bilião de dólares até 2027. Na última década, muitos Diretores de TI justificaram esta despesa com a promessa de redução de custos, a premissa de que encerrar o datacenter corporativo e entregar a operação à AWS ou Azure cortaria automaticamente a despesa de infraestrutura, reduziria equipas e converteria despesa de capital (CapEx) em despesa operacional gerível (OpEx).

A realidade para muitas empresas de SaaS B2B empresariais tem sido o oposto exato. Após concluírem uma dolorosa migração de dois anos, abrem a primeira fatura consolidada da AWS e descobrem que estão a gastar 30–50% mais do que gastavam em servidores físicos (bare-metal). Este fenómeno tem nome próprio: “Choque da Cloud.” É o resultado direto e previsível da estratégia de migração “Lift and Shift”. e é inteiramente evitável se compreenderes o que realmente estás a comprar quando alugas infraestrutura cloud.

O desajuste fundamental do Lift and Shift

O Lift and Shift (também chamado “rehosting”) é o caminho de menor resistência. Consiste em pegar em Máquinas Virtuais (VMs) legadas e migrá-las diretamente para instâncias cloud. As equipas de manutenção não mudam nada na arquitetura da aplicação, a mesma aplicação monolítica Java que corria num Dell PowerEdge na cave de uma fábrica ou de uma grande clínica agora corre numa instância m5.4xlarge EC2 em eu-west-1. O sistema operativo é o mesmo. A alocação de memória é a mesma. A base de dados é a mesma. A única diferença é a fatura.

O desastre financeiro deriva da diferença entre a forma como as aplicações legadas gerem recursos e a forma como a faturação cloud funciona. Um monólito on-premise é tipicamente provisionado para a carga máxima. Se a aplicação precisa de 64GB de RAM durante um pico de tráfego na Black Friday, tem 64GB de RAM alocados permanentemente, em janeiro, em julho, às 3h da manhã de uma terça-feira. On-premise, este sobre-provisionamento é aceitável porque o servidor é um custo afundado. Já pagaste o hardware.

Na cloud, estás a alugar computação à hora. Alocar uma instância EC2 com 64GB de RAM que fica inativa a 5% de utilização durante 11 meses do ano é suicídio financeiro. O contador da cloud corre continuamente, indiferente a se a tua aplicação está a processar 10.000 pedidos por segundo ou zero. Estás a pagar um prémio massivo por um ambiente altamente elástico enquanto o usas de forma completamente estática, o pior dos dois mundos.

# Comparação real de custos: Lift-and-shift vs. dimensionamento correto
# On-premise: Dell PowerEdge R740 (64GB RAM, 16 cores)  -  ~$8.000 amortizado em 3 anos = ~$222/mês
# Cloud (Lift-and-Shift): AWS m5.4xlarge (64GB, 16 vCPU) on-demand = ~$550/mês
# Cloud (Dimensionado): AWS t3.xlarge (16GB, 4 vCPU) + auto-scaling = ~$120/mês média

# A migração ingénua custa 2.5x o servidor on-premise.
# A migração corretamente arquitetada custa 54% do servidor on-premise.

Rearquitetar para o modelo de custo variável

Para poupar dinheiro de verdade na cloud, as aplicações têm de ser rearquitetadas para a elasticidade. Uma verdadeira migração de plataforma exige decompor o monólito em cargas de trabalho que possam escalar para cima, escalar para baixo, e (criticamente) escalar para zero de forma independente.

Em vez de correres uma VM de base de dados massiva com 32GB fixos alocados, migras para um serviço gerido (como o Amazon Aurora ou Google Cloud SQL) que escala automaticamente réplicas de leitura durante os picos de tráfego e as desliga durante a noite. Em vez de correres o teu servidor API numa instância dedicada 24/7, implementa-lo como um workload containerizado atrás de um Kubernetes Horizontal Pod Autoscaler que adiciona réplicas quando o CPU ultrapassa 70% e as remove quando a procura baixa.

# Elasticidade cloud-native via Kubernetes HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: billing-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: billing-service
  minReplicas: 2        # Mínimo always-on para disponibilidade
  maxReplicas: 50       # Capacidade de burst para eventos de pico
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # Prevenir oscilações
      policies:
      - type: Percent
        value: 25
        periodSeconds: 60

O modelo de faturação também oferece ferramentas de compromisso sofisticadas que a maioria das equipas de lift-and-shift nunca usa. AWS Reserved Instances e Savings Plans oferecem descontos de 30–72% para utilização comprometida. Spot Instances oferecem descontos de 60–90% para cargas de trabalho interruptíveis como processamento batch, pipelines de CI/CD e transformação de dados. Um deployment cloud corretamente arquitetado usa uma estratégia em camadas: capacidade reservada para a base, auto-scaling on-demand para picos previsíveis, e instâncias spot para tudo o que tolere interrupção.

O contra-argumento da repatriação

O choque de custos cloud gerou um contra-movimento: a repatriação cloud. A Basecamp (agora 37signals) migrou famosamente para fora da AWS em 2022, reclamando poupanças projetadas de 7 milhões de dólares em cinco anos. O argumento deles é direto, se a tua carga de trabalho é previsível e estável, a elasticidade cloud não proporciona benefício nenhum, e estás simplesmente a pagar um prémio por infraestrutura que podias possuir.

Esta é uma posição arquitetónica válida, mas aplica-se a um conjunto restrito de empresas. A repatriação faz sentido quando: (1) os teus padrões de tráfego são planos e previsíveis, (2) tens a equipa DevOps para gerir hardware físico, (3) não precisas de distribuição geográfica, e (4) já amortizaste o custo de migração. Para a vasta maioria das plataformas SaaS B2B (especialmente as com tráfego variável, utilizadores globais, ou ambições de scaling agressivo) a cloud permanece a arquitetura correta. O problema nunca foi a cloud em si. O problema foi migrar para a cloud sem mudar a arquitetura.

FinOps: Engenharia para o custo como métrica de primeira classe

A migração cloud não é um destino; é um modelo operacional arquitetónico. Exige a adoção de princípios de FinOps, uma prática cultural e de engenharia que traz responsabilidade financeira ao modelo de despesa variável da cloud.

A FinOps Foundation define um modelo de maturidade com três fases: Informar (visibilidade sobre o que estás a gastar), Otimizar (dimensionamento correto, compra de compromissos, eliminação de desperdício), e Operar (governança de custos contínua integrada no fluxo de trabalho de engenharia). A maioria das organizações que sofrem choque de cloud está presa na primeira fase, conseguem ver a fatura, mas não têm processos de engenharia para atuar sobre ela.

Uma prática de FinOps madura, o modelo que o x078 implementa para clientes SaaS B2B que gerem estates multi-cloud, embute o custo como um requisito não-funcional ao lado da latência, uptime e segurança. Cada pull request que provisiona um novo recurso cloud deve incluir uma estimativa de custo. Cada pipeline de deployment deve emitir telemetria de custo. Cada retrospetiva de sprint deve incluir uma revisão da variância do orçamento cloud. Isto não é um exercício de contabilidade, é uma disciplina de engenharia.

Se a tua equipa técnica acredita que “a cloud é apenas o computador de outra pessoa”, a tua migração vai falhar financeiramente. A cloud é uma API hiper-otimizada para alugar computação ao milissegundo. Se não refatorares o teu software para desligar a luz quando sai da sala, a cloud vai levar a tua empresa à falência mais rápido do que o datacenter alguma vez faria.