Este guia de arquitetura fornece orientações práticas sobre como planejar e arquitetar ambientes híbridos e multicloud usando Google Cloud. Este documento é o primeiro de três documentos. Ele examina as oportunidades e as considerações associadas a essas arquiteturas de um negócio do ponto de vista da tecnologia. Ele também analisa e discute muitos padrões comprovados de arquitetura híbrida e multicloud.
O conjunto de documentos para padrões de arquitetura híbrida e multicloud consiste nestas partes:
- Criar arquiteturas híbridas e multicloud: aborda o planejamento de uma estratégia para desenvolver uma configuração híbrida e multicloud com o Google Cloud (este artigo).
- Padrões de arquitetura híbridos e de várias nuvens: discute padrões de arquitetura comuns a serem adotados como parte de um modelo híbrido e de várias nuvens.
- Padrões de arquitetura de rede segura híbrida e multicloud: aborda padrões de arquitetura de rede híbrida e multicloud de uma perspectiva de rede de computadores.
É possível ler cada um desses artigos sobre arquitetura de forma independente, mas, para um melhor aproveitamento, recomendamos a leitura em sequência antes de decidir sobre a arquitetura.
O ritmo acelerado das mudanças nas demandas do mercado aumentou os requisitos e as expectativas estabelecidas para a TI corporativa, como escala dinâmica, aumento do desempenho para otimizar a experiência do usuário e a segurança. Muitas empresas acham difícil atender a essas demandas e expectativas usando apenas a infraestrutura e os processos tradicionais. Os departamentos de TI também se encontram sob pressão para melhorar a relação custo-benefício, sendo difícil justificar investimentos de capital adicionais em data centers e equipamentos.
A estratégia de nuvem híbrida que usa recursos de computação em nuvem pública oferece uma solução pragmática. Ao usar a nuvem pública, é possível ampliar a capacidade e os recursos das plataformas de computação sem um investimento de capital inicial.
Ao adicionar uma ou mais soluções baseadas em nuvem pública, como Google Cloud, à infraestrutura atual, você não apenas preserva os investimentos atuais, mas também evita se comprometer com um único fornecedor de nuvem. Por fim, a adoção de uma estratégia híbrida possibilita modernizar aplicativos e processos de forma incremental, conforme permitido pelos recursos.
Para planejar sua decisão de arquitetura e o planejamento de estratégia híbrida ou multicloud, existem vários desafios potenciais e considerações de design. Este guia de arquitetura com várias partes destaca os benefícios potenciais de várias arquiteturas e os desafios potenciais.
Visão geral sobre nuvem híbrida e multicloud
Como cada empresa têm cargas de trabalho, infraestrutura e processos únicos, é necessário adaptar cada estratégia de nuvem híbrida às necessidades específicas. O resultado mostra que os termos nuvem híbrida e multicloud são usados de forma inconsistente.
No contexto deste Google Cloud guia de arquitetura, o termo nuvem híbrida descreve uma arquitetura em que as cargas de trabalho são implantadas em vários ambientes de computação, um baseado na nuvem pública e pelo menos um particular, por exemplo, um data center local ou uma instalação de colocation.
O termo multicloud descreve uma arquitetura que combina no mínimo duas CSPs públicas. Conforme o diagrama a seguir, às vezes essa arquitetura inclui um ambiente de computação privado, que pode incluir o uso de um componente de nuvem privada. Ela é chamada de arquitetura híbrida e multicloud.
Colaboradores
Autor: Marwan Al Shawi | Engenheiro de clientes parceiro
Outros colaboradores:
- Saud Albazei | Engenheiro de clientes, modernização de aplicativos
- Anna Berenberg | Pesquisadora de engenharia
- Marco Ferrari | Arquiteto de soluções do Cloud
- Victor Moreno | Gerente de produtos, Cloud Networking
- Johannes Passing | Arquiteto de soluções na nuvem
- Mark Schlagenhauf | Redator técnico, Rede
- Daniel Strebel | Líder de soluções na EMEA, modernização de aplicativos
- Ammett Williams | Engenheiro de relações com desenvolvedores
Impulsionadores, considerações, estratégia e abordagens
Este documento define e discute os objetivos, os motivadores e os requisitos de negócios, além de como esses fatores podem influenciar suas decisões de design ao criar arquiteturas híbridas e multicloud.
Objetivos
Uma organização pode adotar uma arquitetura híbrida ou de várias nuvens como uma solução permanente para atender a objetivos de negócios específicos ou como um estado temporário para facilitar determinados requisitos, como uma migração para a nuvem.
Responder às perguntas a seguir sobre sua empresa é uma boa maneira de definir os requisitos de negócios e estabelecer expectativas específicas sobre como alcançar alguns ou todos os objetivos de negócios. Essas perguntas se concentram no que é necessário para sua empresa, não em como alcançar isso tecnicamente.
- Quais metas de negócios estão impulsionando a decisão de adotar uma arquitetura híbrida ou multicloud?
- Quais objetivos de negócios e técnicos uma arquitetura híbrida ou multicloud vai ajudar a alcançar?
- Quais motivadores de negócios influenciaram esses objetivos?
- Quais são os requisitos específicos de negócios?
No contexto de arquiteturas híbridas e multinuvem, um objetivo de negócios para um cliente corporativo pode ser expandir as operações de vendas on-line ou os mercados de uma única região para se tornar um dos líderes globais no segmento de mercado. Um dos objetivos de negócios pode ser começar a aceitar pedidos de compra de usuários em todo o mundo (ou de regiões específicas) em seis meses.
Para atender aos requisitos e objetivos de negócios mencionados anteriormente, um objetivo técnico principal possível é expandir a infraestrutura de TI e a arquitetura de aplicativos de uma empresa de um modelo apenas local para uma arquitetura híbrida, usando os recursos e serviços globais de nuvens públicas. Esse objetivo precisa ser específico e mensurável, definindo claramente o escopo da expansão em termos de regiões e cronogramas de destino.
Em geral, uma arquitetura híbrida ou multicloud raramente é o objetivo final. Geralmente, elas são um meio de atender a objetivos técnicos motivados por determinados requisitos de negócios. Portanto, escolher a arquitetura híbrida ou multicloud certa requer que esses requisitos sejam claros.
É importante diferenciar os objetivos de negócios e os objetivos técnicos do seu projeto de TI. Seus objetivos de negócios precisam se concentrar na meta e na missão da sua organização. Seus objetivos técnicos devem se concentrar na criação de uma base tecnológica que permita que sua organização atenda aos requisitos e objetivos de negócios.
Os fatores de negócios influenciam a realização dos objetivos e metas de negócios. Portanto, identificar claramente os fatores de negócios pode ajudar a moldar os objetivos ou metas de negócios para que sejam mais relevantes para as necessidades e tendências do mercado.
O fluxograma a seguir ilustra os fatores de negócios, metas, objetivos e requisitos, além dos objetivos e requisitos técnicos, e como todos esses fatores se relacionam:
Impulsionadores de negócios e técnicos
Considere como os motivadores de negócios influenciam seus objetivos técnicos. Alguns impulsionadores de negócios comuns e influentes ao escolher uma arquitetura híbrida incluem:
- observação das leis e regulamentos sobre soberania de dados;
- Reduzir a despesa de capital (CAPEX) ou os gastos gerais com TI com o suporte
de disciplinas de gerenciamento financeiro e otimização de custos na nuvem, como
FinOps.
- A adoção da nuvem pode ser impulsionada por cenários que ajudam a reduzir o CAPEX, como criar uma solução de recuperação de desastres em uma arquitetura híbrida ou multinuvem.
- Melhorar a experiência do usuário.
- Aumento da flexibilidade e agilidade para responder às mudanças nas demandas do mercado.
- Melhorar a transparência em relação aos custos e ao consumo de recursos.
Considere sua lista de motivadores de negócios para adotar uma arquitetura híbrida ou multicloud. Não considere os dois isoladamente. Sua decisão final depende do equilíbrio das prioridades da sua empresa.
Depois que sua organização perceber os benefícios da nuvem, ela poderá decidir fazer a migração completa se não houver restrições, como custos ou requisitos de conformidade específicos que exijam dados altamente seguros para serem hospedados localmente, que impeçam isso.
Embora a adoção de um único provedor de nuvem possa oferecer vários benefícios, como redução da complexidade, integrações integradas entre serviços e opções de otimização de custos, como descontos por uso garantido, ainda há alguns cenários em que uma arquitetura multicloud pode ser benéfica para uma empresa. Confira a seguir os impulsionadores de negócios comuns para adotar uma arquitetura multinuvem, além das considerações associadas a cada impulsionador:
- Observação das leis e regulamentos sobre soberania de dados: o cenário mais comum
é quando uma organização está expandindo seus negócios para uma nova região
ou país e precisa obedecer a novas regulamentações de hospedagem de dados.
- Se o provedor de serviços em nuvem (CSP) usado não tiver uma região de nuvem local nesse país, para fins de compliance, a solução comum é usar outro CSP que tenha uma região de nuvem local nesse país.
- Redução de custos: muitas vezes, a redução de custos é o motivador de negócios mais comum para a adoção de uma tecnologia ou arquitetura. No entanto, é importante considerar mais do que apenas o custo dos serviços e possíveis descontos de preços ao decidir se vai adotar uma arquitetura multicloud. Considere o custo de criar e operar uma solução em várias nuvens e todas as restrições de arquitetura que possam surgir dos sistemas atuais.
Às vezes, os possíveis desafios associados a uma estratégia multicloud podem ser maiores que os benefícios. Uma estratégia de várias nuvens pode gerar custos adicionais mais tarde.
Desafios comuns associados ao desenvolvimento de uma estratégia multicloud incluem:
- Aumento da complexidade de gerenciamento.
- Manter a segurança consistente.
- Integração de ambientes de software.
- Alcançar desempenho e confiabilidade consistentes entre nuvens.
- Criar uma equipe técnica com habilidades multinuvem pode ser caro e exigir a expansão da equipe, a menos que ela seja gerenciada por uma empresa terceirizada.
- Gerenciar as ferramentas de preços e gerenciamento de produtos de cada CSP.
- Sem uma solução que ofereça visibilidade e painéis de custo unificados, pode ser difícil gerenciar custos de maneira eficiente em vários ambientes. Nesses casos, você pode usar a solução de gerenciamento de custos na nuvem do Looker, quando aplicável. Para mais informações, consulte A estratégia para otimizar de forma eficaz o gerenciamento de custos do Cloud Billing.
- Usar os recursos exclusivos de cada CSP: uma arquitetura multicloud
permite que as organizações usem novas tecnologias para melhorar as
próprias ofertas de recursos comerciais sem se limitar às opções
oferecidas por um único provedor de nuvem.
- Para evitar qualquer risco ou complexidade imprevista, avalie seus possíveis desafios com uma avaliação de viabilidade e eficácia, incluindo os desafios comuns mencionados anteriormente.
- Evitar dependência de fornecedores: às vezes, as empresas querem evitar
ficar presas a um único provedor de nuvem. Uma abordagem multicloud permite que eles escolham
a melhor solução para as necessidades de negócios. No entanto, a viabilidade dessa decisão depende de vários fatores, como:
- Dependências técnicas
- Considerações sobre interoperabilidade entre aplicativos
- Custos de reconstrução ou refatoração de aplicativos
- Habilidades técnicas
- Segurança e capacidade de gerenciamento consistentes
- Melhorar o nível de confiabilidade e disponibilidade de aplicativos essenciais para os negócios: em alguns cenários, uma arquitetura multicloud pode oferecer resiliência a interrupções. Por exemplo, se uma região de um CSP ficar inativa, o tráfego poderá ser direcionado para outro CSP na mesma região. Esse cenário pressupõe que os dois provedores de nuvem ofereçam suporte aos recursos ou serviços necessários nessa região.
Quando as regulamentações de residência de dados em um país ou região específico exigem o armazenamento de dados sensíveis, como informações de identificação pessoal (PII), nesse local, uma abordagem multicloud pode oferecer uma solução em conformidade. Ao usar dois CSPs em uma região para oferecer resiliência a interrupções, você pode facilitar a conformidade com as restrições regulamentares e atender aos requisitos de disponibilidade.
Confira a seguir algumas considerações sobre resiliência que precisam ser avaliadas antes de adotar uma arquitetura multicloud:
- Movimento de dados: com que frequência os dados podem ser movidos no seu ambiente multicloud?
- O movimento de dados pode gerar cobranças significativas de transferência de dados?
- Segurança e capacidade de gerenciamento: há possíveis complexidades de segurança ou gerenciamento?
- Paridade de recursos: os dois CSPs na região selecionada oferecem os recursos e serviços necessários?
- Conjunto de habilidades técnicas: a equipe técnica tem as habilidades necessárias para gerenciar uma arquitetura multicloud?
Considere todos esses fatores ao avaliar a viabilidade de usar uma arquitetura multicloud para melhorar a resiliência.
Ao avaliar a viabilidade de uma arquitetura multicloud, é importante considerar os benefícios a longo prazo. Por exemplo, a implantação de aplicativos em várias nuvens para recuperação de desastres ou aumento da confiabilidade pode aumentar os custos a curto prazo, mas pode evitar interrupções ou falhas. Essas falhas podem causar danos financeiros e de reputação a longo prazo. Portanto, é importante considerar os custos de curto prazo em relação ao valor potencial de longo prazo da adoção de várias nuvens. Além disso, o valor potencial de longo prazo pode variar de acordo com o tamanho da organização, a escala da tecnologia, a criticidade da solução tecnológica e o setor.
As organizações que planejam criar um ambiente híbrido ou multicloud devem considerar criar um Centro de Excelência em Nuvem (COE). Uma equipe de COE pode se tornar o canal para transformar a forma como as equipes internas da sua organização atendem à empresa durante a transição para a nuvem. Um COE é uma das maneiras de sua organização adotar a nuvem mais rapidamente, impulsionar a padronização e manter um alinhamento mais forte entre a estratégia de negócios e os investimentos em nuvem.
Se o objetivo da arquitetura híbrida ou multicloud é criar um estado temporário, os impulsionadores de negócios comuns incluem:
- A necessidade de reduzir o CAPEX ou os gastos gerais com TI para projetos de curto prazo.
- A capacidade de provisionar essa infraestrutura rapidamente para
apoiar um caso de uso comercial. Por exemplo:
- Essa arquitetura pode ser usada para projetos por tempo limitado. Ele pode ser usado para oferecer suporte a um projeto que exige uma infraestrutura distribuída de grande escala em um período limitado, usando dados locais.
- A necessidade de projetos de transformação digital de vários anos que exigem que uma grande empresa estabeleça e use uma arquitetura híbrida por algum tempo para ajudar a alinhar a infraestrutura e a modernização de aplicativos com as prioridades de negócios.
- A necessidade de criar uma arquitetura híbrida, multicloud ou mista temporária após uma fusão corporativa. Isso permite que a nova organização defina uma estratégia para o estado final da nova arquitetura de nuvem. É comum que duas empresas em fusão usem provedores de nuvem diferentes ou que uma empresa use um data center privado local e a outra use a nuvem. Em qualquer caso, a primeira etapa da fusão e aquisição é quase sempre integrar os sistemas de TI.
Impulsionadores técnicos
A seção anterior discutiu os impulsionadores de negócios. Para serem aprovadas, as principais decisões de arquitetura quase sempre precisam do apoio desses drivers. No entanto, os fatores técnicos, que podem ser baseados em um ganho técnico ou em uma restrição, também podem influenciar os fatores de negócios. Em alguns cenários, é necessário traduzir os fatores técnicos em fatores de negócios e explicar como eles podem afetar positivamente ou negativamente o negócio.
A lista a seguir, não exaustiva, contém alguns fatores técnicos comuns para adotar uma arquitetura híbrida ou multicloud:
- desenvolvimento de recursos tecnológicos, como serviços de análise avançada e IA, que podem ser difíceis de implementar em ambientes atuais;
- Melhorar a qualidade e o desempenho do serviço.
- Automatização e aceleração da distribuição de aplicativos para reduzir o tempo de lançamento e do ciclo;
- Usar APIs e serviços de alto nível para acelerar o desenvolvimento.
- aceleração do provisionamento de recursos computacionais e de armazenamento.
- Usar serviços sem servidor para criar serviços e recursos elásticos de maneira mais rápida e em grande escala.
- Usar recursos de infraestrutura global para criar arquiteturas globais ou multirregionais e atender a determinados requisitos técnicos.
O fator técnico mais comum para arquiteturas híbridas temporárias e multinuvem temporárias é facilitar a migração do local para a nuvem ou para outra nuvem. Em geral, as migrações para a nuvem quase sempre levam à configuração de nuvem híbrida. As empresas geralmente precisam fazer a transição sistemática de aplicativos e dados com base nas prioridades. Da mesma forma, uma configuração de curto prazo pode ser destinada a facilitar uma prova de conceito usando tecnologias avançadas disponíveis na nuvem por um determinado período.
Decisões técnicas de design
O objetivo técnico identificado e os fatores de influência dele são essenciais para tomar uma decisão de arquitetura orientada a negócios e selecionar um dos padrões de arquitetura discutidos neste guia. Por exemplo, para apoiar uma meta de negócios específica, uma empresa pode definir um objetivo de negócios para criar uma prática de pesquisa e desenvolvimento por três a seis meses. O principal requisito de negócios para apoiar esse objetivo pode ser criar o ambiente de tecnologia necessário para pesquisa e design com o menor CAPEX possível.
O objetivo técnico, nesse caso, é ter uma configuração temporária de nuvem híbrida. O objetivo desse objetivo técnico é aproveitar o modelo de preços sob demanda da nuvem para atender ao requisito de negócios mencionado anteriormente. Outro fator é influenciado pelos requisitos de tecnologia específicos que exigem uma solução baseada na nuvem com alta capacidade de computação e configuração rápida.
Use Google Cloud para arquiteturas híbridas e de várias nuvens
O uso de soluções de código aberto pode facilitar a adoção de uma abordagem híbrida e de várias nuvens e minimizar a dependência de um único fornecedor. No entanto, considere as seguintes possíveis complexidades ao planejar uma arquitetura:
- Interoperabilidade
- Gerenciamento
- Custo
- Segurança
Criar em uma plataforma de nuvem que contribui e oferece suporte ao código aberto pode ajudar a simplificar o processo de adoção de arquiteturas híbridas e de várias nuvens. A nuvem aberta oferece uma abordagem que oferece a melhor escolha e abstrai a complexidade. Além disso, o Google Cloud oferece a flexibilidade de migrar, criar e otimizar aplicativos em ambientes híbridos e multicloud, minimizando a dependência do fornecedor, usando as melhores soluções e atendendo aos requisitos regulatórios.
O Google também é um dos maiores colaboradores do ecossistema de código aberto e trabalha com a comunidade de código aberto para desenvolver tecnologias de código aberto conhecidas, como o Kubernetes. Quando implantado como um serviço gerenciado, o Kubernetes pode ajudar a reduzir a complexidade da segurança e da capacidade de gerenciamento híbrido e multicloud.
Planejar uma estratégia híbrida e de várias nuvens
Este documento explica como aplicar considerações de negócios predefinidas ao planejar uma estratégia híbrida e multicloud. Ele expande a orientação em Drivers, considerações, estratégia e abordagens. O artigo define e analisa as considerações de negócios que as empresas devem levar em conta ao planejar essa estratégia.
Esclarecer e concordar com a visão e os objetivos
Em última análise, o principal objetivo de uma estratégia híbrida ou multicloud é atingir os requisitos de negócios identificados e os objetivos técnicos associados para cada caso de uso de negócios alinhados com objetivos de negócios específicos. Para atingir essa meta, crie um plano bem estruturado que inclua as seguintes considerações:
- Quais cargas de trabalho devem ser executadas em cada ambiente de computação.
- Quais padrões de arquitetura de aplicativo aplicar em várias cargas de trabalho.
- Qual tecnologia e padrão de arquitetura de rede usar.
Definir um plano que considere todas as cargas de trabalho e requisitos é difícil, em especial em um ambiente de TI complexo. Além disso, o planejamento é demorado e pode resultar em conflitos de interesses entre as partes envolvidas.
Para evitar essas situações, formule de início uma declaração de visão que aborde as seguintes questões (no mínimo):
- Qual é o caso de uso de negócios adequado para atender a objetivos de negócios específicos?
- Por que a abordagem e o ambiente de computação atuais são insuficientes para atender aos objetivos de negócios?
- Quais são os principais aspectos tecnológicos a serem otimizados usando a nuvem pública?
- Por que e como a nova abordagem vai otimizar e atender aos seus objetivos de negócios?
- Por quanto tempo você planeja usar sua configuração híbrida ou multicloud?
Concordar com os principais objetivos e motivadores comerciais e técnicos e obter a aprovação das partes interessadas relevantes pode fornecer uma base para as próximas etapas do processo de planejamento. Para alinhar efetivamente a solução proposta com a visão de arquitetura abrangente da organização, trabalhe com sua equipe e as partes interessadas responsáveis por liderar e patrocinar a iniciativa.
Identificar e esclarecer outras considerações
Ao planejar uma arquitetura híbrida ou multicloud, é importante identificar e estabelecer concordância sobre as restrições arquitetônicas e operacionais do projeto.
Do ponto de vista das operações, a seguinte lista não abrangente fornece alguns requisitos que podem criar algumas restrições a serem consideradas ao planejar a arquitetura:
- Gerenciar e configurar várias nuvens separadamente em comparação com criar um modelo abrangente para gerenciar e proteger os diferentes ambientes de nuvem.
- Garantia de que a autenticação, a autorização, a auditoria e as políticas sejam consistentes nos diferentes ambientes.
- Usar ferramentas e processos consistentes em todos os ambientes para fornecer uma visão abrangente da segurança, dos custos e das oportunidades de otimização.
- Usar padrões consistentes de conformidade e segurança para aplicar uma governança unificada.
Do ponto de vista da arquitetura, os sistemas atuais geralmente causam as maiores restrições, que podem incluir:
- dependências entre aplicativos;
- requisitos de desempenho e latência para comunicação entre sistemas;
- dependência de hardware ou sistemas operacionais não disponíveis na nuvem pública.
- Restrições de licenciamento
- Dependência da disponibilidade dos recursos necessários nas regiões selecionadas de uma arquitetura multicloud
Para mais informações sobre outras considerações relacionadas à portabilidade das cargas de trabalho, à movimentação de dados e aos aspectos de segurança, consulte Outras considerações.
Projetar uma estratégia de arquitetura híbrida e multicloud
Depois de esclarecer as especificidades dos objetivos de negócios e técnicos com os requisitos de negócios associados (e, idealmente, esclarecer e estabelecer concordância sobre uma declaração de visão), é possível criar a estratégia para elaborar uma arquitetura híbrida ou multicloud.
O fluxograma a seguir resume as etapas lógicas para criar essa estratégia.
Para ajudar a determinar os objetivos e as necessidades técnicas da arquitetura híbrida ou multicloud, as etapas no fluxograma anterior começam com os requisitos e objetivos de negócios. A maneira como você implementa sua estratégia pode variar de acordo com os objetivos, motivadores e o caminho de migração tecnológica de cada caso de uso de negócios.
É importante lembrar que a migração é uma jornada. O diagrama a seguir ilustra as etapas dessa jornada, conforme descrito em Migrar para o Google Cloud.
Esta seção fornece orientação sobre as etapas "Avaliação", "Planejamento", "Implantação" e "Otimização" no diagrama anterior. Ele apresenta essas informações no contexto de uma migração híbrida ou multicloud. Alinhe qualquer migração com as orientações e práticas recomendadas discutidas na seção do caminho de migração do guia "Migrar para Google Cloud ". Essas etapas podem ser aplicadas a cada carga de trabalho individualmente, não a todas de uma vez. A qualquer momento, várias cargas de trabalho podem estar em etapas diferentes:
Etapa de avaliação
Na etapa de avaliação, você realiza uma avaliação inicial da carga de trabalho. Durante esta etapa, considere as metas descritas nos seus documentos de planejamento de visão e estratégia. Decida sobre um plano de migração identificando primeiro uma lista de cargas de trabalho candidatas que podem se beneficiar da implantação ou migração para a nuvem pública.
Para começar, escolha uma carga de trabalho que não seja crítica para os negócios ou muito difícil de migrar (com pouca ou nenhuma dependência de qualquer carga de trabalho em outros ambientes), mas que seja comum o suficiente para servir como um modelo para futuras implantações ou migrações.
Idealmente, a carga de trabalho ou aplicativo selecionado deve fazer parte de um caso de uso de negócios ou função que tenha um efeito mensurável nos negócios após a conclusão.
Para avaliar e mitigar quaisquer riscos potenciais de migração, conduza uma avaliação de riscos de migração, porque é importante avaliar a carga de trabalho candidata a fim de determinar a adequação dela para a migração para um ambiente multicloud. Essa avaliação envolve a análise de vários aspectos dos aplicativos e da infraestrutura, incluindo o seguinte:
- Requisitos de compatibilidade dos aplicativos com os provedores de nuvem selecionados
- Modelos de preços
- Recursos de segurança oferecidos pelos provedores de nuvem selecionados
- Requisitos de interoperabilidade dos aplicativos
Executar uma avaliação também ajuda a identificar requisitos de privacidade de dados, requisitos de compliance, requisitos de consistência e soluções em vários ambientes de nuvem. Os riscos identificados podem afetar as cargas de trabalho que você escolhe migrar ou operar.
Há vários tipos de ferramentas, como o Google Cloud Migration Center, para ajudar a avaliar as cargas de trabalho atuais. Para mais informações, consulte Migração para o Google Cloud: escolha uma ferramenta de avaliação.
De uma perspectiva de modernização de carga de trabalho, a ferramenta de avaliação de adequação ajuda a avaliar uma carga de trabalho de VM para determinar se ela é adequada para modernização em um contêiner ou para a migração para o Compute Engine.
Etapa de planejamento
Na etapa de planejamento, comece com os aplicativos identificados e as cargas de trabalho de nuvem necessárias e execute as seguintes tarefas:
- Desenvolva uma estratégia de migração priorizada que defina caminhos e ondas de migração de aplicativos.
- Identifique o padrão de arquitetura de aplicativo híbrido ou multicloud de alto nível aplicável.
- Selecione um padrão de arquitetura de rede que dê suporte ao padrão de arquitetura de aplicativo selecionado.
O ideal é incorporar o padrão de rede em nuvem ao design da zona de destino. O design da zona de destino serve como um elemento fundamental das arquiteturas híbridas e multicloud em geral. Esse design requer integração adequada com os padrões. Não projete a zona de destino de modo isolado. Considere esses padrões de rede como um subconjunto do design da zona de destino.
Uma zona de destino pode consistir em diferentes aplicativos, cada um com um padrão de arquitetura de rede diferente. Além disso, nesta fase, é importante decidir sobre o design da Google Cloud organização, projetos e hierarquia de recursos para preparar a zona de destino do ambiente de nuvem para a integração e a implantação híbrida ou multicloud.
Como parte dessa etapa, você precisa considerar o seguinte:
- Defina a abordagem de migração e modernização. Há mais informações sobre abordagens de migração posteriormente neste guia. Isso também é abordado com mais detalhes na seção tipos de migração de Migrar para o Google Cloud.
- Use as descobertas da etapa de avaliação e descoberta. Alinhe-as com a carga de trabalho candidata que você planeja migrar. Em seguida, desenvolva um plano de ondas de migração de aplicativos. O plano deve incorporar os requisitos estimados de dimensionamento de recursos que você determinou durante a etapa de avaliação.
- Defina o modelo de comunicação necessário entre os aplicativos distribuídos e entre os componentes dos aplicativos para a arquitetura híbrida ou multicloud pretendida.
- Decida um arquétipo de implantação adequado para implantar a carga de trabalho, como zonal, regional, multirregional ou global, para o padrão de arquitetura escolhido. O arquétipo selecionado forma a base para a criação das arquiteturas de implantação específicas do aplicativo, adaptadas às suas necessidades de negócios e técnicas.
- Decida critérios de sucesso mensuráveis para a migração, com marcos claros para cada etapa ou onda de migração. Selecionar critérios é essencial, mesmo que o objetivo técnico seja ter a arquitetura híbrida como uma configuração de curto prazo.
- Defina SLAs e KPIs de aplicativo quando os aplicativos operarem em uma configuração híbrida, em especial para aqueles que podem ter componentes distribuídos em vários ambientes.
Consulte Sobre o planejamento da migração para mais informações sobre como planejar uma migração de sucesso e minimizar os riscos associados.
Etapa de implantação
Na etapa de implantação, tudo está pronto para começar a executar a estratégia de migração. Dado o número potencial de requisitos, é melhor adotar uma abordagem iterativa.
Priorize as cargas de trabalho com base nas ondas de migração e aplicativos que você desenvolveu durante a etapa de planejamento. Com arquiteturas híbridas e multicloud, inicie a implantação estabelecendo a conectividade necessária entre o Google Cloud e os outros ambientes de computação. Para facilitar o modelo de comunicação necessário para a arquitetura híbrida ou multicloud, baseie a implantação no design e no tipo de conectividade de rede selecionados, além de no padrão de rede aplicável. Recomendamos adotar essa abordagem para a decisão geral de design de zona de destino.
Além disso, teste e valide o aplicativo ou serviço com base nos critérios de sucesso do aplicativo definidos. O ideal é que esses critérios incluam requisitos de teste funcional e de carga (não funcional) antes de passar para a produção.
Etapa de otimização
Na etapa de otimização, teste a implantação: depois de concluir o teste e o aplicativo ou serviço atender às expectativas de capacidade funcional e de desempenho, é possível movê-lo para a produção. Ferramentas de monitoramento e visibilidade de nuvem, como o Cloud Monitoring, podem fornecer insights sobre o desempenho, a disponibilidade e a integridade dos aplicativos e da infraestrutura e ajudar você a otimizar o que for necessário.
Para mais informações, consulte Migrar para o Google Cloud: otimizar o ambiente. Para saber como projetar essas ferramentas para arquiteturas híbridas ou multicloud, consulte Padrões híbridos e multicloud de monitoramento e geração de registros.
Avaliar as cargas de trabalho candidatas
A escolha de ambientes de computação para diferentes cargas de trabalho afeta significativamente o sucesso de uma estratégia híbrida e multicloud. As decisões de posicionamento de carga de trabalho devem estar alinhadas com objetivos de negócios específicos. Portanto, essas decisões devem ser baseadas em casos de uso de negócios adequados que permitam efeitos de negócios mensuráveis. No entanto, começar com a carga de trabalho/aplicativo mais crítico para os negócios nem sempre é necessário ou recomendado. Para mais informações, consulte Como escolher os aplicativos para migrar primeiro no guia "Migrar para o Google Cloud ".
Conforme discutido na seção Motivadores de negócios e técnicos, há diferentes tipos de motivadores e considerações para arquiteturas híbridas e multicloud.
A seguinte lista resumida de fatores pode ajudar você a avaliar o caso de uso de migração no contexto de uma arquitetura híbrida ou multicloud com oportunidades de ter um efeito de negócios mensurável:
- Potencial para diferenciação de mercado ou inovação que é possível devido ao uso de serviços de nuvem para ativar certas funções ou recursos de negócios, como a capacidades de inteligência artificial que usam dados locais para treinar modelos de machine learning.
- Potencial para economizar no custo total de propriedade de um aplicativo.
- Potencial para melhorias em disponibilidade, resiliência, segurança ou desempenho, por exemplo, ao adicionar um site de recuperação de desastres (DR) na nuvem.
- Potencial de aceleração dos processos de desenvolvimento e lançamento, por exemplo, ao criar os ambientes de desenvolvimento e teste na nuvem.
Os seguintes fatores podem ajudar você a avaliar os riscos de migração:
- O efeito potencial de interrupções causadas por uma migração.
- A experiência que sua equipe tem com implantações de nuvem pública ou com implantações para um novo ou segundo provedor de nuvem.
- Necessidade de obedecer a todas as restrições legais ou regulatórias em vigor.
Os seguintes fatores podem ajudar você a avaliar as dificuldades técnicas de uma migração:
- Tamanho, complexidade e idade do aplicativo.
- O número de dependências com outros aplicativos e serviços em diferentes ambientes de computação.
- Quaisquer restrições impostas por licenças de terceiros.
- Dependências de versões específicas de sistemas operacionais, bancos de dados ou outras configurações do ambiente.
Depois de avaliar as cargas de trabalho iniciais, você pode começar a priorizá-las e definir suas abordagens e ondas de migração. Em seguida, é possível identificar padrões de arquitetura aplicáveis e padrões de rede de suporte. Esta etapa pode exigir várias iterações, porque a avaliação pode mudar ao longo do tempo. Portanto, vale a pena reavaliar as cargas de trabalho depois de fazer as primeiras implantações na nuvem.
Abordagens de arquitetura para adotar uma arquitetura híbrida ou de várias nuvens
Este documento fornece orientações sobre abordagens comuns e comprovadas e considerações para migrar sua carga de trabalho para a nuvem. Ele amplia as orientações em Projetar uma estratégia de arquitetura híbrida e multicloud, que discute várias etapas possíveis e recomendadas para projetar uma estratégia de adoção de uma arquitetura híbrida ou multicloud.
Priorização da nuvem
Uma maneira comum de começar a usar a nuvem pública é adotar a abordagem de priorização da nuvem. Nessa abordagem, você implanta as novas cargas de trabalho na nuvem pública, enquanto as cargas de trabalho atuais permanecem onde estão. Nesse caso, pense na implantação clássica em um ambiente computacional particular somente se a implantação na nuvem pública for impossível por motivos técnicos ou organizacionais.
A estratégia de priorização da nuvem tem vantagens e desvantagens. Como ponto positivo, ela é voltada para o futuro. É possível implantar novas cargas de trabalho de maneira moderna, evitando (ou pelo menos minimizando) as dificuldades de migrar as cargas de trabalho atuais.
Embora uma abordagem de priorização da nuvem possa oferecer algumas vantagens, ela pode resultar em oportunidades perdidas de melhorar ou usar cargas de trabalho existentes. As novas cargas de trabalho podem representar uma fração do cenário geral de TI, e o efeito delas nas despesas e no desempenho de TI pode ser limitado. A alocação de tempo e recursos para migrar uma carga de trabalho atual pode gerar benefícios ou economias de custo mais substanciais em comparação com a tentativa de acomodar uma nova carga de trabalho no ambiente de nuvem.
Seguir uma abordagem rígida de priorização da nuvem também implica o risco de aumentar a complexidade geral do seu ambiente de TI. Essa abordagem pode criar redundâncias, reduzir o desempenho devido à possível comunicação excessiva entre ambientes ou resultar em um ambiente de computação inadequado para a carga de trabalho individual. Além disso, o compliance com regulamentações do setor e leis de privacidade de dados pode restringir a migração de determinados aplicativos que contêm dados sensíveis.
Levando todos esses riscos em consideração, talvez seja melhor usar uma abordagem de priorização da nuvem somente para cargas de trabalho específicas. Usar uma abordagem que prioriza a nuvem permite que você se concentre nas cargas de trabalho que podem se beneficiar mais de uma implantação ou migração na nuvem. Essa abordagem também considera a modernização das cargas de trabalho atuais.
Um exemplo comum de arquitetura híbrida de nuvem é quando aplicativos e serviços legados que armazenam dados críticos precisam ser integrados a novos dados ou aplicativos. Para concluir a integração, use uma arquitetura híbrida que modernize os serviços legados usando interfaces de API, o que os desbloqueia para consumo por novos serviços e aplicativos em nuvem. Com uma plataforma de gerenciamento de API na nuvem, como a Apigee, é possível implementar esses casos de uso com mudanças mínimas no aplicativo e adicionar segurança, análise e escalonabilidade aos serviços legados.
Migração e modernização
A nuvem híbrida e a modernização de TI são conceitos distintos, mas conectados em um círculo virtuoso. Usar a nuvem pública pode facilitar e simplificar a modernização das cargas de trabalho de TI. A modernização das cargas de trabalho de TI pode ajudar você a aproveitar melhor a nuvem.
Os principais objetivos de modernizar as cargas de trabalho são:
- ter mais agilidade para se adaptar às mudanças nos requisitos;
- Reduzir os custos de infraestrutura e operações.
- Aumente a confiabilidade e a resiliência para minimizar o risco.
No entanto, talvez não seja viável modernizar todos os aplicativos no processo de migração ao mesmo tempo. Conforme descrito em Migração para Google Cloud, é possível implementar um dos seguintes tipos de migração ou até mesmo combinar vários tipos conforme necessário:
- Re-hospedagem (migração lift-and-shift)
- Reformulação de plataforma (migração lift-and-optimize)
- Refatoração (mover e melhorar)
- Reestruturar (continuar a modernizar)
- Recriar (remover e substituir, às vezes chamado de rip-and-replace)
- Recompra
Ao tomar decisões estratégicas sobre arquiteturas híbridas e multicloud, é importante considerar a viabilidade da estratégia em termos de custo e tempo. Considere uma abordagem de migração por fases, começando com lift-and-shift ou troca de plataforma e, em seguida, refatoração ou reengenharia como a próxima etapa. Normalmente, o lifting and shifting ajuda a otimizar aplicativos do ponto de vista da infraestrutura. Depois que os aplicativos são executados na nuvem, fica mais fácil usar e integrar serviços de nuvem para otimizar ainda mais usando arquiteturas e recursos de nuvem. Além disso, esses aplicativos ainda podem se comunicar com outros ambientes por uma conexão de rede híbrida.
Por exemplo, é possível refatorar ou reprojetar um aplicativo grande e monolítico baseado em VM e transformá-lo em vários microsserviços independentes, com base em uma arquitetura de microsserviço baseada na nuvem. Neste exemplo, a arquitetura de microsserviços usa Google Cloud serviços de contêineres gerenciados, como o Google Kubernetes Engine (GKE) ou o Cloud Run. No entanto, se a arquitetura ou a infraestrutura de um aplicativo não for compatível com o ambiente de destino da nuvem, considere começar com a replataformação, refatoração ou reengenharia da estratégia de migração para superar essas restrições, quando possível.
Ao usar qualquer uma dessas abordagens de migração, considere modernizar seus aplicativos (quando aplicável e viável). A modernização pode exigir a adoção e implementação da engenharia de confiabilidade do site (SRE) ou dos princípios de DevOps. Assim, talvez seja necessário estender a modernização do aplicativo para seu ambiente particular em uma configuração híbrida. Embora a implementação dos princípios de SRE envolva engenharia, é mais um processo de transformação do que um desafio técnico. Por isso, provavelmente vai exigir mudanças procedimentais e culturais. Para saber mais sobre como a primeira etapa da implementação de SRE em uma organização é conseguir o apoio da liderança, consulte Com SRE, não planejar é planejar para falhar.
Combinar abordagens de migração
Cada abordagem de migração discutida aqui tem pontos fortes e fracos. Uma das principais vantagens de seguir uma estratégia de nuvem híbrida e de várias nuvens é que você não precisa escolher uma única abordagem. Em vez disso, é você que decide qual delas funciona melhor para cada carga de trabalho ou pilha de aplicativos, conforme mostrado no diagrama abaixo.
Este diagrama conceitual ilustra os vários caminhos ou abordagens de migração e modernização que podem ser aplicados simultaneamente a diferentes cargas de trabalho, dirigidos pelos requisitos comerciais, técnicos e objetivos exclusivos de cada carga de trabalho ou aplicativo.
Além disso, não é necessário que os mesmos componentes da pilha de aplicativos sigam a mesma abordagem ou estratégia de migração. Exemplo:
- O banco de dados local de back-end de um aplicativo pode ser reimplementado de MySQL auto-hospedado para um banco de dados gerenciado usando o Cloud SQL em Google Cloud.
- As máquinas virtuais do front-end do aplicativo podem ser refatoradas para serem executadas em contêineres usando o Autopilot do GKE, em que o Google gerencia a configuração do cluster, incluindo nós, escalonamento, segurança e outras configurações predefinidas.
- A solução de balanceamento de carga de hardware local e os recursos do WAF do firewall do aplicativo da Web podem ser substituídos pelo Cloud Load Balancing e pelo Google Cloud Armor.
Escolha a rehost (lift-and-shift) se uma das seguintes condições for verdadeira para as cargas de trabalho:
- A carga de trabalho tem um número relativamente pequeno de dependências no ambiente.
- Não vale a pena refatorar essas cargas de trabalho, ou refatorar antes da migração não é viável.
- A carga de trabalho é baseada em software de terceiros.
Considere refatorar (mover e melhorar) para estes tipos de carga de trabalho:
- A carga de trabalho tem dependências que precisam ser desatadas.
- A carga de trabalho depende de sistemas operacionais, de hardware ou de banco de dados que não podem ser ajustados para a nuvem.
- A carga de trabalho não faz um uso eficiente dos recursos computacionais ou de armazenamento.
- Não é possível implantar de forma automatizada sem algum esforço.
Considere se a recriação (remover e substituir) atende às suas necessidades para estes tipos de cargas de trabalho:
- A carga de trabalho não satisfaz mais aos requisitos atuais.
- Eles podem ser incorporados a outros aplicativos que oferecem recursos semelhantes sem comprometer os requisitos de negócios.
- A carga de trabalho é baseada em tecnologia de terceiros que chegou ao fim da vida útil.
- A carga de trabalho exige taxa de licenciamento de terceiros que não são mais econômicas.
O Programa de migração rápida mostra como Google Cloud ajuda os clientes a usar as práticas recomendadas, reduzir riscos, controlar custos e simplificar o caminho para o sucesso na nuvem.
Outras considerações
Este documento destaca as principais considerações de design que desempenham um papel fundamental na elaboração da arquitetura híbrida e multicloud. Analise e avalie de forma holística essas considerações em toda sua solução do BigQuery, englobando todas as cargas de trabalho, não apenas algumas específicas.
Refatorar
Em uma migração de refatoração, você modifica as cargas de trabalho para aproveitar as capacidades da nuvem, não apenas para fazê-las funcionar no novo ambiente. É possível aprimorar o desempenho, os recursos, o custo e a experiência do usuário para cada carga de trabalho. Como destacado em Refatorar: mover e melhorar, alguns cenários de refatoração permitem modificar as cargas de trabalho antes da migração para a nuvem. Essa abordagem de refatoração oferece os benefícios a seguir, especialmente se a meta for criar uma arquitetura híbrida de longo prazo direcionada:
- Melhoria do processo de implantação
- Você pode acelerar a cadência de lançamento e encurtar os ciclos de feedback investindo em ferramentas e infraestrutura de integração/implantação contínuas (CI/CD).
- É possível usar a refatoração como base para criar e gerenciar modelos de arquitetura híbrida com portabilidade de aplicativos.
Para funcionar bem, essa abordagem geralmente requer certos investimentos em infraestrutura e ferramentas no local. Por exemplo, configurar um Container Registry local e provisionar os clusters do Kubernetes para conteinerizar os aplicativos. A edição do Google Kubernetes Engine (GKE) Enterprise pode ser útil nesta abordagem para ambientes híbridos. Confira na seção a seguir mais informações sobre o GKE Enterprise. Você também pode consultar a arquitetura de referência de ambiente híbrido do GKE Enterprise para mais informações.
Portabilidade de cargas de trabalho
Com arquiteturas híbridas e multicloud, talvez você queira transferir cargas de trabalho entre os ambientes computacionais que hospedam os dados. Para ativar a movimentação perfeita de cargas de trabalho entre ambientes, considere os seguintes fatores:
- Mova um aplicativo de um ambiente computacional para outro
sem modificar significativamente o aplicativo e o modelo operacional:
- A implantação e o gerenciamento de aplicativos são consistentes em ambientes computacionais.
- Visibilidade, configuração e segurança são consistentes em ambientes computacionais.
- A capacidade de tornar uma carga de trabalho portátil não deve entrar em conflito com a carga de trabalho com priorização da nuvem.
Automação da infraestrutura
A automação da infraestrutura é essencial para a portabilidade em arquiteturas híbridas e multicloud. Uma abordagem comum para automatizar a criação de infraestrutura é usar a infraestrutura como código (IaC, na sigla em inglês). A IaC envolve gerenciar a infraestrutura em arquivos em vez de configurar manualmente os recursos, como uma VM, um grupo de segurança ou um balanceador de carga, em uma interface do usuário. O Terraform é uma ferramenta de IaC conhecida para definir recursos de infraestrutura em um arquivo. O Terraform também permite automatizar a criação desses recursos em ambientes heterogêneos.
Para mais informações sobre as funções principais do Terraform que podem ajudar você a automatizar o provisionamento e o gerenciamento de recursos Google Cloud , consulte Modelos e módulos do Terraform para Google Cloud.
Além disso, use ferramentas de gerenciamento de configuração, como Ansible, Puppet ou Chef para estabelecer um processo comum de implantação e configuração. Se preferir, use uma ferramenta de preparação de imagens, como o Packer, para criar imagens de VM para plataformas diferentes. Ao usar um único arquivo de configuração do Terraform, use o Packer e o Cloud Build para criar uma imagem de VM para uso no Compute Engine. Por fim, use soluções como o Prometheus e o Grafana para garantir o monitoramento consistente nos vários ambientes.
Com base nessas ferramentas, é possível montar uma cadeia de ferramentas comum semelhante à ilustrada no diagrama abaixo. Essa cadeia de ferramentas comum abstrai as diferenças entre os ambientes computacionais. Ele também permite unificar o provisionamento, a implantação o gerenciamento e o monitoramento.
Embora uma cadeia de ferramentas comum possa ajudar a alcançar a portabilidade, ela está sujeita a várias das seguintes limitações:
- O uso de VMs como base comum pode dificultar a implementação de aplicativos com a priorização da nuvem verdadeira. Além disso, o uso de VMs só impede que você use os serviços gerenciados na nuvem. Você pode perder oportunidades de reduzir o overhead administrativo.
- Criar e manter uma cadeia de ferramentas comum incorre gera overhead e custos operacionais.
- À medida que a cadeia de ferramentas se expande, ela pode desenvolver complexidades únicas para as necessidades específicas da sua empresa. Esse aumento da complexidade pode contribuir para o aumento dos custos de treinamento.
Antes de desenvolver ferramentas e automação, conheça os serviços gerenciados oferecidos pelo seu provedor de nuvem. Quando o provedor oferece serviços gerenciados que oferecem suporte ao mesmo caso de uso, é possível abstrair parte da complexidade dele. Isso permite que você se concentre na carga de trabalho e na arquitetura do aplicativo, em vez da infraestrutura subjacente.
Por exemplo, é possível usar um Modelo de recursos do Kubernetes para automatizar a criação de clusters do Kubernetes usando um abordagem de configuração. É possível usar a Conversão do Deployment Manager para converter as configurações e os modelos do Deployment Manager em outros formatos de configuração declarativa compatíveis com o Google Cloud (como o Terraform e o modelo de recursos do Kubernetes) para que eles sejam portáteis ao serem publicados.
Também é possível automatizar a criação de projetos e de recursos dentro deles. Essa automação pode ajudar você a adotar uma abordagem de infraestrutura como código para o provisionamento de projetos.
Contêineres e Kubernetes
Usar recursos gerenciados na nuvem ajuda a reduzir a complexidade de criar e manter uma cadeia de ferramentas personalizada para alcançar a automação e a portabilidade da carga de trabalho. No entanto, usar as VMs como base comum dificulta a implementação de aplicativos que verdadeiramente priorizam a nuvem. Uma outra solução é utilizar contêineres e o Kubernetes.
Com os contêineres, seu software continua funcionando de maneira confiável mesmo depois de migrá-lo de um ambiente para outro. Como os contêineres separam os aplicativos da infraestrutura do host subjacente, eles facilitam a implantação em vários ambientes, como híbrido e multicloud.
O Kubernetes lida com a orquestração, a implantação, o escalonamento e o gerenciamento dos aplicativos conteinerizados. Ele tem código aberto e é regido pelo Cloud Native Computing Foundation: O uso do Kubernetes fornece os serviços que formam a base de um aplicativo de priorização da nuvem. Por ser possível instalar e executar o Kubernetes em uma variedade de ambientes computacionais, também é possível usá-lo para estabelecer uma camada de ambiente de execução comum nos diferentes ambientes computacionais:
- O Kubernetes fornece os mesmos serviços e APIs para o ambiente computacional particular ou em nuvem. Além disso, o nível de abstração é muito maior do que o proporcionado pelas VMs. Na maioria das vezes, isso se traduz em menos trabalho de preparação e maior produtividade do desenvolvedor.
- Ao contrário de uma cadeia de ferramentas personalizada, o Kubernetes é amplamente adotado para o desenvolvimento e o gerenciamento de aplicativos. Dessa forma, é possível aproveitar o conhecimento especializado, a documentação e o suporte de terceiros que você já tem.
- O Kubernetes oferece suporte a todas as implementações de contêiner que:
- Oferecem suporte ao Container Runtime Interface (CRI)do Kubernetes
- São adotadas pelo setor de aplicativos
- Não estão vinculadas a um fornecedor específico
Quando uma carga de trabalho está em execução no Google Cloud, é possível evitar o esforço de instalar e operar o Kubernetes usando uma plataforma gerenciada do Kubernetes, como o Google Kubernetes Engine (GKE). Isso pode ajudar a equipe de operações a mudar o foco da criação e manutenção da infraestrutura para a criação e manutenção de aplicativos.
Você também pode usar o Autopilot, um modo de operação do GKE que gerencia a configuração do cluster, incluindo nós, escalonamento, segurança e outras configurações pré-configuradas. Ao usar o Autopilot do GKE, considere os requisitos de escalonamento e os limites de escalonamento.
Tecnicamente, é possível instalar e executar o Kubernetes em muitos ambientes computacionais para estabelecer uma camada de ambiente de execução comum. Na prática, criar e operar essa arquitetura pode aumentar a complexidade. A arquitetura fica mais complexa quando é preciso ter controle de segurança no nível do contêiner ( malha de serviço).
Para simplificar o gerenciamento de implantações de vários clusters, use o GKE Enterprise para executar aplicativos modernos em qualquer lugar e em escala. O GKE inclui componentes avançados de código aberto gerenciados para proteger cargas de trabalho, aplicar políticas de compliance, além de oferecer a observabilidade e a solução de problemas de rede profunda.
Conforme ilustrado no diagrama a seguir, usar o GKE Enterprise significa que é possível operar aplicativos de vários clusters como frotas.
O GKE Enterprise ajuda com as seguintes opções de design para oferecer suporte a arquiteturas híbridas e multicloud:
Projete e crie experiências semelhantes à nuvem, no local ou soluções unificadas para a transição de aplicativos para o ambiente híbrido do GKE Enterprise. Para mais informações, consulte a Arquitetura de referência do ambiente híbrido do GKE Enterprise.
Projete e crie uma solução para resolver a complexidade multicloud com governança, operações e postura de segurança consistentes com o GKE Multi-cloud. Para mais informações, consulte a documentação do GKE Multi-cloud.
O GKE Enterprise também oferece agrupamentos lógicos de ambientes semelhantes, com segurança, configuração e gerenciamento de serviços consistentes. Por exemplo, o GKE Enterprise possibilita uma arquitetura distribuída de confiança zero. Em uma arquitetura distribuída de confiança zero, os serviços implantados no local ou em outro ambiente de nuvem podem se comunicar entre ambientes com comunicações seguras de serviços completas do mTLS.
Considerações sobre a portabilidade da carga de trabalho
O Kubernetes e o GKE Enterprise oferecem uma camada de abstração para cargas de trabalho que pode ocultar as muitas complexidades e diferenças entre os ambientes computacionais. A lista a seguir descreve algumas dessas abstrações:
- Um aplicativo pode ser portável para um ambiente diferente com
alterações mínimas, mas isso não significa que ele terá um bom funcionamento nos dois ambientes.
- Diferenças na computação subjacente, nos recursos de segurança da infraestrutura ou na infraestrutura de rede, assim como a proximidade a serviços dependentes, podem levar a um desempenho substancialmente diferente.
- A migração da carga de trabalho entre ambientes computacionais também pode exigir a migração dos dados.
- Diferentes ambientes podem ter diferentes tipos de armazenamento e de gerenciamento de projetos e instalações.
- O comportamento e o desempenho dos balanceadores de carga provisionados com o Kubernetes ou o GKE Enterprise podem variar entre os ambientes.
Movimentação de dados
Como pode ser complexo mover, compartilhar e acessar dados em escala entre ambientes computacionais, as empresas podem hesitar em criar uma arquitetura híbrida ou multicloud. Essa hesitação pode aumentar se eles já estiverem armazenando a maior parte dos dados no local ou em uma nuvem.
No entanto, as várias opções de movimentação de dados oferecidas pelo Google Cloudoferecem às empresas um conjunto abrangente de soluções para mover, integrar e transformar os dados. Essas opções ajudam as empresas a armazenarem, compartilharem e acessarem dados em diferentes ambientes de uma maneira que atenda aos casos de uso específicos. Por fim, essa capacidade torna mais fácil para os tomadores de decisões empresariais e tecnológicas adotarem arquiteturas híbridas e multicloud.
A movimentação de dados é uma consideração importante para estratégias de planejamento de arquitetura híbridas e multicloud. Sua equipe precisa identificar os diferentes casos de uso de negócios e os dados que os alimentam. Considere também as opções de armazenamento tipo, capacidade, acessibilidade e movimento.
Se uma empresa tem uma classificação de dados para setores regulamentados, a classificação pode ajudar a identificar locais de armazenamento e restrições de movimentação de dados entre regiões para determinadas classes de dados. Para mais informações, consulte a Proteção de Dados Sensíveis A proteção de dados sensíveis é um serviço totalmente gerenciado projetado para ajudar você a descobrir, classificar e proteger os recursos de dados.
Para conhecer o processo, desde o planejamento de uma transferência de dados até o uso das práticas recomendadas na implementação de um plano, consulte Migração para o Google Cloud: como transferir conjuntos de dados grandes.
Segurança
À medida que as organizações adotam arquiteturas híbridas e multicloud, a superfície de ataque pode aumentar, dependendo da forma como os sistemas e dados são distribuídos em ambientes diferentes. Combinado com o cenário de ameaças em constante evolução, o aumento das superfícies de ataque pode levar a um risco maior de acesso não autorizado, perda de dados e outros incidentes de segurança. Considere com cuidado a segurança ao planejar e implementar estratégias híbridas ou multicloud.
Para mais informações, consulte Gerenciamento de superfície de ataque do Google Cloud.
Ao criar uma arquitetura híbrida, nem sempre é tecnicamente viável estender as abordagens de segurança do local para a nuvem. No entanto, a maioria dos recursos de segurança de rede de dispositivos de hardware priorizam a nuvem e operam de maneira distribuída. Para mais informações sobre os recursos de segurança de rede com priorização da nuvem do Google Cloud, consulte Segurança de rede na nuvem.
Arquiteturas híbridas e multicloud podem aumentar a comprovação de segurança adicional, como consistência e observabilidade. Todos os provedores de nuvem pública tem sua abordagem de segurança, incluindo diferentes modelos, práticas recomendadas, recursos de segurança de aplicativos e infraestrutura, obrigações de compliance, e até mesmo nomes dos serviços de segurança. Essas inconsistências podem aumentar os riscos de segurança. Além disso, o modelo de responsabilidade compartilhada de cada provedor de nuvem pode ser diferente. É essencial identificar e entender a demarcação exata de responsabilidades em uma arquitetura multicloud.
A observabilidade é fundamental para obter insights e métricas de diferentes ambientes. Em uma arquitetura multicloud, cada nuvem geralmente fornece ferramentas para monitorar a postura de segurança e as configurações incorretas. No entanto, o uso dessas ferramentas resulta em visibilidade isolada, o que impede a criação de uma inteligência sobre ameaças avançada em todo o ambiente. Por isso, a equipe de segurança precisa alternar entre ferramentas e painéis para manter a nuvem segura. Sem uma visibilidade de segurança de ponta a ponta abrangente para os ambientes híbridos e multicloud, fica difícil priorizar e mitigar as vulnerabilidades.
Para obter uma visibilidade e uma postura completas de todos os ambientes, priorize as vulnerabilidades e mitigue as vulnerabilidades identificadas. Recomendamos um modelo de visibilidade centralizado. Um modelo de visibilidade centralizado, evita a correlação manual entre diferentes ferramentas e painéis de diferentes plataformas. Para mais informações, consulte Padrões de geração de registros e monitoramento híbrido e multicloud.
Como parte do planejamento para mitigar riscos de segurança e implantar cargas de trabalho no Google Cloud, e para ajudar você a planejar e projetar sua solução de nuvem para atingir seus objetivos de segurança e conformidade, confira a Central de práticas recomendadas de segurança do Google Cloud e o blueprint de bases empresariais.
Os objetivos de compliance podem variar, já que são influenciados pelas regulamentações específicas do setor e pelos distintos requisitos regulatórios em diferentes regiões e países. Para mais informações, consulte a Google Cloud Central de recursos de compliance. Estas são algumas das principais recomendações para criar uma arquitetura segura híbrida e multicloud:
Desenvolva a estratégia e a arquitetura de segurança na nuvem unificadas e personalizadas. Estratégias de segurança híbridas e multicloud precisam ser adaptadas às necessidades e objetivos da sua organização.
É essencial entender a arquitetura e o ambiente alvo antes de implementar controles de segurança, porque cada ambiente pode usar diferentes recursos, configurações e serviços.
Considere uma arquitetura de segurança unificada em ambientes de nuvem híbrida e multicloud.
Padronize o design e as implantações na nuvem, especialmente o design e os recursos de segurança. Isso melhora a eficiência e permite uma governança e ferramentas unificadas.
Use vários controles de segurança.
Normalmente, nenhum controle de segurança pode atender adequadamente a todos os requisitos de proteção. Portanto, as organizações precisam usar uma combinação de controles de segurança para uma defesa com várias camadas, também conhecida como defesa em profundidade.
Monitorar e melhorar continuamente as posturas de segurança: a organização deve monitorar os diferentes ambientes em busca de ameaças e vulnerabilidades de segurança. Ele também deve melhorar continuamente a postura de segurança.
Considere usar o Cloud Security Posture Management (CSPM) para identificar e corrigir configurações incorretas de segurança e ameaças à segurança cibernética. O CSPM também oferece avaliações de vulnerabilidade em ambientes híbridos e multicloud.
O Security Command Center é uma solução integrada de gerenciamento de segurança e risco do Google Cloud que ajuda a identificar configurações incorretas, vulnerabilidades e muito mais. O Security Health Analytics é uma ferramenta gerenciada de verificação para a avaliação de vulnerabilidades. Um recurso do Security Command Center que identifica os riscos e as vulnerabilidades de segurança no ambienteGoogle Cloud e oferece recomendações para corrigi-los.
O Mandiant Attack Surface Management para Google Cloud permite que sua organização enxergue melhor os ativos de ambientes de nuvem híbrida e multicloud. Ele descobre automaticamente os ativos de vários provedores de nuvem, DNS e a superfície de ataque externa estendida para oferecer à sua empresa uma compreensão mais profunda do ecossistema. Use estas informações para priorizar a correção das vulnerabilidades e das exposições que apresentam um risco maior.
- Solução de gerenciamento de eventos e informações de segurança na nuvem (SIEM, na em inglês): ajuda a coletar e analisar registros de segurança de ambientes híbridos e multicloud para detectar e responder a ameaças. O SIEM do Google Security Operations do Google Cloud ajuda a fornecer informações de segurança e gerenciamento de eventos ao coletar, analisar, detectar e investigar todos os dados de segurança em um só lugar.
Criar arquiteturas híbridas e multicloud usando Google Cloud: próximas etapas
- Saiba mais sobre como começar a migração para o Google Cloud.
- Saiba mais sobre os padrões de arquitetura comuns para as implantações híbrida e multicloud, em quais cenários eles são mais adequados e como aplicá-los.
- Saiba mais sobre os padrões de rede para arquiteturas híbridas e multicloud, e como projetá-las.
- Conheça, analise e compare os diferentes arquétipos de implantação em Google Cloud.
- Saiba mais sobre o design da zona de destino em Google Cloud.
- Saiba mais sobre o Google Cloud Framework de arquitetura.
- Leia sobre nossas práticas recomendadas de migração de VMs para o Compute Engine.