Estratégia de priorização e migração - AWS Orientação prescritiva

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Estratégia de priorização e migração

Um elemento-chave do planejamento da migração é estabelecer critérios de priorização. O objetivo desse exercício é entender a ordem na qual os aplicativos serão migrados. A estratégia é adotar uma abordagem iterativa e progressiva para desenvolver o modelo de priorização.

Priorizando aplicativos

Essa etapa da avaliação se concentra em estabelecer critérios iniciais para priorizar cargas de trabalho de baixo risco e baixa complexidade. Essas cargas de trabalho são boas candidatas para aplicativos piloto. Usar cargas de trabalho de baixo risco e baixa complexidade nas migrações iniciais reduz o risco e dá às equipes a oportunidade de ganhar experiência. Esses critérios serão desenvolvidos em outros estágios de avaliação para alinhar a priorização aos fatores de negócios ao criar o plano da onda de migração.

Os critérios iniciais devem priorizar aplicativos com um pequeno número de dependências, executados em infraestrutura suportada pela nuvem e em ambientes que não sejam de produção. Um exemplo seriam aplicativos com 0 a 3 dependências prontas para serem rehospedados como estão em um ambiente de desenvolvimento ou teste. Esses critérios são válidos para definir os aplicativos piloto e, potencialmente, a primeira e a segunda ondas de migração, dependendo do nível de maturidade e dos níveis de confiança na adoção da nuvem.

Decidindo quais critérios iniciais usar

Selecione de 2 a 10 pontos de dados a serem usados para priorizar suas primeiras cargas de trabalho. Esses pontos de dados vêm do seu inventário inicial de aplicativos e infraestrutura (consulte a seção de coleta de dados).

Em seguida, defina uma pontuação ou peso para cada valor possível de cada ponto de dados. Por exemplo, se o atributo de ambiente for selecionado e os valores possíveis forem produção, desenvolvimento e teste, cada valor receberá uma pontuação, um número maior representando maior prioridade. Embora seja opcional, recomendamos atribuir um fator multiplicador de importância ou relevância a cada ponto de dados. Essa etapa opcional fornece um diferencial de alto nível para enfatizar o que é mais importante, o que ajuda a manter os critérios alinhados à medida que você itera a atribuição de pontuações aos valores.

Com base na estratégia de priorizar aplicativos simples e de baixo risco para as primeiras ondas de migração, a tabela a seguir mostra exemplos de seleção de atributos e suas atribuições de valor.

Atributo (ponto de dados)

Possíveis valores

Pontuação (0-99)

Fator multiplicador de importância ou relevância

Ambiente

Teste

60

Alto (1x)

Desenvolvimento

40

Produção

20

Criticidade dos negócios

Baixo

60

Alto (1x)

Médio

40

Alta

20

Estrutura regulatória ou de conformidade

Nenhum

60

Alto (1x)

FedRAMP

10

Suporte ao sistema operacional

Pronto para a nuvem

60

Médio-alto (0,8x)

Não suportado na nuvem

10

Número de instâncias computacionais

1 a 3

60

Médio-alto (0,8x)

4-10

40

11 ou mais

20

Estratégia de migração

Redefinir a hospedagem

70

Médio (0,6x)

Redefinir a plataforma

30

Refatore ou reestruture

10

Certifique-se de selecionar atributos que possam atuar como principais diferenciais entre os aplicativos. Caso contrário, os critérios resultarão em muitas cargas de trabalho compartilhando a mesma prioridade. Depois de aplicar o modelo, recomendamos examinar a parte superior e inferior da classificação resultante para ver se você concorda. Se você geralmente não concorda, pode rever os critérios usados para pontuar as cargas de trabalho.

Depois de obter uma classificação, veja a distribuição das pontuações em todo o portfólio. As pontuações em si não importam. É a diferença entre as pontuações que importa. Por exemplo, você pode descobrir que a pontuação total máxima é 8.000 e a pontuação inferior é 800. Considere traçar as pontuações resultantes como um histograma, para que você possa verificar se tem uma boa distribuição. A distribuição ideal parece uma curva de sino padrão, com algumas cargas de trabalho de prioridade muito alta e algumas cargas de trabalho de prioridade muito baixa. A maioria dos aplicativos estará em algum lugar intermediário.

Outro aspecto importante da priorização inicial é incluir equipes internas ou unidades de negócios que demonstrem interesse em serem pioneiras na adoção da nuvem. Isso pode ser uma alavanca considerável na obtenção de suporte comercial para migrar um determinado aplicativo, especialmente nos primeiros dias. Se esse for o caso em sua organização, inclua o atributo da unidade de negócios na tabela anterior. Atribua uma pontuação alta às unidades de negócios que estão dispostas a apresentar seus aplicativos. Usar o atributo de unidade de negócios ajudará a colocar esses aplicativos no topo da lista.

Depois de concordar com a classificação resultante, selecione os 5 a 10 melhores aplicativos. Esses serão seus candidatos iniciais à migração de aplicativos. Refine a lista para confirmar de 3 a 5 inscrições. Isso ajuda você a adotar uma abordagem direcionada ao realizar uma avaliação detalhada do aplicativo. Para obter mais informações, consulte Avaliação de aplicativos priorizados.

Determinando o tipo R para migração

A decisão sobre uma estratégia de migração para cada aplicativo e infraestrutura associada terá implicações na velocidade, no custo e no nível de benefícios da migração. É fundamental determinar a estratégia com base em uma combinação equilibrada de fatores, incluindo motivadores de negócios, princípios orientadores técnicos, critérios de priorização e estratégia de negócios.

Às vezes, esses fatores criam visões conflitantes. Por exemplo, o principal fator para a migração pode ser inovação e agilidade. Ao mesmo tempo, talvez seja necessário reduzir custos rapidamente. A modernização de todos os aplicativos dentro do escopo reduzirá os custos a longo prazo, mas exigirá um maior investimento inicial. Nesse caso, uma abordagem é migrar aplicativos usando estratégias que exijam menos esforço, como rehospedar ou reformular a plataforma. Isso pode proporcionar eficiência rápida e redução de custos no curto prazo. Em seguida, reinvista a economia na modernização do aplicativo em um estágio posterior e obtenha uma maior redução de custos.

No entanto, começar com uma nova hospedagem completa de todos os aplicativos atrasa os maiores benefícios da modernização. A chave é encontrar o equilíbrio entre as estratégias de migração para que os aplicativos estratégicos de negócios sejam priorizados para modernização, enquanto outros aplicativos possam ser rehospedados ou reformulados primeiro e depois modernizados.

Como determinar uma estratégia de migração para seus aplicativos?

Nesse estágio de avaliação, o foco é incorporar um modelo inicial para orientar a seleção da estratégia de migração. Para validar a estratégia de migração para os aplicativos iniciais, use o modelo em conjunto com os impulsionadores de negócios e os critérios de priorização. A lógica padrão da árvore decisória ajudará você a determinar o tratamento inicial para o escopo. Na árvore, as abordagens mais complexas, como refatorar ou rearquitetar, são reservadas para suas cargas de trabalho estratégicas.

Diagrama do processo de decisão de 6 R discutido neste guia.

Uma versão draw.io personalizável desse diagrama está disponível na seção Anexos.

A primeira etapa para um modelo inicial é atualizar os drivers de negócios no topo da árvore com aqueles definidos pela sua organização. Em seguida, aplique a árvore aos componentes do aplicativo, e não aos aplicativos como um todo. Por exemplo, no caso de um aplicativo de três camadas com três componentes (front-end, camada de aplicativo e banco de dados), cada componente deve transitar pela árvore de forma independente e receber uma estratégia e um padrão específicos. Isso ocorre porque, em alguns casos, talvez você queira rehospedar ou reformular uma determinada camada e refatorar (rearquitetar) outras camadas.

A atribuição independente de componentes levará você a definir uma estratégia de migração para a infraestrutura associada. A estratégia de infraestrutura pode ser a mesma do componente do aplicativo ao qual ela oferece suporte, ou pode ser diferente. Por exemplo, um componente do aplicativo que será reformulado em uma nova máquina virtual com um sistema operacional mais novo seguirá a estratégia de replataforma, enquanto a máquina virtual atual que o hospeda será desativada. A estratégia de migração da infraestrutura é calculada com base na estratégia escolhida para os componentes do aplicativo.

Antes de usar a árvore decisória para estabelecer estratégias de migração, teste a lógica com alguns aplicativos e veja se você geralmente concorda com o resultado. A árvore de decisão de 6 Rs é um guia que não substitui a análise necessária para determinar sua exatidão. A lógica da árvore pode não se aplicar a casos específicos. Trate esses casos como exceções e anule a decisão orientada pela árvore documentando a justificativa para a substituição em vez de alterar a lógica da árvore. Isso evita várias versões da árvore de decisão, que podem se tornar difíceis de gerenciar. A orientação geral é que a árvore seja válida para pelo menos 70 a 80 por cento das cargas de trabalho. Quanto ao resto, haverá exceções. Quaisquer ajustes na lógica da árvore, nesse estágio de avaliação, devem ser focados no estabelecimento de um modelo inicial. Outras iterações e refinamentos ocorrerão em estágios posteriores, como análise de portfólio e planejamento de migração.

Anexos

attachment.zip