Com o padrão de arquitetura híbrido de ambiente, você mantém o ambiente de produção de carga de trabalho no data center atual. Depois, você usa a rede nuvem para seus ambientes de desenvolvimento e teste ou outros. Esse padrão depende da implantação redundante dos mesmos aplicativos em vários ambientes de computação. O objetivo da implantação é ajudar a aumentar a capacidade, a agilidade e a resiliência.
Ao avaliar quais cargas de trabalho migrar, talvez você perceba casos em que a execução de um aplicativo específico na nuvem pública apresenta desafios:
- Restrições relativas a uma jurisdição ou regulatórias podem exigir que você mantenha dados em um país específico.
- Termos de licenciamento de terceiros podem impedir que você opere determinados softwares em um ambiente de nuvem.
- Um aplicativo pode exigir acesso a dispositivos de hardware disponíveis apenas localmente.
Nesses casos, considere não só o ambiente de produção, mas todos ambientes que estão envolvidos no ciclo de vida de um aplicativo, incluindo desenvolvimento, teste e preparo. Essas restrições geralmente se aplicam à o ambiente de produção e os dados dele. Talvez elas não se apliquem a outras ambientes que não usam dados reais. Verifique a conformidade departamento de sua organização ou a equipe equivalente.
O diagrama a seguir mostra um típico padrão híbrido de ambiente.
Executar sistemas de desenvolvimento e teste em ambientes diferentes sistemas de produção podem parecer arriscados e podem se desviar do seu melhor práticas ou de suas tentativas de minimizar diferenças entre suas do Google Cloud. Essas preocupações se justificam, mas não se aplicam se você distinguir entre os cenários dos processos de desenvolvimento e teste:
Os processos de desenvolvimento, teste e implantação são diferentes para cada aplicativo, mas eles geralmente envolvem variações dos seguintes cenários:
- Desenvolvimento: criar um candidato de versão.
- Teste funcional ou teste de aceitação do usuário: verificar se o candidato de versão atende aos requisitos funcionais.
- Teste de desempenho e confiabilidade: verificar se o candidato de versão atende aos requisitos não funcionais. Também é conhecido como teste de carga.
- Teste de implantação ou preparo: verificar se o procedimento de implantação funciona.
- Produção: lançar aplicativos novos ou atualizados.
Raramente vale a pena realizar mais de um desses cenários em um único ambiente. Portanto, cada um deles normalmente requer um ou mais ambientes dedicados.
O objetivo principal de um ambiente de teste é executar testes funcionais. O a finalidade principal de um ambiente de preparação é testar se o aplicativo de implantação funcionam conforme o esperado. No momento em que uma versão chega ao estágio de preparo ambiente, seu teste funcional deve estar concluído. O preparo é o último antes de implantar o software na implantação de produção.
Para garantir que os resultados do teste sejam significativos e se apliquem à implementação de produção, é preciso que o conjunto de ambientes, usado durante o ciclo de vida de um aplicativo, atenda às seguintes regras, na medida do possível
- Todos os ambientes são funcionalmente equivalentes. Ou seja, a arquitetura, as APIs e as versões de sistemas operacionais e bibliotecas são equivalentes e os sistemas se comportam da mesma forma em todos os ambientes. Esta a equivalência evita situações em que os aplicativos funcionam em um só ambiente mas falham em outra ou quando os defeitos não são reproduzíveis.
- Ambientes que são usados para teste de desempenho e confiabilidade, preparação e produção são equivalentes de maneira não funcional. Ou seja, o desempenho, a escala, a configuração e a maneira como são operados e mantidos são iguais ou diferem apenas de maneiras insignificantes. Caso contrário, os testes de desempenho e preparo perderão o sentido.
Em geral, tudo bem se os ambientes usados para desenvolvimento e os testes funcionais diferem não funcionalmente dos outros ambientes.
Conforme ilustrado no diagrama a seguir, os ambientes de teste e desenvolvimento são criados no Google Cloud. Um banco de dados gerenciado, como o Cloud SQL, pode ser usado como uma opção para desenvolvimento e teste no Google Cloud. Desenvolvimento e testes podem usar o mesmo mecanismo de banco de dados e versão no ambiente local de rede, um que é funcionalmente equivalente ou uma nova versão lançada para o ambiente de produção após a etapa de teste. No entanto, como o na infraestrutura dos dois ambientes não são iguais, abordagem aos testes de carga de desempenho não é válida.
Os cenários a seguir podem se encaixar bem com o padrão de ambiente híbrido:
- Alcance a equivalência funcional em todos os ambientes usando
Kubernetes como uma camada de ambiente de execução comum, quando aplicável e viável.
A edição Google Kubernetes Engine (GKE) Enterprise pode ser uma tecnologia fundamental para esse
abordagem humilde.
- Garanta a portabilidade da carga de trabalho e abstraia as diferenças entre de computação em nuvem. Com um malha de serviço de confiança zero, é possível controlar e manter a separação de comunicações entre os diferentes ambientes.
- Execute ambientes de desenvolvimento e testes funcionais na nuvem pública. Esses ambientes podem ser funcionalmente equivalentes aos ambientes, mas podem diferir em aspectos não funcionais, como desempenho. Esse conceito é ilustrado no diagrama anterior.
- Execute ambientes para produção, teste e desempenho (teste de carregamento) e testes de confiabilidade no ambiente de computação particular e garanta as equivalências funcional e não funcional.
Considerações sobre o design
- Necessidades comerciais: cada estratégia de implantação e lançamento para aplicativos tem vantagens e desvantagens próprias. Para garantir que a abordagem selecionada se alinha com seus requisitos específicos, base suas seleções em uma avaliação completa das necessidades e restrições do seu negócio.
- Diferenças de ambiente: como parte desse padrão, o objetivo principal de usar esse ambiente de nuvem é para desenvolvimento e teste. O último é hospedar o aplicativo testado no ambiente privado de produção. Para evitar o desenvolvimento e o teste de um recurso que podem funcionar como esperado no ambiente de nuvem e falhar de produção (no local), a equipe técnica deve conhecer entender as arquiteturas e os recursos dos dois ambientes. Esta inclui dependências de outros aplicativos e do hardware infraestrutura, por exemplo, sistemas de segurança que realizam inspeção de tráfego.
- Governança: controlar o que a empresa pode desenvolver em nuvem e quais dados podem ser usados para testes, uma análise de e governança do processo. Esse processo também pode ajudar sua empresa a garantir ele não usa nenhum recurso de nuvem no desenvolvimento e nos testes ambientes que não existem no ambiente de produção local.
- Critérios de sucesso: precisam ser claros, predefinidos e mensuráveis. os critérios de sucesso do teste que se alinham com o software garantia de qualidade de qualidade para sua organização. Aplique esses padrões a qualquer aplicativo que você desenvolve e testa.
- Redundância: embora os ambientes de desenvolvimento e teste possam não com tanta confiabilidade quanto o ambiente de produção, eles ainda precisam redundantes e redundantes e na capacidade de testar diferentes cenários de falha. Seus requisitos do cenário de falha podem fazer com que o design inclua redundância como parte de seu ambiente de desenvolvimento e teste.
Vantagens
A execução de cargas de trabalho de desenvolvimento e de testes funcionais na nuvem pública tem muitas vantagens:
- É possível iniciar e interromper ambientes automaticamente conforme a necessidade.
Por exemplo, é possível provisionar um ambiente inteiro para cada solicitação de confirmação ou recepção, permitir que os testes sejam executados e, em seguida, desligá-lo novamente. Essa abordagem
também oferece as seguintes vantagens:
- É possível reduzir custos interrompendo instâncias de máquina virtual (VM) quando estão inativos ou provisionando ambientes apenas sob demanda.
- Você pode acelerar o desenvolvimento e os testes iniciando ambientes temporários para cada solicitação de envio. Isso também reduz a sobrecarga de manutenção reduz inconsistências no ambiente de build.
- A execução desses ambientes na nuvem pública ajuda a criar familiaridade e confiança na nuvem e nas ferramentas relacionadas, o que pode ajudar na migração de outras cargas de trabalho. Essa abordagem é particularmente útil se você decidir explorar Portabilidade de cargas de trabalho com contêineres e Kubernetes, por exemplo, usando GKE Enterprise entre ambientes.
Práticas recomendadas
Para implementar o padrão de arquitetura híbrida de ambiente, Considere as seguintes recomendações:
- Defina os requisitos de comunicação do aplicativo, incluindo o rede e segurança ideais para você. Em seguida, use o padrão de rede espelhada para ajudar você a projetar sua arquitetura de rede para evitar comunicações diretas entre sistemas de diferentes ambientes. Se comunicação é necessária entre ambientes, ela tem que ser em um ambiente semelhante.
A estratégia de implantação e teste do aplicativo escolhida deve estar alinhada com seus objetivos e requisitos de negócios. Isso pode envolver fazer implementar alterações sem inatividade ou implementar recursos gradualmente para um ambiente ou grupo de usuários específico antes do lançamento mais abrangente. Para mais informações, consulte Implantação de aplicativos e estratégias de testes.
Para tornar as cargas de trabalho portáteis e abstrair as diferenças entre ambientes, é possível usar contêineres com o Kubernetes. Para mais informações, consulte Arquitetura de referência do ambiente híbrido do GKE Enterprise.
Estabelecer uma cadeia de ferramentas comum que funcione em ambientes de computação para implantação, configuração e operação de cargas de trabalho. O uso do Kubernetes oferece essa consistência.
Garantir que os pipelines de CI/CD sejam consistentes em toda a computação ambientes e o mesmo conjunto de binários, pacotes ou os contêineres são implantados nesses ambientes.
Ao usar o Kubernetes, use um sistema de CI, como o Tekton, para implementar um canal de implantação que implante em clusters e funcione em vários ambientes. Para mais informações, consulte Soluções de DevOps no Google Cloud.
Para ajudar você com a liberação contínua de aplicativos seguros e confiáveis aplicativos, incorporam a segurança como parte integrante do de segurança (DevSecOps). Para mais informações, consulte Entregue e proteja seu aplicativo voltado para a Internet em menos de uma hora usando o kit de ferramentas Dev(Sec)Ops.
Use as mesmas ferramentas para geração de registros e monitoramento no Google Cloud e em ambientes de nuvem atuais. Considere usar o monitoramento de código aberto sistemas. Para mais informações, consulte Padrões de geração de registros e monitoramento híbrido e de várias nuvens.
Quando equipes diferentes gerenciam cargas de trabalho de teste e produção, ferramentas podem ser aceitáveis. No entanto, usar as mesmas ferramentas com diferentes permissões de leitura podem ajudar a reduzir o esforço e a complexidade do treinamento.
Quando você escolhe os serviços de banco de dados, armazenamento e mensagens para aplicativos testes, use produtos que tenham um equivalente gerenciado no Google Cloud. Confiar em serviços gerenciados ajuda a diminuir o esforço administrativo de manter ambientes de desenvolvimento e teste.
Para proteger informações sensíveis, recomendamos criptografar todas comunicações em trânsito. Se a criptografia for necessária no nível de conectividade há várias opções disponíveis, baseadas na estrutura híbrida e conectividade de rede. Essas opções incluem túneis VPN, VPN de alta disponibilidade pelo Cloud Interconnect e MACsec para Cloud Interconnect.
Na tabela a seguir, mostramos quais produtos do Google Cloud são compatíveis com produtos OSS comuns.
| Produto OSS | Compatível com o produto do Google Cloud |
|---|---|
| Apache HBase | Bigtable |
| Apache Beam | Dataflow |
| CDAP | Cloud Data Fusion |
| Apache Hadoop | Dataproc |
| MySQL, PostgreSQL | Cloud SQL |
| Cluster do Redis, Redis, Memcached | Memorystore |
| Sistema de arquivos de rede (NFS, na sigla em inglês) | Filestore |
| JMS, Kafka | Pub/Sub |
| Kubernetes | GKE Enterprise |