Atualizado em
Workloads elegíveis para Cloud Repatriation: como classificar seu ambiente workload por workload
Não existe resposta de “tudo ou nada”. A decisão de repatriar é tomada carga por carga, com base em cinco critérios objetivos. Este guia mostra como fazer essa classificação de forma sistemática.
Resumo Executivo
Sumário
- O que é um workload (e como delimitar)
- Os 5 critérios de elegibilidade
- Ferramenta de scoring por workload
- Workloads de alta elegibilidade
- Workloads com elegibilidade condicionada
- Workloads não elegíveis
- Tabela de referência completa
- Como montar seu inventário de workloads
- Erros comuns na classificação
- FAQ
O que é um workload (e como delimitar)
Para fins de classificação de Cloud Repatriation, um workload é uma unidade funcional de computação que pode ser avaliada e migrada de forma relativamente independente. Pode ser uma aplicação, um banco de dados, um serviço de background, um ambiente de processamento batch ou um conjunto de containers com propósito único.
A delimitação correta é crucial: workloads muito granulares dificultam a análise (um microsserviço isolado raramente faz sentido avaliar sem o contexto do sistema); workloads muito amplos perdem a granularidade necessária para uma boa decisão (avaliar “toda a infraestrutura” como uma unidade perde a distinção entre cargas que deveriam repatriar e as que não deveriam).
Critérios para delimitar um workload
- Unidade de negócio: o workload serve a um propósito de negócio identificável (ERP, CRM, sistema de BI, e-commerce, sistema de arquivos).
- Ciclo de vida independente: pode ser provisionado, escalado e desligado com impacto limitado nos demais.
- Padrão de uso característico: tem seu próprio perfil de consumo de recursos (previsível vs. variável; continuo vs. batch).
- Responsável identificado: tem um dono claro — time de produto, área de negócio ou equipe de infraestrutura.
Para organizações com ambientes complexos, comece com o agrupamento por tag de projeto ou centro de custo no billing do provedor de cloud. Cada grupo de recursos sob a mesma tag pode ser tratado como um workload candidato à avaliação.
Os 5 critérios de elegibilidade
A elegibilidade de um workload para repatriação não é binária — é uma função de cinco dimensões independentes. Um workload pode pontuar alto em custo e baixo em conformidade; outro pode ser o oposto. O score composto orienta a decisão.
Critério 1 — Previsibilidade de demanda
Workloads com consumo de recursos estável e previsível ao longo do tempo são os melhores candidatos à repatriação. A cloud pública cobra um prêmio de conveniência que só tem valor real quando há necessidade de elasticidade. Sem elasticidade real, é apenas custo adicional.
Como medir: calcule o coeficiente de variação (desvio padrão ÷ média) do consumo de CPU e memória nos últimos 90 dias. Variação abaixo de 20% = alta previsibilidade; acima de 50% = baixa previsibilidade.
Critério 2 — Intensidade de dados
Workloads que armazenam grandes volumes de dados e os transferem frequentemente para fora do ambiente de cloud geram egress fees expressivas. Para esses workloads, a eliminação do egress em cloud privada pode, por si só, justificar a repatriação.
Como medir: verifique o volume de egress mensal do workload no billing do provedor. Acima de 5 TB/mês = alta intensidade; abaixo de 500 GB/mês = baixa intensidade.
Critério 3 — Conformidade e regulação
Workloads que processam dados pessoais (LGPD), dados financeiros (BACEN), dados de saúde (ANS/ANVISA) ou dados estratégicos sensíveis têm exigências de auditabilidade, localização e controle que são mais facilmente atendidas em infraestrutura privada certificada.
Como medir: existe exigência regulatória específica sobre localização, acesso ou auditoria dos dados deste workload? A resposta é qualitativa, mas impacta o score diretamente.
Critério 4 — Acoplamento a serviços nativos de cloud
Quanto mais um workload depende de serviços gerenciados nativos do provedor sem equivalente open-source ou portável, mais difícil e cara é a migração. Um workload com banco de dados PostgreSQL gerenciado pode migrar para PostgreSQL auto-hospedado com relativa facilidade. Um workload que usa DynamoDB, Lambda e SQS requer reescrita significativa.
Como medir: liste todos os serviços do provedor que o workload consome. Substitua cada um pela alternativa open-source equivalente. Serviços sem equivalente simples = alto acoplamento.
Critério 5 — TCO comparativo
O custo total de ownership comparativo entre cloud pública e cloud privada em horizonte de 36 meses. Workloads com maior diferença de TCO favorável à cloud privada têm maior elegibilidade econômica.
Como medir: use a metodologia de TCO descrita no artigo correspondente desta série.
Ferramenta de scoring por workload
Para cada workload candidato, atribua um score de 1 a 5 em cada dimensão. Some os cinco scores. O total orienta a decisão de elegibilidade.
Workloads de alta elegibilidade
Estes workloads reúnem as características que tornam a repatriação economicamente e estrategicamente atrativa: uso contínuo e previsível, alto volume de dados, requisitos de conformidade e/ou forte diferencial de TCO.
Score ACRI tipicamente 18–25 — Priorizar para repatriação
Workloads com elegibilidade condicionada
Estes workloads têm características mistas. A decisão depende de análise mais detalhada — perfil de uso real, grau de acoplamento a serviços nativos e TCO específico do ambiente.
Score ACRI tipicamente 10–17 — Avaliar individualmente
Workloads não elegíveis
Estes workloads têm características que tornam a repatriação ineficiente, cara ou tecnicamente inviável. A recomendação é mantê-los em cloud pública e focar os esforços nos workloads elegíveis.
Score ACRI tipicamente 5–9 — Manter em cloud pública
Tabela de referência completa
| Workload | Classificação | Principal driver |
|---|---|---|
| Banco de dados OLTP (PostgreSQL, MySQL, Oracle) | Alta | Uso 24×7, alto custo RDS, dados sensíveis |
| ERP e sistema de gestão | Alta | Uso previsível, dados financeiros/pessoais, portável |
| Servidor de arquivos corporativo | Alta | Alto volume de storage, egress elevado |
| Backup e arquivamento | Alta | Volume massivo, egress na restauração, custo storage |
| PACS / imagens médicas | Alta | Dados de saúde, crescimento intenso, latência |
| SIEM e monitoramento centralizado | Alta | Ingestão massiva, custo por GB cobrado pelo provedor |
| Data warehouse previsível | Alta | Carga estável, alto egress de exports |
| CRM auto-hospedado | Alta | Dados pessoais, uso horário comercial, portável |
| Aplicação web — tráfego estável | Condicionado | Avaliar variação histórica de tráfego |
| Kubernetes com cargas mistas | Condicionado | Repatriar cluster; manter burst em cloud pública |
| Inferência ML em produção | Condicionado | GPU dedicada se carga for previsível |
| ETL com janelas fixas | Condicionado | Depende das ferramentas — portável ou acoplado |
| Ambiente de QA regular | Condicionado | Avaliar frequência e duração dos ciclos |
| Funções serverless | Não elegível | Dependência estrutural do modelo serverless da cloud |
| Aplicação global multi-região | Não elegível | Sem equivalente privado para presença global |
| Desenvolvimento efêmero | Não elegível | Uso on-demand — privado ficaria ocioso |
| Carga com pico sazonal intenso | Não elegível | Elasticidade da cloud pública tem valor econômico real |
| CDN e entrega de conteúdo | Não elegível | Presença global impossível de replicar privatamente |
| Treino de modelos ML/AI | Não elegível | GPU elastic necessário; carga não-contínua |
| SaaS integrado (Salesforce, HubSpot) | Não elegível | Dependência de SaaS de terceiro; sem infraestrutura para repatriar |
Como montar seu inventário de workloads
O inventário de workloads é a entrada obrigatória para qualquer análise de Cloud Repatriation. Sem ele, a tomada de decisão é baseada em intuição — e a intuição em infraestrutura de TI é notoriamente imprecisa.
Exportar todos os recursos com custo do provedor
Use o Cost and Usage Report (AWS), Billing Export (GCP) ou Cost Management Export (Azure) para extrair todos os recursos com custo dos últimos 3 meses. Filtre por tag de projeto ou centro de custo para agrupar por workload.
Identificar e nomear cada workload
Agrupe recursos por propósito de negócio. Um banco de dados, as instâncias de aplicação que o usam e o load balancer na frente formam um único workload, não três. Nomeie cada workload de forma que o responsável de negócio reconheça.
Coletar 8 atributos por workload
Para cada workload: (1) nome e responsável, (2) ambiente (prod/staging/dev), (3) custo mensal médio (últimos 3 meses), (4) percentual de egress no custo total, (5) variação de consumo de CPU/memória (estável/variável), (6) dados pessoais ou regulados (sim/não), (7) serviços nativos de cloud utilizados, (8) documentação e SLA exigido.
Aplicar o scoring de 5 dimensões
Para cada workload candidato (produção, custo acima de R$ 3.000/mês), aplique o scoring de D1 a D5 descrito na seção anterior. Priorize os workloads com score acima de 18 para análise de TCO detalhada.
Construir a lista priorizada
Ordene os candidatos por score de elegibilidade × impacto de custo (score × custo mensal). Workloads com alto score E alto custo têm prioridade máxima para análise de TCO e planejamento de migração.
O Cloud Repatriation Assessment da Adentro inclui template de inventário de workloads em planilha, com fórmulas de scoring pré-configuradas e integração com exportação de billing de AWS, Azure e GCP. O preenchimento guiado leva em média 2 horas para ambientes de até 50 workloads.
Erros comuns na classificação de workloads
1. Classificar o ambiente inteiro, não cada workload
“Nossa cloud pública é cara” não é suficiente para decidir o que repatriar. O mesmo ambiente pode ter 3 workloads altamente elegíveis e 8 que devem ficar. A análise granular por workload é inegociável.
2. Assumir que “banco de dados = sempre repatriar”
Um banco de dados de desenvolvimento com 5 GB e uso efêmero não é candidato à repatriação. Um banco de dados de produção com 8 TB rodando 24×7 provavelmente é. O tipo de workload é apenas o ponto de partida — o perfil de uso decide.
3. Ignorar o acoplamento oculto
Um workload que parece portável pode ter dependências não óbvias: chamadas a APIs nativas do provedor no código da aplicação, formato proprietário de storage, dependência de IAM role específica. Uma análise de acoplamento requer revisão do código e da arquitetura — não apenas da lista de serviços no console.
4. Classificar sem dados históricos suficientes
Avaliar previsibilidade de demanda com menos de 90 dias de dados é arriscado. Sazonalidades mensais e eventos pontuais não aparecem em janelas menores. Use pelo menos 6 meses de dados para workloads com comportamento sazonal conhecido.
5. Não considerar interdependências entre workloads
Workloads raramente são completamente independentes. Migrar o banco de dados sem migrar a aplicação que o usa intensamente pode criar latência inter-ambiente cara (cloud pública → cloud privada). Mapear as dependências antes de definir a sequência de migração é essencial.
FAQ
Sim, e frequentemente é a abordagem mais eficiente. Um exemplo comum: mover apenas a camada de dados (banco de dados + storage) para cloud privada, mantendo a camada de aplicação em cloud pública. Isso elimina egress do banco para a internet e reduz o custo de storage, sem migrar a lógica de aplicação. A latência entre a aplicação em cloud pública e o banco em cloud privada precisa ser avaliada — um link dedicado (Direct Connect / ExpressRoute) resolve essa questão.
Workloads sem responsável identificado são um sinal de problema de governança, não apenas de inventário. Antes de classificar para repatriação, identifique o responsável. Se ninguém reconhecer o workload como necessário, ele é um candidato a desligamento — não a migração. Workloads ociosos custam dinheiro em qualquer ambiente.
Não necessariamente. A portabilidade do container diz respeito ao runtime — a imagem pode rodar em qualquer Kubernetes. Mas o workload pode depender de serviços externos ao container que são nativos da cloud (banco de dados gerenciado, filas gerenciadas, armazenamento proprietário). Avaliar a portabilidade do sistema completo, não apenas do container.
Após o scoring de elegibilidade, aplique um segundo critério: facilidade de migração. Workloads com poucos serviços, boa documentação, dados portáveis e responsável engajado migram mais rápido e com menor risco. Comece pelos de maior elegibilidade E menor complexidade de migração — o sucesso dos primeiros cria confiança e aprende para os mais complexos.
Sim. A classificação deve ser revisada periodicamente porque o ambiente muda: um workload serverless pode ser refatorado para containers portáveis; um sistema de pico sazonal pode ter seu padrão mudado com uma reformulação de produto; novas regulações podem tornar o controle privado obrigatório para dados antes sem exigência. Revisite o inventário a cada 12 meses.
Geralmente não como prioridade. Ambientes de staging têm uso intermitente, não são críticos para o negócio e se beneficiam da flexibilidade de cloud pública. A exceção é quando o staging precisa ser ambientalmente idêntico ao produção (para testes de conformidade ou regulação) — nesse caso, faz sentido repatriar junto com o ambiente de produção.
Classifique seus workloads com o Assessment Adentro
O Cloud Repatriation Assessment inclui o inventário completo, scoring por workload e priorização de migração — em uma sessão de trabalho conjunto com nossa equipe técnica.
Para a visão estratégica completa de Cloud Repatriation — incluindo ACRI, checklist e exemplos por segmento:
