Migração para o Google Cloud: primeiros passos

Este documento ajuda você a planejar, projetar e implementar o processo de migração das cargas de trabalho para o Google Cloud. Mover aplicativos de um ambiente para outro é uma tarefa desafiadora, até mesmo para equipes experientes. Por isso, é necessário planejar e executar a migração com cuidado.

Este artigo faz parte de uma série:

Este documento é útil se você estiver planejando uma migração de um ambiente local, de um ambiente de hospedagem particular, de outro provedor de nuvem para o Google Cloud ou se estiver avaliando a oportunidade de migrar e quiser explorar as possibilidades.

Primeiros passos

Ao planejar sua migração para o Google Cloud, você começa definindo os ambientes envolvidos na migração. O ponto de partida pode ser um ambiente local, um ambiente de hospedagem particular ou outro ambiente de nuvem pública.

Um ambiente local é um ambiente em que você tem propriedade e responsabilidade totais. Também é necessário que você tenha controle total sobre todos os aspectos do ambiente, como refrigeração, segurança física e manutenção de hardware.

Em um ambiente de hospedagem particular, como uma instalação de colocation, uma parcela da infraestrutura física e do gerenciamento é terceirizada para uma parte externa. Essa infraestrutura costuma ser compartilhada entre os clientes. Em um ambiente de hospedagem particular, não é necessário gerenciar os serviços de proteção e segurança física. Alguns ambientes de hospedagem permitem gerenciar parte do hardware físico, como servidores, racks e dispositivos de rede, enquanto outros gerenciam esse hardware para você. Normalmente, cabos de energia e de rede são fornecidos como um serviço, para que não seja preciso gerenciá-los. Você tem total controle dos hipervisores que virtualizam recursos físicos, da infraestrutura virtualizada provisionada e das cargas de trabalho executadas nessa infraestrutura.

A vantagem de um ambiente de nuvem pública é que você não precisa gerenciar toda a pilha de recursos por conta própria. Ele permite que você se concentre no aspecto da pilha que considerar mais valioso. Como em um ambiente de hospedagem particular, não é necessário gerenciar a infraestrutura física subjacente. Além disso, não é necessário gerenciar o hipervisor de virtualização de recursos. Nessa nova infraestrutura, é possível criar uma infraestrutura virtualizada e implantar cargas de trabalho. Também é possível contratar serviços totalmente gerenciados, de modo que você só precisa se preocupar com as cargas de trabalho, sem necessidade de lidar com toda a carga operacional relacionada ao gerenciamento de ambientes de execução.

Neste documento, são avaliados os aspectos a seguir para cada ambiente., além de quem fornece e gerencia os respectivos serviços:

Recursos Ambiente local Ambiente de hospedagem particular Ambiente de nuvem pública
Segurança física e proteção Você Provedor de serviços Provedor de serviços
Cabos de energia e rede Você Provedor de serviços Provedor de serviços
Hardware (inclusive manutenção) Você Depende do provedor de serviços Provedor de serviços
Plataforma de virtualização Você Você Provedor de serviços
Recursos do aplicativo Você Você Você (às vezes aproveitando serviços totalmente gerenciados)

Neste documento, o ambiente de destino é o Google Cloud.

Depois de definir os ambientes inicial e de destino, defina os tipos de carga de trabalho e processos operacionais relacionados que farão parte do escopo da migração. Neste documento, consideramos dois tipos de cargas de trabalho e operações: legadas e nativas da nuvem.

As cargas de trabalho e operações legadas são desenvolvidas sem levar em consideração os ambientes de nuvem. Essas cargas de trabalho e operações podem ser difíceis de modificar, além de serem caras de executar e manter, porque geralmente não são compatíveis com nenhum tipo de escalonabilidade.

As cargas de trabalho e operações nativas da nuvem são escalonáveis, portáteis, disponíveis e seguras. As cargas de trabalho e operações podem ajudar a aumentar a produtividade e a agilidade do desenvolvedor. Com elas, os desenvolvedores podem se concentrar nas cargas de trabalho reais, em vez de desperdiçar esforços gerenciando ambientes de desenvolvimento e execução ou lidando com processos de implantação manuais complicados. O Google Cloud também tem um modelo de responsabilidade compartilhado para segurança. O Google Cloud é responsável pela segurança física e pela segurança da infraestrutura, e você é responsável pela segurança das cargas de trabalho que implanta na infraestrutura.

Considerando os tipos de ambiente e carga de trabalho, a situação inicial é uma das seguintes:

  • Ambiente de hospedagem local ou particular com cargas de trabalho e operações legadas
  • Ambiente de hospedagem local ou particular com cargas de trabalho e operações nativas da nuvem
  • Nuvem pública ou ambiente de hospedagem particular com cargas de trabalho e operações legadas
  • Nuvem pública ou ambiente de hospedagem privado com cargas de trabalho e operações nativas da nuvem

O processo de migração depende do ponto de partida.

Migrar uma carga de trabalho de um ambiente local legado ou de um ambiente de hospedagem privado para um ambiente nativo da nuvem, como uma nuvem pública, pode ser desafiador e arriscado. Migrações bem-sucedidas alteram a carga de trabalho para migrar o mínimo possível durante as operações de migração. Mover aplicativos locais legados para a nuvem geralmente requer várias etapas de migração.

Tipos de migração

Há três tipos principais de migração:

  • Migração lift-and-shift
  • Improve-and-move
  • Migração rip-and-replace

Nas seções a seguir, cada tipo de migração é definido com exemplos de quando usar cada tipo.

Migração lift-and-shift

Em uma migração lift-and-shift, as cargas de trabalho são movidas de um ambiente de origem para um ambiente de destino com pequenas ou nenhuma modificação ou refatoração. As cargas de trabalho a serem migradas são modificadas o mínimo possível, apenas o bastante para que elas operem no ambiente de destino.

Uma migração lift-and-shift é ideal quando uma carga de trabalho pode operar no ambiente de destino no estado em que se encontra ou quando há pouca ou nenhuma necessidade corporativa de mudança. Esse tipo de migração requer menos tempo porque a quantidade de refatoração é mínima.

Pode haver problemas técnicos que forçam uma migração lift-and-shift. É obrigatório usar a migração lift-and-shift caso não seja possível refatorar a carga de trabalho para migrar ou descomissionar a carga de trabalho. Por exemplo, pode ser difícil ou impossível modificar o código-fonte da carga de trabalho, ou o processo de compilação não é direto, de modo que não seja possível produzir novos artefatos após a refatoração do código-fonte.

As migrações lift-and-shift são as mais fáceis de executar porque não precisam de novos conhecimentos: sua equipe pode usar o mesmo conjunto de ferramentas e habilidades. Essas migrações também são compatíveis com softwares prontos. Como as cargas de trabalho atuais são migradas com o mínimo de refatoração, as migrações lift-and-shift tendem a ser as mais rápidas do que migrações improve-and-move ou rip-and-replace.

Por outro lado, os resultados de uma migração lift-and-shift são cargas de trabalho nativas da nuvem executadas no ambiente de destino. Essas cargas de trabalho não aproveitam ao máximo os recursos da plataforma de nuvem, como escalonabilidade horizontal, preços detalhados e serviços altamente gerenciados.

Migração improve-and-move

Em uma migração improve-and-move, a carga de trabalho é modernizada durante a migração. Nesse tipo de migração, as cargas de trabalho são modificadas para otimizá-las para os recursos nativos da nuvem, não apenas para que elas funcionem no novo ambiente. É possível aprimorar o desempenho, os recursos, o custo ou a experiência do usuário para cada carga de trabalho.

Se a arquitetura ou a infraestrutura atual de um aplicativo não for compatível com o ambiente de destino, será necessário um certo nível de refatoração para superar essas limitações.

A abordagem improve-and-move também é recomendada quando é necessária uma atualização importante na carga de trabalho, além das atualizações exigidas para migrar.

As migrações improve-and-move permitem que seu aplicativo aproveite os recursos de uma plataforma de nuvem, como escalonabilidade e alta disponibilidade. Também é possível arquitetar o aprimoramento para aumentar a portabilidade do aplicativo.

Por outro lado, as migrações improve-and-move levam mais tempo do que as migrações lift-and-shift, porque precisam ser refatoradas para que o aplicativo migre. É necessário avaliar o tempo e o esforço extra como parte do ciclo de vida do aplicativo.

A migração improve-and-move também exige que você domine novas habilidades.

Migração rip-and-replace

Em uma migração rip-and-replace, você desativa um aplicativo atual e faz um projeto completamente novo para reescrevê-lo na forma de um aplicativo nativo da nuvem.

Se o aplicativo atual não estiver atingindo suas metas, por exemplo, você não quer mantê-lo, é muito caro migrar usando uma das abordagens mencionadas anteriormente ou ele não é compatível com o Google Cloud, será possível fazer uma migração rip-and-replace.

As migrações rip-and-replace permitem que o aplicativo aproveite ao máximo os recursos do Google Cloud, como escalonabilidade horizontal, serviços altamente gerenciados e alta disponibilidade. Como você está reescrevendo o aplicativo do zero, o débito técnico da versão legada atual também é removido.

No entanto, as migrações rip-and-replace podem levar mais tempo do que migrações lift-and-shift e improve-and-move. Além disso, esse tipo de migração não é adequado para aplicativos prontos para serem usados porque requer a reelaboração do aplicativo. Você precisa avaliar o tempo e o esforço extras para reformular e reescrever o aplicativo como parte de seu ciclo de vida.

Uma migração rip-and-replace também requer novas habilidades. É necessário usar um novo conjunto de ferramentas para provisionar e configurar o novo ambiente e implantar o aplicativo nele.

Framework de adoção do Google Cloud

Antes de iniciar a migração, é necessário avaliar a maturidade da organização durante a adoção de tecnologias de nuvem. O framework de adoção do Google Cloud serve como um mapa para determinar onde estão os recursos de tecnologia da informação da sua empresa e como um guia para onde você quer chegar.

É possível usar essa estrutura para avaliar o preparo da sua organização para o Google Cloud e o que você precisa fazer para preencher as lacunas e desenvolver novas competências, conforme ilustrado no diagrama a seguir.

Arquitetura do framework de adoção do Google Cloud com quatro temas e três etapas.

A estrutura avalia quatro temas:

  • Aprender. A qualidade e a escala de seus programas de aprendizado.
  • Liderar. Até que ponto seus departamentos de TI recebem o apoio da liderança para realizar a migração para o Google Cloud.
  • Escalonar. Quanto você usa os serviços nativos da nuvem e quanta automação operacional está em vigor atualmente.
  • Proteger. A capacidade de proteger seu ambiente atual contra acessos não autorizados e inadequados.

Para cada tema, você precisa estar em uma das três fases a seguir, de acordo com a estrutura:

  • Tática. Não há planos coerentes que cubram todas as cargas de trabalho individuais atuais. Você tem interesse principalmente em um retorno rápido sobre os investimentos e em diminuir as interrupções na organização de TI.
  • Estratégica. Há um plano de desenvolvimento de cargas de trabalho individuais focado nas necessidades futuras de escalonamento. Você tem interesse no objetivo de médio prazo de simplificar as operações para ser mais eficiente do que hoje.
  • Transformacional. As operações na nuvem funcionam sem problemas e você usa os dados coletados dessas operações para melhorar seus negócios de TI. Você tem interesse no objetivo de longo prazo de tornar o departamento de TI um dos motores da inovação dentro da sua organização.

Ao avaliar os quatro tópicos com base nas três fases, você chegará à escala de maturidade do Cloud. Para cada tema, veja o que acontece quando você deixa de adotar novas tecnologias quando necessário para começar a trabalhar com elas de forma mais estratégica em toda a organização, o que naturalmente significa um treinamento mais profundo, abrangente e consistente para suas equipes.

O caminho da migração

É importante lembrar que a migração é uma jornada. Você está no ponto A com sua infraestrutura e ambientes atuais e quer alcançar o ponto B. Para ir de A para B, é possível escolher qualquer uma das opções descritas anteriormente.

O diagrama a seguir mostra o caminho dessa jornada.

Caminho de migração com quatro fases.

Há quatro fases de migração:

  • Avaliar. Nesta fase, você realiza uma avaliação e descoberta completa do ambiente atual para entender seu inventário de aplicativos e ambientes, identificar dependências e requisitos de aplicativos, calcular o custo total da propriedade e comparar o desempenho de aplicativos.
  • Planejar. Nesta fase, você cria a infraestrutura básica da nuvem para as cargas de trabalho e planeja como moverá os aplicativos. Esse planejamento inclui gerenciamento de identidade, organização e estrutura do projeto, rede, classificação de aplicativos e desenvolvimento de uma estratégia de migração priorizada.
  • Implantar. Nesta fase, você projeta, implementa e executa um processo de implantação a fim de migrar cargas de trabalho para o Google Cloud. Também convém refinar a infraestrutura em nuvem para lidar com novas necessidades.
  • Otimizar. Nesta fase, você começa a aproveitar ao máximo as tecnologias e recursos nativos da nuvem para expandir o potencial do seu negócio no que diz respeito a desempenho, escalonabilidade, recuperação de desastres, custos, treinamento, além de abrir as portas para integrar machine learning e inteligência artificial no seu aplicativo.

Fase 1 da migração: avaliar

Na fase de avaliação, você reúne informações sobre as cargas de trabalho que quer migrar e sobre o ambiente de execução.

Fazer um inventário

Para que a migração seja bem-sucedida, é importante entender quais são os aplicativos do ambiente atual, quais os bancos de dados, intermediários de mensagens, armazenamentos de dados e dispositivos de rede, além das dependências de aplicativos de cada um deles. É necessário listar todas as máquinas, especificações de hardware, sistemas operacionais, licenças e quais aplicativos e serviços são usados por cada um deles.

Catalogar aplicativos

Depois que fizer seu inventário, será possível criar sua matriz de catalogação para ajudar a organizar seus aplicativos em categorias com base na complexidade e no risco da migração deles para o Google Cloud.

A tabela a seguir é um exemplo de matriz de catalogação.

Não tem dependências nem dependentes Tem dependências ou dependentes
Missão crítica
  • Microsserviços sem estado (médio)
  • ERP (difícil)
  • Bancos de dados OLTP (difícil)
  • Aplicativo de comércio eletrônico (difícil)
  • Armazenamentos de dados (difícil)
  • Ferramenta de firewall (não pode)
Não é de missão crítica
  • Site de marketing (fácil)
  • Backup e arquivamento (fácil)
  • Ambientes de desenvolvimento e teste (fácil)
  • Processamento em lote (fácil)
  • Back-office (difícil)
  • Análise de dados (difícil)

Este exemplo de matriz de catalogação tem duas dimensões de critérios de avaliação. Talvez seus aplicativos exijam mais dimensões ou considerações. Crie uma matriz que inclua todos os requisitos específicos do seu ambiente.

Instrua sua organização sobre o Google Cloud.

Como parte da fase de avaliação, sua organização precisa saber mais sobre o Google Cloud. Você precisa treinar e certificar seus engenheiros de software e de rede sobre como a nuvem funciona e quais produtos do Google Cloud eles podem aproveitar, bem como que tipo de frameworks, APIs e bibliotecas eles podem usar para implantar cargas de trabalho no Google Cloud.

Testar e projetar provas de conceito

Outra parte importante da fase de avaliação é escolher uma prova de conceito (PoC, na sigla em inglês) e implementá-la, ou testar produtos do Google Cloud para validar casos de uso ou possíveis áreas de incerteza.

Considere os seguintes casos de uso:

  • Verificar se uma zona pode ativar até 50.000 núcleos de CPU virtual.
  • Implementar regras de firewall para uma carga de trabalho complexa.
  • Comparar o desempenho de seus bancos de dados locais com Cloud SQL, Cloud Spanner Firestore ou Cloud Bigtable.
  • Testar a disponibilidade de clusters regionais do GKE.
  • Testar a latência das redes interna e externa dos seus aplicativos no Google Cloud.
  • Avaliar a velocidade e a confiabilidade de um pipeline de implantação do Cloud Build para contêineres do GKE
  • Comparar o Dataflow com o Spark no Dataproc.
  • Transferir dados para o BigQuery e formular consultas críticas de negócios para testar a exatidão.
  • Avaliar o Cloud Logging para substituir outros mecanismos de geração de registros.

Para cada experiência, o impacto nos negócios é medido, como nos exemplos a seguir:

  • Se você observar uma redução de 95% do tempo de inicialização para 50.000 núcleos de CPU virtual no Google Cloud em comparação com o ambiente atual, isso reduzirá o tempo de lançamento em um determinado fator. Essa redução também afeta o tempo de configuração do ambiente de recuperação de desastres, porque diminui o tempo de inatividade das linhas críticas de negócios.
  • Se você tiver um plano de recuperação de desastres sempre disponível e ativado, será possível aumentar a confiabilidade do aplicativo.
  • Usando a tecnologia de dimensionamento em nuvem, é possível reduzir o custo total dos serviços diminuindo a escala quando houver pouca demanda de recursos e expandindo-a quando necessário.

Calcular o custo total de propriedade

A criação de um modelo de custo total de propriedade permite comparar seus custos no Google Cloud com os gastos atuais. Existem ferramentas que podem ajudar, como a calculadora de preços do Google Cloud, e também é possível aproveitar algumas de nossas ofertas de parceiros. Não se esqueça dos custos operacionais da execução no local ou em seu próprio data center: o custo total de propriedade é afetado pelos serviços de apoio, como energia, refrigeração, manutenção e outros.

Escolher quais cargas de trabalho migrar primeiro

Para se preparar para a migração, é necessário identificar os aplicativos com recursos importantes que os tornam prioritários para migração. É possível escolher apenas um ou incluir muitos aplicativos na lista de aplicativos prioritários para migração. Esses aplicativos prioritários permitem que suas equipes executem e testem aplicativos no ambiente do Cloud, onde podem se concentrar na migração, e não na complexidade dos aplicativos. Começar com um aplicativo menos complexo reduz o risco inicial, porque mais tarde você usará os novos aprendizados da equipe na migração de aplicativos mais complicados.

Identificar um aplicativo prioritário pode ser complexo, mas esse tipo de aplicativo costuma satisfazer muitos dos critérios de carga de trabalho a seguir:

  • Não é essencial para os negócios. Portanto, a principal linha de negócios não é afetada pela migração, porque as equipes ainda não têm uma experiência significativa com as tecnologias do Cloud.
  • Não é um caso excepcional, porque é fácil aplicar o mesmo padrão a outras cargas de trabalho que você queira migrar.
  • Pode ser usado para construir uma base de conhecimento.
  • Tem suporte de uma equipe altamente motivada e ansiosa para executar o Google Cloud.
  • A migração precisa envolver uma equipe central que migra outras cargas de trabalho. Migrar a primeira carga de trabalho faz com que a equipe tenha mais experiência, o que pode ser útil em futuras migrações de carga de trabalho.
  • É mais fácil migrar uma carga de trabalho com poucas dependências, como uma sem estado, porque ela pode ser movida sem afetar outras cargas de trabalho ou com alterações mínimas na configuração.
  • Requer pouca refatoração ou alterações mínimas nos aplicativos.
  • Não requer que a movimentação de grandes quantidades de dados.
  • Não tem exigências rigorosas de conformidade.
  • Não requer licenças de terceiros, porque alguns provedores não oferecem licenças de produtos para o Cloud ou exigem uma alteração no tipo de licença.
  • Não é afetado pelo tempo de inatividade causado por uma janela de transição. Por exemplo, é possível exportar dados do seu banco de dados atual e depois importá-los para uma instância de banco de dados no Google Cloud durante uma janela de manutenção planejada. É mais complicado sincronizar duas instâncias do banco de dados para ter uma migração com tempo de inatividade zero.

Fase 2 da migração: planejar

Nesta fase, você provisiona e configura a infraestrutura em nuvem e os serviços que darão suporte às suas cargas de trabalho no Google Cloud. Construir uma base de configurações e serviços críticos é um processo em evolução. Quando você estabelecer regras, governança e configurações, lembre-se de deixar espaço para alterações futuras. Evite tomar decisões que limitem as maneiras de fazer as coisas. É melhor ter opções caso você queira alterar as coisas posteriormente.

Para planejar sua migração, é necessário fazer o seguinte:

  • Estabelecer identidades de usuário e serviço.
  • Projetar sua organização de recursos.
  • Definir grupos e papéis para acessar recursos.
  • Projetar a topologia de rede e estabelecer conectividade.

Estabelecer identidades

No Google Cloud, você tem tipos de identidade para escolher:

  • Contas do Google. Uma conta que geralmente pertence a um usuário individual que interage com o Google Cloud.
  • Contas de serviço. Uma conta que geralmente pertence a um aplicativo ou a um serviço, não a um usuário.
  • Grupos do Google. Uma coleção de contas do Google com nome.
  • Domínios do G Suite. Um grupo virtual de todas as Contas do Google que foram criadas na conta do G Suite de uma organização.
  • Domínios do Cloud Identity. Esses domínios são como os domínios do G Suite, mas não têm acesso aos aplicativos do G Suite.

Para mais informações, leia sobre cada tipo de identidade.

Por exemplo, é possível federar o Google Cloud com o Active Directory para estabelecer mecanismos consistentes de autenticação e autorização em um ambiente híbrido.

Projetar a organização de recursos

Depois de estabelecer as identidades necessárias para o aplicativo, conceda permissões em recursos, como projeto, pastas ou buckets, usados pelo aplicativo. Isso pode ser feito atribuindo papéis a cada identidade. Um papel é um conjunto de permissões. Uma permissão é um conjunto de operações permitidas em um recurso.

Para evitar repetir as mesmas etapas de configuração, organize seus recursos em diferentes tipos de estruturas. Essas estruturas são organizadas em uma hierarquia:

  • Organizações são a raiz de uma hierarquia de recursos e representam uma organização real, como uma empresa. Uma organização pode conter pastas e projetos. Um administrador da organização pode conceder permissões sobre todos os recursos da organização.
  • Pastas são uma camada extra de isolamento entre projetos e podem ser consideradas suborganizações dentro da organização. Uma pasta pode conter outras pastas e projetos. Um administrador pode usar a pasta para delegar direitos de administrador.
  • Os projetos são as entidades da organização no nível base e precisam ser usados para acessar outros recursos do Google Cloud. Cada instância de recurso que você implanta e usa está contida em um projeto.

Como os recursos herdam permissões do nó pai, é possível evitar ter que repetir as mesmas etapas de configuração para recursos com o mesmo pai. Para mais detalhes sobre o mecanismo de herança do gerenciamento de identidade e acesso (IAM, na sigla em inglês), consulte a seção sobre herança de políticas da documentação do Resource Manager.

Organizações, pastas e projetos são recursos e dão suporte a um conjunto de operações como todos os outros recursos do Google Cloud. É possível interagir com esses recursos como faria com qualquer outro recurso do Google Cloud. Por exemplo, é possível automatizar a criação da hierarquia usando a API Resource Manager. É possível organizar a hierarquia de recursos de acordo com suas necessidades. O nó raiz de cada hierarquia é sempre uma organização. Nas seções a seguir, há tipos de hierarquias que podem ser implantados na organização. Cada tipo de hierarquia é caracterizado pela flexibilidade e complexidade de implantação.

Hierarquia voltada a ambientes

Em uma hierarquia voltada ao ambiente, você tem uma organização que contém uma pasta por ambiente.

O diagrama a seguir mostra um exemplo de hierarquia voltada a ambientes.

Arquitetura de uma hierarquia voltada a ambientes.

Os diversos ambientes são desenvolvimento, garantia de qualidade e produção. Em cada ambiente, foram implantadas várias instâncias dos dois mesmos aplicativos, My app 1 e My app 2.

Essa hierarquia é simples de implementar, porque tem apenas três níveis. No entanto, ela pode ser desafiadora caso você precise implantar serviços compartilhados em vários ambientes.

Hierarquia voltada a funções

Em uma hierarquia voltada a funções, você tem uma organização que contém uma pasta por função de negócios, como tecnologia da informação e gerenciamento. Cada pasta de função de negócios pode conter várias pastas de ambiente.

O diagrama a seguir mostra um exemplo de hierarquia voltada a funções.

Arquitetura de uma hierarquia voltada a funções.

Nessa hierarquia, as várias funções de negócios são aplicativos, gerenciamento e tecnologia da informação. É possível implantar várias instâncias do My app, além de serviços compartilhados, como o Jira e o site.

Essa opção é mais flexível do que a hierarquia voltada a ambientes, porque oferece a mesma separação de ambientes, além de permitir a implantação de serviços compartilhados. Por outro lado, uma hierarquia voltada a funções é mais complexa de gerenciar do que uma hierarquia voltada a ambientes. Além disso, ela não separa o acesso por unidade de negócios, como varejo ou financeiro.

Hierarquia voltada ao acesso granular

Em uma hierarquia voltada ao acesso granular, você tem uma organização que contém uma pasta por unidade de negócios, como varejo ou financeira. Cada pasta de unidade de negócios pode conter uma pasta por função de negócios. Cada pasta de função de negócios pode conter uma pasta por ambiente.

O diagrama a seguir mostra um exemplo de hierarquia voltada ao acesso granular.

Arquitetura de uma hierarquia voltada ao acesso.

Nesta hierarquia, há várias unidades de negócios, várias funções de negócios e ambientes. É possível implantar várias instâncias dos aplicativos My app 1 e My app 2 e um serviço compartilhado, um host da rede.

Essa hierarquia é a opção mais flexível e extensível. Por outro lado, é necessário mais esforço para gerenciar a estrutura, os papéis e as permissões. A topologia de rede também pode ser significativamente mais complexa, porque o número de projetos é maior em comparação com as outras opções.

Definir grupos e papéis para acesso a recursos

Você precisa configurar os grupos e papéis para conceder acesso a recursos. No Google Cloud, é possível delegar acesso de administrador aos recursos da organização. No mínimo, você precisa dos seguintes papéis:

  • Um administrador da organização que define as políticas do IAM e a hierarquia da organização e dos recursos dela.
  • Um administrador de rede que cria e configura redes, sub-redes e dispositivos de rede, como o Cloud Router, o Cloud VPN e o Cloud Load Balancing. Outra responsabilidade dele é manter regras de firewall com a ajuda do administrador de segurança.
  • Um administrador de segurança que estabelece políticas e restrições para a organização e seus recursos, configura novos papéis do IAM para projetos e mantém a visibilidade em registros e recursos.
  • Um administrador de faturamento que configura contas de faturamento e monitora o uso e os gastos com recursos em toda a organização.

Projetar a topologia de rede e estabelecer a conectividade

A última etapa da fase de planejamento é configurar a topologia e a conectividade da rede no ambiente existente para o Google Cloud.

Depois de criar projetos e estabelecer identidades, você precisa criar pelo menos uma rede de nuvem privada virtual (VPC, na sigla em inglês). As VPCs permitem que você tenha um espaço de endereçamento global particular, abrangendo várias regiões. A comunicação inter-regional não usa a Internet pública. É possível criar VPCs para separar partes dos aplicativos ou ter uma VPC compartilhada que abrange vários projetos. Depois de configurar as VPCs, configure também a geração de registro de fluxo de rede e a geração de registro de regras de firewall usando o Cloud Logging. Para mais informações sobre VPCs e como configurá-las, consulte Práticas recomendadas e arquiteturas de referência para o design da VPC.

O Google Cloud oferece muitas opções de conectividade híbrida para conectar seu ambiente existente aos projetos do Google Cloud:

  • Internet pública
  • Cloud VPN
  • Peering
  • Cloud Interconnect

Conectar-se usando a Internet pública é uma opção simples e barata porque é apoiada por uma infraestrutura resiliente que usa a rede de borda atual do Google. Por outro lado, essa infraestrutura não é particular nem dedicada. A segurança dessa opção depende dos aplicativos que trocam dados em cada conexão. Por isso, não recomendamos usar esse tipo de conexão para enviar tráfego não criptografado.

Cloud VPN estende sua rede existente para o Google Cloud usando um túnel IPSec. O tráfego é criptografado e percorre as duas redes pela Internet pública. O Cloud VPN exige configuração extra e pode afetar a capacidade da conexão, mas geralmente será a melhor opção se você não criptografar o tráfego no nível do aplicativo e precisar acessar recursos particulares do Google Cloud.

O peering permite estabelecer uma conexão com a rede do Google por meio de um canal particular. Há dois tipos de peering:

  • O peering direto permite estabelecer uma conexão de peering direta entre sua rede e a rede de borda do Google. Se você não precisar acessar recursos particulares no Google Cloud e atender aos requisitos de peering do Google, esta será uma boa opção. Ele não tem nenhum contrato de nível de serviço (SLA, na sigla em inglês), mas permite reduzir mais taxas de saída do que o acesso à Internet pública do Cloud VPN.
  • O peering de operadora permite conexão à rede do Google usando serviços de rede de nível empresarial gerenciados por um provedor de serviços. O Google não oferece SLA nessa opção de conectividade, mas pode estar coberto pelo SLA de um provedor de serviços. Ao avaliar o preço dessa opção, considere as taxas de saída do Google Cloud e as taxas do provedor de serviços.

O Cloud Interconnect estende a rede atual para a rede do Google por meio de uma conexão altamente disponível. Por padrão, ele não fornece nenhum canal criptografado. Portanto, se você quiser essa opção, recomendamos criptografar o tráfego confidencial no nível do aplicativo. Há duas opções do Cloud Interconnect:

  • A interconexão dedicada oferece conexões particulares com largura de banda alta com pelo menos 10 Gbps, mas exige equipamento de roteamento em uma instalação de colocation. Em outras palavras, é necessário encontrar o Google em um dos pontos de presença (PoPs, na sigla em inglês). O Google oferece um SLA de ponta a ponta para interconexões dedicadas e você é cobrado de acordo com a largura de banda dedicada e o número de anexos.
  • A interconexão por parceiro permite usar conexões particulares dedicadas de alta largura de banda, gerenciadas por um provedor de serviços sem a necessidade de configurar o equipamento de roteamento em uma instalação de colocation do Google. O Google fornece um SLA referente à conexão entre o Google e o provedor de serviços. O provedor de serviços pode oferecer um SLA referente à conexão entre você e eles. O Partner Interconnect é cobrado de acordo com a capacidade de conexão e a quantidade de tráfego de saída que passa pela interconexão. Além disso, pode haver cobranças do provedor de serviços.

Fase 3 da migração: implantar

Depois de criar uma base para o ambiente do Google Cloud, será possível começar a implantar suas cargas de trabalho. O processo de implantação pode ser implementado e refinado durante a migração. Talvez seja necessário revisitar a base do ambiente conforme a migração é realizada. Podem surgir novas necessidades conforme você se torna mais proficiente com o novo ambiente, plataformas, serviços e ferramentas de nuvem.

Quando projetar o processo de implantação para suas cargas de trabalho, você precisa levar em conta quanto de automação e flexibilidade você precisa. Há vários tipos de processos de implantação para você escolher, desde um processo totalmente manual até um processo simplificado e totalmente automatizado.

Implantações totalmente manuais

Provisionar, configurar e implantar de maneira totalmente manual permite que você teste rapidamente a plataforma e as ferramentas. No entanto, esse tipo de implantação também é propenso a erros, não costuma ser documentado e não é replicável. Por isso, recomendamos que você evite implantações totalmente manuais, exceto se você não tiver outra opção. Por exemplo, é possível criar recursos manualmente usando o Console do Cloud, como uma instância do Compute Engine, e executar manualmente os comandos para implantar sua carga de trabalho.

Ferramentas de gerenciamento de configurações

Uma ferramenta de gerenciamento de configurações permite configurar um ambiente de forma automatizada, replicável e controlada. A ferramenta de gerenciamento de configurações pode ser usada para configurar o ambiente e implantar suas cargas de trabalho. Ele é um processo melhor em comparação a uma implantação totalmente manual, mas normalmente não tem os recursos necessários para uma implantação elaborada, como uma implantação sem inatividade ou uma implantação azul-verde. Algumas ferramentas de gerenciamento de configurações permitem implementar sua própria lógica de implantação e podem ser usadas para imitar esses recursos ausentes. No entanto, usar uma ferramenta de gerenciamento de configurações como uma ferramenta de implantação pode aumentar a complexidade do processo. Com isso, é possível que ele fique mais difícil de gerenciar e manter do que um conjunto dedicado de ferramentas de implantação. Projetar, criar e manter uma solução de implantação personalizada pode ser um enorme obstáculo extra para a equipe de operações.

Orquestração de contêineres

Se você já investiu em contentorização, pode ir além e usar um serviço como o Google Kubernetes Engine (GKE) para orquestrar as cargas de trabalho. Usando o Kubernetes para orquestrar contêineres, não é preciso se preocupar com a infraestrutura subjacente e a lógica de implantação.

Automação de implantação

Ao implementar um processo de produção e implantação de artefatos automatizados, como um pipeline de integração contínua e entrega contínua (CI/CD), é possível automatizar a criação e a implantação de artefatos. Esse processo pode ser totalmente automatizado, e é possível até mesmo inserir etapas manuais de aprovação, se necessário.

Para um exemplo de implementação desse processo, consulte Pipelines de entrega contínua com Spinnaker e Google Kubernetes Engine.

Infraestrutura como código

É possível automatizar o processo de implantação implementando um pipeline de CI/CD, mas você também pode adotar um processo semelhante para sua infraestrutura. Ao definir sua infraestrutura como código, é possível provisionar automaticamente todos os recursos necessários para executar suas cargas de trabalho. Com esse tipo de processo, você torna sua infraestrutura mais observável e replicável. Também é possível usar uma abordagem de desenvolvimento voltado a testes na infraestrutura. Por outro lado, é necessário investir tempo e esforço para implementar uma infraestrutura como processo de código. Portanto, leve isso em consideração quando estiver planejando a migração.

O Cloud Deployment Manager é uma ferramenta que pode ajudar a implementar sua infraestrutura como processos de código no Google Cloud.

Fase 4 da migração: otimizar

Depois de implantar suas cargas de trabalho, comece a otimizar seu ambiente de destino. Nessa fase de otimização, as seguintes atividades intersetoriais podem ajudar a otimizar o ambiente:

  • Construir e treinar a equipe.
  • Monitorar tudo.
  • Automatizar tudo.
  • Codificar tudo.
  • Usar serviços gerenciados em vez de serviços autogerenciados.
  • Otimizar para desempenho e escalonabilidade.
  • Reduzir custos.

Construir e treinar a equipe

Durante o planejamento da migração, treine suas equipes de desenvolvimento e operações para aproveitar ao máximo o novo ambiente de nuvem. Com treinamento eficaz, essas equipes podem ser mais eficientes e escolher as melhores ferramentas e serviços nativos da nuvem para a tarefa. As oportunidades de treinamento ajudam a reter talentos técnicos e capacitar engenheiros para aproveitar todas as vantagens do Google Cloud.

Durante essa fase, você também pode revisar os processos de negócios que governam essas equipes. Caso identifique nos processos algo ineficiente ou alguma sobrecarga desnecessária, você terá a chance de refiná-los e melhorá-los com treinamento.

Monitore tudo

O monitoramento é a chave para garantir que tudo no ambiente esteja funcionando conforme esperado e para melhorar seus ambientes, práticas e processos.

Antes de expor seu ambiente ao tráfego de produção, recomendamos que você projete e implemente um sistema de monitoramento e que defina as principais métricas para avaliar o funcionamento correto do ambiente e componentes, incluindo cargas de trabalho. Por exemplo, se estiver implantando uma infraestrutura em contêiner, será possível implementar um sistema de monitoramento de white-box com o Prometheus. Também é possível monitorar seus dispositivos do IoT Core com o Cloud Logging e o Cloud Functions.

Também recomendamos que você configure um sistema de alertas como o alerta do Cloud Monitoring, o que permite ser proativo, e não apenas reativo. É necessário configurar alertas de erros e condições críticas, além de avisos que permitam que você corrija uma situação potencialmente disruptiva antes que ela afete os usuários.

É possível exportar os registros de métricas do Cloud Monitoring para armazenamento a longo prazo porque os registros do Cloud Logging têm um período de retenção limitado. Há também a opção de executar análises de dados com base nas métricas extraídas desses registros para receber insights sobre o desempenho do seu ambiente e começar a planejar melhorias.

Automatizar tudo

Operações manuais têm um alto risco de erros e também são demoradas. Na maioria dos casos, é possível automatizar atividades críticas, como implantações, trocas de segredos e atualizações de configuração. A automação poupa tempo, diminui custos e reduz riscos. As equipes também se tornam mais eficientes, porque não precisam se esforçar em tarefas repetitivas. Como automatizar a infraestrutura com o Cloud Composer e Como automatizar o Canary Analysis no Google Kubernetes Engine com Spinnaker são exemplos de automação no Google Cloud.

Codificar tudo

Ao aprovisionar o ambiente de destino no Google Cloud, você precisa capturar todos os aspectos possíveis no código. Implementando processos como infraestrutura como código e política como código, você será capaz de tornar o ambiente totalmente auditável e replicável. Também é possível usar uma abordagem de desenvolvimento voltado a testes para aspectos além do código, para ter um feedback imediato sobre as modificações que você pretende aplicar ao ambiente.

Usar serviços gerenciados em vez de serviços autogerenciados

O Google Cloud tem um portfólio de serviços e produtos que é possível usar sem precisar gerenciar servidores ou infraestrutura subjacentes. Na fase de otimização, é possível expandir cargas de trabalho para usar esses serviços ou substituir algumas cargas de trabalho atuais por esses serviços.

Veja a seguir alguns exemplos de serviços gerenciados:

  • Usar o Cloud SQL for MySQL em vez de gerenciar seu próprio cluster do MySQL.
  • Usar o AutoML para marcar e classificar imagens em vez de implantar e manter seus próprios modelos de machine learning.
  • Implantar suas cargas de trabalho no GKE em vez de usar seu próprio cluster autogerenciado do Kubernetes, ou até mesmo migrar suas VMs para contêineres e executá-las no GKE.
  • Usar o Google App Engine para hospedar na Web sem servidor.

Otimizar para desempenho e escalonabilidade

Uma das vantagens da migração para a nuvem é o acesso a recursos. É possível reforçar recursos atuais, adicionar mais quando precisar e também remover recursos desnecessários de forma escalonável.

Você tem mais opções para otimizar o desempenho do que em implantações locais:

Reduzir custos

O Google Cloud oferece uma ampla gama de ferramentas e opções de preços para ajudar você a reduzir custos.

Por exemplo, se você tiver provisionado instâncias do Compute Engine, pode aplicar recomendações de dimensionamento nessas instâncias.

Para reduzir seu faturamento, é possível analisar seus relatórios de faturamento para estudar suas tendências de gasto e determinar quais produtos do Google Cloud são usados com mais frequência. É possível até mesmo exportar dados de faturamento para o BigQuery ou para um arquivo para análise.

Para reduzir ainda mais seus custos, o Google Cloud tem recursos como descontos por uso prolongado que aplicam descontos automáticos ao faturamento do Compute Engine. Também é possível comprar contratos de uso contínuo para garantir preços com desconto para instâncias do Compute Engine. Para o BigQuery, inscreva-se no sistema de preços de taxa fixa. Os recursos de escalonamento automático do Google Cloud também ajudam a reduzir seu faturamento por meio da diminuição dos recursos de acordo com as solicitações dos clientes. Para reduzir os custos de monitoramento e geração de registros, otimize o uso do Cloud Monitoring e do Cloud Logging.

Como encontrar ajuda

O Google Cloud oferece várias opções e recursos para você encontrar a ajuda e o suporte necessários para aproveitar melhor os serviços do Google Cloud.

Recursos de autoatendimento

Caso não precise de suporte dedicado, use estes recursos de autoatendimento:

Parceiros em tecnologia

O Google Cloud firmou uma parceria com várias empresas para permitir que você use os produtos delas. Algumas das ofertas podem ser gratuitas. Dessa maneira, pergunte à empresa e ao gerente da sua conta do Google Cloud.

Veja alguns dos produtos:

Integradores de sistemas

O Google Cloud faz parceria não apenas com empresas de produtos e tecnologia, mas com integradores de sistemas que podem fornecer assistência prática. Na lista de parceiros, você encontra uma lista de integradores de sistemas especializados em migrações na nuvem.

Google Cloud Professional Services

Nossa equipe de serviços profissionais está aqui para ajudar você a aproveitar ao máximo seu investimento no Google Cloud.

Cloud Plan and Foundations: ajuda na sua migração

Os Serviços Profissionais podem ajudar a planejar sua migração e implantar suas cargas de trabalho com nossa oferta do Cloud Plan and Foundations. Esses especialistas orientam sua equipe em cada fase da migração de sua carga de trabalho para a produção, desde a configuração do Google Cloud Foundations até a otimização da plataforma para suas necessidades exclusivas de carga de trabalho e implantação da carga de trabalho.

Os objetivos do Cloud Plan and Foundations são estes:

  • Configurar a base do Google Cloud.
  • Criar a documentação do projeto.
  • Planejar atividades de implantação e migração.
  • Implantar cargas de trabalho até a produção.
  • Acompanhar problemas e riscos.

Os Serviços Profissionais orientam sua equipe por meio das seguintes atividades e materiais:

  1. Realização de workshops técnicos iniciais
  2. Criação de um documento de projeto técnico
  3. Criação de um plano de migração
  4. Criação de uma licença do programa
  5. Gerenciamento de projetos
  6. Conhecimento técnico

Cloud Sprint: acelere sua migração para o Google Cloud

O Cloud Sprint é um workshop prático e intensivo que acelera a migração do seu app para o Google Cloud. Neste workshop, os serviços profissionais do Google Cloud lideram uma das suas equipes por meio de discussões interativas, sessões expositivas e revisão dos aplicativos de destino a serem migrados para o Google Cloud. Durante o Cloud Sprint, os serviços profissionais trabalham com os membros da equipe para ajudar você a ter experiência em nuvem com as atividades de implantação necessárias para entender as próximas etapas das futuras migrações do Google Cloud.

Treinamento: desenvolver as habilidades da sua equipe

Os serviços profissionais do Google Cloud podem fornecer treinamentos nos campos com base nas necessidades da sua equipe.

A seguir