Neste documento, mostramos uma arquitetura que usa uma malha de serviço do Istio para migrar de um ambiente legado, como um data center local que executa aplicativos em máquinas virtuais, para Google Kubernetes Engine (GKE). O uso de uma malha de serviço pode reduzir a complexidade da migração e da refatoração, porque ela separa as funções de rede das funções de serviço.
Este documento explica a lógica da migração e descreve suas fases de alto nível. É possível usar essa arquitetura para realizar uma migração em uma operação (às vezes chamada de migração big-bang) ou para realizar uma migração gradual, recurso a recurso. O documento de implantação complementar orienta você em um exemplo de migração.
Esta arquitetura e o guia de implantação dela são destinados a profissionais de TI que gerenciam uma infraestrutura complexa e querem migrar e modernizar gradualmente, minimizando os seguintes problemas:
- Inatividade
- Esforço de refatoração
- Complexidade operacional da rede
Os conceitos explicados aplicam-se a qualquer nuvem, portanto, o documento pressupõe que você conhece as tecnologias da nuvem, contêineres e microsserviços.
Conforme descrito em Migrar para o Google Cloud: primeiros passos, há vários padrões de migração para a nuvem. A arquitetura neste documento usa um padrão de refatoração (às vezes chamado de mover e melhorar), em que o padrão é aplicado a cada recurso do aplicativo, e não ao aplicativo como um todo.
Durante a migração, o aplicativo tem uma arquitetura híbrida em que alguns recursos estão no Google Cloud e outros ainda estão no ambiente legado. Após a conclusão da migração, o aplicativo inteiro fica hospedado no Google Cloud.
Arquitetura
O diagrama a seguir mostra como é possível usar uma malha de serviço para rotear o tráfego para microsserviços em execução no ambiente de origem ou para o Google Cloud:
A arquitetura inclui os seguintes componentes:
Um ambiente de origem. Neste caso, uma instância do Compute Engine que hospeda a carga de trabalho de exemplo a ser migrada. O ambiente de origem também pode ser local ou hospedado em outras plataformas de nuvem.
Uma malha de serviço, neste caso, o Istio Gateway, que vincula diferentes serviços. A malha de serviço fornece recursos de rede de alto valor, como descoberta de serviços, comunicações seguras, balanceamento de carga, gerenciamento de tráfego e observabilidade.
Uma implementação típica de uma malha de serviço combina cada serviço com um proxy que fornece esses recursos. O proxy de serviço é mais frequentemente chamado de um arquivo secundário. O papel do arquivo secundário é aumentar e melhorar o aplicativo ao qual ele está anexado, geralmente sem o conhecimento dele. No guia de implantação complementar, use o Envoy como um proxy de arquivo secundário.
Uma carga de trabalho que contém um aplicativo composto de microsserviços. Um microsserviço é um componente independente, criado para acomodar um recurso do aplicativo. Nesta arquitetura, o aplicativo é composto por diferentes microsserviços que os usuários não conseguem distinguir. Por exemplo, um componente que processa resenhas literárias é um microsserviço.
No padrão de microsserviços, o aplicativo é o agregado de vários microsserviços, cada um com uma finalidade específica. Por exemplo, é possível ter um microsserviço que processa as classificações de livros e outro que processa as resenhas literárias. Esses microsserviços devem ser ligeiramente acoplados e interagir uns com os outros por meio de APIs bem definidas. Eles podem ser escritos em linguagens e frameworks diferentes (como em aplicativos poliglotas) e podem ter ciclos de vida diferentes.
Um contêiner que serve para definir melhor os limites de cada microsserviço. Como o ambiente de destino nesta arquitetura é orquestrado com o Kubernetes, recomendamos que você coloque os microsserviços em um contêiner usando as seguintes ferramentas:
- Docker: é uma ferramenta para isolar programas no nível do espaço do usuário no nível do sistema operacional. Executa pacotes denominados contêineres.
- Kubernetes: é a solução líder de orquestração para cargas de trabalho em contêineres. Inclui recursos como descoberta de serviços, balanceamento de carga, pods, nós e secret de autorrecuperação e gerenciamento de configuração.
- O GKE é um ambiente gerenciado e pronto para produção do Kubernetes que faz parte do Google Cloud.
Para receber orientações sobre como fazer isso, consulte Práticas recomendadas para criar contêineres e Práticas recomendadas para operar contêineres.
Para realizar uma migração usando uma malha de serviço, conclua as fases a seguir:
- Avalie o ambiente legado: colete informações e estabeleça um conjunto de requisitos para o ambiente de destino e um valor de referência para teste e validação.
- Crie uma base no ambiente de destino: provisione seu ambiente de destino e aplique uma metodologia de infraestrutura como código para tornar sua infraestrutura auditável, repetível e automaticamente provisionáveis.
- Implantar serviços e começar a rotear o tráfego para o ambiente de destino: conclua uma única operação para implantar todas as instâncias de microsserviço ao mesmo tempo ou conclua uma implantação gradual para implantar um microsserviço por vez.
- Interromper o roteamento do tráfego para o ambiente legado: configure regras de roteamento para rotear o tráfego para serviços em execução apenas no ambiente de destino.
- Desativar o ambiente legado: atualize seus registros DNS de modo que eles apontem para o balanceador de carga configurado durante a fase de provisionamento do ambiente de destino.
Neste documento, descrevemos algumas considerações de design para esse tipo de migração, e o guia de implantação complementar fornece etapas detalhadas para concluir a migração.
Considerações sobre o design
Esta seção fornece orientações para ajudar você a desenvolver uma arquitetura que atenda aos seus requisitos específicos de confiabilidade, eficiência operacional, custo e otimização de desempenho.
Confiabilidade
As seções a seguir descrevem considerações sobre a confiabilidade da migração.
Usar uma estratégia de migração gradual
Embora essa arquitetura possa ser usada para uma migração de operação única, recomendamos que você use uma estratégia de migração gradual. Concluir a migração em uma operação é difícil devido aos desafios e riscos envolvidos na migração de um ou mais aplicativos de uma só vez. Quando há restrições de tempo e orçamento, concentrar-se em uma migração de operação simpes não deixa muita capacidade de trabalho para novos recursos de aplicativos.
Por outro lado, uma migração gradual, recurso a recurso, tem uma complexidade geral reduzida pelo tamanho menor da carga de trabalho a ser migrada: um único recurso ocupa menos espaço do que o aplicativo inteiro. Uma migração gradual permite distribuir o risco em eventos de migração menores e não em um único exercício de alto risco. Uma migração gradual também permite que a equipe de migração possa planejar, projetar e desenvolver várias estratégias de migração para acomodar diferentes tipos de recursos.
Para orientações sobre como escolher quais recursos migrar primeiro e como migrar recursos com estado, consulte Como escolher os apps para migrar primeiro em "Migrar para o Google Cloud: avaliar e a descobrir suas cargas de trabalho".
Usar um pacote de testes de conformidade
Para facilitar a migração, recomendamos que você use um pacote de testes de conformidade. Um conjunto de testes de conformidade é um conjunto de testes que pode ser executado em um ambiente para verificar se ele atende a um determinado conjunto de requisitos. Se o ambiente é válido, ele atende aos requisitos. Por exemplo, é possível validar a resposta para uma solicitação de teste ou verificar se as dependências do aplicativo estão instaladas.
Inicie com ferramentas de monitoramento, rastreamento e visualização de malha de serviço para fazer uma validação manual. Em seguida, implemente o pacote de testes e desenvolva-o ao longo do tempo das seguintes maneiras:
- Teste de carga: aplique o conjunto de testes enviando automaticamente o tráfego de teste para o ambiente e avaliando os resultados.
- Ferramenta de teste de conformidade: é possível projetar e desenvolver um conjunto de testes usando uma ferramenta dedicada.
Execute o conjunto de testes de conformidade no ambiente legado como um valor de referência e também no ambiente de destino, durante e após a migração.
O conjunto de testes deve se concentrar nos aspectos a seguir para validação durante a migração:
- Provisionamento: provisione os recursos necessários no seu ambiente antes de configurá-los.
- Configuração: depois de provisionar os recursos no ambiente, configure-os de acordo com as necessidades do aplicativo. Ter um conjunto de testes de configuração garante que o ambiente esteja pronto para hospedar o aplicativo.
- Lógica de negócios: depois de validar o provisionamento e a configuração do ambiente, valide a lógica de negócios do seu aplicativo. Por exemplo, é possível validar as respostas às solicitações.
Chef InSpec, RSpec e Serverspec são ferramentas para desenvolver conjuntos de testes de conformidade automatizados. Eles funcionam em qualquer plataforma e são extensíveis para que você possa implementar seus próprios controles, começando pelos controles integrados.
Quando você provisiona seu ambiente de destino, pode usar o pacote de testes de conformidade para validá-lo. Talvez seja necessário atualizar o conjunto de testes para considerar as as eventuais diferenças entre o ambiente legado e o de destino, como hardware e topologia de rede. Você está mudando de um ambiente local, com controle total, para um ambiente de nuvem pública, em que você normalmente não tem acesso total à pilha inteira.
Antes de rotear o tráfego da camada de balanceamento de carga do ambiente legado para o ambiente de destino, recomendamos que você execute o conjunto de testes de conformidade da lógica de negócios nos microsserviços expostos pelo ambiente de destino. O pacote de testes ajuda a garantir que os microsserviços funcionem conforme o esperado. Por exemplo, é possível validar as respostas retornadas pelos serviços expostos pela malha de serviço. Mantenha a rota original como uma opção de backup para o caso de precisar reverter as alterações e voltar para o ambiente legado. Ao encaminhar uma pequena parte do tráfego de produção para instâncias dos microsserviços em execução no ambiente de destino, é possível criar confiança no ambiente de destino e aumentar o tráfego total ao longo do tempo.
Não permitir solicitações entre ambientes
Durante a fase de teste de conformidade, recomendamos que você refine as regras de roteamento para impedir solicitações entre ambientes. Assim, quando uma solicitação do cliente atingir um ambiente, legado ou de destino, ela permanecerá nesse ambiente. O bloqueio de solicitações entre ambientes ajuda a garantir que os testes validem corretamente o ambiente de destino. Se você não bloquear essas solicitações, um teste poderá informar sucesso no ambiente de origem em vez de no ambiente de destino, sem seu conhecimento.
Desativar o ambiente legado
Antes de desativar o ambiente legado, verifique se todas as condições a seguir são verdadeiras:
- Nenhum tráfego está sendo roteado para instâncias de microsserviços em execução no ambiente legado.
- Nenhum tráfego chega por meio das interfaces do ambiente legado.
- O ambiente de destino foi validado completamente.
Se essas condições foram atendidas, atualize os registros DNS para apontar para o balanceador de carga que você configurou durante a fase de provisionamento do ambiente de destino. Não desative o ambiente legado, a menos que você tenha certeza de que o ambiente de destino foi validado. Não limite a validação somente à lógica de negócios, mas pense em outros requisitos não funcionais, como desempenho e escalonabilidade.
Eficiência operacional
As seções a seguir descrevem considerações relacionadas à eficiência operacional da migração.
Avaliar o ambiente legado
Antes de projetar ou implementar um plano de migração, você precisa avaliar o ambiente legado para coletar informações e estabelecer um conjunto de requisitos para o ambiente de destino e um valor de referência para teste e validação. Comece criando um catálogo de todos os recursos de aplicativos a serem migrados. Para cada recurso, você deverá responder a este conjunto com alguns exemplos de perguntas:
- Quais são os requisitos de ambiente de execução e desempenho?
- Há alguma dependência de outros recursos?
- Esse recurso é essencial para a empresa?
- Esse recurso é sem estado ou com estado?
- Quanto de refatoração é esperado para migrá-lo?
- Esse recurso pode arcar com uma janela de transferência?
Para mais informações, consulte Migrar para o Google Cloud: avaliar e descobrir as cargas de trabalho.
Recursos sem estado versus com estado
A arquitetura usa uma malha de serviço porque ela separa as funções de serviço (como a lógica de negócios é implementada) das funções de rede (como e quando rotear o tráfego para as funções de serviço). Na implantação correspondente, use o Istio como a malha de serviço.
No ambiente legado, a maioria das chamadas de serviço não envolve a rede porque ocorrem em uma plataforma monolítica. Em uma arquitetura de microsserviços, as comunicações entre serviços ocorrem em uma rede, e os serviços precisam lidar com esse modelo diferente. Uma malha de serviço abstrai as funções para lidar com as comunicações de rede, portanto, você não precisa implementá-las em cada aplicativo. Uma malha de serviço também reduz a complexidade operacional da rede, porque fornece canais de comunicação seguros, balanceamento de carga, gerenciamento de tráfego e recursos de observabilidade que não exigem nenhuma configuração.
Ao implantar e configurar uma malha de serviço, é possível direcionar dinamicamente o tráfego para o ambiente legado ou de destino. Não é preciso modificar a configuração do aplicativo para dar suporte à sua migração, porque o gerenciamento de tráfego é transparente para os serviços na malha.
Embora essa abordagem funcione bem para recursos sem estado, é preciso mais planejamento e refatoração para migrar recursos com estado, sensíveis à latência ou altamente acoplados a outros recursos:
- Com estado: ao migrar recursos com estado, você também precisa migrar os dados para minimizar a inatividade e os problemas de sincronização e integridade durante a migração. Saiba mais sobre as estratégias de migração de dados na seção Como avaliar abordagens de migração de dados de "Migração para o Google Cloud: como transferir seus grandes conjuntos de dados".
- Sensível à latência: se um recurso for sensível à latência ao se comunicar com outros recursos, talvez seja necessário implantar mais componentes durante o processo de migração. Proxies que podem fazer a pré-busca de dados ou camadas de armazenamento em cache geralmente são usados para mitigar essa sensibilidade.
- Altamente acoplado a outros recursos: se dois ou mais recursos estiverem altamente acoplados, talvez seja necessário migrá-los ao mesmo tempo. Essa abordagem é mais fácil que migrar um aplicativo inteiro, mas ela pode ser mais difícil que migrar um único recurso.
Registrar serviços com a malha de serviço
Como seu ambiente legado não está diretamente integrado à malha de serviço, ao configurar a migração, você precisará registrar manualmente todos os serviços em execução no ambiente legado com a malha de serviço. Se o ambiente já estiver em execução no Kubernetes, será possível automatizar o registro usando a integração incorporada com as APIs da malha de serviço.
Depois de registrar o ambiente legado, use a malha de serviço para expor os microsserviços em execução no ambiente legado. Em seguida, será possível rotear gradualmente o tráfego para microsserviços das interfaces do ambiente legado para as interfaces do ambiente de destino.
Os clientes não veem nenhuma interrupção do serviço, porque acessam as interfaces dos dois ambientes por meio de uma camada de balanceamento de carga. O roteamento de tráfego dentro da malha de serviço é transparente para os clientes. Portanto, eles não saberão que a configuração de roteamento foi alterada.
Otimização de custos
Nesta arquitetura, usamos os seguintes componentes faturáveis do Google Cloud:
Ao implantar a arquitetura, use a calculadora de preços para gerar uma estimativa de custo com base no uso projetado.
Otimização de desempenho
Nessa arquitetura, o tráfego é dividido quase igualmente entre os serviços em execução no Compute Engine e os serviços em execução no GKE. A malha de serviço equilibra o tráfego entre as instâncias de um serviço selecionado, estejam elas em execução no cluster do GKE ou nas instâncias do Compute Engine. Se você quiser que todo o tráfego passe pela malha de serviço, será necessário reconfigurar as cargas de trabalho em execução no Compute Engine para apontar para os serviços na malha, em vez de se conectar diretamente a eles. É possível configurar a política de balanceamento de carga para as revisões de cada serviço com o recurso DestinationRule.
Implantação
Para implantar essa arquitetura, consulte Implantar a migração com a expansão de malha do Istio.
A seguir
- Leia sobre o GKE.
- Leia sobre o Istio.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.