Blog/Artigos · Cloud e Plataforma
Os 6 Rs de rehost a refactor, a tensão entre lift-and-shift e reescrever, as ondas de migração e o mapeamento de dependência.
A Torá dedica um capítulo inteiro a listar, uma por uma, as jornadas do povo pelo deserto: estas são as etapas, daqui para ali, dali para adiante. Não foi um salto do Egito para a terra; foi uma travessia longa, por estágios, cada acampamento uma decisão. Migração para a nuvem é uma jornada assim, e tratá-la como salto é o erro que arruína projetos. Não se levanta tudo de uma vez e se deixa cair na nuvem torcendo. Cada carga é uma etapa da jornada, com uma decisão própria sobre como se move, e a travessia acontece em ondas, com mapa, não numa mudança apressada onde se joga tudo no caminhão e se descobre o que quebrou só na chegada.
O erro mais comum em migração é começar pelo como antes do quê e do porquê. Times mergulham em mover servidores sem antes entender o portfólio: o que existe, o que depende de quê, o que vale a pena mover, o que deveria morrer. O resultado é a migração que atravessa o deserto sem mapa, descobrindo dependências escondidas quando algo quebra em produção, estourando prazo e orçamento, e às vezes chegando à nuvem com uma cópia fiel do caos que havia no datacenter, agora mais cara.
A jornada madura tem fases claras, e a AWS as organiza em avaliar, mobilizar e migrar e modernizar. A avaliação entende o portfólio e monta o caso de negócio. A mobilização prepara a fundação, a Landing Zone, as habilidades, o plano de ondas. A migração move as cargas em levas, e a modernização otimiza o que já está lá. Pular a avaliação para começar a mover é o atalho que mais custa caro: cada acampamento da jornada existe para que o próximo seja possível, e sair correndo do primeiro é como marchar no deserto sem saber para onde nem com o quê.
Cada acampamento existe para o próximo ser possível. Pular a avaliação para começar a mover é o atalho que mais custa caro na jornada inteira.
Para cada carga do portfólio, há uma decisão de como movê-la, e o mercado a organiza nos 6 Rs, popularizados por Gartner e AWS. Rehost é o lift-and-shift: mover como está, sem mudar, rápido e de baixo risco. Replatform é mover com pequenos ajustes que colhem algum benefício, como trocar um banco autogerenciado por um gerenciado. Repurchase é abandonar o software próprio e comprar um SaaS que faz o mesmo. Refactor é reescrever para nativo da nuvem, caro e demorado, mas com o maior retorno. Retire é desligar o que ninguém usa mais. Retain é manter onde está, por ora, o que não faz sentido mover.
A sabedoria dos 6 Rs não é escolher um para tudo; é escolher conscientemente para cada carga. Um sistema legado estável e sem futuro merece rehost ou retain, não uma reescrita cara. Uma carga central para o negócio, que vai crescer, justifica o refactor. Um software de prateleira que alguém mantém sem valor agregado pede repurchase. E o mais esquecido dos Rs, o retire, costuma ser o de maior retorno imediato: uma parte relevante do que roda no datacenter não é usado por ninguém, e a migração é a chance rara de descobrir isso e simplesmente desligar, em vez de pagar para mover lixo.
A grande briga da migração é entre rehost e refactor, e ela não tem vencedor universal. O rehost é rápido, barato e de baixo risco, e tira você do datacenter logo, mas leva para a nuvem uma aplicação que não foi feita para ela: não escala elástico, não usa serviço gerenciado, e muitas vezes fica mais cara do que era, porque paga por máquina ociosa que na nuvem custa a cada hora. O refactor colhe todo o benefício da nuvem, elasticidade, gerenciado, resiliência nativa, mas é um projeto de engenharia longo e caro, e adia a saída do datacenter.
A resposta madura quase nunca é escolher um dos extremos para tudo, e sim sequenciar. Uma estratégia comum e sensata é rehost primeiro para sair do datacenter rápido, parando de pagar o contrato antigo, e refactor depois, com calma, nas cargas que justificam. O perigo dessa estratégia é o depois que nunca chega: a empresa faz o lift-and-shift, respira aliviada, e congela, ficando para sempre com aplicações caras e não nativas rodando na nuvem, colhendo o custo da nuvem sem o benefício dela. Quem escolhe rehost como primeira etapa precisa se comprometer, por escrito, com a etapa de modernização que vem depois, ou a jornada para no pior acampamento.
Migração séria acontece em ondas, não de uma vez. Uma onda é um conjunto de cargas migradas juntas, escolhido para equilibrar risco e aprendizado. A primeira onda costuma ser deliberadamente fácil: cargas simples, de baixo risco, pouco acopladas, para o time aprender o processo e afinar as ferramentas onde errar não dói. As ondas seguintes crescem em complexidade à medida que a confiança e a maquinaria de migração amadurecem. É o pouco a pouco de novo: cada onda ensina, e a próxima é mais ambiciosa porque a anterior provou o caminho.
O que torna as ondas possíveis é o mapa de dependência. A pior surpresa da migração é mover uma aplicação e descobrir, em produção, que ela dependia de um serviço que ficou no datacenter, ou que outra aplicação dependia dela silenciosamente. Mapear quem fala com quem, antes de mover, é o que evita cortar um fio que segurava algo invisível. Esse mapa é difícil de fazer à mão, porque as dependências reais raramente batem com a documentação, e é onde a análise do tráfego real vale ouro: ela mostra as conversas que de fato acontecem, e não as que alguém achou que existiam.
A migração amadurece do salto às cegas à jornada instrumentada. No começo é mover servidores sem avaliação, torcendo. Depois vem o uso dos 6 Rs como quadro de decisão consciente. No meio é a migração em ondas com mapa de dependência. No topo é a jornada guiada por dado, com a decisão de R por carga fundamentada em uso e custo, e o compromisso escrito com a modernização que vem depois do rehost. Cada degrau troca surpresa por previsão, e o custo de errar cai a cada onda que ensina a seguinte.
A migração não é o começo nem o fim da jornada na nuvem. Antes dela vem a Landing Zone, a fundação onde as cargas aterrissam; sem ela, migra-se para a bola de lama. Depois dela vem a modernização, que colhe o benefício nativo, e a maturidade de cloud, que sobe degrau por degrau. A migração é o meio da travessia, o conjunto de acampamentos entre o datacenter e a nuvem madura. Listar as jornadas, uma por uma, como a Torá faz, não é burocracia: é o reconhecimento de que a travessia se faz por etapas conscientes, e que cada uma existe para tornar a próxima possível.
Migração para a nuvem é jornada por etapas conscientes, como as jornadas que a Torá lista uma a uma, não um salto às cegas. Os 6 Rs dão a decisão certa para cada carga, do rehost rápido ao refactor nativo, e o retire esquecido rende mais que todos. A jornada acontece em ondas, com mapa de dependência pelo tráfego real, e o perigo maior é o rehost que congela sem a modernização prometida. A IA inventaria, mapeia e recomenda o R por dado. Mas escolher o R de uma carga central, e comprometer-se com o depois, continua sendo decisão de arquitetura e de negócio de quem conduz a travessia.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Cloud e Plataformaיְסוֹד
Quem começa na nuvem com uma conta só constrói na areia e paga depois. Landing Zone é a fundação lançada antes: múltiplas contas que isolam o dano, guardrails no nível da organização e um baseline que toda conta nova herda pronto.
Cloud e Plataformaמַעֲלוֹת
Um modelo de cinco níveis para maturidade de cloud, como medir pelos seis pilares, onde a IA encurta a subida e o que fazer nos primeiros 90 dias.
