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

Last reviewed 2023-06-07 UTC

Use este documento para planejar, projetar e implementar a fase de avaliação da migração para o Google Cloud. Descobrir seu inventário de apps e 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.

A fase de avaliação é a primeira da migração para o Google Cloud, em que você determina os requisitos e as dependências para migrar seus apps para o Google Cloud.

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.

A fase de avaliação é fundamental para o sucesso da migração. Você precisa ter um excelente conhecimento dos apps 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.

Nesta fase, você executa as seguintes etapas:

  1. Criação de um inventário completo dos seus apps
  2. Catalogue seus apps de acordo com as propriedades e dependências deles.
  3. Treine e instrua suas equipes no Google Cloud.
  4. Crie um experimento e uma prova de conceito no Google Cloud.
  5. Calcule o custo total de propriedade (TCO) do ambiente de destino.
  6. Escolha das cargas de trabalho que você quer migrar primeiro

Como criar um inventário dos seus apps

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 apps, 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 compatíveis com a infraestrutura do app, como repositórios de origem, ferramentas de integração contínua (CI) 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 um app 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 apps. 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 desatualizar rapidamente, e a migração resultante pode falhar porque foi baseada em suposições incorretas.

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 informações sobre como criar um inventário de apps, consulte Central de migração: iniciar uma descoberta de recursos.

O Google faz parcerias com várias empresas para ajudar você na sua jornada de migração. Para mais informações, consulte Como encontrar ajuda.

Exemplo de um inventário de aplicativos

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.

Apps

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/D Banco de dados SQL 4 núcleos de CPU
4 GB de RAM
App de comércio eletrônico App próprio 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) App próprio Fornecedor Z, modelo C, versão 7.0 Manual N/D Banco de dados SQL 10 núcleos de CPU
32 GB de RAM
Microsserviços sem estado Repositório corporativo Java Automatizado N/D 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 compatíveis

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/D 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/D 10 núcleos de CPU
8 GB de RAM
Ferramenta de CI Jenkins N/D 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/D 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/D Ferramenta de CI 4 núcleos de CPU
8 GB de RAM
Serviço de armazenamento em cache Memcached
Redis		 N/D N/D 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/D N/A N/D
Instâncias do servidor j Fornecedor K
Modelo B		 Precisa ser desativado porque não é mais compatível N/D N/D
Equipamento NAS Fornecedor Y
Modelo Z
NFS
iSCSI		 N/D N/A N/A

Avaliar os processos operacionais e de implantação

Depois de criar os inventários das cargas de trabalho, recomendamos avaliar seus processos operacionais e de implantação. Os processos operacionais e de implantação são uma parte fundamental das práticas que preparam e mantêm seu ambiente de produção e as cargas de trabalho executadas nele.

Esses processos podem provisionar a infraestrutura necessária e criar os artefatos indispensáveis às suas cargas de trabalho, como pacotes do sistema operacional, pacotes de implantação de carga de trabalho, imagens do sistema operacional e imagens de contêiner. Para cada carga de trabalho, colete informações sobre: quantos artefatos são necessários, o tipo de cada artefato, como você criará esses artefatos, como e onde você os armazenará e como injetará a configuração do ambiente de execução para que esses artefatos sejam reutilizáveis em vários ambientes.

Depois de avaliar seus processos operacionais e de implantação, também recomendamos avaliar como esses processos podem facilitar a migração para o Google Cloud e como eles ajudam a reduzir o escopo e o risco da migração. Por exemplo, é possível refatorar os processos de criação de artefatos para armazenar artefatos no ambiente de origem e no Google Cloud enquanto a migração está em andamento. Com os artefatos nos dois ambientes, você se concentra na migração das cargas de trabalho e dos dados do ambiente de origem para o Google Cloud sem precisar implementar processos de criação de artefatos no ambiente de destino do Google Cloud, desde o início do processo de migração.

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:

  • Os processos que você adotou para provisionar os recursos indispensáveis à carga de trabalho, por exemplo, infraestrutura como código.
  • 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 projetos.
  • Como você conectou seu ambiente a outros, como ambientes locais e outros provedores de nuvem.

Como categorizar seus aplicativos

Depois de concluir o inventário, organize os apps em categorias diferentes. Essa categorização pode ajudar você a priorizar os apps 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 app. Por exemplo, talvez você tenha interesse em saber se um app 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 app, você precisa adicionar um indicador de complexidade de migração. Esse indicador estima a dificuldade de migração de cada app. 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 apps, consulte Central de migração: iniciar uma descoberta de recursos.

Exemplo de um catálogo de aplicativos

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

  1. A importância de um app para a empresa.
  2. Se um app tem dependências ou é uma dependência para outros apps.
  3. Inatividade máxima permitida para o aplicativo.
  4. A dificuldade de migrar um app.
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
App de comércio eletrônico 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 à migração de apps para o Google Cloud.

No gráfico anterior, a maioria dos apps é fácil de migrar, enquanto apenas três deles são difíceis, e um deles não pode ser migrado.

Como orientar 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 avaliar e praticar. 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 apps ou operadores de infraestrutura sobre como usar os serviços do Google Cloud da melhor maneira.

É possível também comprovar o conhecimento dos seus engenheiros 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.

Como avaliar 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 dos apps 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 seus apps, incluindo casos incomuns e isolados.
  • Todos os requisitos para cada caso de uso, como requisitos de desempenho e escalonabilidade, garantias de consistência esperada, 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 seus apps 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 do novo app 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.

Como 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 apps 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.

Como escolher os apps que serão migrados primeiro

Agora que você tem uma visão completa do seu ambiente atual, é necessário concluir o plano de migração escolhendo a ordem inicial em que você quer migrar os apps. É possível aprimorar essa ordem durante a migração quando tiver experiência com o Google Cloud e conhecer seu ambiente e seus apps.

Os apps 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. É possível escolher um app ou vários apps da sua matriz na lista de primeira migração.

A tarefa de identificar o que será migrado primeiro é complexa, mas veja a seguir alguns critérios para orientar você:

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

Valor comercial

A escolha de um app 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 do seu app 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 seus apps, ou melhor ainda, o banco de dados de preparo.

Evite apps que são usados raramente. Por exemplo, se você escolher um app 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 outros apps 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. Reaplique o que você aprendeu com esses primeiros elementos ao migrar apps no futuro.

Por exemplo, se a maioria dos seus apps 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 um app 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 os apps em Python.

Equipes

Ao escolher o que será migrado primeiro, preste atenção às equipes responsáveis por cada app. A equipe responsável pelo que for migrado primeiro precisará 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 app, poderá ser uma excelente candidata.

Dependências

Dedique-se também aos apps que têm o menor número de dependências, seja de outros apps ou de serviços. A migração de um app sem dependências é mais fácil quando você tem uma experiência limitada no Google Cloud.

Se você precisar escolher apps que dependam de outros componentes, escolha aqueles menos vinculados às dependências deles. Se um app já foi projetado para a indisponibilidade eventual das respectivas dependências, é possível reduzir o atrito durante a migração dele para o ambiente de destino. Por exemplo, os candidatos menos vinculados são apps 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 apps com estado, mas um app sem estado raramente requer migração de dados. A migração de um app 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 dos apps. 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 os apps, o que será realizado nas fases posteriores da migração.

Por exemplo, um app 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 seus apps podem ser licenciados sob termos que afetam sua migração. Por exemplo, algumas licenças proíbem expressamente a execução de apps 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 dos apps. Por esses motivos, escolha os apps 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 um aplicativo 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 o app voltado para o cliente do site de comércio eletrônico em que os usuários finalizam as transações.

A seguir