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 governação, operações e segurança 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 crítica. 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, APIs e mecanismos de autenticação em vários backends, recomendamos, quando aplicável, que implemente um gateway de API ou um proxy como uma fachada unificadora. Esta gateway ou proxy funciona como um ponto de controlo centralizado e executa 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.