Os 7 Rs da migração para a nuvem: como escolher o método certo

Por que 7R?

O modelo R não é novo, mas evoluiu significativamente ao longo dos anos. Sua gênese é frequentemente atribuída ao Gartner, que criou o modelo 5Rs em 2010. Os cinco Rs originais eram realocar, refatorar, revisar, reconstruir e substituir.

À medida que a nuvem continuou a evoluir e cargas de trabalho mais diversas foram migradas para ela, a AWS adicionou um sexto R (retirar) e, eventualmente, um sétimo (reter). Este sétimo R é, na verdade, um reconhecimento de que nem todas as cargas de trabalho são adequadas para serem hospedadas na nuvem.

Aqui está o que cada um dos 7 Rs significa na prática.

1. Rehost – Realojamento ou Rehospedagem

A rehospedagem costuma ser conhecida como "lift and shift" e envolve mover um aplicativo como está para a nuvem.

A rehospedagem pode ser feita de diversas maneiras, mas geralmente envolve a criação de máquinas virtuais baseadas em nuvem que imitam a infraestrutura na qual um aplicativo é executado atualmente. Como a infraestrutura em nuvem é muito semelhante à infraestrutura local, mover seu aplicativo para um novo local na nuvem torna-se uma tarefa relativamente simples. Por exemplo, algumas organizações hospedam novamente um aplicativo construindo sua infraestrutura virtual na nuvem e depois restaurando um backup para a nova infraestrutura baseada em nuvem. Geralmente há algumas pequenas tarefas pós-migração, como atualizar registros DNS para que o aplicativo possa ser acessado em seu novo local.

2. Relocate – Realocar

O segundo R, realocar, é semelhante ao realojamento. Ambos os métodos envolvem mover um aplicativo executado no local para uma instância de máquina virtual executada na nuvem, mas há uma diferença fundamental. Para hospedar novamente um aplicativo, você precisa criar uma instância de máquina virtual na nuvem e, em seguida, mover o aplicativo para essa instância. Por outro lado, a relocação envolve mover uma máquina virtual existente de um ambiente local para a nuvem sem fazer alterações significativas nela.

Digamos que sua organização use software de virtualização VMware e precise migrar uma de suas máquinas virtuais para a nuvem. Em vez de realizar um tedioso processo de migração manual, você pode encontrar um provedor que ofereça VMware na nuvem e migrar a máquina virtual para a nuvem do provedor.

A maior vantagem deste tipo de migração é a sua simplicidade. Outra vantagem é que, por usar uma versão em nuvem da plataforma de virtualização usada localmente, praticamente não há curva de aprendizado para a equipe de TI.

3. Replatform – Replataforma

Embora a relocação às vezes seja chamada de "elevação e mudança", a replataforma é mais uma "elevação e remodelação". Originalmente revisado no modelo 5 Rs do Gartner, às vezes é chamado de "lift, tinker and shift".

A ideia por trás da reestruturação é que, se você estiver migrando um aplicativo legado, os provedores de nuvem provavelmente oferecerão muitos recursos e capacidades que não existiam quando o aplicativo foi criado. Pode fazer sentido atualizar seu aplicativo como parte do processo de migração para que você possa aproveitar ao máximo o que a nuvem tem a oferecer, como escalabilidade e flexibilidade.

Mudar a plataforma de um aplicativo costuma ser caro e demorado, mas em alguns casos o esforço é justificado. Isso é especialmente verdadeiro se você estiver atualizando um aplicativo de linha principal de negócios de uma forma que aumentará a receita ou permitirá que você continue usando o aplicativo por anos.

Uma coisa a ter em mente é que nem todos os aplicativos podem mudar de plataforma. A troca de plataformas é principalmente uma opção para aplicativos de código aberto ou desenvolvidos internamente. Os fornecedores de software comercial normalmente não fornecem seu código-fonte, o que é um requisito absoluto para mudar de plataforma.

4. Refactor – Refatorar

O quarto R, refatorar, é como uma reestruturação, pois envolve a modificação de um aplicativo para aproveitar tudo o que a nuvem tem a oferecer, mas há diferenças importantes. Em particular, quando você reestrutura uma aplicação, sua arquitetura é preservada e ela continua a funcionar da mesma forma. Em comparação, a refatoração envolve fazer alterações arquitetônicas fundamentais no aplicativo. Por exemplo, você pode dividir um aplicativo em uma coleção de microsserviços.

A refatoração é sem dúvida o tipo mais difícil de migração, mas às vezes vale a pena como forma de preparar um aplicativo para o futuro. Assim como acontece com a refatoração, você precisa ter acesso ao código-fonte do aplicativo para refatorá-lo.

5. Repurchase – Recompra

O quinto R, recompra, tem vários significados. Por um lado, pode significar substituir um aplicativo local por um aplicativo nativo da nuvem que faça a mesma coisa. Também pode significar substituir um aplicativo local por uma versão SaaS do aplicativo.

Por último, a recompra pode referir-se à eliminação progressiva de componentes arquitetônicos legados em favor de sistemas gerenciados sem servidor. Por exemplo, uma organização pode substituir seu banco de dados SQL Server por um serviço gerenciado, no qual o provedor de nuvem executa o SQL Server na nuvem. A vantagem dessa abordagem (em comparação com a simples execução do SQL Server em uma máquina virtual baseada em nuvem) é que quando um banco de dados é oferecido como um serviço gerenciado, o provedor de nuvem cuida de toda a manutenção associada. O provedor mantém o serviço em execução, fornece a redundância necessária e cuida de qualquer gerenciamento de patches necessário.

6. Retire – Retirar

Nem sempre faz sentido mover todas as cargas de trabalho para a nuvem. Talvez seja melhor retirar alguns aplicativos antigos.

Uma carga de trabalho pode ser adequada para desativação se não for mais suportada ativamente pelo fornecedor. Nesses casos, é importante garantir que você tenha uma solução alternativa antes de descontinuar um aplicativo que ainda esteja em uso pela organização. Isso pode significar adotar um aplicativo concorrente que ofereça funcionalidade semelhante ou desenvolver um internamente.

Às vezes, você pode precisar fazer alterações significativas nos processos de negócios da sua organização antes de poder descontinuar um aplicativo obsoleto. Por exemplo, se um aplicativo não tiver mais suporte e as substituições adequadas tiverem um custo proibitivo, talvez seja melhor alterar os processos de negócios.

7. Retain – Reter

O sétimo R, reter, significa essencialmente deixar um aplicativo sozinho por enquanto.

Digamos que sua organização dependa de um aplicativo específico que esteja atualmente em execução no local. Embora possa haver pressão para movê-lo para a nuvem, o provedor anunciou uma versão SaaS para o final do ano. Provavelmente não faz sentido suportar o custo e o incômodo de uma migração para a nuvem quando você pode esperar que a versão na nuvem esteja disponível.

A estratégia de retenção também pode entrar em ação quando as dependências do aplicativo devem ser consideradas. Digamos, por exemplo, que sua organização tenha um aplicativo específico que você deseja migrar para a nuvem. Durante a fase de planejamento, você descobre que outro aplicativo em execução local depende do aplicativo que a organização deseja migrar e pode parar de funcionar. Nessa situação, o aplicativo deverá ser mantido em seu estado atual até que os aplicativos dependentes sejam migrados ou desativados.

Sobre o autor: Brien Posey é 22 vezes MVP da Microsoft e candidato a astronauta comercial. Em seus mais de 30 anos em TI, atuou como principal engenheiro de rede do Departamento de Defesa dos EUA e administrador de rede de algumas das maiores companhias de seguros dos Estados Unidos.