Como migrar aplicativos da Web de dois níveis para o Google Cloud

Neste artigo, apresentamos as opções do Google Cloud para organizações que estejam avaliando a possibilidade de mover um aplicativo da Web de dois níveis para a nuvem.

Tipos de aplicativo

Os aplicativos da Web de dois níveis são compostos de um servidor da Web, em que é executado um aplicativo, e um banco de dados para armazenar dados do aplicativo. A execução do Linux, Apache, MySQL e PHP, normalmente chamada de pilha LAMP, é um exemplo comum de um aplicativo da Web de dois níveis. As variações na distribuição do Linux, feita no software do servidor da Web, no banco de dados ou na linguagem de programação, afetam os detalhes técnicos de qualquer migração, mas a visão geral da migração e as etapas permanecem consistentes.

Fases da migração

As migrações para a nuvem ocorrem nas quatro fases a seguir.

Avaliação

Identifique todas as características da carga de trabalho, liste os recursos necessários para executá-la na nuvem e chame todas as principais dependências e conexões com outras cargas de trabalho. O uso da lista completa de características permite planejar quais aplicativos e cargas de trabalho devem ser movidos e em que ordem.

As empresas modernas usam vários tipos de aplicativos como, por exemplo, os voltados para o cliente, back office, as ferramentas para desenvolvedores e os experimentais. Mover todos eles ao mesmo tempo e da mesma maneira seria arriscado e ineficiente.

Um exemplo é a classificação dos aplicativos nos três buckets gerais a seguir:

  • Aplicativos fáceis de mover. Têm menos dependências, são mais recentes, foram elaborados internamente, ou seja, não exigem licenciamento e são mais flexíveis em relação ao escalonamento e ao suporte dos padrões de concepção da nuvem.
  • Aplicativos difíceis de mover. Têm mais dependências, são menos flexíveis em relação ao escalonamento, difíceis de executar com serviços de nuvem ou têm requisitos complexos de licença.
  • Aplicativos que não podem ser movidos. Alguns aplicativos talvez não sejam bons candidatos para a migração, porque são executados em hardware especializado ou mais antigo, têm requisitos regulatórios ou de negócios que exigem que eles sejam mantidos no seu data center ou têm requisitos complexos de licenciamento que não permitem movê-los para a nuvem.

Esses são apenas alguns exemplos de como classificar aplicativos. Há diversos outros fatores a serem considerados para a criação de uma matriz de priorização de todos os aplicativos. A partir dessa classificação, escolha o primeiro aplicativo a ser movido e comece a planejar a fundação do Google Cloud.

Fundação

Arquitete e planeje detalhes específicos para implantar o novo ambiente de nuvem. Veja alguns exemplos:

  • A arquitetura de nuvem e o modelo de segurança para fornecer uma base de infraestrutura para suas cargas de trabalho.
  • Recursos de rede para permitir uma comunicação segura e confiável entre aplicativos. Isso requer planejamento abrangente para gerenciamento de identidade e acesso (IAM), nuvem privada virtual (VPC) e métodos de acesso externo.

  • A tecnologia de estado final e as ferramentas em que suas cargas de trabalho serão executadas.

  • Contabilização do gerenciamento de dependências, cronogramas e métodos de transferência de dados.

Migração

Mova os dados e implante serviços, infraestrutura e códigos para seu destino. É necessário o uso de automação e ferramentas para dar suporte a essas operações.

Otimização

Verifique se as decisões e suposições feitas nas fases de avaliação e fundação correspondem à realidade após a fase de migração. Identifique a necessidade de possíveis alterações. Pense em como explorar outras opções nativas da nuvem, como passar da Infrastructure as a Service (IaaS) para a Platform as a Service (PaaS) ou aproveitar as ofertas de serviços gerenciados. Dependendo do resultado da fase de otimização, é possível iniciar o ciclo novamente para analisar alterações ou modificações. Sempre recomece na fase de avaliação e use sua experiência para ficar mais eficiente a cada iteração.

Tipos de migrações

As seções a seguir apresentam as três estratégias de migração mais comuns utilizadas para mover aplicativos para a nuvem.

Migração lift-and-shift

Use a migração lift-and-shift para mover os aplicativos alterando o mínimo possível o funcionamento deles. Isso é uma boa opção para aplicativos que podem ser executados sem modificações na nuvem, quando a movimentação rápida do aplicativo é uma prioridade ou quando o negócio tem pouco ímpeto ou necessidade de alteração. Essa migração requer mais envolvimento das equipes de infraestrutura e de operações para dar suporte às mudanças fundamentais em que o serviço será executado e menos envolvimento dos desenvolvedores, já que quase nenhum código precisa ser alterado.

Por exemplo, se os dois níveis do aplicativo da Web estiverem hospedados em VMs, use o Migrate for Compute Engine para fazer a migração deles como estiverem. Quando essas VMs estiverem na nuvem, considere fazer upgrade para uma plataforma de computação mais nativa da nuvem para ter mais benefícios.

Migração improve-and-move

Use transformar e mover quando quiser modernizar seu aplicativo no processo de migração para a nuvem. Isso é usado com frequência quando o aplicativo não tem suporte na nuvem da forma como está ou quando as principais atualizações no software ou no hardware já estão no escopo e planejadas. Essa migração exige que as equipes de infraestrutura, operações e os desenvolvedores trabalhem juntos para melhorar a função do aplicativo na nuvem e permite que o aplicativo tenha os benefícios nativos da nuvem, como mais portabilidade, escalonabilidade e confiabilidade.

Outra variação dessa estratégia é transformar e mover em um só movimento. Se os dois níveis do aplicativo da Web estiverem hospedados em VMs, use o Migrate for Anthos para mover e converter automaticamente essas VMs em contêineres em execução no Google Kubernetes Engine (GKE).

Migração rip-and-replace

Use a migração do tipo romper e substituir quando quiser criar uma nova solução na nuvem e abandonar a versão atual da solução local. Isso é usado com frequência nas seguintes condições:

  • Não vale a pena, do ponto de vista técnico ou financeiro, manter o aplicativo atual na nuvem.
  • Licenciar o software na nuvem é proibitivo ou impraticável.
  • O aplicativo deixou de atender às necessidades do negócio.

A migração do tipo romper e substituir não é abordada neste guia porque exige que o aplicativo seja reescrito a partir do zero.

Fase de avaliação

Antes de começar qualquer migração, é preciso ter uma compreensão detalhada do seu ponto de partida.

Qualquer dúvida não esclarecida representa riscos para o sucesso da migração. Empenhar-se na fase de avaliação ajuda a garantir uma fase de migração tranquila e sem incidentes. Passe o máximo de tempo possível para reunir a maior quantidade possível de informações relevantes para sua migração.

Pilha de software do aplicativo

Trabalhe com as equipes de infraestrutura, operações e desenvolvimento para identificar os seguintes detalhes:

  • Sistema operacional: distribuição exata, versão, patches, pacotes instalados.
  • Servidor da Web: pacote de software exato, número de versão, pacotes ou outra modificação de software e todos os arquivos e regras de configuração para o software do servidor da Web.
  • Banco de dados: nome exato do software, versão, esquema, estratégia de replicação e cronograma de backup.
  • Ambientes de execução: versões exatas de todos os ambientes de back-end e front-end.

Recursos de hardware do sistema

Para o servidor da Web e os níveis do banco de dados, responda às seguintes perguntas:

  • Quantos servidores estão sendo executados agora?
  • Qual é a alocação total de CPUs, incluindo geração, tipo de arquitetura e velocidade?
  • Quais são a RAM e o espaço em disco alocados para cada servidor? Os HDDs ou SSDs estão em uso? RAID?
  • Qual é a utilização atual, qual é a utilização média e qual é a utilização máxima de CPU, de RAM e do espaço em disco? Analise sua média e seu pico de uso no contexto de seu uso comercial específico. Por exemplo, uma empresa ligada às Olimpíadas talvez precise analisar o resultado de dois anos antes para determinar seu pico real, enquanto outros aplicativos podem ter uma taxa de execução mais estável. Observe a linha do tempo de caso de uso mais comum para a média e a linha de tempo de uso mais pesado para o pico. Além disso, procure padrões de uso cíclico, como finais de semana, noites e dias úteis.
  • Para o banco de dados, qual estratégia de backup, replicação ou fragmentação está em uso e como essa estratégia afeta os requisitos de espaço em disco e o número de servidores necessários?

Recursos de rede

Analise a arquitetura de rede que permite o funcionamento do aplicativo. Verifique se os diagramas de topologia de rede lógicos e físicos da infraestrutura que dá suporte ao seu aplicativo são precisos e estão atualizados. Os diagramas precisam descrever claramente todas as conexões, dependências e serviços de rede.

Responda às seguintes perguntas:

  • Como os clientes acessam seu aplicativo? Por um navegador da Web? Diretamente por um endereço IP? Por um aplicativo para dispositivos móveis? Por uma conexão de rede privada virtual?
  • Você tem uma lista de todos os certificados SSL/TLS aplicáveis e chaves de criptografia?
  • Onde todos os certificados SSL/TLS aplicáveis estão hospedados? Quando eles expiram? Como você os certifica? Como você adquire novos certificados? Você tem acesso a todos os certificados atuais?
  • Você tem uma lista de todos os domínios aplicáveis, compatíveis com o aplicativo?
  • Onde esses domínios estão hospedados? Quando eles expiram? Como você os renova? Você tem acesso às contas que controlam o registro?
  • Onde seu DNS está hospedado e é controlado?
  • Você tem acesso a todos os sistemas e ferramentas que controlam o DNS? Quais são os atuais mapeamentos CNAME para IP de cada domínio e, você tem um backup?
  • Quais são suas configurações de DNS de time to live (TTL)?
  • Onde seus firewalls e outros dispositivos de acesso e controle de rede se encaixam na arquitetura? Que regras estão em vigor atualmente para permitir ou negar o tráfego? Quem é responsável por alterar ou atualizar essas regras e qual é o procedimento previsto para isso?
  • Você usa algum serviço de rede externo? Por exemplo, um provedor de rede de fornecimento de conteúdo (CDN, na sigla em inglês) ou um serviço de proteção de ataque distribuído de negação de serviço (DDoS, na sigla em inglês)?

Fase de fundação

O Google Cloud oferece muitas opções para executar cargas de trabalho de computação e de banco de dados para aplicativos de vários níveis, como LAMP. Nesta seção, apresentamos essas opções e explicamos as razões para você escolher uma entre todas elas.

Opções focadas em computação

Compute Engine

O Compute Engine é uma oferta de IaaS que permite executar uma máquina virtual (VM) no Google Cloud. É possível instalar frameworks da Web, software servidor, bancos de dados e qualquer outro software compatível com seu sistema operacional. Se você estiver executando seu próprio aplicativo LAMP em um bare metal, uma VM, um data center ou outro provedor de nuvem, será possível criar uma réplica aproximada ou até mesmo exata de seu servidor atual utilizando essa opção. Essa opção oferece o maior grau de controle sobre a configuração do sistema operacional e as configurações do software do servidor da Web. Com o Compute Engine, você tem um amplo controle sobre os tipos de máquinas, grupos de instâncias, opções de armazenamento, balanceadores de carga e vários outros detalhes. Consulte a documentação completa do Compute Engine para ver mais guias de início rápido, tutoriais e muito mais.

Mover seu aplicativo diretamente para o Compute Engine é o tipo mais comum de migração lift-and-shift. Para orientações sobre como mapear recursos locais para o Compute Engine, consulte Práticas recomendadas de migração de máquinas virtuais para o Compute Engine.

Cloud Deployment Manager

O Google Cloud Marketplace também oferece uma instalação simples do LAMP por meio do Deployment Manager. É possível iniciar um servidor com o Debian Linux, Apache, MySQL, PHP e phpMyAdmin já instalados e configurados em uma configuração padrão. Você recebe em poucos minutos um servidor da Web totalmente funcional e credenciais para a instalação do MySQL.

Google Kubernetes Engine

O GKE é um ambiente gerenciado e pronto para produção para implantar aplicativos em contêineres. Usando o GKE, você para de administrar um sistema operacional por meio da contentorização do seu software de servidor Web. Por exemplo, os servidores da Web Apache e NGINX estão disponíveis em todos os repositórios de contêineres públicos. Se você usa contêineres para executar cargas de trabalho no ambiente, o GKE é um serviço eficiente para manter um fluxo de trabalho de implantação e teste semelhante durante a migração da carga de trabalho do LAMP para o Google Cloud. Se você não usa contêineres, explore o GKE para implantações e recuperação mais rápidas e maior eficiência no uso de recursos sem precisa gerenciar o sistema operacional e a VM subjacentes.

Para saber mais informações sobre gerenciamento de aplicativos de contêiner em escala, consulte a documentação do GKE para guias de início rápido, tutoriais, conceitos, guias de instruções e outros recursos para ajudá-lo a começar.

Mover o aplicativo LAMP local para o GKE é uma migração transformar e mover, enquanto a migração de uma infraestrutura autogerenciada baseada em contêiner é uma migração lift-and-shift.

App Engine

O App Engine é uma plataforma sem servidor para a criação de aplicativos altamente escalonáveis. Dependendo do tipo de aplicativo que está sendo executado, o App Engine pode eliminar a necessidade de gerenciar servidores, contêineres ou implantações, permitindo que seus desenvolvedores se concentrem apenas em escrever código e reduzindo a complexidade do gerenciamentto de qualquer infraestrutura subjacente. Nem todas as cargas de trabalho são boas opções para migrar para o Google App Engine, mas sim aquelas que apresentam reduções de custo e complexidade ao mesmo tempo que aumentam a velocidade de dimensionamento e a resiliência do aplicativo sob carga.

O App Engine é dividido em dois tipos: o ambiente padrão abrange várias linguagens (incluindo PHP para nosso aplicativo LAMP), e o ambiente flexível permite mais personalização de ambientes de execução, desempenho e infraestrutura. Confira a documentação da linguagem de sua preferência para saber mais.

Opções de banco de dados

Autogerenciado no Compute Engine

É possível instalar o MySQL, o PostgreSQL ou qualquer outro banco de dados baseado em SQL em uma instância do Compute Engine. Com isso, você tem o mesmo nível de controle que você teria ao executar o MySQL em uma estação de trabalho, um servidor, um data center ou como uma VM em outro provedor de nuvem. Quando você executa seu banco de dados em uma VM, é sua responsabilidade configurar, monitorar e manter failover, replicação, particionamento e alta disponibilidade.

Trate o banco de dados como uma carga de trabalho de computação, considerando CPU, RAM e espaço em disco para garantir que haja recursos suficientes para o aplicativo ser executado de maneira confiável.

Assim como a movimentação da carga de trabalho de computação para o Compute Engine, essa abordagem representa uma migração lift-and-shift.

Cloud SQL

O Cloud SQL é um serviço de banco de dados totalmente gerenciado que transfere a instalação, a configuração e a manutenção do banco de dados para o Google Cloud. Ele automatiza backups, replicações, patches e atualizações e permite que você se concentre no seu aplicativo. É possível usar os bancos de dados do Cloud SQL com cargas de trabalho em execução em qualquer serviço de computação do Google, incluindo o Compute Engine, o GKE e o App Engine. A menos que você precise de um nível profundo de controle sobre seu banco de dados MySQL, o Cloud SQL é uma opção fácil de configurar e repleta de recursos para executar uma carga de trabalho LAMP.

O Cloud SQL executa de forma nativa e é compatível com MySQL e PostgreSQL. Se você estiver migrando de um desses bancos de dados para o Cloud SQL, será necessária uma migração lift-and-shift. Se você estiver buscando novos métodos de replicação, estratégia de backup ou simplificação do gerenciamento de sua infraestrutura, será necessária uma migração improve-and-move.

Outras opções de armazenamento

O Cloud Storage é um repositório de objetos ou blobs que é escalonável, econômico e de alta confiabilidade, ideal para armazenar imagens, ativos estáticos e outros dados não estruturados. É possível usar o Cloud Storage para hospedar um site estático, mas ele não é projetado para armazenar conteúdo ativo do banco de dados. Também é um local ideal para armazenar objetos de backup e de recuperação de desastres, além de dados a serem usados para streaming.

Pense no Cloud Storage como um local para armazenar backups do banco de dados durante e após a migração.

Firestore

O Firestore é um banco de dados de documentos NoSQL totalmente gerenciado, sem servidor e nativo de nuvem, que simplifica o armazenamento, a sincronização e a consulta de dados para aplicativos móveis, da Web e da Internet das Coisas (IoT) em escala global. As bibliotecas de cliente dele oferecem sincronização em tempo real e suporte off-line. Além disso, os recursos de segurança e de integração com o Firebase e o Google Cloud aceleram a criação de aplicativos verdadeiramente sem servidor. Caso seu aplicativo tenha conteúdo que possa se beneficiar de um formato NoSQL, como perfis de usuário, catálogos de produtos ou estado de jogo, considere o Firestore na fase de otimização da migração.

Firebase

O Firebase é uma plataforma de desenvolvimento móvel abrangente que inclui opções de armazenamento e de banco de dados. Se o aplicativo for compatível com uma carga de trabalho móvel, a plataforma do Firebase deve ser explorada na fase de otimização.

Cloud Spanner

O Spanner é um serviço de banco de dados criado para a nuvem, de nível empresarial, distribuição global e consistência forte. Ele combina os benefícios das estruturas de bancos de dados relacionais com a escalonabilidade horizontal de bancos de dados não relacionais. Se o aplicativo puder se beneficiar de capacidade de gerenciamento e de escalonabilidade aprimoradas, além de transações com consistência forte, considere a migração de seu banco de dados para o Spanner na fase de otimização.

O Google Cloud oferece muitas outras opções de armazenamento compatíveis com diversas cargas de trabalho.

Fase de migração

Depois de concluir a avaliação e planejar a migração, comece o trabalho de mover dados, serviços e recursos para o Google Cloud. Cada aplicativo tem necessidades específicas. Nesta seção, apresentamos alguns exemplos para ajudar a demonstrar o que acontece nessa fase.

Migração lift and shift: Compute Engine

O primeiro passo para começar a migração lift-and-shift é estabelecer um serviço de vários níveis compatível com o Google Compute Engine. Embora existam muitas abordagens para isso, as três mais comuns são as seguintes:

  • Configuração manual. Inicie uma VM com o sistema operacional que você quer usar, atualize manualmente os repositórios, instale e configure o software e provisione e configure o banco de dados e o ambiente de execução manualmente. Essa abordagem proporciona um alto nível de controle mas leva mais tempo, é mais propensa a erros e é menos reproduzível do que outros métodos.
  • Automatização. Use o Migrate for Compute Engine para migrar uma pilha de VMs (em uma ordem especificada) do local para VMs de tamanho certo, provisionadas e configuradas automaticamente no Compute Engine.
  • Cloud Marketplace. Inicie uma pilha LAMP pré-configurada no projeto do Google Cloud. Certifique-se de que o sistema operacional e as versões de software fornecidos funcionam com seu aplicativo. Consulte a documentação do Cloud Marketplace para saber mais.
  • Implantação automatizada. Crie VMs prontas para produção usando conceitos de integração contínua/implantação contínua e diversas de ferramentas de gestão de configuração (Chef, Puppet, Ansible, Salt), infraestrutura como código (Deployment Manager, Terraform), e frameworks de automatização (Cloud Build). A implantação automatizada permite métodos testáveis, reproduzíveis e automatizados para implantar VMs e softwares que atendem às suas necessidades de aplicativos e de governança.

Transformar e mover: GKE e Cloud SQL

Para migrar para uma solução de contêiner gerenciado, você precisa primeiro estabelecer a base para a solução de cluster e SQL gerenciada.

Como lançar um cluster do GKE

As primeiras etapas são criar um cluster no GKE e gerenciar esse cluster. Use as informações das fases de avaliação e de fundação para dimensionar e configurar adequadamente o cluster inicial e aplicar as práticas recomendadas de aumento da proteção de segurança.

Opções de lançamento do Cloud SQL

Usando as informações do banco de dados adquiridas nas fases de avaliação e fundação, crie uma nova instância do Cloud SQL e siga outros guias de instruções para criar o banco de dados para seu aplicativo. O Google fornece uma lista de práticas recomendadas do Cloud SQL, guias para configurar alta disponibilidade e outros tutoriais para escalonamento horizontal. Consulte as opções de conexão do Google Kubernetes Engine ao Cloud SQL e escolha a melhor opção para seu aplicativo e seu nível de experiência.

Transformar e mover sem servidor: App Engine e Cloud SQL

Se você decidir migrar seu aplicativo LAMP para um framework sem servidor, talvez seja necessário modificar seu aplicativo para que seja compatível com o App Engine. Cada aplicativo é diferente e há muitas estratégias. Comece avaliando o seguinte:

Dependendo da sua experiência organizacional e pessoal e da sua familiaridade com a execução de código sem servidor, a estratégia de migração transformar e mover sem servidor pode levar muito mais tempo do que as opções de migração lift-and-shift. No entanto, adquirir o melhor da tecnologia sem servidor pode ser um importante recurso para sua organização.

Fase de otimização

Depois que seu aplicativo estiver em execução no Google Cloud, será possível validar suas suposições e decisões das três fases anteriores. Às vezes migrações completas levam muito tempo, e há a possibilidade de mudança nos detalhes ao longo do processo. A otimização abrange muitas áreas, mas aqui estão algumas categorias comuns.

Otimização de custos

Mover-se do local para a nuvem altera a maneira como você gasta dinheiro em aplicativos, serviços e infraestrutura. É possível concluir uma avaliação de um serviço local legado e descobrir, após a migração, que o hardware moderno, a memória mais rápida e as novas arquiteturas de CPU o executam com mais eficiência. Isso pode significar que suas VMs estão aprovisionadas em excesso e desperdiçando dinheiro.

Investigue usando instâncias de VM preemptivas no Compute Engine. Talvez você não precise usar uma quantidade tão grande de balanceadores de carga agora ou talvez tenha conseguido limpar seu banco de dados durante a mudança e, assim, liberado um espaço que ainda não está em uso. Encontrar maneiras de economizar dinheiro e reduzir os custos operacionais na nuvem é um trabalho em tempo integral com grandes retornos. O Google Cloud tem várias ferramentas de gerenciamento de custos que podem ajudar a entender os preços da nuvem.

Automação

A automatização correta das cargas de trabalho de computação na nuvem gera economia e benefícios de eficiência. O Deployment Manager é um produto do Google Cloud desenvolvido para ajudar a criar e gerenciar recursos de nuvem usando modelos simples. Usar scripts com o gcloud é uma opção se você preferir criar suas próprias automações. Além de benefícios financeiros, a automatização traz outras vantagens, como estas:

  • Processos padrão e repetitivos para reduzir as taxas de erro.
  • Rastreamentos auditáveis de conformidade e governança.
  • Maior compreensão sobre como o aplicativo funciona, como deixa de funcionar e como consertá-lo.

A automatização aumenta o tempo de atividade ao reduzir a dependência dos alertas e do tempo de reação humana, diminui o débito técnico por meio da documentação do fluxo de trabalho e permite que os engenheiros se concentrem menos na manutenção e mais na criação de produtos, ferramentas e serviços melhores. Esses conceitos estão no centro da engenharia de confiabilidade do site (SRE). O Google Cloud oferece um livro on-line gratuito sobre engenharia de confiabilidade do site, bem como uma apostila de SRE com exemplos práticos e estudos de caso.

Como desacoplar sua infraestrutura e código

Você desacopla serviços muitas vezes à medida que um aplicativo cresce. Desmembrar os serviços conectados e saber como dimensioná-los de maneira independente melhora a disponibilidade e a confiabilidade de seus aplicativos. Geralmente, há três etapas para esse processo:

  • Implemente em todos os lugares a infraestrutura como código (IaC, na sigla em inglês). Ao implementar a IaC e os processos de gerenciamento de configuração, você consegue elementos básicos rastreáveis, auditáveis e reproduzíveis para o aprovisionamento e a configuração de toda sua infraestrutura.
  • Desacople seus serviços atuais em microsserviços. Use um middleware orientado a mensagens, como o Pub/Sub, para permitir que cada microsserviço seja seu próprio domínio de falha.
  • Comece a migrar os serviços da infraestrutura como serviço para a plataforma como serviço ou até mesmo para funções como serviço ou sem servidor como serviço. A jornada de "código e infraestrutura monolítica" para "microsserviços desacoplados que funcionam de maneira eficiente em todo o espectro de IaaS" é uma meta valiosa em que o atingimento demandará tempo, esforço e dedicação.

Ajuste de desempenho

O ajuste de desempenho gera ganhos significativos na utilização do sistema e no tempo de resposta. Cada carga de trabalho tem um método diferente para ajuste de desempenho, desde os arquivos de configuração de software até as sinalizações de ajuste do kernel. Para aplicativos LAMP, o ajuste de desempenho geralmente é classificado dentro de três categorias:

A seguir