O padrão de arquitetura de multicloud particionado combina vários ambientes de nuvem operados por diferentes provedores de serviços de nuvem. Essa arquitetura oferece a flexibilidade de implantar um aplicativo em um ambiente computacional otimizador que é responsável por drivers multicloud e considerações discutidas na primeira parte desta série.
O diagrama a seguir mostra uma arquitetura multicloud particionada padrão.
Esse padrão de arquitetura pode ser criado de duas maneiras diferentes. A primeira abordagem é baseada na implantação dos componentes do aplicativo em diferentes nuvens públicas do Google Cloud. Essa abordagem também é conhecida como arquitetura composta e é a mesma abordagem da arquitetura padrão híbrida em camadas. Em vez de usar um ambiente no local com uma rede pública, ela usa no mínimo dois ambientes de nuvem. Em uma arquitetura de composição, uma única carga de trabalho ou aplicativo usa componentes de mais de uma nuvem. A segunda abordagem implanta aplicativos diferentes em ambientes de nuvem pública. Esta lista com alguns exemplos descreve alguns dos motivadores de negócios para a segunda abordagem:
- Integrar totalmente aplicativos hospedados em ambientes de nuvem diferentes durante um cenário de fusão e aquisição entre duas empresas.
- Promover a flexibilidade e atender a diversas preferências da nuvem em toda a organização. Essa abordagem incentiva as unidades organizacionais a escolher o provedor de nuvem mais adequado às suas necessidades e preferências específicas.
- Operar em uma implantação multirregional ou de nuvem global. Se uma empresa precisar cumprir os regulamentos de residência de dados em determinadas regiões ou países, ela tem que escolher entre os provedores de nuvem disponíveis no local, caso seu provedor de nuvem principal não tenha uma nuvem nesse local.
Com o padrão de arquitetura multicloud particionada, opcionalmente, é possível 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 cargas de trabalho se torna um requisito importante. Quando você implanta cargas de trabalho em vários ambientes computacionais e quer manter a capacidade de mover as cargas de trabalho entre esses ambientes, é preciso deixar de lado as diferenças entre eles. Com o GKE Enterprise, é possível projetar e criar uma solução para resolver a complexidade multicloud com governança, operações e segurança na postura de segurança. Para mais informações, consulte GKE Multi-Cloud-Cloud.
Conforme mencionado anteriormente, existem algumas situações em que pode haver motivos comerciais e técnicos para combinar o Google Cloud com outro provedor de nuvem e particionar as cargas de trabalho nesses ambientes de nuvem. Soluções multicloud oferecem a flexibilidade de migrar, criar e otimizar a portabilidade de aplicativos entre ambientes multicloud, minimizando a dependência e atendendo aos requisitos regulatórios. Por exemplo, talvez você conecte o Google Cloud ao Oracle Cloud Infrastructure (OCI) para criar uma solução multicloud que aproveite os recursos de cada plataforma usando uma interconexão privada do Cloud Interconnect para combinar componentes em execução no OCI com recursos em execução no Google Cloud. Para mais informações, consulte Google Cloud e Oracle Cloud Infrastructure: como aproveitar ao máximo o recurso multicloud. Além disso, o Cross-Cloud Interconnect facilita a conectividade dedicada de alta largura de banda entre o Google Cloud e outros provedores de serviços em nuvem suportados, que permitem arquitetar e criar soluções multicloud para lidar com o volume de tráfego entre nuvens.
Vantagens
A arquitetura multicloud oferece vários benefícios, de negócios e técnicos, conforme discutido em Impulsionadores, considerações, estratégias e abordagens. Ela é essencial para realizar uma avaliação de viabilidade detalhada de cada benefício potencial. Sua avaliação deve considerar cuidadosamente qualquer associação direta, desafios indiretos ou potenciais obstáculos e a capacidade de enfrentá-los de maneira eficaz. Além disso, ela considera que o crescimento a longo prazo dos aplicativos ou serviços pode introduzir complexidades que talvez superem os benefícios iniciais.
Essas são algumas das principais vantagens do padrão de arquitetura multicloud particionada:
Em cenários em que é necessário minimizar a compromisso com um único provedor de nuvem, é possível distribuir aplicativos em diferentes provedores de serviços. Como resultado, você pode reduzir relativamente a dependência de fornecedores com a capacidade de alterar planos (até certo ponto) nos provedores de nuvem. A nuvem aberta ajuda a oferecer os recursos do Google Cloud, como o GKE Enterprise, para diferentes locais físicos. Ao estender os recursos do Google Cloud no local, em várias nuvens públicas e na borda, ela oferece flexibilidade, agilidade e promove a transformação.
Por motivos regulamentares, você veicula um determinado segmento da sua base de usuários e dados de um país onde o Google Cloud ainda não tem presença.
O padrão de arquitetura multicloud particionada pode ajudar a reduzir a latência e melhorar a qualidade geral da experiência do usuário em locais em que o provedor de nuvem principal não tem um ponto de presença na região. Esse padrão é útil principalmente ao usar a conectividade multicloud de alta capacidade e baixa latência, como o Cross-Cloud Interconnect e o CDN Interconnect com uma CDN distribuída.
É possível implantar aplicativos em vários provedores de nuvem para escolher entre os melhores serviços oferecidos por outros provedores de nuvem.
O padrão de arquitetura multicloud particionada pode facilitar e acelerar cenários de fusão e aquisição, em que os aplicativos e os serviços de duas empresas podem estar hospedados em ambientes de nuvem pública diferentes.
Práticas recomendadas
- Comece implantando uma carga de trabalho não essencial. Essa implantação inicial na nuvem secundária poderá servir como padrão para futuras implantações ou migrações. No entanto, essa abordagem provavelmente não é aplicável em situações em que a carga de trabalho específica é legal ou regulatória e deve estar localizada em uma região de nuvem específica, e o provedor de nuvem principal não tem uma região no território necessário.
- Minimize dependências entre sistemas que estão sendo executados em diferentes ambientes de nuvem pública, especialmente quando a comunicação é tratada de maneira síncrona. Essas dependências podem retardar o desempenho, diminuir a disponibilidade e, possivelmente, ter cobranças adicionais de transferência de dados de saída.
- Para se abstrair das diferenças entre os ambientes, avalie o uso de contêineres e Kubernetes quando possível e se for compatível com os aplicativos.
- Verifique se os pipelines e as ferramentas de CI/CD para implantação e monitoramento são consistentes em todos os ambientes de nuvem.
- Selecione um padrão de arquitetura de rede ideal que ofereça uma
comunicação mais eficiente e eficaz para os aplicativos
que estiver usando.
- A comunicação precisa ser refinada e controlada. Use APIs seguras para expor componentes de aplicativos.
- Considere usar uma arquitetura padrão em malha ou um dos padrões de rede controlados, com base nos requisitos técnicos e comerciais específicos.
- Para atender às suas expectativas de disponibilidade e desempenho, crie um projeto com alta disponibilidade de ponta a ponta, baixa latência e níveis de capacidade de processamento apropriados.
Para proteger informações sensíveis, recomendamos criptografar todas as comunicações em trânsito.
- Se a criptografia for necessária na camada de conectividade, várias opções estão disponíveis, com base na solução de conectividade híbrida selecionada. Essas opções incluem túneis VPN, VPN de alta disponibilidade pelo Cloud Interconnect e MACsec para o Cross-Cloud Interconnect.
Se estiver usando várias CDNs como parte do padrão de arquitetura multicloud particionada e preenchendo outra CDN com arquivos de dados grandes do Google Cloud, use links do CDN Interconnect entre o Google Cloud e provedores compatíveis para otimizar esse tráfego e, potencialmente, o custo da operação.
Estenda a solução de gerenciamento de identidade entre os ambientes para que a autenticação dos sistemas possa ser feita com segurança nos limites do ambiente.
Para equilibrar efetivamente as solicitações no Google Cloud e em outras plataformas de nuvem, como o Cloud Platform, use o Cloud Load Balancing. Para mais informações, consulte Rotear o tráfego para um local físico ou outra nuvem.
- Se o volume de transferência de dados de saída do Google Cloud para outros ambientes for alto, use o Cross-Cloud Interconnect.
Para superar inconsistências em protocolos, APIs e mecanismos de autenticação em vários serviços de back-end, recomendamos, quando aplicável, implantar um gateway de API ou proxy como uma fachada unificadora. Esse gateway ou proxy atua como um ponto de controle centralizado e faz o seguinte:
- Implementa medidas de segurança adicionais.
- Protege apps clientes e outros serviços contra mudanças no código de back-end.
- Facilita trilhas de auditoria para comunicação entre todos aplicativos entre ambientes e seus componentes dissociados.
- Atua como
camada de comunicação intermediária
entre serviços legados e modernizados.
- A Apigee e a Apigee híbrida permitem hospedar e gerenciar gateways híbridos e corporativos no local, de borda, em outras nuvens e em ambientes do Google Cloud.
Em alguns dos casos a seguir, o uso do Cloud Load Balancing com um gateway de API pode fornecer uma solução robusta e segura para gerenciar, proteger e distribuir o tráfego da API em grande escala em várias regiões:
- Como implantar o failover multirregional para a execução da API Apigee em diferentes regiões.
Como melhorar a performance com o Cloud CDN.
Proteção de WAF e DDoS com o Google Cloud Armor.
Use ferramentas consistentes para geração de registros e monitoramento em ambientes na nuvem sempre que possível. Considere usar o código aberto e o monitoramento de sistemas. Para mais informações, consulte Padrões de geração de registros e monitoramento híbrido e multicloud.
Se estiver implantando componentes de aplicativo de maneira distribuída, os componentes de um único aplicativo serão implantados em mais de um ambiente. Consulte as práticas recomendadas para o padrão de arquitetura híbrida em camadas.