Padrões de arquitetura híbrida e de várias nuvens

Last reviewed 2024-11-27 UTC

Esta página oferece uma vista de página única de todas as páginas em Crie arquiteturas híbridas e de várias nuvens com Google Cloud. Pode imprimir esta página ou guardá-la em formato PDF através da função de impressão do navegador e escolhendo a opção Guardar como PDF. Esta página não apresenta um painel do índice (ToC) no lado direito.

Este documento é o segundo de três documentos num conjunto. Este artigo aborda padrões de arquitetura híbrida e de várias nuvens comuns. Também descreve os cenários para os quais estes padrões são mais adequados. Por último, fornece as práticas recomendadas que pode usar quando implementar essas arquiteturas no Google Cloud.

O conjunto de documentos para padrões de arquitetura híbrida e de várias nuvens é composto pelas seguintes partes:

• Crie arquiteturas híbridas e de várias nuvens: aborda o planeamento de uma estratégia para criar uma configuração híbrida e de várias nuvens com o Google Cloud.
• Padrões de arquitetura híbrida e de várias nuvens: aborda padrões de arquitetura comuns a adotar como parte de uma estratégia híbrida e de várias nuvens (este documento).
• Padrões de arquitetura de rede segura híbrida e de várias nuvens: aborda padrões de arquitetura de rede híbrida e de várias nuvens de uma perspetiva de rede.

Cada empresa tem um portefólio único de cargas de trabalho de aplicações que impõem requisitos e restrições à arquitetura de uma configuração híbrida ou multicloud. Embora tenha de conceber e adaptar a sua arquitetura para cumprir estas restrições e requisitos, pode basear-se em alguns padrões comuns para definir a arquitetura fundamental.

Um padrão de arquitetura é uma forma repetível de estruturar vários componentes funcionais de uma solução tecnológica, uma aplicação ou um serviço para criar uma solução reutilizável que satisfaça determinados requisitos ou exemplos de utilização. Uma solução de tecnologia baseada na nuvem é frequentemente composta por vários serviços na nuvem distintos e distribuídos. Estes serviços colaboram para oferecer a funcionalidade necessária. Neste contexto, cada serviço é considerado um componente funcional da solução tecnológica. Da mesma forma, uma aplicação pode consistir em vários níveis funcionais, módulos ou serviços, e cada um pode representar um componente funcional da arquitetura da aplicação. Esta arquitetura pode ser padronizada para abordar exemplos de utilização de empresa específicos e servir como um padrão fundamental e reutilizável.

Para definir geralmente um padrão de arquitetura para uma aplicação ou uma solução, identifique e defina o seguinte:

• Os componentes da solução ou da aplicação.
• As funções esperadas para cada componente, por exemplo, funções de front-end para fornecer uma interface gráfica do utilizador ou funções de back-end para fornecer acesso a dados.
• Como os componentes comunicam entre si e com sistemas externos ou utilizadores. Nas aplicações modernas, estes componentes interagem através de interfaces ou APIs bem definidas. Existem vários modelos de comunicação, como assíncronos e síncronos, pedido-resposta ou baseados em filas.

Seguem-se as duas categorias principais de padrões de arquitetura híbrida e multicloud:

• Padrões de arquitetura distribuída: Estes padrões baseiam-se numa implementação distribuída de cargas de trabalho ou componentes de aplicações. Isto significa que executam uma aplicação (ou componentes específicos dessa aplicação) no ambiente de computação que melhor se adequa ao padrão. Isto permite que o padrão tire partido das diferentes propriedades e caraterísticas dos ambientes de computação distribuídos e interligados.
• Padrões de arquitetura redundantes: estes padrões baseiam-se em implementações redundantes de cargas de trabalho. Nestes padrões, implementa as mesmas aplicações e os respetivos componentes em vários ambientes de computação. O objetivo é aumentar a capacidade de desempenho ou a resiliência de uma aplicação, ou replicar um ambiente existente para desenvolvimento e testes.

Quando implementa o padrão de arquitetura que seleciona, tem de usar um arquétipo de implementação adequado. Os arquétipos de implementação são zonais, regionais, multirregionais ou globais. Esta seleção forma a base para a criação de arquiteturas de implementação específicas da aplicação. Cada arquétipo de implementação define uma combinação de domínios de falhas nos quais uma aplicação pode operar. Estes domínios de falha podem abranger uma ou mais Google Cloud zonas ou regiões e podem ser expandidos para incluir os seus centros de dados no local ou domínios de falha noutros fornecedores de nuvem.

Esta série contém as seguintes páginas:

• Padrões de arquitetura distribuída

  • Padrão híbrido hierárquico

  • Padrão de várias nuvens particionadas

  • Padrão híbrido e multicloud do Analytics

  • Padrão híbrido de limite

• Padrões de arquitetura redundantes

  • Padrão híbrido do ambiente
  • Padrões híbridos e multicloud de continuidade empresarial
  • Padrão de aumento de capacidade da nuvem

Colaboradores

Autor: Marwan Al Shawi | Partner Customer Engineer

Outros colaboradores:

• Saud Albazei | Customer Engineer, Application Modernization
• Anna Berenberg | Engineering Fellow
• Marco Ferrari | Arquiteto de soluções na nuvem
• Victor Moreno | Gestor de produtos, redes na nuvem
• Johannes Passing | Arquiteto de soluções na nuvem
• Mark Schlagenhauf | Redator técnico, redes
• Daniel Strebel | EMEA Solution Lead, Application Modernization
• Ammett Williams | Developer Relations Engineer

Padrões de arquitetura distribuída

Quando migrar de um ambiente de computação não híbrido ou não multinuvem para uma arquitetura híbrida ou multinuvem, considere primeiro as restrições das suas aplicações existentes e como essas restrições podem levar a falhas nas aplicações. Esta consideração torna-se mais importante quando as suas aplicações ou componentes de aplicações funcionam de forma distribuída em diferentes ambientes. Depois de considerar as suas restrições, desenvolva um plano para as evitar ou superar. Certifique-se de que considera as capacidades únicas de cada ambiente de computação numa arquitetura distribuída.

Nota: pode aplicar diferentes padrões de arquitetura a diferentes aplicações, com base nos respetivos exemplos de utilização e requisitos. Isto significa que pode ter várias aplicações com diferentes padrões de arquitetura híbrida e multicloud a funcionar em simultâneo.

Considerações de design

As seguintes considerações de design aplicam-se a padrões de implementação distribuídos. Consoante a solução de segmentação e os objetivos da empresa, a prioridade e o efeito de cada consideração podem variar.

Latência

Em qualquer padrão de arquitetura que distribua componentes de aplicações (front-ends, back-ends ou microsserviços) em diferentes ambientes de computação, pode ocorrer latência de comunicação. Esta latência é influenciada pela conetividade de rede híbrida (Cloud VPN e Cloud Interconnect) e pela distância geográfica entre o site nas instalações e as regiões da nuvem, ou entre regiões da nuvem numa configuração de várias nuvens. Por conseguinte, é fundamental avaliar os requisitos de latência das suas aplicações e a respetiva sensibilidade a atrasos na rede. As aplicações que podem tolerar a latência são candidatos mais adequados para a implementação distribuída inicial num ambiente híbrido ou de várias nuvens.

Arquitetura de estado temporária versus final

Para especificar as expetativas e as potenciais implicações para o custo, a escala e o desempenho, é importante analisar o tipo de arquitetura de que precisa e a duração prevista como parte da fase de planeamento. Por exemplo, se planear usar uma arquitetura híbrida ou multicloud durante muito tempo ou permanentemente, é recomendável considerar usar o Cloud Interconnect. Para reduzir os custos de transferência de dados de saída e otimizar o desempenho da rede de conetividade híbrida, o Cloud Interconnect aplica descontos aos custos de transferência de dados de saída que cumprem as condições da taxa de transferência de dados com desconto.

Fiabilidade

A fiabilidade é uma consideração importante ao arquitetar sistemas de TI. A disponibilidade do tempo de atividade é um aspeto essencial da fiabilidade do sistema. No Google Cloud, pode aumentar a capacidade de recuperação de uma aplicação implementando componentes redundantes dessa aplicação em várias zonas numa única região¹ ou em várias regiões, com capacidades de comutação. A redundância é um dos elementos principais para melhorar a disponibilidade geral de uma aplicação. Para aplicações com uma configuração distribuída em ambientes híbridos e de várias nuvens, é importante manter um nível de disponibilidade consistente.

Para melhorar a disponibilidade de um sistema num ambiente no local ou noutros ambientes de nuvem, pondere que redundância de hardware ou software, com mecanismos de comutação por falha, precisa para as suas aplicações e respetivos componentes. Idealmente, deve considerar a disponibilidade de um serviço ou uma aplicação nos vários componentes e infraestrutura de apoio (incluindo a disponibilidade de conetividade híbrida) em todos os ambientes. Este conceito também é conhecido como a disponibilidade composta de uma aplicação ou um serviço.

Com base nas dependências entre os componentes ou os serviços, a disponibilidade composta de uma aplicação pode ser superior ou inferior à de um serviço ou um componente individual. Para mais informações, consulte o artigo Disponibilidade composta: calcular a disponibilidade geral da infraestrutura na nuvem.

Para alcançar o nível de fiabilidade do sistema que pretende, defina métricas de fiabilidade claras e crie aplicações para se autorrepararem e resistirem a interrupções de forma eficaz nos diferentes ambientes. Para ajudar a definir formas adequadas de medir a experiência do cliente dos seus serviços, consulte o artigo Defina a fiabilidade com base nos objetivos da experiência do utilizador.

Conetividade híbrida e de várias nuvens

Os requisitos da comunicação entre os componentes das aplicações distribuídas devem influenciar a sua seleção de uma opção de conetividade de rede híbrida. Cada opção de conetividade tem as suas vantagens e desvantagens, bem como fatores específicos a considerar, como o custo, o volume de tráfego, a segurança, etc. Para mais informações, consulte a secção Considerações de design de conetividade.

Capacidade de gestão

As ferramentas de gestão e monitorização consistentes e unificadas são essenciais para configurações híbridas e multinuvem bem-sucedidas (com ou sem portabilidade da carga de trabalho). A curto prazo, estas ferramentas podem adicionar custos de desenvolvimento, testes e operações. Tecnicamente, quanto mais fornecedores de nuvem usar, mais complexa se torna a gestão dos seus ambientes. A maioria dos fornecedores de nuvem pública não só tem funcionalidades diferentes, como também tem várias ferramentas, SLAs e APIs para gerir serviços na nuvem. Por conseguinte, pondere as vantagens estratégicas da arquitetura selecionada em função da potencial complexidade a curto prazo em comparação com as vantagens a longo prazo.

Custo

Cada fornecedor de serviços na nuvem num ambiente de várias nuvens tem as suas próprias métricas e ferramentas de faturação. Para oferecer uma melhor visibilidade e dashboards unificados, considere usar ferramentas de gestão e otimização de custos em várias nuvens. Por exemplo, quando cria soluções baseadas na nuvem em vários ambientes de nuvem, os produtos, os preços, os descontos e as ferramentas de gestão de cada fornecedor podem criar inconsistências de custos entre esses ambientes.

Recomendamos que tenha um método único e bem definido para calcular os custos totais dos recursos da nuvem e para oferecer visibilidade dos custos. A visibilidade de custos é essencial para a otimização de custos. Por exemplo, combinando os dados de faturação dos fornecedores de nuvem que usa e usando o Google Cloud bloco de gestão de custos na nuvem do Looker, pode criar uma vista centralizada dos seus custos em várias nuvens. Esta vista pode ajudar a fornecer uma vista de relatórios consolidada dos seus gastos em várias nuvens. Para mais informações, consulte A estratégia para otimizar eficazmente a gestão de custos do Cloud Billing.

Também recomendamos a utilização da prática do FinOps para tornar os custos visíveis. Como parte de uma prática de FinOps sólida, uma equipa central pode delegar a tomada de decisões para a otimização de recursos a quaisquer outras equipas envolvidas num projeto para incentivar a responsabilidade individual. Neste modelo, a equipa central deve padronizar o processo, os relatórios e as ferramentas para a otimização de custos. Para mais informações acerca dos diferentes aspetos de otimização de custos e das recomendações que deve considerar, consulte o artigo Google Cloud Estrutura bem arquitetada: otimização de custos.

Movimento de dados

A movimentação de dados é uma consideração importante para a estratégia híbrida e de várias nuvens, bem como para o planeamento da arquitetura, especialmente para sistemas distribuídos. As empresas têm de identificar os seus diferentes exemplos de utilização empresarial, os dados que os suportam e como os dados são classificados (para setores regulamentados). Também devem considerar como o armazenamento, a partilha e o acesso a dados para sistemas distribuídos em vários ambientes podem afetar o desempenho das aplicações e a consistência dos dados. Esses fatores podem influenciar a aplicação e a arquitetura do pipeline de dados. O conjunto abrangente de opções de movimentação de dados da Google Cloud permite que as empresas satisfaçam as suas necessidades específicas e adotem arquiteturas híbridas e multicloud sem comprometer a simplicidade, a eficiência nem o desempenho.Google Cloud

Segurança

Ao migrar aplicações para a nuvem, é importante considerar as capacidades de segurança prioritárias na nuvem, como a consistência, a observabilidade e a visibilidade de segurança unificada. Cada fornecedor de nuvem pública tem a sua própria abordagem, práticas recomendadas e capacidades de segurança. É importante analisar e alinhar estas capacidades para criar uma arquitetura de segurança funcional padrão. Os controlos de IAM fortes, a encriptação de dados, a análise de vulnerabilidades e a conformidade com os regulamentos da indústria também são aspetos importantes da segurança na nuvem.

Ao planear uma estratégia de migração, recomendamos que analise as considerações mencionadas anteriormente. Podem ajudar a minimizar as probabilidades de introduzir complexidades na arquitetura à medida que as suas aplicações ou volumes de tráfego aumentam. Além disso, a conceção e a criação de uma zona de destino são quase sempre um pré-requisito para implementar cargas de trabalho empresariais num ambiente de nuvem. Uma zona de destino ajuda a sua empresa a implementar, usar e dimensionar os serviços na nuvem de forma mais segura em várias áreas e inclui diferentes elementos, como identidades, gestão de recursos, segurança e rede. Para mais informações, consulte o artigo Estrutura da zona de destino no Google Cloud.

Os seguintes documentos desta série descrevem outros padrões de arquitetura distribuída:

• Padrão híbrido hierárquico
• Padrão de várias nuvens particionadas
• Padrão híbrido e multinuvem do Analytics
• Padrão híbrido de limite

Padrão híbrido hierárquico

Os componentes de arquitetura de uma aplicação podem ser categorizados como frontend ou backend. Em alguns cenários, estes componentes podem ser alojados para funcionar a partir de diferentes ambientes de computação. Como parte do padrão de arquitetura híbrida hierárquica, os ambientes de computação estão localizados num ambiente de computação privado no local e em Google Cloud.

Os componentes da aplicação de front-end são expostos diretamente aos utilizadores finais ou aos dispositivos. Como resultado, estas aplicações são frequentemente sensíveis ao desempenho. Para desenvolver novas funcionalidades e melhorias, as atualizações de software podem ser frequentes. Uma vez que as aplicações de frontend dependem normalmente de aplicações de backend para armazenar e gerir dados, e possivelmente lógica empresarial e tratamento de introdução do utilizador, são frequentemente sem estado ou gerem apenas volumes limitados de dados.

Para serem acessíveis e utilizáveis, pode criar as suas aplicações de front-end com várias estruturas e tecnologias. Alguns fatores importantes para uma aplicação de frontend bem-sucedida incluem o desempenho da aplicação, a velocidade de resposta e a compatibilidade com o navegador.

Normalmente, os componentes da aplicação de back-end focam-se no armazenamento e na gestão de dados. Em algumas arquiteturas, a lógica de negócio pode ser incorporada no componente de back-end. As novas versões das aplicações de back-end tendem a ser menos frequentes do que as versões das aplicações de front-end. As aplicações de back-end têm os seguintes desafios de gestão:

• Processar um grande volume de pedidos
• Processar um grande volume de dados
• Proteger os dados
• Manter dados atuais e atualizados em todas as réplicas do sistema

A solução de app Web de três camadas é uma das implementações mais populares para criar aplicações Web empresariais, como Websites de comércio eletrónico que contêm diferentes componentes de aplicações. Esta arquitetura contém os seguintes níveis. Cada nível funciona de forma independente, mas estão estreitamente ligados e funcionam todos em conjunto.

• Nível de apresentação e front-end da Web
• Nível de aplicação
• Acesso aos dados ou camada de back-end

Colocar estas camadas em contentores separa as respetivas necessidades técnicas, como os requisitos de escalabilidade, e ajuda a migrá-las de forma faseada. Além disso, permite-lhe implementá-los em serviços na nuvem independentes da plataforma que podem ser portáteis em vários ambientes, usar a gestão automatizada e dimensionar com plataformas geridas na nuvem, como o Cloud Run ou a edição Enterprise do Google Kubernetes Engine (GKE). Além disso, as bases de dados geridas, como o Cloud SQL, ajudam a fornecer o back-end como a camada de base de dados.Google Cloud

Nota: a implementação desta arquitetura e a definição dos respetivos componentes podem variar consoante se separar os níveis em sistemas e camadas individuais ou se os combinar.

O padrão de arquitetura híbrida em camadas foca-se na implementação de componentes de aplicações de front-end existentes na nuvem pública. Neste padrão, mantém todos os componentes da aplicação de back-end existentes no respetivo ambiente de computação privado. Consoante a escala e o design específico da aplicação, pode migrar os componentes da aplicação de front-end caso a caso. Para mais informações, consulte Migrar para Google Cloud.

Se tiver uma aplicação existente com componentes de back-end e front-end alojados no seu ambiente no local, considere os limites da sua arquitetura atual. Por exemplo, à medida que a sua aplicação é dimensionada e as exigências sobre o respetivo desempenho e fiabilidade aumentam, deve começar a avaliar se as partes da sua aplicação devem ser refatoradas ou movidas para uma arquitetura diferente e mais otimizada. O padrão de arquitetura híbrido hierárquico permite-lhe transferir algumas cargas de trabalho e componentes da aplicação para a nuvem antes de fazer uma transição completa. Também é essencial considerar o custo, o tempo e o risco envolvidos numa migração deste tipo.

O diagrama seguinte mostra um padrão de arquitetura híbrido hierárquico típico.

No diagrama anterior, os pedidos do cliente são enviados para o frontend da aplicação que está alojado em Google Cloud. Por sua vez, o front-end da aplicação envia dados de volta para o ambiente no local onde o back-end da aplicação está alojado (idealmente através de um gateway de API).

Com o padrão de arquitetura híbrido hierárquico, pode tirar partido da Google Cloud infraestrutura e dos serviços globais, conforme mostrado na arquitetura de exemplo no diagrama seguinte. O front-end da aplicação pode ser acedido através de Google Cloud. Também pode adicionar elasticidade ao front-end através do ajuste de escala automático para responder de forma dinâmica e eficiente à procura de ajuste de escala sem aprovisionar em excesso a infraestrutura. Existem diferentes arquiteturas que pode usar para criar e executar apps Web escaláveis no Google Cloud. Cada arquitetura tem vantagens e desvantagens para diferentes requisitos.

Para mais informações, veja o vídeo Três formas de executar apps Web escaláveis no Google Cloud YouTube. Para saber mais sobre as diferentes formas de modernizar a sua plataforma de comércio eletrónico no Google Cloud, consulte o artigo Como criar uma plataforma de comércio digital no Google Cloud.

No diagrama anterior, o front-end da aplicação está alojado no Google Cloud para oferecer uma experiência do utilizador multirregional e otimizada a nível global que usa o equilíbrio de carga, o dimensionamento automático e a proteção contra DDoS através do Google Cloud Armor.

Ao longo do tempo, o número de aplicações que implementa na nuvem pública pode aumentar até ao ponto em que pode considerar mover os componentes da aplicação de back-end para a nuvem pública. Se espera publicar um tráfego elevado, optar por serviços geridos na nuvem pode ajudar a poupar esforços de engenharia na gestão da sua própria infraestrutura. Considere esta opção, a menos que as restrições ou os requisitos exijam a alojamento de componentes da aplicação de back-end no local. Por exemplo, se os dados de back-end estiverem sujeitos a restrições regulamentares, é provável que tenha de manter esses dados no local. No entanto, quando aplicável e em conformidade, a utilização de capacidades de proteção de dados confidenciais, como técnicas de desidentificação, pode ajudar a mover esses dados quando necessário.

No padrão de arquitetura híbrida hierárquica, também pode usar o Google Distributed Cloud em alguns cenários. A nuvem distribuída permite-lhe executar clusters do Google Kubernetes Engine em hardware dedicado fornecido e mantido pela Google e separado do Google Cloud centro de dados. Para garantir que o Distributed Cloud cumpre os seus requisitos atuais e futuros, conheça as limitações do Distributed Cloud em comparação com uma zona do GKE convencional baseada na nuvem.

Vantagens

Focar-se primeiro nas aplicações de front-end tem várias vantagens, incluindo as seguintes:

• Os componentes de front-end dependem dos recursos de back-end e, ocasionalmente, de outros componentes de front-end.
• Os componentes de back-end não dependem dos componentes de front-end. Por conseguinte, o isolamento e a migração de aplicações de front-end tendem a ser menos complexos do que a migração de aplicações de back-end.
• Como as aplicações de front-end são frequentemente sem estado ou não gerem dados por si próprias, tendem a ser menos difíceis de migrar do que os back-ends.
  • Os componentes de front-end podem ser otimizados como parte da migração para usar a arquitetura sem estado. Para mais informações, veja o vídeo Como portar apps Web com estado para o Cloud Run no YouTube.

A implementação de aplicações de front-end existentes ou recentemente desenvolvidas na nuvem pública oferece várias vantagens:

• Muitas aplicações de front-end estão sujeitas a alterações frequentes. A execução destas aplicações na nuvem pública simplifica a configuração de um processo de integração contínua/implementação contínua (CI/CD). Pode usar a CI/CD para enviar atualizações de forma eficiente e automática. Para mais informações, consulte CI/CD no Google Cloud.
• Os front-ends sensíveis ao desempenho com carga de tráfego variável podem beneficiar substancialmente do equilíbrio de carga, das implementações multirregionais, da colocação em cache do Cloud CDN, das capacidades sem servidor e de escalamento automático que uma implementação baseada na nuvem permite (idealmente com uma arquitetura sem estado).

• A adoção de microsserviços com contentores através de uma plataforma gerida na nuvem, como o GKE, permite-lhe usar arquiteturas modernas, como o microfrontend, que estendem os microsserviços aos componentes de front-end.

  A extensão de microsserviços é usada frequentemente com interfaces que envolvem várias equipas a colaborar na mesma aplicação. Este tipo de estrutura de equipa requer uma abordagem iterativa e manutenção contínua. Seguem-se algumas das vantagens de usar microfrontends:

  • Pode ser transformado em módulos de microserviços independentes para desenvolvimento, testes e implementação.
  • Oferece separação, onde as equipas de desenvolvimento individuais podem selecionar as suas tecnologias e código preferidos.
  • Pode fomentar ciclos rápidos de desenvolvimento e implementação sem afetar os restantes componentes de front-end que podem ser geridos por outras equipas.

• Quer estejam a implementar interfaces do utilizador ou APIs, ou a processar a introdução de dados da Internet das Coisas (IoT), as aplicações de front-end podem beneficiar das capacidades dos serviços na nuvem, como o Firebase, o Pub/Sub, o Apigee, o Cloud CDN, o App Engine ou o Cloud Run.

• Os proxies de API geridos na nuvem ajudam a:

  • Desacople a API virada para a app dos seus serviços de back-end, como os microsserviços.
  • Proteja as apps contra alterações ao código de back-end.
  • Suporte as suas arquiteturas de front-end existentes baseadas em APIs, como back-end para front-end (BFF), micro front-end e outras.
  • Exponha as suas APIs no Google Cloud ou noutros ambientes através da implementação de proxies de API no Apigee.

Também pode aplicar o padrão híbrido em camadas de forma inversa, implementando back-ends na nuvem e mantendo os front-ends em ambientes de computação privados. Embora seja menos comum, esta abordagem é melhor aplicada quando está a lidar com um frontend pesado e monolítico. Nestes casos, pode ser mais fácil extrair a funcionalidade de back-end de forma iterativa e implementar estes novos back-ends na nuvem.

A terceira parte desta série aborda possíveis padrões de rede para ativar essa arquitetura. O Apigee Hybrid ajuda como plataforma para criar e gerir proxies de API num modelo de implementação híbrido. Para mais informações, consulte o artigo Arquitetura com acoplamento fraco, incluindo arquiteturas hierárquicas monolíticas e de microsserviços.

Práticas recomendadas

Use as informações nesta secção ao planear a sua arquitetura híbrida hierárquica.

Práticas recomendadas para reduzir a complexidade

Quando aplica o padrão de arquitetura híbrido hierárquico, considere as seguintes práticas recomendadas que podem ajudar a reduzir a complexidade geral de implementação e operacional:

• Com base na avaliação dos modelos de comunicação das aplicações identificadas, selecione a solução de comunicação mais eficiente e eficaz para essas aplicações.

Uma vez que a maioria das interações dos utilizadores envolve sistemas que se ligam em vários ambientes de computação, a conetividade rápida e de baixa latência entre esses sistemas é importante. Para cumprir as expetativas de disponibilidade e desempenho, deve criar em função da alta disponibilidade, da baixa latência e dos níveis de débito adequados. Do ponto de vista da segurança, a comunicação tem de ser detalhada e controlada. Idealmente, deve expor os componentes da aplicação através de APIs seguras. Para mais informações, consulte o artigo Saída controlada.

• Para minimizar a latência de comunicação entre ambientes, selecione uma Google Cloud região geograficamente próxima do ambiente de computação privado onde os componentes de back-end da sua aplicação estão alojados. Para mais informações, consulte o artigo Práticas recomendadas para a seleção de regiões do Compute Engine.
• Minimize as dependências elevadas entre sistemas que estão a ser executados em ambientes diferentes, especialmente quando a comunicação é processada de forma síncrona. Estas dependências podem abrandar o desempenho, diminuir a disponibilidade geral e, potencialmente, incorrer em custos adicionais de transferência de dados de saída.
• Com o padrão de arquitetura híbrido em camadas, pode ter volumes maiores de tráfego de entrada de ambientes no local que entram noGoogle Cloud em comparação com o tráfego de saída que sai Google Cloud. No entanto, deve conhecer o volume de transferência de dados de saída previsto que Google Cloudsai. Se planeia usar esta arquitetura a longo prazo com volumes elevados de transferência de dados de saída, considere usar o Cloud Interconnect. O Cloud Interconnect pode ajudar a otimizar o desempenho da conetividade e pode reduzir os custos de transferência de dados de saída para o tráfego que cumpre determinadas condições. Para mais informações, consulte os preços do Cloud Interconnect.
• Para proteger informações confidenciais, recomendamos que encriptem todas as comunicações em trânsito. Se a encriptação for necessária na camada de conetividade, pode usar túneis de VPN, VPN de alta disponibilidade através do Cloud Interconnect e MACsec para o Cloud Interconnect.

• Para superar as inconsistências nos protocolos, nas APIs e nos mecanismos de autenticação em vários back-ends, recomendamos, quando aplicável, que implemente um gateway de API ou um proxy como uma fachada unificadora. Este gateway ou proxy funciona como um ponto de controlo centralizado e toma as seguintes medidas:

  • Implementa medidas de segurança adicionais.
  • Protege as apps de cliente e outros serviços contra alterações ao código de back-end.
  • Facilita as pistas de auditoria para a comunicação entre todas as aplicações em vários ambientes e os respetivos componentes separados.
  • Atua como uma camada de comunicação intermédia entre os serviços antigos e modernizados.
    • O Apigee e o Apigee Hybrid permitem-lhe alojar e gerir gateways híbridos e de nível empresarial em ambientes nas instalações, na periferia, noutras nuvens e emGoogle Cloud ambientes.

• Para facilitar o estabelecimento de configurações híbridas, use o Cloud Load Balancing com conetividade híbrida. Isto significa que pode estender as vantagens do Cloud Load Balancing aos serviços alojados no seu ambiente de computação no local. Esta abordagem permite migrações de cargas de trabalho faseadas para o Google Cloud com uma interrupção mínima ou nula do serviço, o que garante uma transição suave para os serviços distribuídos. Para mais informações, consulte o artigo Vista geral dos grupos de pontos finais de rede de conetividade híbrida.

• Por vezes, a utilização de um gateway de API ou um proxy e um Application Load Balancer em conjunto pode oferecer uma solução mais robusta para gerir, proteger e distribuir o tráfego da API em grande escala. A utilização do Cloud Load Balancing com gateways de API permite-lhe realizar o seguinte:

  • Forneça APIs de elevado desempenho com o Apigee e a RFC do Google Cloud, para reduzir a latência, alojar APIs globalmente e aumentar a disponibilidade para temporadas de pico de tráfego. Para mais informações, veja o vídeo Fornecer APIs de alto desempenho com o Apigee e o Cloud CDN no YouTube.
  • Implemente a gestão avançada de tráfego.
  • Use o Cloud Armor como um serviço de proteção contra DDoS e de segurança de rede para proteger as suas APIs.
  • Faça a gestão do balanceamento de carga eficiente em gateways em várias regiões. Para mais informações, veja o vídeo Proteger APIs e implementar a comutação por falha multirregião com o Private Service Connect e o Apigee no YouTube.

• Use a gestão de APIs e a malha de serviços para proteger e controlar a comunicação e a exposição de serviços com a arquitetura de microsserviços.

  • Use a Cloud Service Mesh para permitir a comunicação entre serviços que mantém a qualidade do serviço num sistema composto por serviços distribuídos onde pode gerir a autenticação, a autorização e a encriptação entre serviços.
  • Use uma plataforma de gestão de APIs, como a Apigee, que permite à sua organização e a entidades externas consumir esses serviços expondo-os como APIs.

• Estabelecer uma identidade comum entre ambientes para que os sistemas possam autenticar em segurança nos limites dos ambientes.

• Implemente sistemas de CI/CD e de gestão de configuração na nuvem pública. Para mais informações, consulte o artigo Padrão de arquitetura de rede espelhada.

• Para ajudar a aumentar a eficiência operacional, use ferramentas consistentes e pipelines de CI/CD em todos os ambientes.

Práticas recomendadas para a carga de trabalho individual e as arquiteturas de aplicações

• Embora o foco esteja nas aplicações de front-end neste padrão, tenha em atenção a necessidade de modernizar as suas aplicações de back-end. Se o ritmo de desenvolvimento das aplicações de back-end for substancialmente mais lento do que o das aplicações de front-end, a diferença pode causar complexidade adicional.
• Tratar as APIs como interfaces de back-end simplifica as integrações, o desenvolvimento de front-end, as interações de serviços e oculta as complexidades do sistema de back-end. Para resolver estes desafios, o Apigee facilita o desenvolvimento e a gestão de gateways/proxies de API para implementações híbridas e em várias nuvens.
• Escolha a abordagem de renderização para a sua aplicação Web de front-end com base no conteúdo (estático versus dinâmico), no desempenho da otimização do motor de pesquisa e nas expetativas sobre as velocidades de carregamento das páginas.
• Quando seleciona uma arquitetura para aplicações Web orientadas por conteúdo, estão disponíveis várias opções, incluindo arquiteturas monolíticas, sem servidor, baseadas em eventos e de microsserviços. Para selecionar a arquitetura mais adequada, avalie cuidadosamente estas opções em função dos requisitos atuais e futuros da aplicação. Para ajudar a tomar uma decisão arquitetónica que esteja alinhada com os seus objetivos empresariais e técnicos, consulte Comparação de diferentes arquiteturas para backends de aplicações Web orientadas por conteúdo e Principais considerações para backends Web.

• Com uma arquitetura de microsserviços, pode usar aplicações em contentores com o Kubernetes como a camada de tempo de execução comum. Com o padrão de arquitetura híbrida em camadas, pode executá-lo num dos seguintes cenários:

  • Em ambos os ambientes (Google Cloud e os seus ambientes no local).

    • Quando usa contentores e o Kubernetes em vários ambientes, tem a flexibilidade de modernizar as cargas de trabalho e, em seguida, migrar para o Google Cloud em alturas diferentes. Isto ajuda quando uma carga de trabalho depende muito de outra e não pode ser migrada individualmente, ou a usar a portabilidade de cargas de trabalho híbridas para usar os melhores recursos disponíveis em cada ambiente. Em todos os casos, o GKE Enterprise pode ser uma tecnologia de ativação fundamental. Para mais informações, consulte o artigo Ambiente híbrido do GKE Enterprise.

  • Num Google Cloud ambiente para os componentes da aplicação migrados e modernizados.

    • Use esta abordagem quando tiver backends antigos no local que não tenham suporte de contentorização ou exijam um tempo e recursos significativos para modernizar a curto prazo.

    Para mais informações sobre a conceção e a refatoração de uma app monolítica para uma arquitetura de microsserviços de forma a modernizar a arquitetura da sua aplicação Web, consulte o artigo Introdução aos microsserviços.

• Pode combinar tecnologias de armazenamento de dados consoante as necessidades das suas aplicações Web. A utilização do Cloud SQL para dados estruturados e do Cloud Storage para ficheiros multimédia é uma abordagem comum para satisfazer diversas necessidades de armazenamento de dados. No entanto, a escolha depende muito do seu exemplo de utilização. Para mais informações sobre as opções de armazenamento de dados para backends de aplicações baseadas em conteúdo e modalidades eficazes, consulte o artigo Opções de armazenamento de dados para apps Web baseadas em conteúdo. Consulte também o artigo As suas Google Cloud opções de base de dados, explicadas.

Padrão de várias nuvens particionadas

O padrão de arquitetura de nuvem múltipla particionada combina vários ambientes de nuvem pública que são operados por diferentes fornecedores de serviços na nuvem. Esta arquitetura oferece a flexibilidade para implementar uma aplicação num ambiente de computação ideal que tem em conta os fatores e as considerações de várias nuvens abordados na primeira parte desta série.

O diagrama seguinte mostra um padrão de arquitetura multicloud particionada.

Este padrão de arquitetura pode ser criado de duas formas diferentes. A primeira abordagem baseia-se na implementação dos componentes da aplicação em diferentes ambientes de nuvem pública. Esta abordagem também é denominada arquitetura composta e é a mesma abordagem que o padrão de arquitetura híbrida em camadas. No entanto, em vez de usar um ambiente no local com uma nuvem pública, usa, pelo menos, dois ambientes de nuvem. Numa arquitetura composta, uma única carga de trabalho ou aplicação usa componentes de mais do que uma nuvem. A segunda abordagem implementa diferentes aplicações em diferentes ambientes de nuvem pública. A seguinte lista não exaustiva descreve alguns dos fatores empresariais da segunda abordagem:

• Para integrar totalmente aplicações alojadas em ambientes de nuvem distintos durante um cenário de fusão e aquisição entre duas empresas.
• Para promover a flexibilidade e dar resposta a diversas preferências de nuvem na sua organização. Adote esta abordagem para incentivar as unidades organizacionais a escolherem o fornecedor de nuvem que melhor se adequa às suas necessidades e preferências específicas.
• Para operar numa implementação de nuvem global ou de várias regiões. Se uma empresa tiver de cumprir os regulamentos de residência dos dados em regiões ou países específicos, tem de escolher entre os fornecedores de nuvem disponíveis nessa localização se o respetivo fornecedor de nuvem principal não tiver uma região de nuvem aí.

Com o padrão de arquitetura multicloud particionada, pode, opcionalmente, manter a capacidade de transferir cargas de trabalho conforme necessário de um ambiente de nuvem pública para outro. Nesse caso, a portabilidade das suas cargas de trabalho torna-se um requisito fundamental. Quando implementa cargas de trabalho em vários ambientes de computação e quer manter a capacidade de mover cargas de trabalho entre ambientes, tem de abstrair as diferenças entre os ambientes. Ao usar o GKE Enterprise, pode conceber e criar uma solução para resolver a complexidade de várias nuvens com posturas de segurança, operações e governação consistentes. Para mais informações, consulte o artigo GKE Multi-Cloud.

Conforme mencionado anteriormente, existem algumas situações em que podem existir motivos empresariais e técnicos para combinar Google Cloud com outro fornecedor de nuvem e para particionar cargas de trabalho nesses ambientes de nuvem. As soluções multicloud oferecem-lhe a flexibilidade de migrar, criar e otimizar a portabilidade de aplicações em ambientes multicloud, ao mesmo tempo que minimizam a dependência e ajudam a cumprir os seus requisitos regulamentares. Por exemplo, pode estabelecer ligação Google Cloud à Oracle Cloud Infrastructure (OCI) para criar uma solução multicloud que tire partido das capacidades de cada plataforma através de uma interligação na nuvem privada para combinar componentes em execução na OCI com recursos em execução no Google Cloud. Para mais informações, consulte Google Cloud e Oracle Cloud Infrastructure: tirar o máximo partido da multinuvem. Além disso, a interligação entre nuvens facilita a conetividade dedicada de elevada largura de banda entre o Google Cloud e outros fornecedores de serviços na nuvem suportados, o que lhe permite criar soluções de várias nuvens para processar um elevado volume de tráfego entre nuvens.

Vantagens

Embora a utilização de uma arquitetura de várias nuvens ofereça várias vantagens empresariais e técnicas, conforme abordado em Motivações, considerações, estratégia e abordagens, é essencial realizar uma avaliação de viabilidade detalhada de cada potencial vantagem. A sua avaliação deve considerar cuidadosamente quaisquer desafios diretos ou indiretos associados, bem como a sua capacidade de os superar de forma eficaz. Além disso, considere que o crescimento a longo prazo das suas aplicações ou serviços pode introduzir complexidades que podem superar as vantagens iniciais.

Seguem-se algumas das principais vantagens do padrão de arquitetura multicloud particionada:

• Em cenários em que possa ter de minimizar o compromisso com um único fornecedor de nuvem, pode distribuir aplicações por vários fornecedores de nuvem. Como resultado, pode reduzir relativamente a dependência de um fornecedor com a capacidade de alterar planos (até certo ponto) nos seus fornecedores de nuvem. A nuvem aberta ajuda a disponibilizar Google Cloud capacidades, como o GKE Enterprise, em diferentes localizações físicas. Ao expandir Google Cloud as capacidades no local, em várias nuvens públicas e na periferia, oferece flexibilidade, agilidade e impulsiona a transformação.

• Por motivos regulamentares, pode publicar um determinado segmento da sua base de utilizadores e dados de um país onde o Google Cloud não tem uma região da nuvem .

• O padrão de arquitetura de multicloud particionada pode ajudar a reduzir a latência e melhorar a qualidade geral da experiência do utilizador em localizações onde o fornecedor de nuvem principal não tem uma região de nuvem ou um ponto de presença. Este padrão é especialmente útil quando usa a conetividade multicloud de alta capacidade e baixa latência, como o Cross-Cloud Interconnect e o CDN Interconnect com uma RFC distribuída.

• Pode implementar aplicações em vários fornecedores de nuvem de uma forma que lhe permita escolher entre os melhores serviços que os outros fornecedores de nuvem oferecem.

• O padrão de arquitetura multicloud particionado pode ajudar a facilitar e acelerar cenários de fusão e aquisição, em que as aplicações e os serviços das duas empresas podem estar alojados em diferentes ambientes de nuvem pública.

Práticas recomendadas

• Comece por implementar uma carga de trabalho não essencial. Esta implementação inicial na nuvem secundária pode servir como um padrão para implementações ou migrações futuras. No entanto, esta abordagem provavelmente não é aplicável em situações em que a carga de trabalho específica é legal ou regulamentarmente obrigatória para residir numa região da nuvem específica, e o fornecedor principal de nuvem não tem uma região no território necessário.
• Minimize as dependências entre sistemas que estão a ser executados em diferentes ambientes de nuvem pública, especialmente quando a comunicação é processada de forma síncrona. Estas dependências podem abrandar o desempenho, diminuir a disponibilidade geral e potencialmente incorrer em custos adicionais de transferência de dados de saída.
• Para abstrair as diferenças entre ambientes, considere usar contentores e o Kubernetes onde for suportado pelas aplicações e viável.
• Certifique-se de que os pipelines de CI/CD e as ferramentas de implementação e monitorização são consistentes em todos os ambientes de nuvem.
• Selecione o padrão de arquitetura de rede ideal que oferece a solução de comunicação mais eficiente e eficaz para as aplicações que está a usar.
  • A comunicação tem de ser detalhada e controlada. Use APIs seguras para expor componentes da aplicação.
  • Considere usar o padrão de arquitetura interligado ou um dos padrões de rede com restrições, com base nos seus requisitos técnicos e empresariais específicos.
• Para cumprir as suas expetativas de disponibilidade e desempenho, crie um design para uma alta disponibilidade (AD) ponto a ponto, uma baixa latência e níveis de débito adequados.

• Para proteger informações confidenciais, recomendamos que encriptem todas as comunicações em trânsito.

  • Se a encriptação for necessária na camada de conetividade, estão disponíveis várias opções, com base na solução de conetividade híbrida selecionada. Estas opções incluem túneis de VPN, VPN de alta disponibilidade através do Cloud Interconnect e MACsec para o Cross-Cloud Interconnect.

• Se estiver a usar várias RFCs como parte do seu padrão de arquitetura particionada em várias nuvens e estiver a preencher a sua outra RFC com ficheiros de dados grandes do Google Cloud, considere usar links do CDN Interconnect entre o Google Cloud e os fornecedores suportados para otimizar este tráfego e, potencialmente, o seu custo.

• Expanda a sua solução de gestão de identidades entre ambientes para que os sistemas possam autenticar-se de forma segura em todos os limites dos ambientes.

• Para equilibrar eficazmente os pedidos entre a Google Cloud plataforma Google Cloud e outra plataforma na nuvem, pode usar o Cloud Load Balancing. Para mais informações, consulte Encaminhar tráfego para uma localização no local ou outra nuvem.

  • Se o volume de transferência de dados de saída de Google Cloud para outros ambientes for elevado, considere usar a Interligação entre clouds.

• Para superar as inconsistências nos protocolos, nas APIs e nos mecanismos de autenticação em vários back-ends, recomendamos, quando aplicável, que implemente um gateway de API ou um proxy como uma fachada unificadora. Este gateway ou proxy funciona como um ponto de controlo centralizado e toma as seguintes medidas:

  • Implementa medidas de segurança adicionais.
  • Protege as apps de cliente e outros serviços contra alterações ao código de back-end.
  • Facilita as pistas de auditoria para a comunicação entre todas as aplicações em vários ambientes e os respetivos componentes separados.
  • Atua como uma camada de comunicação intermédia entre os serviços antigos e modernizados.
    • O Apigee e o Apigee Hybrid permitem-lhe alojar e gerir gateways híbridos e de nível empresarial em ambientes nas instalações, na periferia, noutras nuvens e emGoogle Cloud ambientes.

• Em alguns dos seguintes casos, a utilização do Equilíbrio de carga na nuvem com um gateway de API pode oferecer uma solução robusta e segura para gerir, proteger e distribuir o tráfego de API em grande escala em várias regiões:

  • Implementar a comutação por falha multirregional para runtimes de API do Apigee em diferentes regiões.

  • Aumentar o desempenho com o Cloud CDN.

  • Fornecer proteção WAF e DDoS através do Google Cloud Armor.

• Use ferramentas consistentes para registo e monitorização em ambientes de nuvem sempre que possível. Pode considerar usar sistemas de monitorização de código aberto. Para mais informações, consulte o artigo Padrões de registo e monitorização híbridos e multicloud.

• Se estiver a implementar componentes de aplicações de forma distribuída, em que os componentes de uma única aplicação são implementados em mais do que um ambiente de nuvem, consulte as práticas recomendadas para o padrão de arquitetura híbrido hierárquico.

Padrão híbrido e de várias nuvens do Analytics

Este documento aborda o facto de o objetivo do padrão híbrido e de várias nuvens de estatísticas ser tirar partido da divisão entre cargas de trabalho transacionais e de estatísticas.

Nos sistemas empresariais, a maioria das cargas de trabalho enquadra-se nestas categorias:

• As cargas de trabalho transacionais incluem aplicações interativas, como vendas, processamento financeiro, planeamento de recursos empresariais ou comunicação.
• As cargas de trabalho de Analytics incluem aplicações que transformam, analisam, refinam ou visualizam dados para ajudar nos processos de tomada de decisões.

Os sistemas de estatísticas obtêm os respetivos dados de sistemas transacionais através de consultas a APIs ou do acesso a bases de dados. Na maioria das empresas, os sistemas de estatísticas e transacionais tendem a ser separados e pouco interligados. O objetivo do padrão de análise híbrida e multicloud é tirar partido desta divisão preexistente executando cargas de trabalho transacionais e de análise em dois ambientes de computação diferentes. Primeiro, os dados não processados são extraídos de cargas de trabalho que estão a ser executadas no ambiente de computação privada e, em seguida, carregados para o Google Cloud, onde são usados para o processamento analítico. Alguns dos resultados podem ser enviados de volta para os sistemas transacionais.

O diagrama seguinte ilustra arquiteturas conceptualmente possíveis, mostrando potenciais pipelines de dados. Cada caminho/seta representa uma possível opção de pipeline de movimentação e transformação de dados que pode basear-se em ETL ou ELT, dependendo da qualidade dos dados e do exemplo de utilização segmentado disponíveis.

Para mover os seus dados para o Google Cloud e desbloquear valor a partir deles, use os serviços de movimento de dados, um conjunto completo de serviços de carregamento, integração e replicação de dados.

Conforme mostrado no diagrama anterior, a ligação Google Cloud com ambientes no local e outros ambientes na nuvem pode permitir vários exemplos de utilização de estatísticas de dados, como a transmissão em fluxo contínuo de dados e as cópias de segurança de bases de dados. Para potenciar o transporte fundamental de um padrão de estatísticas híbrido e multinuvem que requer um volume elevado de transferência de dados, a Cloud Interconnect e a Cross-Cloud Interconnect oferecem conectividade dedicada a fornecedores de nuvem nas instalações e outros.

Vantagens

A execução de cargas de trabalho de estatísticas na nuvem tem várias vantagens importantes:

• O tráfego de entrada, ou seja, a movimentação de dados do seu ambiente de computação privado ou de outras nuvens para oGoogle Cloud, pode ser gratuito.
• Os fluxos de trabalho de análise precisam frequentemente de processar quantidades substanciais de dados e podem ser irregulares, pelo que são especialmente adequados para implementação num ambiente de nuvem pública. Ao dimensionar dinamicamente os recursos de computação, pode processar rapidamente grandes conjuntos de dados, evitando investimentos iniciais ou ter de aprovisionar em excesso equipamento de computação.
• Google Cloud oferece um conjunto abrangente de serviços para gerir dados ao longo do respetivo ciclo de vida completo, desde a aquisição inicial ao processamento e análise, até à visualização final.
  • Os serviços de movimentação de dados no Google Cloud oferecem um conjunto completo de produtos para mover, integrar e transformar dados de forma integrada de diferentes formas.
  • O Cloud Storage é adequado para criar um lago de dados.

• Google Cloud ajuda a modernizar e otimizar a sua plataforma de dados para eliminar os silos de dados. A utilização de um data lakehouse ajuda a padronizar diferentes formatos de armazenamento. Também pode oferecer a flexibilidade, a escalabilidade e a agilidade necessárias para ajudar a garantir que os seus dados geram valor para a sua empresa, em vez de ineficiências. Para mais informações, consulte o artigo sobre o BigLake.

• O BigQuery Omni oferece capacidade de computação que é executada localmente no armazenamento no AWS ou Azure. Também ajuda a consultar os seus próprios dados armazenados no Amazon Simple Storage Service (Amazon S3) ou no Azure Blob Storage. Esta capacidade de análise em várias nuvens permite que as equipas de dados analisem os silos de dados. Para mais informações sobre a consulta de dados armazenados fora do BigQuery, consulte o artigo Introdução a origens de dados externas.

Práticas recomendadas

Para implementar o padrão de arquitetura híbrido e multicloud do Analytics, considere as seguintes práticas recomendadas gerais:

• Use o padrão de rede de transferência para permitir o carregamento de dados. Se os resultados analíticos tiverem de ser enviados de volta para os sistemas transacionais, pode combinar o padrão de transferência e o padrão de saída controlada.
• Use filas do Pub/Sub ou contentores do Cloud Storage para transferir dados Google Cloud de sistemas transacionais que estão a ser executados no seu ambiente de computação privado. Estas filas ou contentores podem, então, servir como origens para pipelines e cargas de trabalho de tratamento de dados.
• Para implementar pipelines de dados ETL e ELT, considere usar o Cloud Data Fusion ou o Dataflow consoante os requisitos específicos do seu exemplo de utilização. Ambos são serviços de processamento de dados na nuvem totalmente geridos para criar e gerir pipelines de dados.
• Para descobrir, classificar e proteger os seus valiosos recursos de dados, considere usar as capacidades de proteção de dados confidenciais, como técnicas de desidentificação. Google Cloud Estas técnicas permitem-lhe ocultar, encriptar e substituir dados sensíveis, como informações de identificação pessoal (IIP), através de uma chave gerada aleatoriamente ou predeterminada, quando aplicável e em conformidade.

• Quando estiver a fazer uma transferência de dados inicial do seu ambiente de computação privado para o Google Cloud, escolha a abordagem de transferência mais adequada para o tamanho do seu conjunto de dados e largura de banda disponível. Para mais informações, consulte Migração para Google Cloud: transferir os seus grandes conjuntos de dados.

• Se a transferência ou a troca de dados entre Google Cloud e outras nuvens for necessária a longo prazo com um volume de tráfego elevado, deve avaliar a utilização da Google Cloud Interligação entre nuvens para ajudar a estabelecer uma conetividade dedicada de elevada largura de banda entre Google Cloud e outros fornecedores de serviços na nuvem (disponível em determinadas localizações).

• Se a encriptação for necessária na camada de conetividade, estão disponíveis várias opções com base na solução de conetividade híbrida selecionada. Estas opções incluem túneis de VPN, HA VPN através do Cloud Interconnect e MACsec para o Cross-Cloud Interconnect.

• Use ferramentas e processos consistentes em todos os ambientes. Num cenário híbrido de estatísticas, esta prática pode ajudar a aumentar a eficiência operacional, embora não seja um pré-requisito.

Padrão híbrido de arestas

A execução de cargas de trabalho na nuvem requer que, em alguns cenários, os clientes tenham uma ligação à Internet rápida e fiável. Dadas as redes atuais, este requisito raramente representa um desafio para a adoção da nuvem. No entanto, existem cenários em que não pode confiar na conetividade contínua, como:

• Os navios e outros veículos podem ter uma ligação intermitente ou acesso apenas a ligações por satélite com latência elevada.
• As fábricas ou as centrais elétricas podem estar ligadas à Internet. Estas instalações podem ter requisitos de fiabilidade que excedem as reivindicações de disponibilidade do respetivo fornecedor de Internet.
• As lojas de retalho e os supermercados podem estar ligados apenas ocasionalmente ou usar links que não oferecem a fiabilidade ou o débito necessários para processar transações críticas para a empresa.

O padrão de arquitetura híbrido de limite resolve estes desafios executando cargas de trabalho críticas para o tempo e a empresa localmente, no limite da rede, enquanto usa a nuvem para todos os outros tipos de cargas de trabalho. Numa arquitetura híbrida de limite, a ligação à Internet é um componente não crítico que é usado para fins de gestão e para sincronizar ou carregar dados, muitas vezes de forma assíncrona, mas não está envolvido em transações críticas para o tempo ou a empresa.

Vantagens

A execução de determinadas cargas de trabalho no limite e outras cargas de trabalho na nuvem oferece várias vantagens:

• O tráfego de entrada, ou seja, a movimentação de dados da periferia para Google Cloud, pode ser gratuito.
• A execução de cargas de trabalho críticas para a empresa e para o tempo no limite ajuda a garantir uma baixa latência e a autossuficiência. Se a ligação à Internet falhar ou estiver temporariamente indisponível, pode continuar a executar todas as transações importantes. Ao mesmo tempo, pode beneficiar da utilização da nuvem para uma parte significativa da sua carga de trabalho geral.
• Pode reutilizar os investimentos existentes em equipamentos de computação e armazenamento.
• Ao longo do tempo, pode reduzir gradualmente a fração de cargas de trabalho que são executadas no limite e movê-las para a nuvem, quer reformulando determinadas aplicações, quer equipando algumas localizações no limite com ligações à Internet mais fiáveis.
• Os projetos relacionados com a Internet das Coisas (IdC) podem tornar-se mais rentáveis através da realização de cálculos de dados localmente. Isto permite que as empresas executem e processem alguns serviços localmente no limite, mais perto das origens de dados. Também permite às empresas enviar seletivamente dados para a nuvem, o que pode ajudar a reduzir a capacidade, a transferência de dados, o processamento e os custos gerais da solução de IoT.
• A computação de extremidade pode atuar como uma camada de comunicação intermédia entre os serviços antigos e modernizados. Por exemplo, serviços que podem estar a executar um gateway de API contentorizado, como o Apigee Hybrid. Isto permite que as aplicações e os sistemas antigos se integrem com serviços modernizados, como soluções de IoT.

Práticas recomendadas

Considere as seguintes recomendações quando implementar o padrão de arquitetura híbrida de limite:

• Se a comunicação for unidirecional, use o padrão de entrada controlada.
• Se a comunicação for bidirecional, considere o padrão de saída controlada e entrada controlada.
• Se a solução consistir em muitos sites remotos periféricos que se ligam à Google Cloud através da Internet pública, pode usar uma solução de WAN (SD-WAN) definida por software. Também pode usar o Network Connectivity Center com um router SD-WAN de terceiros suportado por um Google Cloud parceiro para simplificar o aprovisionamento e a gestão da conetividade segura em grande escala.
• Minimize as dependências entre sistemas que estão a ser executados no limite e sistemas que estão a ser executados no ambiente de nuvem. Cada dependência pode prejudicar as vantagens de fiabilidade e latência de uma configuração híbrida de limite.
• Para gerir e operar várias localizações periféricas de forma eficiente, deve ter um plano de gestão centralizado e uma solução de monitorização na nuvem.
• Certifique-se de que os pipelines de CI/CD, juntamente com as ferramentas de implementação e monitorização, são consistentes nos ambientes de nuvem e periféricos.
• Considere usar contentores e o Kubernetes quando aplicável e viável, para abstrair as diferenças entre várias localizações periféricas e também entre localizações periféricas e a nuvem. Uma vez que o Kubernetes fornece uma camada de tempo de execução comum, pode desenvolver, executar e operar cargas de trabalho de forma consistente em ambientes de computação. Também pode mover cargas de trabalho entre a periferia e a nuvem.
  • Para simplificar a configuração e o funcionamento híbridos, pode usar o GKE Enterprise para esta arquitetura (se os contentores forem usados nos ambientes). Considere as possíveis opções de conetividade que tem para ligar um cluster do GKE Enterprise em execução no seu ambiente no local ou de limite à Google Cloud.
• No âmbito deste padrão, embora alguns componentes do GKE Enterprise possam manter-se durante uma interrupção temporária da conetividade com oGoogle Cloud, não use o GKE Enterprise quando estiver desligado do Google Cloud como um modo de funcionamento nominal. Para mais informações, consulte Impacto da desativação temporária da ligação ao Google Cloud.
• Para superar as inconsistências nos protocolos, nas APIs e nos mecanismos de autenticação em diversos serviços de back-end e de limite, recomendamos, quando aplicável, que implemente um gateway de API ou um proxy como uma fachada unificadora. Este gateway ou proxy funciona como um ponto de controlo centralizado e toma as seguintes medidas:
  • Implementa medidas de segurança adicionais.
  • Protege as apps de cliente e outros serviços contra alterações ao código de back-end.
  • Facilita as pistas de auditoria para a comunicação entre todas as aplicações em vários ambientes e os respetivos componentes separados.
  • Atua como uma camada de comunicação intermédia entre os serviços antigos e modernizados.
    • O Apigee e o Apigee Hybrid permitem-lhe alojar e gerir gateways híbridos e de nível empresarial em ambientes nas instalações, na periferia, noutras nuvens e emGoogle Cloud ambientes.
• Estabelecer uma identidade comum entre ambientes para que os sistemas possam autenticar em segurança nos limites dos ambientes.
• Uma vez que os dados trocados entre ambientes podem ser sensíveis, certifique-se de que todas as comunicações são encriptadas em trânsito através de túneis VPN, TLS ou ambos.

Padrão híbrido do ambiente

Com o padrão de arquitetura híbrido de ambiente, mantém o ambiente de produção de uma carga de trabalho no centro de dados existente. Em seguida, usa a nuvem pública para os seus ambientes de desenvolvimento e teste, ou outros ambientes. Este padrão baseia-se na implementação redundante das mesmas aplicações em vários ambientes de computação. O objetivo da implementação é ajudar a aumentar a capacidade, a agilidade e a resiliência.

Ao avaliar que cargas de trabalho migrar, pode reparar em casos em que a execução de uma aplicação específica na nuvem pública apresenta desafios:

• As restrições jurisdicionais ou regulamentares podem exigir que mantenha os dados num país específico.
• Os termos de licenciamento de terceiros podem impedir a utilização de determinado software num ambiente de nuvem.
• Uma aplicação pode exigir acesso a dispositivos de hardware que só estão disponíveis localmente.

Nesses casos, considere não só o ambiente de produção, mas todos os ambientes envolvidos no ciclo de vida de uma aplicação, incluindo sistemas de desenvolvimento, testes e preparação. Estas restrições aplicam-se frequentemente ao ambiente de produção e aos respetivos dados. Podem não se aplicar a outros ambientes que não usam os dados reais. Consulte o departamento de conformidade da sua organização ou a equipa equivalente.

O diagrama seguinte mostra um padrão de arquitetura híbrido de ambiente típico:

A execução de sistemas de desenvolvimento e teste em ambientes diferentes dos seus sistemas de produção pode parecer arriscada e pode desviar-se das suas práticas recomendadas existentes ou das suas tentativas de minimizar as diferenças entre os seus ambientes. Embora estas preocupações sejam justificadas, não se aplicam se distinguir as fases dos processos de desenvolvimento e teste:

Embora os processos de desenvolvimento, teste e implementação sejam diferentes para cada aplicação, normalmente, envolvem variações das seguintes fases:

• Desenvolvimento: criar um candidato ao lançamento.
• Testes funcionais ou testes de aceitação do utilizador: verificar se a versão candidata cumpre os requisitos funcionais.
• Testes de desempenho e fiabilidade: verificar se o candidato ao lançamento cumpre os requisitos não funcionais. Também é conhecido como teste de carga.
• Testes de preparação ou implementação: verificar se o procedimento de implementação funciona.
• Produção: lançamento de aplicações novas ou atualizadas.

A execução de mais do que uma destas fases num único ambiente raramente é prática, pelo que cada fase requer normalmente um ou mais ambientes dedicados.

Nota: o termo ambiente de preparação é frequentemente confundido com ambiente de testes.

O objetivo principal de um ambiente de teste é executar testes funcionais. O objetivo principal de um ambiente de preparação é testar se os procedimentos de implementação da sua aplicação funcionam conforme previsto. Quando um lançamento atinge um ambiente de preparação, os testes funcionais devem estar concluídos. A preparação é o último passo antes de implementar software na sua implementação de produção.

Para garantir que os resultados dos testes são significativos e que se aplicam à implementação de produção, o conjunto de ambientes que usa ao longo do ciclo de vida de uma aplicação tem de satisfazer as seguintes regras, na medida do possível:

• Todos os ambientes são funcionalmente equivalentes. Ou seja, a arquitetura, as APIs e as versões dos sistemas operativos e das bibliotecas são equivalentes, e os sistemas comportam-se da mesma forma em todos os ambientes. Esta equivalência evita situações em que as aplicações funcionam num ambiente, mas falham noutro, ou em que os defeitos não são reproduzíveis.
• Os ambientes usados para testes de desempenho e fiabilidade, preparação e produção são funcionalmente não equivalentes. Ou seja, o respetivo desempenho, escala e configuração, bem como a forma como são operados e mantidos, são iguais ou diferem apenas de formas insignificantes. Caso contrário, os testes de desempenho e de preparação tornam-se sem sentido.

Em geral, não há problema se os ambientes usados para o desenvolvimento e os testes funcionais diferirem de forma não funcional dos outros ambientes.

Conforme ilustrado no diagrama seguinte, os ambientes de teste e desenvolvimento são criados com base no Google Cloud. Uma base de dados gerida, como o Cloud SQL, pode ser usada como uma opção para desenvolvimento e testes no Google Cloud. O desenvolvimento e os testes podem usar o mesmo motor de base de dados e versão no ambiente no local, um que seja funcionalmente equivalente ou uma nova versão implementada no ambiente de produção após a fase de testes. No entanto, uma vez que a infraestrutura subjacente dos dois ambientes não é idêntica, esta abordagem aos testes de carga de desempenho não é válida.

Os seguintes cenários podem adaptar-se bem ao padrão híbrido do ambiente:

• Alcançar a equivalência funcional em todos os ambientes através da utilização do Kubernetes como uma camada de tempo de execução comum, sempre que aplicável e viável. A edição Google Kubernetes Engine (GKE) Enterprise pode ser uma tecnologia de ativação fundamental para esta abordagem.
  • Garantir a portabilidade da carga de trabalho e abstrair as diferenças entre os ambientes de computação. Com uma rede de serviços de confiança zero, pode controlar e manter a separação de comunicação necessária entre os diferentes ambientes.
• Execute ambientes de programação e testes funcionais na nuvem pública. Estes ambientes podem ser funcionalmente equivalentes aos restantes ambientes, mas podem diferir em aspetos não funcionais, como o desempenho. Este conceito é ilustrado no diagrama anterior.
• Execute ambientes para produção, preparação e desempenho (testes de carga) e testes de fiabilidade no ambiente de computação privado, garantindo a equivalência funcional e não funcional.

Considerações de design

• Necessidades da empresa: cada estratégia de implementação e lançamento para aplicações tem as suas próprias vantagens e desvantagens. Para garantir que a abordagem que selecionar está alinhada com os seus requisitos específicos, baseie as suas seleções numa avaliação exaustiva das necessidades e restrições da sua empresa.
• Diferenças de ambiente: como parte deste padrão, o objetivo principal da utilização deste ambiente de nuvem é o desenvolvimento e os testes. O estado final é alojar a aplicação testada no ambiente local privado (produção). Para evitar desenvolver e testar uma capacidade que possa funcionar conforme esperado no ambiente de nuvem e falhar no ambiente de produção (nas instalações), a equipa técnica tem de conhecer e compreender as arquiteturas e as capacidades de ambos os ambientes. Isto inclui dependências de outras aplicações e da infraestrutura de hardware, por exemplo, sistemas de segurança que realizam a inspeção do tráfego.
• Governança: para controlar o que a sua empresa tem autorização para desenvolver na nuvem e que dados pode usar para testes, use um processo de aprovação e governança. Este processo também pode ajudar a sua empresa a certificar-se de que não usa funcionalidades na nuvem nos seus ambientes de desenvolvimento e teste que não existam no seu ambiente de produção no local.
• Critérios de sucesso: têm de existir critérios de sucesso de testes claros, predefinidos e mensuráveis que estejam alinhados com as normas de controlo de qualidade de software da sua organização. Aplique estas normas a qualquer aplicação que desenvolva e teste.
• Redundância: embora os ambientes de desenvolvimento e teste possam não exigir tanta fiabilidade como o ambiente de produção, continuam a precisar de capacidades redundantes e da capacidade de testar diferentes cenários de falha. Os requisitos do cenário de falha podem levar o design a incluir redundância como parte do seu ambiente de desenvolvimento e testes.

Vantagens

A execução de cargas de trabalho de desenvolvimento e testes funcionais na nuvem pública tem várias vantagens:

• Pode iniciar e parar automaticamente ambientes conforme necessário. Por exemplo, pode aprovisionar um ambiente completo para cada commit ou pedido de obtenção, permitir a execução de testes e, em seguida, desativá-lo novamente. Esta abordagem também oferece as seguintes vantagens:
  • Pode reduzir os custos parando as instâncias de máquinas virtuais (VM) quando estão inativas ou aprovisionando ambientes apenas a pedido.
  • Pode acelerar o desenvolvimento e os testes iniciando ambientes efémeros para cada pedido de obtenção. Ao fazê-lo, também reduz os custos gerais de manutenção e reduz as inconsistências no ambiente de compilação.
• A execução destes 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. Esta abordagem é particularmente útil se decidir explorar a portabilidade da carga de trabalho usando contentores e o Kubernetes, por exemplo, usando o GKE Enterprise em vários ambientes.

Práticas recomendadas

Para implementar com êxito o padrão de arquitetura híbrida do ambiente, considere as seguintes recomendações:

• Defina os requisitos de comunicação da sua aplicação, incluindo o design de rede e segurança ideal. Em seguida, use o padrão de rede espelhada para ajudar a conceber a arquitetura de rede de modo a evitar comunicações diretas entre sistemas de diferentes ambientes. Se for necessária comunicação entre ambientes, esta tem de ser feita de forma controlada.

• A estratégia de implementação e testes de aplicações que escolher deve estar alinhada com os objetivos e os requisitos da sua empresa. Isto pode envolver a implementação de alterações sem tempo de inatividade ou a implementação de funcionalidades gradualmente num ambiente ou grupo de utilizadores específico antes do lançamento mais amplo.

• Para tornar as cargas de trabalho portáteis e abstrair as diferenças entre os ambientes, pode usar contentores com o Kubernetes. Para mais informações, consulte a arquitetura de referência do ambiente híbrido do GKE Enterprise.

• Estabelecer uma cadeia de ferramentas comum que funcione em todos os ambientes de computação para implementar, configurar e operar cargas de trabalho. A utilização do Kubernetes oferece-lhe esta consistência.

• Certifique-se de que os pipelines de CI/CD são consistentes em todos os ambientes de computação e que o mesmo conjunto exato de ficheiros binários, pacotes ou contentores é implementado nesses ambientes.

• Quando usar o Kubernetes, use um sistema de CI, como o Tekton, para implementar um pipeline de implementação que seja implementado em clusters e funcione em vários ambientes. Para mais informações, consulte o artigo Soluções de DevOps no Google Cloud.

• Para ajudar no lançamento contínuo de aplicações seguras e fiáveis, incorpore a segurança como parte integrante do processo de DevOps (DevSecOps). Para mais informações, consulte o artigo Implemente e proteja a sua aplicação virada para a Internet em menos de uma hora com o conjunto de ferramentas de Dev(Sec)Ops.

• Use as mesmas ferramentas para registo e monitorização em Google Cloud e ambientes de nuvem existentes. Considere usar sistemas de monitorização de código aberto. Para mais informações, consulte o artigo Padrões de registo e monitorização híbridos e multicloud.

• Se diferentes equipas gerirem cargas de trabalho de teste e produção, a utilização de ferramentas separadas pode ser aceitável. No entanto, a utilização das mesmas ferramentas com diferentes autorizações de visualização pode ajudar a reduzir o esforço e a complexidade da formação.

• Quando escolhe serviços de base de dados, armazenamento e mensagens para testes funcionais, use produtos que tenham um equivalente gerido no Google Cloud. Confiar em serviços geridos ajuda a diminuir o esforço administrativo de manutenção dos ambientes de desenvolvimento e teste.

• Para proteger informações confidenciais, recomendamos que encriptem todas as comunicações em trânsito. Se a encriptação for necessária na camada de conetividade, estão disponíveis várias opções baseadas na solução de conetividade híbrida selecionada. Estas opções incluem túneis de VPN, VPN de alta disponibilidade através do Cloud Interconnect e MACsec para o Cloud Interconnect.

A tabela seguinte mostra os Google Cloud produtos compatíveis com produtos OSS comuns.

Produto OSS	Compatível com o produto Google Cloud
Apache HBase	Bigtable
Apache Beam	Dataflow
CDAP	Cloud Data Fusion
Apache Hadoop	Dataproc
MySQL, PostgreSQL	Cloud SQL
Redis Cluster, Redis, Memcached	Memorystore
Sistema de Arquivos de Rede (NFS)	Filestore
JMS, Kafka	Pub/Sub
Kubernetes	GKE Enterprise

Padrões híbridos e de várias nuvens de continuidade do negócio

O principal motivo para considerar a continuidade da atividade empresarial para sistemas essenciais é ajudar uma organização a ser resiliente e continuar as suas operações empresariais durante e após eventos de falha. Ao replicar sistemas e dados em várias regiões geográficas e evitar pontos únicos de falha, pode minimizar os riscos de um desastre natural que afete a infraestrutura local. Outros cenários de falha incluem falhas graves do sistema, um ataque de cibersegurança ou até mesmo um erro de configuração do sistema.

A otimização de um sistema para resistir a falhas é essencial para estabelecer uma continuidade do negócio eficaz. A fiabilidade do sistema pode ser influenciada por vários fatores, incluindo, entre outros, o desempenho, a resiliência, a disponibilidade de tempo de atividade, a segurança e a experiência do utilizador. Para mais informações sobre como criar a arquitetura e operar serviços fiáveis no Google Cloud, consulte o pilar de fiabilidade do Google Cloud Framework Well-Architected e os elementos básicos da fiabilidade no Google Cloud.

Este padrão de arquitetura baseia-se numa implementação redundante de aplicações em vários ambientes de computação. Neste padrão, implementa as mesmas aplicações em vários ambientes de computação com o objetivo de aumentar a fiabilidade. A continuidade da atividade empresarial pode ser definida como a capacidade de uma organização continuar as suas principais funções ou serviços empresariais a níveis aceitáveis predefinidos após um evento disruptivo.

A recuperação de desastres (RD) é considerada um subconjunto da continuidade da atividade empresarial, focando-se explicitamente em garantir que os sistemas de TI que suportam funções empresariais críticas estão operacionais o mais rapidamente possível após uma interrupção. Em geral, as estratégias e os planos de recuperação de desastres ajudam frequentemente a formar uma estratégia de continuidade do negócio mais abrangente. Do ponto de vista tecnológico, quando começa a criar estratégias de recuperação de desastres, a análise do impacto na empresa deve definir duas métricas principais: o objetivo de ponto de recuperação (RPO) e o objetivo de tempo de recuperação (RTO). Para mais orientações sobre a utilização Google Cloud para resolver a recuperação de desastres, consulte o Guia de planeamento de recuperação de desastres.

Quanto menores forem os valores alvo de RPO e RTO, mais rapidamente os serviços podem recuperar de uma interrupção com uma perda de dados mínima. No entanto, isto implica um custo mais elevado, uma vez que significa criar sistemas redundantes. Os sistemas redundantes capazes de realizar a replicação de dados quase em tempo real e que operam à mesma escala após um evento de falha aumentam a complexidade, os custos administrativos e os custos.

A decisão de selecionar uma estratégia de recuperação de desastres ou um padrão deve ser baseada numa análise do impacto empresarial. Por exemplo, as perdas financeiras incorridas com apenas alguns minutos de inatividade para uma organização de serviços financeiros podem exceder em muito o custo de implementação de um sistema de recuperação de desastres. No entanto, as empresas noutras indústrias podem suportar horas de inatividade sem um efeito empresarial significativo.

Quando executa sistemas essenciais para a missão num centro de dados no local, uma abordagem de recuperação de desastres consiste em manter sistemas de reserva num segundo centro de dados numa região diferente. No entanto, uma abordagem mais rentável é usar um ambiente de computação baseado na nuvem pública para fins de comutação por falha. Esta abordagem é o principal motor do padrão de continuidade do negócio híbrido. A nuvem pode ser especialmente apelativa do ponto de vista dos custos, porque permite desativar parte da sua infraestrutura de recuperação de desastres quando não está em utilização. Para alcançar uma solução de recuperação de desastres de custo mais baixo, uma solução na nuvem permite que uma empresa aceite o potencial aumento nos valores de OPR e OTR.

O diagrama anterior ilustra a utilização da nuvem como um ambiente de recuperação de desastres ou de failover para um ambiente no local.

Uma variante menos comum (e raramente necessária) deste padrão é o padrão de continuidade de negócio em várias nuvens. Nesse padrão, o ambiente de produção usa um fornecedor de nuvem e o ambiente de recuperação de desastres usa outro fornecedor de nuvem. Ao implementar cópias de cargas de trabalho em vários fornecedores de nuvem, pode aumentar a disponibilidade além do que uma implementação multirregional oferece.

A avaliação de uma recuperação de desastres em várias nuvens em comparação com a utilização de um fornecedor de nuvem com diferentes regiões requer uma análise exaustiva de várias considerações, incluindo o seguinte:

• Capacidade de gestão
• Segurança
• Viabilidade geral.
• Custo
  • Os potenciais custos de transferência de dados de saída de mais do que um fornecedor de nuvem podem ser dispendiosos com a comunicação contínua entre nuvens.
  • Pode haver um elevado volume de tráfego ao replicar bases de dados.
  • Custo total de propriedade e o custo de gestão da infraestrutura de rede entre nuvens.

Nota: para mais informações sobre como o Cross-Cloud Interconnect pode ajudar a reduzir o CTP e a complexidade, consulte o artigo Anunciamos o Cross-Cloud Interconnect: conetividade integrada a todas as suas nuvens.

Se os seus dados tiverem de permanecer no seu país para cumprir os requisitos regulamentares, pode usar um segundo fornecedor de nuvem que também esteja no seu país como DR. Essa utilização de um segundo fornecedor de nuvem pressupõe que não existe nenhuma opção para usar um ambiente no local para criar uma configuração híbrida. Para evitar a reestruturação da sua solução na nuvem, o ideal é que o segundo fornecedor de nuvem ofereça todas as capacidades e serviços necessários na região.

Considerações de design

• Expectativa de DR: os objetivos de RPO e RTO que a sua empresa quer alcançar devem orientar a arquitetura de DR e o planeamento de compilação.
• Arquitetura de solução: com este padrão, tem de replicar as funções e as capacidades existentes do seu ambiente no local para cumprir as suas expetativas de recuperação de desastres. Por conseguinte, tem de avaliar a viabilidade e a exequibilidade da reativação da alojamento, da refatoração ou da reestruturação das suas aplicações para fornecer as mesmas funções (ou mais otimizadas) e o mesmo desempenho no ambiente da nuvem.
• Conceber e criar: a criação de uma zona de destino é quase sempre um pré-requisito para implementar cargas de trabalho empresariais num ambiente de nuvem. Para mais informações, consulte o artigo Design da zona de destino no Google Cloud.

• Invocações de DR: é importante que o design e o processo de DR tenham em consideração as seguintes questões:

  • O que aciona um cenário de recuperação de desastres? Por exemplo, uma DR pode ser acionada pela falha de funções ou sistemas específicos no site principal.
  • Como é que a comutação por falha para o ambiente de recuperação de desastres é invocada? É um processo de aprovação manual ou pode ser automatizado para atingir um objetivo de RTO baixo?
  • Como devem ser concebidos os mecanismos de deteção e notificação de falhas do sistema para invocar a comutação por falha em conformidade com o RTO esperado?
  • Como é que o tráfego é reencaminhado para o ambiente de recuperação após a deteção da falha?

  Valide as suas respostas a estas perguntas através de testes.

• Testes: teste e avalie exaustivamente a comutação por falha para a recuperação de desastres. Certifique-se de que cumpre as suas expetativas de RPO e RTO. Desta forma, pode ter mais confiança para invocar a DR quando necessário. Sempre que for feita uma nova alteração ou atualização ao processo ou à solução tecnológica, volte a realizar os testes.

• Competências da equipa: uma ou mais equipas técnicas têm de ter as competências e a experiência para criar, operar e resolver problemas da carga de trabalho de produção no ambiente de nuvem, a menos que o seu ambiente seja gerido por terceiros.

Vantagens

A utilização Google Cloud para a continuidade do negócio oferece várias vantagens:

• Uma vez que o Google Cloud tem muitas regiões em todo o mundo à sua escolha, pode usá-lo para fazer uma cópia de segurança ou replicar dados para um site diferente no mesmo continente. Também pode fazer uma cópia de segurança ou replicar dados para um site num continente diferente.
• Google Cloud oferece a capacidade de armazenar dados no Cloud Storage num contentor de duas regiões ou multirregional. Os dados são armazenados de forma redundante em, pelo menos, duas regiões geográficas separadas. Os dados armazenados em contentores de duas regiões e multirregionais são replicados em regiões geográficas através da replicação predefinida.
  • Os contentores de duas regiões oferecem georredundância para suportar a continuidade das atividades e os planos de recuperação de desastres. Além disso, para replicar mais rapidamente, com um RPO mais baixo, os objetos armazenados em duas regiões podem usar opcionalmente a replicação turbo nessas regiões.
  • Da mesma forma, a replicação multirregional oferece redundância em várias regiões, armazenando os seus dados dentro do limite geográfico da região múltipla.
• Oferece uma ou mais das seguintes opções para reduzir as despesas de capital e as despesas operacionais para criar uma DR:
  • As instâncias de VM paradas só incorrem em custos de armazenamento e são substancialmente mais baratas do que as instâncias de VM em execução. Isto significa que pode minimizar o custo de manutenção dos sistemas de reserva a frio.
  • O modelo de pagamento por utilização Google Cloud significa que só paga pelo armazenamento e pela capacidade de computação que realmente usa.
  • As capacidades de elasticidade, como o dimensionamento automático, permitem-lhe dimensionar automaticamente o seu ambiente de recuperação de desastres conforme necessário.

Por exemplo, o diagrama seguinte mostra uma aplicação em execução num ambiente no local (produção) que usa componentes de recuperação emGoogle Cloud com o Compute Engine, o Cloud SQL e o Cloud Load Balancing. Neste cenário, a base de dados é aprovisionada previamente através de uma base de dados baseada em VMs ou de uma base de dados gerida, como o Cloud SQL, para uma recuperação mais rápida com replicação de dados contínua. Google Cloud Pode iniciar VMs do Compute Engine a partir de instantâneos pré-criados para reduzir o custo durante as operações normais. Com esta configuração e após um evento de falha, o DNS tem de apontar para o endereço IP externo do Cloud Load Balancing.

Para ter a aplicação operacional na nuvem, tem de aprovisionar as VMs Web e de aplicações. Consoante o nível de RTO segmentado e as políticas da empresa, o processo completo para invocar uma DR, aprovisionar a carga de trabalho na nuvem e reencaminhar o tráfego pode ser concluído manual ou automaticamente.

Para acelerar e automatizar o aprovisionamento da infraestrutura, considere gerir a infraestrutura como código. Pode usar o Cloud Build, que é um serviço de integração contínua, para aplicar automaticamente manifestos do Terraform ao seu ambiente. Para mais informações, consulte o artigo Gerir a infraestrutura como código com o Terraform, o Cloud Build e o GitOps.

Práticas recomendadas

Quando usar o padrão de continuidade da empresa, considere as seguintes práticas recomendadas:

• Crie um plano de recuperação de desastres que documente a sua infraestrutura, juntamente com os procedimentos de ativação pós-falha e recuperação.
• Considere as seguintes ações com base na análise do impacto na empresa e nos alvos de RPO e RTO necessários identificados:
  • Decida se a cópia de segurança dos dados para o Google Cloud é suficiente ou se tem de considerar outra estratégia de recuperação de desastres (sistemas de reserva a frio, a quente ou ativos).
  • Defina os serviços e os produtos que pode usar como elementos básicos para o seu plano de DR.
  • Enquadre os cenários de DR aplicáveis para as suas aplicações e dados como parte da sua estratégia de DR selecionada.
• Considere usar o padrão de transferência quando estiver apenas a fazer uma cópia de segurança dos dados. Caso contrário, o padrão com malha pode ser uma boa opção para replicar a arquitetura de rede do ambiente existente.
• Minimize as dependências entre sistemas que estão a ser executados em ambientes diferentes, especialmente quando a comunicação é processada de forma síncrona. Estas dependências podem abrandar o desempenho e diminuir a disponibilidade geral.

• Evite o problema de divisão de cérebros. Se replicar dados bidirecionalmente em vários ambientes, pode ficar exposto ao problema de divisão de cérebros. O problema de divisão de cérebro ocorre quando dois ambientes que replicam dados bidirecionalmente perdem a comunicação entre si. Esta divisão pode fazer com que os sistemas em ambos os ambientes concluam que o outro ambiente está indisponível e que têm acesso exclusivo aos dados. Isto pode levar a modificações dos dados em conflito. Existem duas formas comuns de evitar o problema de divisão de cérebro:

  • Usar um ambiente de computação de terceiros. Este ambiente permite que os sistemas verifiquem a existência de um quórum antes de modificar os dados.

  • Permitir a conciliação de modificações de dados em conflito após o restauro da conetividade.

    Com as bases de dados SQL, pode evitar o problema de divisão de cérebros tornando a instância principal original inacessível antes de os clientes começarem a usar a nova instância principal. Para mais informações, consulte o artigo Recuperação de desastres da base de dados do Cloud SQL.

• Certifique-se de que os sistemas de CI/CD e os repositórios de artefactos não se tornam um único ponto de falha. Quando um ambiente não está disponível, tem de conseguir implementar novos lançamentos ou aplicar alterações de configuração.

• Torne todas as cargas de trabalho portáteis quando usar sistemas de espera. Todas as cargas de trabalho devem ser portáteis (quando suportadas pelas aplicações e viáveis) para que os sistemas permaneçam consistentes em todos os ambientes. Pode alcançar esta abordagem considerando os contentores e o Kubernetes. Ao usar a edição Enterprise do Google Kubernetes Engine (GKE), pode simplificar a compilação e as operações.

• Integre a implementação de sistemas de reserva no seu pipeline de CI/CD. Esta integração ajuda a garantir que as versões e as configurações das aplicações são consistentes em todos os ambientes.

• Certifique-se de que as alterações de DNS são propagadas rapidamente configurando o DNS com um valor de tempo de vida razoavelmente curto para poder reencaminhar os utilizadores para sistemas de espera quando ocorrer um desastre.

• Selecione a política de DNS e a política de encaminhamento que se alinham com a sua arquitetura e comportamento da solução. Além disso, pode combinar vários equilibradores de carga regionais com políticas de encaminhamento de DNS para criar arquiteturas de equilíbrio de carga globais para diferentes exemplos de utilização, incluindo a configuração híbrida.

• Use vários fornecedores de DNS. Quando usa vários fornecedores de DNS, pode:

  • Melhorar a disponibilidade e a capacidade de recuperação das suas aplicações e serviços.

  • Simplifique a implementação ou a migração de aplicações híbridas que têm dependências em ambientes no local e na nuvem com uma configuração de DNS de vários fornecedores.

    Google Cloud oferece uma solução de código aberto baseada no octoDNS para ajudar a configurar e operar um ambiente com vários fornecedores de DNS. Para mais informações, consulte o artigo DNS público de vários fornecedores com o Cloud DNS.

• Use balanceadores de carga quando usar sistemas de espera para criar uma comutação por falha automática. Tenha em atenção que o hardware do equilibrador de carga pode falhar.

• Use o Cloud Load Balancing em vez de balanceadores de carga de hardware para ativar alguns cenários que ocorrem quando usa este padrão de arquitetura. Os pedidos de clientes internos ou pedidos de clientes externos podem ser redirecionados para o ambiente principal ou o ambiente de recuperação de desastres com base em diferentes métricas, como a divisão do tráfego com base no peso. Para mais informações, consulte o artigo Vista geral da gestão de tráfego para o Application Load Balancer externo global.

• Considere usar o Cloud Interconnect ou o Cross-Cloud Interconnect se o volume de transferência de dados de saída Google Cloud para Google Cloud o outro ambiente for elevado. O Cloud Interconnect pode ajudar a otimizar o desempenho da conetividade e pode reduzir os encargos de transferência de dados de saída para o tráfego que cumpre determinadas condições. Para mais informações, consulte os preços do Cloud Interconnect.

• Considere usar a sua solução de parceiros preferida no Google Cloud Marketplace para ajudar a facilitar as cópias de segurança, as replicações e outras tarefas de dados que cumprem os seus requisitos, incluindo os objetivos de OPR e OTR.

• Teste e avalie cenários de invocação de DR para compreender com que facilidade a aplicação consegue recuperar de um evento de desastre em comparação com o valor de RTO alvo.

• Encripte as comunicações em trânsito. Para proteger informações confidenciais, recomendamos que encriptem todas as comunicações em trânsito. Se a encriptação for necessária na camada de conetividade, estão disponíveis várias opções com base na solução de conetividade híbrida selecionada. Estas opções incluem túneis de VPN, VPN de alta disponibilidade através do Cloud Interconnect e MACsec para o Cloud Interconnect.

Padrão de aumento de capacidade da nuvem

As aplicações de Internet podem sofrer flutuações extremas na utilização. Embora a maioria das aplicações empresariais não enfrente este desafio, muitas empresas têm de lidar com um tipo diferente de carga de trabalho intermitente: tarefas em lote ou de CI/CD.

Este padrão de arquitetura baseia-se numa implementação redundante de aplicações em vários ambientes de computação. O objetivo é aumentar a capacidade, a resiliência ou ambas.

Embora possa acomodar cargas de trabalho intermitentes num ambiente de computação baseado em centros de dados, esta abordagem pode não ser rentável. Com as tarefas em lote, pode otimizar a utilização prolongando a respetiva execução durante períodos mais longos, embora o atraso das tarefas não seja prático se forem sensíveis ao tempo.

A ideia do padrão de expansão na nuvem é usar um ambiente de computação privado para a carga de base e expandir temporariamente para a nuvem quando precisar de capacidade adicional.

No diagrama anterior, quando a capacidade de dados atinge o limite num ambiente privado local, o sistema pode obter capacidade adicional de um ambienteGoogle Cloud quando necessário.

Os principais fatores deste padrão são a poupança de dinheiro e a redução do tempo e do esforço necessários para responder às alterações dos requisitos de escala. Com esta abordagem, só paga os recursos usados quando processa cargas adicionais. Isto significa que não tem de aprovisionar em excesso a sua infraestrutura. Em alternativa, pode tirar partido dos recursos na nuvem a pedido e escalá-los de acordo com a procura e quaisquer métricas predefinidas. Como resultado, a sua empresa pode evitar interrupções de serviço durante os períodos de pico de procura.

Um requisito potencial para cenários de expansão rápida na nuvem é a portabilidade da carga de trabalho. Quando permite que as cargas de trabalho sejam implementadas em vários ambientes, tem de abstrair as diferenças entre os ambientes. Por exemplo, o Kubernetes permite alcançar a consistência ao nível da carga de trabalho em diversos ambientes que usam infraestruturas diferentes. Para mais informações, consulte a arquitetura de referência do ambiente híbrido do GKE Enterprise.

Considerações de design

O padrão de expansão na nuvem aplica-se a cargas de trabalho interativas e em lote. No entanto, quando lida com cargas de trabalho interativas, tem de determinar como distribuir os pedidos pelos ambientes:

• Pode encaminhar os pedidos de utilizadores recebidos para um equilibrador de carga que seja executado no data center existente e, em seguida, fazer com que o equilibrador de carga distribua os pedidos pelos recursos locais e na nuvem.

  Esta abordagem requer que o balanceador de carga ou outro sistema que esteja a ser executado no centro de dados existente também monitorize os recursos que estão alocados na nuvem. O equilibrador de carga ou outro sistema também tem de iniciar a expansão ou a redução automática dos recursos. Com esta abordagem, pode desativar todos os recursos na nuvem durante períodos de baixa atividade. No entanto, a implementação de mecanismos para acompanhar os recursos pode exceder as capacidades das suas soluções de balanceamento de carga e, por conseguinte, aumentar a complexidade geral.

• Em vez de implementar mecanismos para monitorizar recursos, pode usar o Equilíbrio de carga do Google Cloud com um backend de grupo de pontos finais de rede (NEG) de conetividade híbrida. Usa este equilibrador de carga para encaminhar pedidos de clientes internos ou pedidos de clientes externos para back-ends localizados no local e naGoogle Cloud , e que se baseiam em diferentes métricas, como a divisão de tráfego baseada no peso. Também pode reduzir as quantidades de back-ends com base na capacidade de fornecimento do balanceamento de carga para cargas de trabalho no Google Cloud. Para mais informações, consulte o artigo Vista geral da gestão de tráfego para o Application Load Balancer externo global.

  Esta abordagem tem várias vantagens adicionais, como tirar partido das capacidades de proteção contra DDoS do Google Cloud Armor, da WAF e da colocação de conteúdo em cache no limite da nuvem através do Cloud CDN. No entanto, tem de dimensionar a conetividade de rede híbrida para processar o tráfego adicional.

• Conforme realçado em Portabilidade da carga de trabalho, uma aplicação pode ser portátil para um ambiente diferente com alterações mínimas para alcançar a consistência da carga de trabalho, mas isso não significa que a aplicação tenha o mesmo desempenho em ambos os ambientes. As diferenças no cálculo subjacente, nas capacidades de segurança da infraestrutura ou na infraestrutura de rede, juntamente com a proximidade dos serviços dependentes, determinam normalmente o desempenho. Através dos testes, pode ter uma visibilidade mais precisa e compreender as expetativas de desempenho.

• Pode usar serviços de infraestrutura na nuvem para criar um ambiente para alojar as suas aplicações sem portabilidade. Use as seguintes abordagens para processar pedidos de clientes quando o tráfego é redirecionado durante os períodos de pico de procura:

  • Use ferramentas consistentes para monitorizar e gerir estes dois ambientes.
  • Certifique-se de que a gestão de versões da carga de trabalho é consistente e que as origens de dados estão atualizadas.
  • Pode ter de adicionar automatização para aprovisionar o ambiente de nuvem e reencaminhar o tráfego quando a procura aumenta e espera-se que a carga de trabalho na nuvem aceite pedidos de clientes para a sua aplicação.

• Se pretender encerrar todos os Google Cloud recursos durante períodos de baixa procura, a utilização de políticas de encaminhamento de DNS principalmente para o equilíbrio de carga de tráfego pode nem sempre ser ideal. Isto deve-se principalmente ao facto de:

  • Os recursos podem demorar algum tempo a inicializar antes de poderem ser apresentados aos utilizadores.
  • As atualizações de DNS tendem a propagar-se lentamente através da Internet.

  Consequentemente:

  • Os utilizadores podem ser encaminhados para o ambiente de nuvem, mesmo quando não existem recursos disponíveis para processar os respetivos pedidos.
  • Os utilizadores podem continuar a ser encaminhados para o ambiente no local temporariamente enquanto as atualizações de DNS são propagadas pela Internet.

Com o Cloud DNS, pode escolher a política de DNS e a política de encaminhamento que se alinham com a arquitetura e o comportamento da sua solução, como as políticas de encaminhamento de DNS de geolocalização. O Cloud DNS também suporta verificações de funcionamento para o Network Load Balancer de passagem interno e o Application Load Balancer interno. Nesse caso, pode incorporá-lo na sua configuração de DNS híbrido geral baseada neste padrão.

Em alguns cenários, pode usar o Cloud DNS para distribuir pedidos de clientes com verificações de estado ativadas Google Cloud, como quando usa balanceadores de carga de aplicações internos ou balanceadores de carga de aplicações internos entre regiões. Neste cenário, o Cloud DNS verifica o estado geral do balanceador de carga da aplicação interno, que, por sua vez, verifica o estado das instâncias de back-end. Para mais informações, consulte o artigo Faça a gestão das políticas de encaminhamento de DNS e das verificações de estado.

Também pode usar o horizonte dividido do Cloud DNS. O horizonte dividido do Cloud DNS é uma abordagem para configurar respostas ou registos de DNS para a localização ou a rede específicas do originador da consulta de DNS para o mesmo nome de domínio. Esta abordagem é usada frequentemente para cumprir requisitos em que uma aplicação é concebida para oferecer uma experiência privada e pública, cada uma com funcionalidades únicas. Esta abordagem também ajuda a distribuir a carga de tráfego entre ambientes.

Tendo em conta estas considerações, o cloud bursting adapta-se geralmente melhor a cargas de trabalho em lote do que a cargas de trabalho interativas.

Vantagens

As principais vantagens do padrão de arquitetura de expansão na nuvem incluem:

• O cloud bursting permite-lhe reutilizar os investimentos existentes em centros de dados e ambientes de computação privados. Esta reutilização pode ser permanente ou estar em vigor até que o equipamento existente tenha de ser substituído, altura em que pode considerar uma migração completa.
• Uma vez que já não tem de manter a capacidade excessiva para satisfazer as exigências máximas, pode aumentar a utilização e a rentabilidade dos seus ambientes de computação privados.
• A expansão na nuvem permite-lhe executar trabalhos em lote atempadamente sem a necessidade de aprovisionar recursos de computação em excesso.

Práticas recomendadas

Ao implementar a expansão para a nuvem, considere as seguintes práticas recomendadas:

• Para garantir que as cargas de trabalho executadas na nuvem podem aceder aos recursos da mesma forma que as cargas de trabalho executadas num ambiente no local, use o padrão em rede com o princípio de acesso de segurança com privilégios mínimos. Se o design da carga de trabalho o permitir, pode permitir o acesso apenas a partir da nuvem ao ambiente de computação nas instalações e não o contrário.
• Para minimizar a latência da comunicação entre ambientes, escolha uma Google Cloud região geograficamente próxima do seu ambiente de computação privado. Para mais informações, consulte o artigo Práticas recomendadas para a seleção de regiões do Compute Engine.
• Quando usar a expansão rápida na nuvem apenas para cargas de trabalho em lote, reduza a superfície de ataque de segurança mantendo todos os Google Cloud recursos privados. Impedir qualquer acesso direto da Internet a estes recursos, mesmo que esteja a usar o balanceamento de carga externo para fornecer o ponto de entrada para a carga de trabalho. Google Cloud

• Selecione a política de DNS e a política de encaminhamento que se alinham com o seu padrão de arquitetura e o comportamento da solução segmentada.

  • Como parte deste padrão, pode aplicar o design das suas políticas de DNS permanentemente ou quando precisar de capacidade adicional através de outro ambiente durante os períodos de pico da procura.
  • Pode usar políticas de encaminhamento de DNS de geolocalização para ter um ponto final de DNS global para os seus equilibradores de carga regionais. Esta tática tem muitos exemplos de utilização para políticas de encaminhamento de DNS de geolocalização, incluindo aplicações híbridas que usam Google Cloud juntamente com uma implementação no local onde Google Cloud existe uma região.

  • Se precisar de fornecer registos diferentes para as mesmas consultas DNS, pode usar o DNS de horizonte dividido, por exemplo, consultas de clientes internos e externos.

    Para mais informações, consulte as arquiteturas de referência para DNS híbrido

• Para garantir que as alterações de DNS são propagadas rapidamente, configure o DNS com um valor de tempo de vida razoavelmente curto para poder reencaminhar os utilizadores para sistemas de espera quando precisar de capacidade adicional através de ambientes na nuvem.

• Para tarefas que não sejam altamente críticas em termos de tempo e não armazenem dados localmente, considere usar instâncias de VM Spot, que são substancialmente mais baratas do que as instâncias de VM normais. No entanto, um pré-requisito é que, se a tarefa da VM for interrompida, o sistema tem de conseguir reiniciar automaticamente a tarefa.

• Use contentores para alcançar a portabilidade da carga de trabalho, quando aplicável. Além disso, o GKE Enterprise pode ser uma tecnologia de ativação fundamental para esse design. Para mais informações, consulte o artigo Arquitetura de referência do ambiente híbrido do GKE Enterprise.

• Monitorize o tráfego enviado de Google Cloud para um ambiente de computação diferente. Este tráfego está sujeito a custos de transferência de dados de saída.

• Se planear usar esta arquitetura a longo prazo com um volume de transferência de dados de saída elevado, considere usar o Cloud Interconnect. O Cloud Interconnect pode ajudar a otimizar o desempenho da conetividade e pode reduzir os encargos de transferência de dados de saída para o tráfego que cumpre determinadas condições. Para mais informações, consulte os preços do Cloud Interconnect.

• Quando usar o Cloud Load Balancing, deve usar as respetivas capacidades de otimização da capacidade da aplicação , quando aplicável. Isto pode ajudar a resolver alguns dos desafios de capacidade que podem ocorrer em aplicações distribuídas globalmente.

• Autenticar as pessoas que usam os seus sistemas através da criação de uma identidade comum entre ambientes para que os sistemas possam autenticar-se de forma segura em limites de ambientes.

• Para proteger informações confidenciais, recomendamos vivamente a encriptação de todas as comunicações em trânsito. Se a encriptação for necessária na camada de conetividade, estão disponíveis várias opções com base na solução de conetividade híbrida selecionada. Estas opções incluem túneis de VPN, VPN de alta disponibilidade através do Cloud Interconnect e MACsec para o Cloud Interconnect.

Padrões de arquitetura híbrida e de várias nuvens: o que se segue

• Saiba como abordar a arquitetura híbrida e multicloud e como escolher cargas de trabalho adequadas.
• Saiba mais sobre os padrões de arquitetura de rede adequados para os padrões de arquitetura híbrida e multicloud selecionados.
• Saiba mais sobre os arquétipos de implementação para aplicações na nuvem.
• Saiba como conceber e implementar uma aplicação Web de comércio eletrónico usando diferentes arquiteturas, incluindo uma aplicação Web de comércio eletrónico baseada em microsserviços usando o GKE e uma aplicação Web dinâmica que é baseada em API sem servidor.

---

1. Para mais informações sobre considerações específicas da região, consulte o artigo Geografia e regiões.  ↩