Migrar para o Google Cloud: avalie e descubra suas cargas de trabalho

Last reviewed 2024-08-02 UTC

Use este documento para planejar, projetar e implementar a fase de avaliação da migração para o Google Cloud. Descobrir suas cargas de trabalho e inventário de serviços e mapear as dependências deles podem ajudar você a identificar o que precisa migrar e em que ordem. Ao planejar e projetar uma migração para o Google Cloud, primeiro você precisa ter um excelente conhecimento do seu ambiente atual e dos apps e cargas de trabalho que serão migrados.

Este documento faz parte da seguinte série de várias partes sobre a migração para o Google Cloud:

No diagrama a seguir, veja o caminho da sua jornada de migração.

Caminho de migração com quatro fases.

Este documento é útil se você planeja migrar de um ambiente local, de um ambiente de hospedagem particular, de outro provedor de nuvem ou avaliar a oportunidade de migração e explorar como seria a fase de avaliação.

Na fase de avaliação, você determina os requisitos e as dependências para migrar seu ambiente de origem para o Google Cloud.

A fase de avaliação é fundamental para o sucesso da migração. Você precisa ter um excelente conhecimento das cargas de trabalho que quer migrar, dos requisitos, das dependências e do ambiente atual. Você precisa saber seu ponto de partida para planejar e executar uma migração do Google Cloud.

A fase de avaliação consiste nas tarefas a seguir:

  1. Criar um inventário abrangente das suas cargas de trabalho.
  2. Catalogar suas cargas de trabalho de acordo com as propriedades e dependências delas.
  3. Treine e instrua suas equipes no Google Cloud.
  4. Criar experimentos e provas de conceito no Google Cloud.
  5. Calcule o custo total de propriedade (TCO) do ambiente de destino.
  6. Escolha a estratégia de migração para suas cargas de trabalho.
  7. Escolha as ferramentas de migração.
  8. Defina o plano e o cronograma de migração.
  9. Valide seu plano de migração.

Criar um inventário das suas cargas de trabalho

Para definir o escopo da migração, primeiro é preciso saber quantos itens, como apps e equipamentos de hardware, existem no ambiente atual, além das dependências. Criar o inventário é uma tarefa mais complexa que requer um esforço significativo, principalmente quando você não tem um sistema de catálogo automático disponível. Para ter um inventário completo, você precisa usar a experiência das equipes responsáveis pelo design, implantação e operação de cada carga de trabalho no seu ambiente atual e do próprio ambiente.

O inventário não deve se limitar apenas a cargas de trabalho, mas sim incluir pelo menos os seguintes elementos:

  • Dependências de cada app, como bancos de dados, agentes de mensagens, sistemas de armazenamento de configuração e outros componentes.
  • Serviços que oferecem suporte à infraestrutura da carga de trabalho, como repositórios de origem, ferramentas de integração e implantação contínuas (CI/CD) e repositórios de artefatos.
  • Servidores virtuais ou físicos e ambientes de execução
  • Equipamentos físicos, como dispositivos de rede, firewalls e outro hardware dedicado

Ao compilar essa lista, colete também informações sobre cada item, incluindo:

  • local do código-fonte e se é possível modificar esse código;
  • método de implantação da carga de trabalho em um ambiente de execução, por exemplo, se você usa um pipeline de implantação automatizado ou manual;
  • restrições de rede ou requisitos de segurança;
  • requisitos de endereço IP;
  • como você expõe a carga de trabalho aos clientes;
  • requisitos de licenciamento de qualquer software ou hardware.
  • como a carga de trabalho é autenticada no sistema de gerenciamento de identidade e acesso.

Por exemplo, para cada equipamento de hardware, é necessário conhecer as especificações detalhadas, como nome, fornecedor, tecnologias e dependências de outros itens do inventário. Por exemplo:

  • Nome: equipamento NAS
  • Fornecedor e modelo: fornecedor Y, modelo Z
  • Tecnologia: NFS, iSCSI
  • Dependências: conectividade de rede com frames Jumbo para hardware de computação de VM

Essa lista também deve incluir informações não técnicas, por exemplo, sob quais termos de licenciamento é possível usar cada item e quaisquer outros requisitos de conformidade. Embora algumas licenças permitam a implantação de uma carga de trabalho em um ambiente de nuvem, outras proíbem expressamente esse tipo de implantação. Algumas licenças são atribuídas com base no número de CPUs ou soquetes em uso, e esses conceitos podem não ser aplicáveis à execução na tecnologia de nuvem. Alguns dos seus dados podem ter restrições em relação à região geográfica onde são armazenados. Por fim, algumas cargas de trabalho confidenciais podem exigir locatário único.

É conveniente incluir no inventário auxiliares de interpretação visual dos dados coletados. Por exemplo, insira um gráfico de dependência e tabelas para destacar aspectos de interesse, por exemplo, como os apps são distribuídos em um processo de implantação automática ou manual.

Como criar seu inventário

Há maneiras diferentes de criar um inventário de cargas de trabalho. Embora a maneira mais rápida de dar os primeiros passos seja continuar manualmente, essa abordagem pode ser difícil no caso de um grande ambiente de produção. As informações em inventários criados manualmente podem se tornar rapidamente desatualizadas, e a migração resultante pode falhar porque você não confirmou o conteúdo dos seus inventários.

A criação do inventário não é um exercício único. Se o ambiente atual for altamente dinâmico, você também precisará dedicar esforços para automatizar a criação e a manutenção do inventário. Desse modo, você terá uma visão consistente de todos os itens no ambiente a qualquer momento. Para saber como criar um inventário de apps, consulte Central de migração: iniciar uma descoberta de recursos.

Exemplo de inventário de carga de trabalho

Este é um exemplo de inventário de um ambiente compatível com um app de comércio eletrônico. O inventário inclui apps, dependências, serviços compatíveis com vários apps e equipamentos de hardware.

Cargas de trabalho

Para cada app no ambiente, a tabela a seguir destaca as tecnologias mais importantes, o procedimento de implantação e outros requisitos.

Nome Local do código-fonte Tecnologias Procedimento de implantação Outros requisitos Dependências Requisitos de recursos do sistema
Site de marketing Repositório corporativo Front-end angular Automatizado O departamento jurídico precisa validar o conteúdo Serviço de armazenamento em cache 5 núcleos de CPU
8 GB de RAM
Área administrativa Repositório corporativo Back-end Java, front-end angular Automatizado N/A Banco de dados SQL 4 núcleos de CPU
4 GB de RAM
Carga de trabalho de e-commerce Carga de trabalho reservada Fornecedor X
Modelo Y
Versão 1.2.0		 Manual Os dados do cliente precisam residir na União Europeia Banco de dados SQL 10 núcleos de CPU
32 GB de RAM
Planejamento de recursos empresariais (ERP, na sigla em inglês) Carga de trabalho reservada Fornecedor Z, modelo C, versão 7.0 Manual N/A Banco de dados SQL 10 núcleos de CPU
32 GB de RAM
Microsserviços sem estado Repositório corporativo Java Automatizado N/A Serviço de armazenamento em cache 4 núcleos de CPU
8 GB de RAM

Dependências

A tabela a seguir é um exemplo das dependências dos apps listados no inventário. Essas dependências são necessárias para que os apps funcionem corretamente.

Nome Tecnologias Outros requisitos Dependências Requisitos de recursos do sistema
Banco de dados SQL PostgreSQL Os dados do cliente precisam residir na União Europeia Sistema de backup e arquivo 30 núcleos de CPU
512 GB de RAM

Serviços de suporte:

No seu ambiente, você pode ter serviços compatíveis com vários apps. Neste exemplo de comércio eletrônico, há os seguintes serviços:

Nome Tecnologias Outros requisitos Dependências Requisitos de recursos do sistema
Repositórios de código-fonte Git N/A Sistema de backup e arquivo 2 núcleos de CPU
4 GB de RAM
Sistema de backup e arquivo Fornecedor G, modelo H, versão 2.3.0 Por lei, o armazenamento de longo prazo é obrigatório para alguns itens N/A 10 núcleos de CPU
8 GB de RAM
Ferramenta de CI Jenkins N/A Repositórios de código-fonte
repositório de artefatos
sistema de backup e arquivo		 32 núcleos de CPU
128 GB de RAM
Repositório de artefatos Fornecedor A
Modelo N
Versão 5.0.0		 N/A Sistema de backup e arquivo 4 núcleos de CPU
8 GB de RAM
Serviço de processamento em lote Cron jobs em execução na ferramenta CI N/A Ferramenta de CI 4 núcleos de CPU
8 GB de RAM
Serviço de armazenamento em cache Memcached
Redis		 N/A N/A 12 núcleos de CPU
50 GB de RAM

Hardware

O ambiente de exemplo tem os seguintes equipamentos de hardware:

Nome Tecnologias Outros requisitos Dependências Requisitos de recursos do sistema
Firewall Fornecedor H
Modelo V		 N/A N/A N/A
Instâncias do servidor j Fornecedor K
Modelo B		 Precisa ser desativado porque não é mais compatível N/A N/A
Equipamento NAS Fornecedor Y
Modelo Z
NFS
iSCSI		 N/A N/A N/A

Avaliar os processos operacionais e de implantação

É fundamental ter um entendimento claro de como seus processos operacionais e de implantação funcionam. Eles são parte fundamental das práticas que preparam e mantêm o ambiente de produção e as cargas de trabalho executadas nele.

Os processos operacionais e de implantação podem criar os artefatos necessários para as cargas de trabalho funcionarem. Portanto, colete informações sobre cada tipo de artefato. Por exemplo, um artefato pode ser um pacote de sistema operacional, um pacote de implantação de aplicativo, uma imagem do sistema operacional, uma imagem de contêiner ou qualquer outra coisa.

Além do tipo de artefato, considere como você conclui as seguintes tarefas:

  • Desenvolva seus workloads. Avalie os processos que as equipes de desenvolvimento têm para criar suas cargas de trabalho. Por exemplo, como suas equipes de desenvolvimento projetam, codificam e testam suas cargas de trabalho?
  • Gerar os artefatos implantados no ambiente de origem. Para implantar as cargas de trabalho no ambiente de origem, você pode gerar artefatos implantáveis, como imagens de contêiner ou do sistema operacional, ou personalizar artefatos existentes, como imagens de sistema operacional de terceiros, instalando e configurando software. A coleta de informações sobre como você gera esses artefatos ajuda a garantir que os artefatos gerados sejam adequados para implantação no Google Cloud.

  • Armazene os artefatos. Se você produzir artefatos armazenados em um registro de artefatos no ambiente de origem, será necessário disponibilizá-los no ambiente do Google Cloud. Para fazer isso, use estratégias como as seguintes:

    • Estabeleça um canal de comunicação entre os ambientes: torne os artefatos no ambiente de origem acessíveis pelo ambiente de destino do Google Cloud.
    • Refatorar o processo de compilação do artefato: conclua uma pequena refatoração do ambiente de origem para que seja possível armazenar artefatos nos ambientes de origem e de destino. Essa abordagem oferece suporte à migração por meio da criação de uma infraestrutura como um repositório de artefatos antes da implementação dos processos de compilação de artefatos no ambiente de destino do Google Cloud. É possível implementar essa abordagem diretamente ou aproveitar a abordagem anterior de estabelecer um canal de comunicação primeiro.

    Ter artefatos disponíveis nos ambientes de origem e de destino permite que você se concentre na migração sem precisar implementar processos de criação de artefatos no ambiente de destino do Google Cloud como parte da migração.

  • Ler e assinar o código. Como parte dos processos de build de artefatos, você pode usar a verificação de código para se proteger contra vulnerabilidades comuns e exposição não intencional à rede, além de assinar o código para garantir que apenas códigos confiáveis sejam executados nos seus ambientes.

  • Implante artefatos no ambiente de origem. Depois de gerar artefatos implantáveis, você pode implantá-los no ambiente de origem. Recomendamos que você avalie cada processo de implantação. A avaliação ajuda a garantir que os processos de implantação sejam compatíveis com o Google Cloud. Isso também ajuda você a entender o esforço necessário para refatorar os processos. Por exemplo, se os processos de implantação funcionarem apenas com o ambiente de origem, talvez seja necessário refatorá-los para segmentar o ambiente do Google Cloud.

  • Injetar a configuração do ambiente de execução. Talvez você esteja injetando a configuração do ambiente de execução para clusters, ambientes de execução ou implantações de carga de trabalho específicos. A configuração pode inicializar variáveis de ambiente e outros valores de configuração, como segredos, credenciais e chaves. Para garantir que os processos de injeção de configuração do ambiente de execução funcionem no Google Cloud, recomendamos que você avalie como está configurando as cargas de trabalho executadas no ambiente de origem.

  • Geração de registros, monitoramento e criação de perfis. Avalie os processos de registro, monitoramento e criação de perfil que você tem para monitorar a integridade do ambiente de origem, as métricas de interesse e como você consome os dados fornecidos por esses processos.

  • Autenticação de cluster. Avalie como você está fazendo a autenticação no seu ambiente de origem.

  • Provisione e configure seus recursos. Para preparar o ambiente de origem, é possível que você tenha projetado e implementado processos que provisionem e configurem recursos. Por exemplo, você pode usar o Terraform com ferramentas de gerenciamento de configuração para provisionar e configurar recursos no ambiente de origem.

Avalie sua infraestrutura

Depois de avaliar os processos operacionais e de implantação, recomendamos que você avalie a infraestrutura atual que está permitindo as cargas de trabalho no ambiente de origem.

Para avaliar essa infraestrutura, considere o seguinte:

  • Como você organizou os recursos no ambiente de origem. Por exemplo, alguns ambientes aceitam uma separação lógica entre recursos usando construções que isolam grupos de recursos uns dos outros, como organizações e namespaces.
  • Como você conectou seu ambiente a outros, como ambientes locais e outros provedores de nuvem.

Categorizar as cargas de trabalho

Depois de concluir o inventário, organize as cargas de trabalho em categorias diferentes. Essa categorização pode ajudar você a priorizar as cargas de trabalho que serão migrados de acordo com a complexidade e o risco de migrar para a nuvem.

Uma matriz de catálogo deve ter uma dimensão para cada critério de avaliação que você está considerando no seu ambiente. Escolha um conjunto de critérios que abranja todos os requisitos do seu ambiente, incluindo os recursos do sistema necessários a cada carga de trabalho. Por exemplo, talvez você tenha interesse em saber se uma carga de trabalho tem alguma dependência ou se é sem estado ou com estado. Ao projetar a matriz de catálogo, considere que, para cada critério adicionado, você inclui outra dimensão para representar. A matriz resultante pode ser difícil de visualizar. Uma possível solução para esse problema pode ser usar várias matrizes menores, em vez de uma única e complexa.

Além disso, ao lado de cada carga de trabalho, você precisa adicionar um indicador de complexidade de migração. Esse indicador estima a dificuldade de migrar cada carga de trabalho. A granularidade desse indicador depende do seu ambiente. Como um exemplo básico, imagine que você tenha três categorias: fácil de migrar, difícil de migrar ou não pode ser migrado. Para concluir essa atividade, você precisa de especialistas em cada item do inventário para estimar a complexidade da migração. Os motivadores dessa complexidade de migração são exclusivos de cada empresa.

Quando o catálogo estiver concluído, também será possível criar recursos visuais e gráficos para ajudar você e sua equipe a avaliar rapidamente as métricas de interesse. Por exemplo, desenhe um gráfico que destaque quantos componentes têm dependências ou a dificuldade de migração de cada componente.

Para saber como criar um inventário de cargas de trabalho, consulte Central de migração: iniciar uma descoberta de recursos.

Exemplo de catálogo de cargas de trabalho

Os seguintes critérios de avaliação são usados neste exemplo, um para cada eixo da matriz:

  1. A importância de uma carga de trabalho para a empresa.
  2. Se uma carga de trabalho tem dependências ou é uma dependência para outras cargas de trabalho.
  3. Inatividade máxima permitida para a carga de trabalho.
  4. A dificuldade de migrar uma carga de trabalho.
Importância para o negócio Não tem dependências nem dependentes Tem dependências ou dependentes Inatividade máxima permitida Dificuldade
Essencial Microsserviços sem estado 2 minutos Fácil
ERP 24 horas Difícil
Carga de trabalho de e-commerce Sem inatividade Difícil
Firewall de hardware Sem inatividade Não é possível migrar
Banco de dados SQL 10 minutos Fácil
Repositórios de código-fonte 12 horas Fácil
Não é essencial Site de marketing 2 horas Fácil
Backup e arquivamento 24 horas Fácil
Serviço de processamento em lote 48 horas Fácil
Serviço de armazenamento em cache 30 minutos Fácil
Área administrativa 48 horas Difícil
Ferramenta de CI 24 horas Fácil
Repositório de artefatos 30 minutos Fácil

Para ajudar a visualizar os resultados no catálogo, é possível criar recursos visuais e gráficos. No gráfico a seguir, destacamos a dificuldade de migração:

Gráfico que mostra a dificuldade associada às cargas de trabalho móveis para o Google Cloud.

No gráfico anterior, a maioria das cargas de trabalho é fácil de migrar, três delas são difíceis de migrar e uma não pode ser migrada.

Instrua sua organização sobre o Google Cloud.

Para aproveitar o Google Cloud ao máximo, sua organização precisa começar a aprender sobre os serviços, produtos e tecnologias que sua empresa pode usar no Google Cloud. Sua equipe pode começar com contas de teste gratuito do Google Cloud, que contêm créditos para ajudá-la a praticar e aprender. Criar um ambiente gratuito para testes e aprendizado é fundamental para a experiência de aprendizado da sua equipe.

Você tem várias opções de treinamento:

  1. Recursos públicos e abertos: dê os primeiros passos para aprender sobre o Google Cloud com laboratórios práticos, séries de vídeos (em inglês), webinars do Cloud OnAir (em inglês) e eventos de treinamento do Cloud OnBoard (em inglês).
  2. Cursos avançados: se você quiser entender melhor como o Google Cloud funciona, participe dos cursos sob demanda do Google Cloud Ensina ou das especializações de Treinamento do Google Cloud da Coursera. Participe on-line no seu próprio ritmo ou faça o treinamento em sala de aula dos nossos parceiros autorizados em todo o mundo. Esses cursos costumam ter duração de um a vários dias.
  3. Programas de aprendizado baseados em funções: você treina seus engenheiros de acordo com o papel deles na organização. Por exemplo, treine seus desenvolvedores de cargas de trabalho ou operadores de infraestrutura sobre como usar os serviços do Google Cloud da melhor maneira.

É possível também certify no Google Cloud com várias certificações, em diferentes níveis:

  1. Certificações de associação: um ponto de partida para quem não tem experiência no Google Cloud, que pode abrir as portas para certificações profissionais, como a Associate Cloud Engineer.
  2. Certificações profissionais: se você quiser avaliar as habilidades avançadas de design e implementação no Google Cloud com base em anos de experiência, recorra a certificações como Professional Cloud Architect ou Professional Data Engineer.
  3. Certificações do Google Workspace: é possível demonstrar habilidades de colaboração usando as ferramentas do Google Workspace com uma certificação do Google Workspace.
  4. Certificações da Apigee: com a certificação de engenheiro de API certificado da Apigee, é possível comprovar a capacidade de projetar e desenvolver APIs robustas, seguras e escalonáveis.
  5. Certificações para desenvolvedores do Google: você pode demonstrar habilidades de desenvolvimento com as certificações Desenvolvedor Android Associado (essa certificação está sendo atualizada) e Especialista em Web para Dispositivos Móveis.

Além do treinamento e da certificação, uma das melhores maneiras de adquirir experiência no Google Cloud é começar a usar o produto para criar provas de conceito de negócios.

Testar e projetar provas de conceito

Para mostrar o valor e a eficácia do Google Cloud, considere projetar e desenvolver uma ou mais provas de conceito (PoCs, na sigla em inglês) para cada categoria das cargas de trabalho no seu catálogo. A avaliação e o teste permitem validar suposições e demonstrar o valor da nuvem para os líderes empresariais.

No mínimo, sua PoC precisa incluir o seguinte:

  • Uma lista abrangente dos casos de uso atendidos por suas cargas de trabalho, incluindo casos incomuns e isolados.
  • Todos os requisitos para cada caso de uso, como requisitos de desempenho, escalonamento e consistência, mecanismos de failover e requisitos de rede.
  • Uma lista de possíveis tecnologias e produtos que você quer investigar e testar.

Crie PoCs e experimentos para validar todos os casos de uso na lista. Cada experimento deve ter um contexto de validade preciso, escopo, resultados esperados e impacto comercial mensurável.

Por exemplo, se um dos suas cargas de trabalho vinculados à CPU precisar de escalonamento rápido para atender aos picos de demanda, execute um experimento para verificar se uma zona pode criar muitos núcleos da CPU virtual e quanto tempo leva para fazer isso. Se você tiver um valor agregado significativo, como redução do tempo de escalonamento da nova carga de trabalho de 95% em comparação com seu ambiente atual, isso poderá demonstrar um valor comercial imediato.

Se você estiver interessado em comparar o desempenho dos seus bancos de dados locais com o Cloud SQL, o Spanner, o Firestore ou o Bigtable, implemente uma PoC em que a mesma lógica de negócios usa bancos de dados diferentes. Essa PoC oferece uma oportunidade de baixo risco para identificar a solução de banco de dados gerenciada certa para sua carga de trabalho em vários comparativos de mercado e custos operacionais.

Se você quiser avaliar o desempenho do processo de provisionamento de VMs no Google Cloud, use uma ferramenta de terceiros, como o PerfKit Benchmarker (em inglês), e compare o Google Cloud com outros provedores de nuvem. É possível medir o tempo total de provisionamento de recursos na nuvem, além de gerar relatórios das métricas padrão de desempenho de pico, incluindo latência, capacidade e tempo de conclusão. Por exemplo, se você tem interesse em saber quanto tempo e esforço são necessários para provisionar muitos clusters do Kubernetes. O PerfKit Benchmarker é uma comunidade de código aberto que conta com mais de 500 participantes, como pesquisadores, instituições acadêmicas e empresas, incluindo o Google.

Calcular o custo total de propriedade

Quando você tem uma visão clara dos recursos necessários no novo ambiente, é possível criar um modelo de custo total de propriedade que permite comparar seus custos no Google Cloud com os do ambiente atual.

Ao criar esse modelo, considere não apenas os custos de hardware e software, mas também todos os custos operacionais de execução do próprio data center, como energia, resfriamento, manutenção e outros serviços de suporte. Considere também que a redução de custos costuma ser mais fácil graças à escalonabilidade elástica dos recursos do Google Cloud, em comparação com um data center local mais rígido.

Um custo que é muito ignorado ao considerar as migrações para a nuvem é o uso de uma rede de nuvem. Em um data center, a compra da infraestrutura de rede, como roteadores e interruptores, e a realização do cabeamento de rede adequado são custos únicos que permitem usar toda a capacidade da rede. Em um ambiente de nuvem, há muitas maneiras de ser cobrado pela utilização da rede. Para cargas de trabalho com uso intensivo de dados ou que geram uma grande quantidade de tráfego de rede, talvez seja necessário considerar novas arquiteturas e fluxos de rede para reduzir os custos de rede na nuvem.

O Google Cloud também oferece uma ampla variedade de opções para escalonamento inteligente de recursos e custos. Por exemplo, no Compute Engine, é possível redimensionar durante a migração com o Migrate for Compute Engine ou depois que as VMs já estiverem em execução ou criar grupos de instâncias de escalonamento automático. Essas opções podem ter um grande impacto nos custos de execução dos serviços e precisam ser exploradas para calcular o custo total de propriedade (TCO, na sigla em inglês).

Para calcular o custo total dos recursos do Google Cloud, use a calculadora de preços.

Escolha a estratégia de migração para suas cargas de trabalho.

Para cada carga de trabalho a ser migrada, avalie e selecione uma estratégia de migração que melhor se adapte ao caso de uso. Por exemplo, suas cargas de trabalho podem ter as seguintes condições:

  • Eles não toleram inatividade ou perda de dados, como cargas de trabalho essenciais. Para essas cargas de trabalho, você pode escolher estratégias de migração com tempo de inatividade zero ou quase zero.
  • Eles toleram tempos de inatividade, como cargas de trabalho secundárias ou de back-end. Para essas cargas de trabalho, você pode escolher estratégias de migração que exigem um tempo de inatividade.

Ao escolher estratégias de migração, considere que as estratégias de migração com inatividade zero ou quase zero geralmente são mais caras e complexas de projetar e implementar do que as estratégias que exigem inatividade.

Escolher as ferramentas de migração

Depois de escolher uma estratégia de migração para suas cargas de trabalho, analise e escolha as ferramentas de migração.

Há muitas ferramentas de migração disponíveis, cada uma otimizada para determinados casos de uso de migração. Os casos de uso podem incluir:

  • Estratégia de migração
  • Ambientes de origem e de destino
  • Dados e tamanho da carga de trabalho
  • Frequência de mudanças nos dados e cargas de trabalho
  • Disponibilidade para usar serviços gerenciados para migração.

Para garantir a migração e a transferência perfeitas, use os padrões de implantação de aplicativos, a orquestração de infraestrutura e os aplicativos de migração personalizados. No entanto, ferramentas especializadas, chamadas de serviços de migração gerenciados, podem facilitar o processo de migração de dados, cargas de trabalho ou até mesmo infraestruturas inteiras de um ambiente para outro. Com esses recursos, elas encapsulam a lógica complexa da migração e oferecem recursos de monitoramento da migração.

Definir o plano e o cronograma de migração

Agora que você tem uma visão completa do seu ambiente atual, é necessário concluir o plano de migração:

  1. Agrupar as cargas de trabalho e os dados a serem migrados em lotes (também chamados de sprints em alguns contextos).
  2. Escolha a ordem em que você quer migrar os lotes.
  3. Escolha a ordem em que você quer migrar as cargas de trabalho em cada lote.

Como parte do seu plano de migração, recomendamos que você também produza os seguintes documentos:

  • Documento de design técnico
  • Matriz RACI
  • Cronograma (como um plano T-minus)

À medida que você ganha experiência com o Google Cloud, ganha impulso com a migração e entende seu ambiente, é possível fazer o seguinte:

  • Refinar o agrupamento de cargas de trabalho e dados a serem migrados.
  • Aumente o tamanho dos lotes de migração.
  • Atualize a ordem em que você migra lotes e cargas de trabalho dentro de lotes.
  • Atualize a composição dos lotes.

Para agrupar as cargas de trabalho e os dados a serem migrados em lotes e definir a ordem da migração, avalie suas cargas de trabalho com base em vários critérios, como estes:

  • Valor comercial da carga de trabalho.
  • Se a carga de trabalho é implantada ou executada de maneira exclusiva em comparação com o restante da infraestrutura
  • Equipes responsáveis por desenvolvimento, implantação e operações da carga de trabalho
  • Número, tipo e escopo das dependências da carga de trabalho
  • Refatoração para que a carga de trabalho funcione no novo ambiente
  • Requisitos de conformidade e licenciamento da carga de trabalho.
  • Requisitos de disponibilidade e confiabilidade da carga de trabalho.

As cargas de trabalho que você migra primeiro são aqueles que permitem que suas equipes adquiram conhecimento e experiência no Google Cloud. Uma maior exposição na nuvem e experiência da sua equipe podem reduzir o risco de complicações durante a fase de migração, além de facilitar e acelerar as migrações seguintes. Por esse motivo, escolher o que será migrado primeiro é essencial para uma migração bem-sucedida.

Valor comercial

A escolha de uma carga de trabalho que não seja essencial para os negócios protege sua linha de negócios principal e diminui o impacto nos negócios contra riscos e erros desconhecidos enquanto sua equipe está aprendendo as tecnologias de nuvem. Por exemplo, se você escolher o componente em que a lógica principal de transações financeiras da sua carga de trabalho de comércio eletrônico será implementada primeiro, qualquer erro durante a migração poderá causar um impacto na sua linha de negócios principal. Uma opção mais adequada é o banco de dados SQL compatível com suas cargas de trabalho, ou melhor ainda, o banco de dados de preparo.

Evite cargas de trabalho usadas raramente. Por exemplo, se você escolher uma carga de trabalho que é usado apenas algumas vezes por ano por poucos usuários, embora seja uma migração de baixo risco, isso não melhora a dinâmica da migração e pode ser difícil detectar e responder a problemas.

Casos extremos

Evite também os casos extremos, de modo que seja possível descobrir padrões que possam ser aplicados a outras cargas de trabalho para migração. Uma meta principal ao selecionar o que será migrado primeiro é adquirir experiência com padrões comuns na sua organização para que seja possível criar uma base de conhecimento. Você pode aplicar o que aprendeu com esses primeiros elementos ao migrar cargas de trabalho no futuro.

Por exemplo, se a maioria das suas cargas de trabalho foi projetada seguindo uma metodologia de desenvolvimento guiado por testes e desenvolvida com a linguagem de programação Python (em inglês), a escolha de uma carga de trabalho com pouca cobertura de teste e desenvolvido usando a linguagem de programação Java não permite que você descubra nenhum padrão que possa ser aplicado ao migrar as cargas de trabalho em Python.

Equipes

Ao escolher o que será migrado primeiro, preste atenção às equipes responsáveis por cada carga de trabalho. A equipe responsável pelo que será migrado primeiro precisa estar altamente motivada e pronta para avaliar o Google Cloud e os serviços dele. Além disso, a liderança corporativa deve ter metas claras em relação às equipes de primeira migração e trabalhar ativamente para patrociná-las e apoiá-las durante o processo.

Por exemplo, uma equipe de alto desempenho localizada no escritório central com um histórico comprovado de implementação de práticas de desenvolvimento modernas, como o DevOps, e de matérias como a engenharia de confiabilidade do site (em inglês) pode ser uma boa candidata. Se ela também tiver patrocinadores de liderança hierárquica e metas claras sobre a migração de cada carga de trabalho, poderá ser uma excelente candidata.

Dependências

Além disso, concentre-se nas cargas de trabalho que têm o menor número de dependências, seja de outras cargas de trabalho ou de serviços. A migração de uma carga de trabalho sem dependências é mais fácil quando você tem uma experiência limitada no Google Cloud.

Se você precisar escolher cargas de trabalho que dependam de outros componentes, escolha aqueles menos vinculados às dependências deles. Se uma carga de trabalho já foi projetada para a indisponibilidade eventual das respectivas dependências, é possível reduzir o atrito durante a migração dela para o ambiente de destino. Por exemplo, os candidatos menos vinculados são cargas de trabalho que se comunicam por meio de um agente de mensagens, que funcionam off-line, ou projetados para tolerar a indisponibilidade do restante da infraestrutura.

Há estratégias para migrar dados de cargas de trabalho com estado, mas uma carga de trabalho sem estado raramente requer migração de dados. A migração de uma carga de trabalho sem estado pode ser mais fácil porque você não precisa se preocupar com uma fase de transição, em que os dados estão parte no ambiente atual, parte no ambiente de destino. Por exemplo, os microsserviços sem estado são bons candidatos à primeira migração porque não dependem de dados locais com estado.

Esforço de refatoração

O primeiro elemento migrado precisa de uma quantidade mínima de refatoração para que você se concentre na migração em si e no Google Cloud, em vez de dedicar um grande esforço às alterações no código e na configuração das cargas de trabalho. A refatoração deve se concentrar nas alterações necessárias que permitem que os apps sejam executados no ambiente de destino, em vez de se concentrar em modernizar e otimizar as cargas de trabalho, o que será realizado nas fases posteriores da migração.

Por exemplo, uma carga de trabalho que requer apenas alterações de configuração é um bom elemento para ser migrado primeiro, porque você não precisa implementar nenhuma alteração no codebase e pode usar os artefatos atuais.

Licenciamento e conformidade

As licenças também desempenham um papel na escolha dos primeiros elementos de migração, porque alguns dos suas cargas de trabalho podem ser licenciados sob termos que afetam sua migração. Por exemplo, algumas licenças proíbem expressamente a execução de cargas de trabalho em um ambiente de nuvem.

Ao analisar os termos de licenciamento, lembre-se dos requisitos de conformidade, porque talvez você tenha requisitos de locação exclusivos para alguns das cargas de trabalho. Por esses motivos, escolha as cargas de trabalho com a menor quantidade de restrições de licenciamento e conformidade como primeiros elementos de migração.

Por exemplo, seus clientes podem ter o direito legal de escolher em que região você armazena os dados deles, ou os dados dos clientes podem estar restritos a uma região específica.

Disponibilidade e confiabilidade

Os primeiros elementos de migração ideais são aqueles capazes de sustentar uma inatividade causada por uma janela de transição. Se você escolher uma carga de trabalho com requisitos de disponibilidade rigorosos, precisará implementar uma estratégia de migração de dados sem inatividade, como Y (gravação e leitura), ou desenvolver um microsserviço de acesso aos dados. Essa é uma abordagem possível, mas que acaba desviando as equipes de ganhar a experiência necessária no Google Cloud porque elas precisam dedicar tempo para implementar essas estratégias.

Por exemplo, os requisitos de disponibilidade de um mecanismo de processamento em lote podem tolerar uma inatividade maior do que a carga de trabalho voltado para o cliente do site de comércio eletrônico em que os usuários finalizam as transações.

Valide seu plano de migração

Antes de iniciar o plano de migração, recomendamos que você valide a viabilidade dele. Para mais informações, consulte Práticas recomendadas para validar um plano de migração.

A seguir

Colaboradores

Autor: Marco Ferrari | Arquiteto de soluções na nuvem