Processo de migração
A migração é um processo altamente replicável. No momento, você tem uma coleção de ativos binários (máquinas virtuais, aplicativos e dados) em um datacenter local. Amanhã, você deseja replicar esses ativos binários para a nuvem e mudar seu tráfego de produção para usar a nova cópia dos mesmos ativos.
Como a maioria dos processos replicáveis, a maior parte do trabalho pode ser automatizada para reduzir as tarefas humanas repetitivas. Contudo, como a maioria das equipes de migração descobre rapidamente, o processo replicável é a parte mais fácil. O que está oculto nesse processo são as ações de gerenciamento de alterações, que exigem decisões e intervenções humanas.
As disciplinas de migração a seguir descrevem como a ferramenta Migrações para Azure e o Cloud Adoption Framework trabalham juntos para moldar a intervenção humana, necessária em um processo replicável.
Migração em massa vs migração iterativa
Os ativos binários que estão sendo movidos para a nuvem teoricamente podem ser migrados em um lote grande. Algumas organizações tiveram êxito nas migrações em massa de todos os ativos usando Migrações para Azure. Isso requer um esforço planejado de análise e correção para garantir que todos os ativos sejam compatíveis com a nuvem. Além disso, também é preciso ter um plano detalhado para testar e certificar o desempenho de cada uma das cargas de trabalho executadas nesses ativos.
O grau de planejamento e o impacto sobre os usuários empresariais fazem com que a abordagem de migração em massa não agrade à maioria das organizações. Uma abordagem alternativa é aplicar os princípios das metodologias ágeis, como o Scrum, para dividir a migração em massa em ondas, migrando uma coleção menor de cargas de trabalho em um ritmo regular.
A abordagem iterativa para a migração permite que a empresa absorva as alterações em unidades menores, o que produz menos interrupções nos negócios. Também permite que a equipe meça e aprenda com cada iteração. A equipe consegue velocidade e experiência progressivamente de uma iteração para a próxima.
Para o restante deste módulo, você pode supor que a Tailwind Traders decidiu seguir uma abordagem iterativa para a migração.
Disciplinas
Em qualquer processo de migração iterativo, a equipe executa três conjuntos de tarefas ou disciplinas para migrar cada carga de trabalho para o Azure com sucesso:
Avaliar as cargas de trabalho: Durante a avaliação das cargas de trabalho em cada onda, os arquitetos buscam, principalmente, a compatibilidade com a nuvem e dependências entre os ativos. Eles também buscam a compatibilidade com oportunidades de modernização e otimização. Às vezes, chegam perto da arquitetura de cargas de trabalho individuais para executar tarefas avançadas de otimização usando a Revisão da Well-Architected Framework do Azure.
Implantar as cargas de trabalho: Durante a migração ou implantação de cargas de trabalho, a equipe usa uma ferramenta de migração para executar a replicação de ativos (máquinas virtuais, aplicativos e dados) na nuvem. Nessa etapa, a equipe estará, principalmente, direcionando e supervisionando o processo replicável para garantir uma replicação precisa dos ativos para as cargas de trabalho selecionadas.
Liberar cargas de trabalho: depois que cada plataforma de tecnologia e carga de trabalho é migrada para a nuvem, a equipe precisa testar, otimizar e liberar o tráfego de produção para as cargas de trabalho migradas recentemente. O teste também pode exigir uma avaliação do roteamento para o usuário e da otimização do caminho de rede para as cargas de trabalho implantadas recentemente.
Repetir essas três disciplinas em cada carga de trabalho no plano de migração garante uma migração bem-sucedida para a nuvem.
Planejamento de sprint
Ao planejar as iniciativas de migração, uma das primeiras etapas é dividir em grupos menores a lista de cargas de trabalho a serem migradas.
À medida que você aprende sobre a velocidade da sua equipe (quantas cargas de trabalho ela consegue migrar em um sprint), sugerimos que você comece com a abordagem Potência de 10. Nessa abordagem, defina de forma consistente grupos de 10 cargas de trabalho comuns em cada onda. Em seguida, você mapeia esses grupos de 10 cargas de trabalho para iterações ou sprints de duas semanas, usando seu plano de adoção da nuvem no Azure DevOps. Confira o módulo de Planejamento para obter diretrizes passo a passo.
Antes de cada sprint, a equipe de migração deve avaliar a próxima onda de cargas de trabalho a ser migrada. O objetivo dessa avaliação é garantir que a equipe tenha todas as informações necessárias e o acesso para ter êxito no sprint atual. Ela também dá à equipe a oportunidade de ajustar as próximas dez cargas de trabalho com base no que aprenderam com os sprints anteriores. Depois que a equipe estiver comprometida com o sprint, o trabalho real poderá começar.
Organização da equipe
Você pode aplicar princípios básicos de organização à estrutura da sua equipe para maximizar os resultados de cada sprint com base na velocidade disponível. As duas formas mais comuns de organização de equipe são:
Equipes auto-organizadas: Esse tipo de organização se alinha às metodologias ágeis. As equipes de organização própria garantem que os membros da equipe de migração possam realizar as atividades coletivamente em cada uma das disciplinas. Em cada sprint, a equipe identifica quem executa as tarefas associadas a cada disciplina em cada carga de trabalho na onda.
Nessa organização, o objetivo é concluir todas as três disciplinas para cada carga de trabalho no sprint atual.
Fábrica de migração: a natureza repetitiva das disciplinas de migração favorece uma divisão de trabalho em equipes altamente especializadas. Nessa abordagem, temos uma equipe dedicada a cada disciplina de migração. A equipe de avaliação está sempre uma a duas ondas à frente da equipe de migração. A equipe de liberação está sempre um a dois sprints atrás da equipe de migração.
A abordagem pode ser eficaz em grandes esforços de migração que incluem milhares de ativos e centenas de cargas de trabalho.
Obstáculos comuns
A tecnologia raramente bloqueia o processo de migração. A maioria dos bloqueadores da migração vêm de etapas perdidas em dependências upstream ou downstream no processo de migração. Abaixo, estão os bloqueadores listados do mais comum ao menos comum:
Estratégia e planejamento: é o bloqueador mais comum de uma migração bem-sucedida, decorrente de etapas perdidas durante esforços de estratégia ou de planejamento. A falha ao definir as expectativas corretas com executivos, gerentes de projeto ou equipe técnica pode criar bloqueadores, mesmo quando todas as disciplinas técnicas estão sendo executadas conforme o planejado.
Antes de iniciar qualquer esforço de migração em escala, verifique se você criou uma estratégia de adoção da nuvem e plano de adoção da nuvem, e se os stakeholders os revisaram.
Ambiental: ambientes configurados incorretamente são os próximos bloqueadores mais comuns de uma migração bem-sucedida. Especificamente, a iniciativa de migração requer um mínimo de configuração de rede e de identidade para cumprir os requisitos adequados de conectividade e acesso.
Para a maioria das iniciativas de migração, as considerações sobre governança e operações devem ser abordadas no início da migração, se não antes do processo de migração. Para garantir a configuração adequada do ambiente, confira o módulo de aprendizado do Cloud Adoption Framework referente a como preparar seu ambiente.
Governança: a maioria das organizações tem requisitos de custo, segurança, consistência e gerenciamento de identidades que vão além da configuração básica do ambiente. Muitas organizações não entendem esses requisitos até que tentem migrar o tráfego de produção para a nuvem.
Recomenda-se que todas as equipes de migração analisem o módulo Learn sobre a Metodologia de governança no Cloud Adoption Framework, antes de iniciar o esforço de migração em escala. A revisão dessas informações pode ajudar a evitar surpresas tardias.
Operações: a maioria das organizações tem conjuntos de requisitos de operações para suas cargas de trabalho de produção no datacenter. Geralmente, supõe-se que esses requisitos de operações funcionarão quando o tráfego de produção for movido para a nuvem. Antes que a equipe de migração comece qualquer esforço de migração em escala, ela deve analisar o módulo Learn sobre como desenvolver uma estratégia clara para entender as expectativas básicas sobre o gerenciamento de operações na nuvem.
Técnicos: às vezes, as cargas de trabalho podem ser bloqueadas devido ao aumento das necessidades de correção, modernização ou alterações na estratégia de racionalização. Quando cargas de trabalho individuais são bloqueadas, elas podem ser tratadas por picos técnicos, que removem cargas de trabalho problemáticas do fluxo padrão.
Normalmente, uma equipe separada aborda picos técnicos em um sprint paralelo. Uma equipe de migração pode abordar várias questões técnicas relacionados à correção e modernização. Os cenários de migração Cloud Adoption Framework compartilhados no final deste módulo abordam esses problemas.
Quando uma carga de trabalho requer alterações abrangentes que afetam a arquitetura do aplicativo, as equipes das cargas de trabalho devem analisar o módulo Learn do Well-Architected Framework para obter orientações adicionais.