Crie arquiteturas híbridas e multicloud com o Google Cloud

Last reviewed 2024-11-27 UTC

Este guia de arquitetura oferece orientações práticas sobre o planeamento e a arquitetura dos seus ambientes híbridos e de várias nuvens através do Google Cloud. Este documento é o primeiro de três documentos no conjunto. Examina as oportunidades e as considerações associadas a estas arquiteturas do ponto de vista empresarial e tecnológico. Também analisa e debate muitos padrões de arquitetura híbrida e multicloud comprovados.

O conjunto de documentos para padrões de arquitetura híbrida e multicloud consiste nas seguintes partes:

Pode ler cada um destes artigos de arquitetura de forma independente, mas para tirar o máximo partido, recomendamos que os leia sequencialmente antes de tomar uma decisão de arquitetura.

O ritmo rápido de mudança nas exigências do mercado aumentou os requisitos e as expetativas colocados na TI empresarial, como a escala dinâmica, o aumento do desempenho para uma experiência do utilizador otimizada e a segurança. Muitas empresas de nível empresarial têm dificuldade em satisfazer estas exigências e expetativas usando apenas infraestrutura e processos tradicionais. Os departamentos de TI também estão sob pressão para melhorar a sua rentabilidade, o que dificulta a justificação de investimentos de capital adicionais em centros de dados e equipamentos.

Uma estratégia de nuvem híbrida que usa capacidades de computação na nuvem pública oferece uma solução pragmática. Ao usar a nuvem pública, pode expandir a capacidade e as capacidades das suas plataformas de computação sem custos de investimento de capital iniciais.

Ao adicionar uma ou mais soluções baseadas na nuvem pública, como Google Cloud, à sua infraestrutura existente, não só preserva os seus investimentos existentes, como também evita comprometer-se com um único fornecedor de nuvem. Além disso, ao usar uma estratégia híbrida, pode modernizar as aplicações e os processos de forma incremental à medida que os recursos o permitem.

Para ajudar a planear a sua decisão de arquitetura e o planeamento da estratégia híbrida ou multicloud, existem vários potenciais desafios e considerações de design que deve ter em conta. Este guia de arquitetura de várias partes realça as potenciais vantagens de várias arquiteturas e os potenciais desafios.

Vista geral da nuvem híbrida e da multinuvem

Uma vez que as cargas de trabalho, a infraestrutura e os processos são exclusivos de cada empresa, cada estratégia de nuvem híbrida tem de ser adaptada às suas necessidades específicas. O resultado é que os termos nuvem híbrida e multinuvem são, por vezes, usados de forma inconsistente.

No contexto deste Google Cloud guia de arquitetura, o termo nuvem híbrida descreve uma arquitetura na qual as cargas de trabalho são implementadas em vários ambientes de computação, um baseado na nuvem pública e, pelo menos, um privado, por exemplo, um centro de dados no local ou uma instalação de colocation.

O termo multicloud descreve uma arquitetura que combina, pelo menos, dois CSPs públicos. Conforme ilustrado no diagrama seguinte, por vezes, esta arquitetura inclui um ambiente de computação privado (que pode incluir a utilização de um componente de nuvem privada). Essa disposição é denominada arquitetura híbrida e multicloud.

Diagrama das três arquiteturas abordadas nesta série: híbrida, de várias nuvens e uma combinação de arquiteturas híbridas e de várias nuvens.

Colaboradores

Autor: Marwan Al Shawi | Partner Customer Engineer

Outros colaboradores:

Motivações, considerações, estratégia e abordagens

Este documento define e aborda os objetivos, os motores e os requisitos empresariais, bem como a forma como estes fatores podem influenciar as suas decisões de design ao criar arquiteturas híbridas e multicloud.

Objetivos

Uma organização pode adotar uma arquitetura híbrida ou multicloud como uma solução permanente para alcançar objetivos de negócio específicos ou como um estado temporário para facilitar determinados requisitos, como uma migração para a nuvem.

Responder às seguintes perguntas sobre a sua empresa é uma boa forma de definir os requisitos da empresa e estabelecer expetativas específicas sobre como alcançar alguns ou todos os objetivos da empresa. Estas perguntas focam-se no que é necessário para a sua empresa e não em como o alcançar tecnicamente.

  • Que objetivos empresariais estão a motivar a decisão de adotar uma arquitetura híbrida ou de várias nuvens?
  • Que objetivos empresariais e técnicos vai ajudar a alcançar uma arquitetura híbrida ou multicloud?
  • Que fatores empresariais influenciaram estes objetivos?
  • Quais são os requisitos empresariais específicos?

No contexto das arquiteturas híbridas e multicloud, um objetivo empresarial de um cliente empresarial pode ser expandir as operações ou os mercados de vendas online de uma única região para se tornar um dos líderes globais no respetivo segmento de mercado. Um dos objetivos empresariais pode ser começar a aceitar ordens de compra de utilizadores em todo o mundo (ou de regiões específicas) no prazo de seis meses.

Para apoiar os requisitos e os objetivos empresariais mencionados anteriormente, um potencial objetivo técnico principal é expandir a infraestrutura de TI e a arquitetura de aplicações de uma empresa de um modelo apenas no local para uma arquitetura híbrida, usando as capacidades e os serviços globais de nuvens públicas. Este objetivo deve ser específico e mensurável, definindo claramente o âmbito da expansão em termos de regiões de destino e prazos.

Geralmente, uma arquitetura híbrida ou multicloud raramente é um objetivo em si, mas sim um meio de cumprir objetivos técnicos determinados por certos requisitos empresariais. Por conseguinte, a escolha da arquitetura híbrida ou multicloud certa requer primeiro a clarificação destes requisitos.

É importante distinguir entre os objetivos empresariais e os objetivos técnicos do seu projeto de TI. Os objetivos da empresa devem focar-se no objetivo e na missão da sua organização. Os seus objetivos técnicos devem focar-se na criação de uma base tecnológica que permita à sua organização cumprir os respetivos requisitos e objetivos empresariais.

Os fatores empresariais influenciam a concretização do objetivo e das metas da empresa. Por conseguinte, a identificação clara dos fatores empresariais pode ajudar a moldar os objetivos ou as metas da empresa para serem mais relevantes para as necessidades e as tendências do mercado.

O fluxograma seguinte ilustra os fatores, os objetivos, os requisitos e os objetivos e requisitos técnicos da empresa, bem como a forma como todos estes fatores se relacionam entre si:

Fluxograma que mostra as aspetos a considerar ao desenvolver requisitos técnicos, incluindo os fatores, os objetivos e os requisitos da empresa, bem como os objetivos técnicos.

Motivações empresariais e técnicas

Considere como os fatores de negócio influenciam os seus objetivos técnicos. Alguns fatores comuns e influentes que determinam a escolha de uma arquitetura híbrida incluem o seguinte:

  • Cumprir as leis e os regulamentos relativos à soberania dos dados.
  • Reduzir as despesas de capital (CAPEX) ou os gastos gerais de TI com o apoio da gestão financeira na nuvem e das disciplinas de otimização de custos, como o FinOps.
    • A adoção da nuvem pode ser impulsionada por cenários que ajudam a reduzir as despesas de capital, como a criação de uma solução de recuperação de desastres numa arquitetura híbrida ou de várias nuvens.
  • Melhorar a experiência do utilizador.
  • Aumentar a flexibilidade e a agilidade para responder às exigências do mercado em constante mudança.
  • Melhorar a transparência sobre os custos e o consumo de recursos.

Considere a sua lista de fatores empresariais para adotar uma arquitetura híbrida ou de várias nuvens em conjunto. Não os considere isoladamente. A sua decisão final deve depender do equilíbrio das prioridades da sua empresa.

Depois de a sua organização perceber as vantagens da nuvem, pode decidir migrar totalmente se não existirem restrições, como custos ou requisitos de conformidade específicos que exijam que os dados altamente seguros sejam alojados no local, que a impeçam de o fazer.

Embora a adoção de um único fornecedor de nuvem possa oferecer várias vantagens, como a redução da complexidade, as integrações incorporadas entre serviços e as opções de otimização de custos, como os descontos por utilização garantida, ainda existem alguns cenários em que uma arquitetura de várias nuvens pode ser benéfica para uma empresa. Seguem-se os fatores empresariais comuns para a adoção de uma arquitetura de várias nuvens, juntamente com as considerações associadas para cada fator:

  • Respeitar as leis e os regulamentos sobre a soberania dos dados: o cenário mais comum ocorre quando uma organização está a expandir a sua atividade para uma nova região ou país e tem de agir em conformidade com os novos regulamentos de alojamento de dados.
    • Se o fornecedor de serviços na nuvem (CSP) usado não tiver uma região na nuvem local nesse país, para fins de conformidade, a solução comum é usar outro CSP que tenha uma região na nuvem local nesse país.
  • Reduzir custos: a redução de custos é, muitas vezes, o fator empresarial mais comum para adotar uma tecnologia ou uma arquitetura. No entanto, é importante considerar mais do que apenas o custo dos serviços e os potenciais descontos nos preços quando decidir se adota uma arquitetura multicloud. Tenha em conta o custo de criação e funcionamento de uma solução em várias nuvens, bem como quaisquer restrições de arquitetura que possam surgir dos sistemas existentes.

Por vezes, os potenciais desafios associados a uma estratégia de várias nuvens podem superar as vantagens. Uma estratégia de várias nuvens pode introduzir custos adicionais mais tarde.

Os desafios comuns associados ao desenvolvimento de uma estratégia de várias nuvens incluem o seguinte:

  • Aumentar a complexidade da gestão.
  • Manter uma segurança consistente.
  • Integrar ambientes de software.
  • Alcançar um desempenho e uma fiabilidade consistentes em várias nuvens.
  • A criação de uma equipa técnica com competências em várias nuvens pode ser cara e pode exigir a expansão da equipa, a menos que seja gerida por uma empresa de terceiros.
  • Gerir os preços dos produtos e as ferramentas de gestão de cada CSP.
  • Usar as capacidades únicas de cada CSP: uma arquitetura de várias nuvens permite que as organizações usem novas tecnologias adicionais para melhorar as suas próprias ofertas de capacidades empresariais sem se limitarem às escolhas oferecidas por um único fornecedor de nuvem.
    • Para evitar qualquer risco ou complexidade imprevistos, avalie os potenciais desafios através de uma avaliação de viabilidade e eficácia, incluindo os desafios comuns mencionados anteriormente.
  • Evitar ficar preso a fornecedores: por vezes, as empresas querem evitar ficar presas a um único fornecedor de nuvem. Uma abordagem de várias nuvens permite-lhes escolher a melhor solução para as necessidades da sua empresa. No entanto, a viabilidade desta decisão depende de vários fatores, como os seguintes:
    • Dependências técnicas
    • Considerações de interoperabilidade entre aplicações
    • Custos de reconstrução ou refatoração de aplicações
    • Conjuntos de competências técnicas
    • Segurança e capacidade de gestão consistentes
  • Melhorar a fiabilidade e o nível de disponibilidade das aplicações essenciais para a empresa: em alguns cenários, uma arquitetura de várias nuvens pode oferecer resiliência a interrupções. Por exemplo, se uma região de um PSC ficar indisponível, o tráfego pode ser encaminhado para outro PSC na mesma região. Este cenário pressupõe que ambos os fornecedores de nuvem suportam as capacidades ou os serviços necessários nessa região.

Quando os regulamentos de residência dos dados num país ou numa região específicos exigem o armazenamento de dados confidenciais, como informações de identificação pessoal (IIP), nessa localização, uma abordagem de várias nuvens pode oferecer uma solução em conformidade. Ao usar dois FSPs numa região para oferecer resiliência a interrupções, pode facilitar a conformidade com as restrições regulamentares e, ao mesmo tempo, satisfazer os requisitos de disponibilidade.

Seguem-se algumas considerações de resiliência a avaliar antes de adotar uma arquitetura de várias nuvens:

  • Movimento de dados: com que frequência os dados podem mover-se no seu ambiente de várias nuvens?
    • A movimentação de dados pode incorrer em custos de transferência de dados significativos?
  • Segurança e capacidade de gestão: existem potenciais complexidades de segurança ou capacidade de gestão?
  • Paridade de capacidade: os dois FSCs na região selecionada oferecem as capacidades e os serviços necessários?
  • Conjunto de competências técnicas: a equipa técnica tem as competências necessárias para gerir uma arquitetura de várias nuvens?

Considere todos estes fatores ao avaliar a viabilidade de usar uma arquitetura de várias nuvens para melhorar a resiliência.

Ao avaliar a viabilidade de uma arquitetura de várias nuvens, é importante considerar as vantagens a longo prazo. Por exemplo, a implementação de aplicações em várias nuvens para recuperação de desastres ou uma fiabilidade aumentada pode aumentar os custos a curto prazo, mas pode evitar interrupções ou falhas. Essas falhas podem causar danos financeiros e reputacionais a longo prazo. Por isso, é importante ponderar os custos a curto prazo em função do potencial valor a longo prazo da adoção da multinuvem. Além disso, o valor potencial a longo prazo pode variar com base na dimensão da organização, na escala tecnológica, na criticidade da solução tecnológica e no setor.

As organizações que planeiam criar com êxito um ambiente híbrido ou multicloud devem considerar criar um centro de excelência (COE) na nuvem. Uma equipa do COE pode tornar-se o canal de transformação da forma como as equipas internas da sua organização servem a empresa durante a transição para a nuvem. Um COE é uma das formas de a sua organização adotar a nuvem mais rapidamente, impulsionar a normalização e manter um alinhamento mais forte entre a sua estratégia empresarial e os seus investimentos na nuvem.

Se o objetivo da arquitetura híbrida ou multicloud for criar um estado temporário, os fatores empresariais comuns incluem:

  • A necessidade de reduzir o CAPEX ou os gastos gerais de TI para projetos de curto prazo.
  • A capacidade de aprovisionar rapidamente essa infraestrutura para suportar um exemplo de utilização de empresa. Por exemplo:
    • Esta arquitetura pode ser usada para projetos de tempo limitado. Pode ser usado para suportar um projeto que requer uma infraestrutura distribuída de grande escala durante um período limitado, enquanto usa dados no local.
  • A necessidade de projetos de transformação digital plurianuais que exigem que uma grande empresa os estabeleça e que use uma arquitetura híbrida durante algum tempo para a ajudar a alinhar a modernização da infraestrutura e das aplicações com as suas prioridades empresariais.
  • A necessidade de criar uma arquitetura híbrida, de várias nuvens ou mista temporária após uma fusão empresarial. Deste modo, a nova organização pode definir uma estratégia para o estado final da sua nova arquitetura na nuvem. É comum que duas empresas em fusão usem fornecedores de nuvem diferentes ou que uma empresa use um centro de dados privado no local e a outra use a nuvem. Em qualquer dos casos, o primeiro passo na fusão e aquisição é quase sempre integrar os sistemas de TI.

Motivações técnicas

A secção anterior abordou os fatores empresariais. Para serem aprovadas, as principais decisões de arquitetura precisam quase sempre do apoio desses responsáveis. No entanto, os fatores técnicos, que podem basear-se num ganho técnico ou numa restrição, também podem influenciar os fatores empresariais. Em alguns cenários, é necessário traduzir os fatores técnicos em fatores empresariais e explicar como podem afetar a empresa de forma positiva ou negativa.

A seguinte lista não exaustiva contém alguns fatores técnicos comuns para a adoção de uma arquitetura híbrida ou multicloud:

  • Desenvolver capacidades tecnológicas, como serviços de estatísticas avançadas e IA, que podem ser difíceis de implementar em ambientes existentes.
  • Melhorar a qualidade e o desempenho do serviço.
  • Automatizar e acelerar as implementações de aplicações para alcançar um tempo de comercialização mais rápido e tempos de ciclo mais curtos.
  • Usar APIs e serviços de alto nível para acelerar o desenvolvimento.
  • Acelerar o aprovisionamento de recursos de computação e armazenamento.
  • Usar serviços sem servidor para criar serviços e capacidades elásticos mais rapidamente e à escala.
  • Usar capacidades de infraestrutura global para criar arquiteturas globais ou multirregionais para satisfazer determinados requisitos técnicos.

O fator técnico mais comum para as arquiteturas híbridas temporárias e multinuvem temporárias é facilitar uma migração das instalações para a nuvem ou para uma nuvem adicional. Em geral, as migrações para a nuvem quase sempre levam naturalmente à configuração da nuvem híbrida. As empresas têm frequentemente de fazer a transição sistemática de aplicações e dados com base nas suas prioridades. Da mesma forma, uma configuração a curto prazo pode destinar-se a facilitar uma validação de conceito através de tecnologias avançadas disponíveis na nuvem durante um determinado período.

Decisões de design técnico

O objetivo técnico identificado e os respetivos fatores são fundamentais para tomar uma decisão de arquitetura orientada para os negócios e selecionar um dos padrões de arquitetura abordados neste guia. Por exemplo, para apoiar um objetivo empresarial específico, uma empresa pode definir um objetivo empresarial para criar uma prática de investigação e desenvolvimento durante três a seis meses. O principal requisito empresarial para apoiar este objetivo pode ser criar o ambiente tecnológico necessário para a investigação e o design com o CAPEX mais baixo possível.

Neste caso, o objetivo técnico é ter uma configuração de nuvem híbrida temporária. O motivo deste objetivo técnico é tirar partido do modelo de preços a pedido da nuvem para cumprir o requisito empresarial mencionado anteriormente. Outro fator é influenciado pelos requisitos tecnológicos específicos que exigem uma solução baseada na nuvem com uma elevada capacidade de computação e uma configuração rápida.

Use Google Cloud para arquiteturas híbridas e multicloud

A utilização de soluções de código aberto pode facilitar a adoção de uma abordagem híbrida e de várias nuvens, bem como minimizar a dependência de fornecedores. No entanto, deve considerar as seguintes potenciais complexidades ao planear uma arquitetura:

  • Interoperabilidade
  • Capacidade de gestão
  • Custo
  • Segurança

A criação numa plataforma de nuvem que contribui e suporta código aberto pode ajudar a simplificar o seu caminho para a adoção de arquiteturas híbridas e de várias nuvens. A nuvem aberta permite-lhe adotar uma abordagem que oferece a máxima escolha e abstrai a complexidade. Além disso, Google Cloud oferece a flexibilidade de migrar, criar e otimizar aplicações em ambientes híbridos e de várias nuvens, ao mesmo tempo que minimiza a dependência de fornecedores, usa as melhores soluções da sua classe e cumpre os requisitos regulamentares.

A Google também é um dos maiores contribuintes para o 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 implementado como um serviço gerido, o Kubernetes pode ajudar a reduzir as complexidades em torno da capacidade de gestão e da segurança híbrida e multicloud.

Planeie uma estratégia híbrida e multicloud

Este documento centra-se na forma de aplicar considerações empresariais predefinidas ao planear uma estratégia híbrida e multinuvem. Expande as orientações em Motivações, considerações, estratégia e abordagens. Esse artigo define e analisa as considerações empresariais que as empresas devem ter em conta ao planear uma estratégia deste tipo.

Esclareça e concorde com a visão e os objetivos

Em última análise, o principal objetivo de uma estratégia híbrida ou multicloud é alcançar os requisitos empresariais identificados e os objetivos técnicos associados para cada exemplo de utilização empresarial alinhado com objetivos empresariais específicos. Para alcançar este objetivo, crie um plano bem estruturado que inclua as seguintes considerações:

Saiba que definir um plano que considere todas as cargas de trabalho e requisitos é, na melhor das hipóteses, difícil, especialmente num ambiente de TI complexo. Além disso, o planeamento demora tempo e pode levar a visões concorrentes dos intervenientes.

Para evitar estas situações, formule inicialmente uma declaração de visão que responda às seguintes perguntas (no mínimo):

  • Qual é o exemplo de utilização empresarial segmentado para atingir objetivos empresariais específicos?
  • Por que motivo a abordagem e o ambiente de computação atuais são insuficientes para atingir os objetivos de negócio?
  • Quais são os principais aspetos tecnológicos a otimizar através da nuvem pública?
  • Porquê e como é que a nova abordagem vai otimizar e atingir os objetivos da sua empresa?
  • Durante quanto tempo planeia usar a sua configuração híbrida ou multicloud?

Concordar com os principais objetivos e motores empresariais e técnicos e, em seguida, obter a aprovação dos intervenientes relevantes pode fornecer uma base para os passos seguintes no processo de planeamento. Para alinhar eficazmente a solução proposta com a visão arquitetónica global da sua organização, alinhe-a com a sua equipa e os intervenientes responsáveis por liderar e patrocinar esta iniciativa.

Identifique e esclareça outras considerações

Ao planear uma arquitetura híbrida ou multicloud, é importante identificar e concordar com as restrições arquitetónicas e operacionais do seu projeto.

Do ponto de vista das operações, a seguinte lista não exaustiva apresenta alguns requisitos que podem criar algumas restrições a ter em conta ao planear a sua arquitetura:

  • Gerir e configurar várias nuvens separadamente em vez de criar um modelo holístico para gerir e proteger os diferentes ambientes de nuvem.
  • Garantir a autenticação, a autorização, a auditoria e as políticas consistentes em todos os ambientes.
  • Usar ferramentas e processos consistentes em todos os ambientes para fornecer uma vista holística da segurança, dos custos e das oportunidades de otimização.
  • Usar padrões de conformidade e segurança consistentes para aplicar uma gestão unificada.

No planeamento da arquitetura, as maiores restrições resultam frequentemente de sistemas existentes e podem incluir o seguinte:

  • Dependências entre aplicações
  • Requisitos de desempenho e latência para a comunicação entre sistemas
  • Confiança no hardware ou nos sistemas operativos que podem não estar disponíveis na nuvem pública
  • Restrições de licenciamento
  • Dependência da disponibilidade das capacidades necessárias nas regiões selecionadas de uma arquitetura multicloud

Para mais informações sobre outras considerações relacionadas com a portabilidade da carga de trabalho, a movimentação de dados e os aspetos de segurança, consulte a secção Outras considerações.

Crie uma estratégia de arquitetura híbrida e multicloud

Depois de esclarecer os detalhes dos objetivos empresariais e técnicos com os requisitos empresariais associados (e, idealmente, esclarecer e concordar com uma declaração de visão), pode criar a sua estratégia para criar uma arquitetura híbrida ou multicloud.

O seguinte fluxograma resume os passos lógicos para criar uma estratégia deste tipo.

Ao criar estratégias, considere os objetivos da sua empresa, obtenha apoio, crie um plano de alto nível e, em seguida, use-o para fundamentar a sua estratégia.

Para ajudar a determinar os objetivos e as necessidades técnicas da sua arquitetura híbrida ou multicloud, os passos no fluxograma anterior começam com os requisitos e os objetivos empresariais. A forma como implementa a sua estratégia pode variar consoante os objetivos, os fatores e o caminho de migração tecnológica de cada exemplo de utilização empresarial.

É importante lembrar que uma migração é um processo. O diagrama seguinte ilustra as fases deste percurso, conforme descrito no artigo Migre para Google Cloud.

Caminho de migração com quatro fases.

Esta secção fornece orientações sobre as fases "Avaliar", "Planear", "Implementar" e "Otimizar" no diagrama anterior. Apresenta estas informações no contexto de uma migração híbrida ou multicloud. Deve alinhar qualquer migração com as orientações e as práticas recomendadas abordadas na secção do caminho de migração do Google Cloud guia de migração. Estas fases podem aplicar-se a cada carga de trabalho individualmente e não a todas as cargas de trabalho em simultâneo. Em qualquer momento, várias cargas de trabalho podem estar em fases diferentes:

Fase de avaliação

Na fase de avaliação, realiza uma avaliação inicial da carga de trabalho. Durante esta fase, considere os objetivos descritos nos documentos de planeamento da visão e estratégia. Decida sobre um plano de migração identificando primeiro uma lista de candidatos de cargas de trabalho que podem beneficiar da implementação ou da migração para a nuvem pública.

Para começar, escolha uma carga de trabalho que não seja essencial para a empresa nem demasiado difícil de migrar (com dependências mínimas ou inexistentes em qualquer carga de trabalho noutros ambientes), mas que seja suficientemente típica para servir de modelo para implementações ou migrações futuras.

Idealmente, a carga de trabalho ou a aplicação que selecionar deve fazer parte de um exemplo de utilização ou de uma função empresarial segmentada que tenha um efeito mensurável na empresa após a conclusão.

Para avaliar e mitigar potenciais riscos de migração, faça uma avaliação dos riscos de migração. É importante avaliar a carga de trabalho candidata para determinar a respetiva adequação à migração para um ambiente de várias nuvens. Esta avaliação envolve a avaliação de vários aspetos das aplicações e da infraestrutura, incluindo o seguinte:

  • Requisitos de compatibilidade de aplicações com os fornecedores de nuvem selecionados
  • Modelos de preços
  • Funcionalidades de segurança oferecidas pelos fornecedores de nuvem selecionados
  • Requisitos de interoperabilidade de aplicações

A execução de uma avaliação também ajuda a identificar os requisitos de privacidade dos dados, os requisitos de conformidade, os requisitos de consistência e as soluções em vários ambientes de nuvem. Os riscos que identificar podem afetar as cargas de trabalho que optar por migrar ou operar.

Existem vários tipos de ferramentas, como o Centro de migração do Google Cloud, para ajudar a avaliar as cargas de trabalho existentes. Para mais informações, consulte o artigo Migração para Google Cloud: escolha uma ferramenta de avaliação.

Do ponto de vista da modernização da carga de trabalho, a ferramenta de avaliação de adequação ajuda a avaliar uma carga de trabalho de VM para determinar se a carga de trabalho é adequada para modernização para um contentor ou para migração para o Compute Engine.

Fase de planeamento

Na fase de Planeamento, comece pelas aplicações identificadas e pelas cargas de trabalho na nuvem necessárias, e execute as seguintes tarefas:

  1. Desenvolva uma estratégia de migração prioritária que defina ondas de migração de aplicações e caminhos.
  2. Identifique o padrão de arquitetura de aplicação híbrida ou multicloud de alto nível aplicável.
  3. Selecione um padrão de arquitetura de rede que suporte o padrão de arquitetura de aplicação selecionado.

Idealmente, deve incorporar o padrão de rede de nuvem com o design da zona de destino. O design da zona de destino serve como um elemento fundamental das arquiteturas híbridas e multicloud gerais. O design requer uma integração perfeita com estes padrões. Não crie a zona de destino isoladamente. Considere estes padrões de rede como um subconjunto do design da zona de destino.

Uma zona de destino pode consistir em diferentes aplicações, cada uma com um padrão de arquitetura de rede diferente. Além disso, nesta fase, é importante decidir sobre a conceção da Google Cloud organização, dos projetos e da hierarquia de recursos para preparar a zona de destino do seu ambiente de nuvem para a integração e a implementação híbrida ou multinuvem.

Como parte desta fase, deve considerar o seguinte:

  • Defina a abordagem de migração e modernização. Existem mais informações sobre abordagens de migração mais adiante neste guia. Também é abordado mais detalhadamente na secção Tipos de migração do artigo Migre para Google Cloud.
  • Use as conclusões da fase de avaliação e descoberta. Alinhe-as com a carga de trabalho candidata que planeia migrar. Em seguida, desenvolva um plano de ondas de migração de aplicações. O plano deve incorporar os requisitos de dimensionamento de recursos estimados que determinou durante a fase de avaliação.
  • Defina o modelo de comunicação necessário entre as aplicações distribuídas e entre os componentes da aplicação para a arquitetura híbrida ou multicloud pretendida.
  • Decida um arquétipo de implementação adequado para implementar a sua carga de trabalho, como zonal, regional, multirregional ou global, para o padrão de arquitetura escolhido. O arquétipo que selecionar forma a base para a criação de arquiteturas de implementação específicas da aplicação, adaptadas às suas necessidades empresariais e técnicas.
  • Decida sobre critérios de sucesso mensuráveis para a migração, com marcos claros para cada fase ou onda de migração. A seleção de critérios é essencial, mesmo que o objetivo técnico seja ter a arquitetura híbrida como uma configuração a curto prazo.
  • Defina SLAs e KPIs de aplicações quando as suas aplicações funcionarem numa configuração híbrida, especialmente para as aplicações que possam ter componentes distribuídos em vários ambientes.

Para mais informações, consulte o artigo Acerca do planeamento da migração para ajudar a planear uma migração bem-sucedida e minimizar os riscos associados.

Fase de implementação

Na fase de Implementação, tem tudo pronto para começar a executar a sua estratégia de migração. Dado o número potencial de requisitos, é melhor adotar uma abordagem iterativa.

Priorize as suas cargas de trabalho com base nas ondas de migração e de aplicações que desenvolveu durante a fase de planeamento. Com arquiteturas híbridas e multicloud, comece a implementação estabelecendo a conetividade necessária entre o Google Cloud e os outros ambientes de computação. Para facilitar o modelo de comunicação necessário para a sua arquitetura híbrida ou multicloud, baseie a implementação no design selecionado e no tipo de conetividade de rede, juntamente com o padrão de rede aplicável. Recomendamos que adote esta abordagem para a sua decisão de design geral da zona de destino.

Além disso, tem de testar e validar a aplicação ou o serviço com base nos critérios de sucesso da aplicação definidos. Idealmente, estes critérios devem incluir requisitos de testes funcionais e de carga (não funcionais) antes de passar para a produção.

Fase de otimização

Na fase de Otimização, teste a implementação: depois de concluir os testes e de a aplicação ou o serviço cumprir as expetativas de capacidade funcional e de desempenho, pode movê-lo para produção. As ferramentas de monitorização e visibilidade na nuvem, como o Cloud Monitoring, podem fornecer estatísticas sobre o desempenho, a disponibilidade e o estado das suas aplicações e infraestrutura, e ajudar a otimizar quando necessário.

Para mais informações, consulte o artigo Migre para Google Cloud: otimize o seu ambiente. Para saber como criar essas ferramentas para uma arquitetura híbrida ou multicloud, consulte os padrões de registo e monitorização híbridos e multicloud.

Avalie 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 da carga de trabalho devem estar alinhadas com objetivos de negócio específicos. Por conseguinte, estas decisões devem ser orientadas por exemplos de utilização da empresa segmentados que permitam efeitos comerciais mensuráveis. No entanto, começar pela carga de trabalho/aplicação mais crítica para a empresa nem sempre é necessário nem recomendado. Para mais informações, consulte Escolher as apps a migrar primeiro no guia Migrar para o Google Cloud .

Conforme abordado na secção Fatores empresariais e técnicos, existem diferentes tipos de fatores e considerações para arquiteturas híbridas e multicloud.

A seguinte lista resumida de fatores pode ajudar a avaliar o seu exemplo de utilização de migração no contexto de uma arquitetura híbrida ou de várias nuvens com oportunidades de ter um efeito empresarial mensurável:

  • Potencial de diferenciação ou inovação no mercado que é ativado através da utilização de serviços na nuvem para ativar determinadas funções ou capacidades empresariais, como capacidades de inteligência artificial que usam dados no local existentes para preparar modelos de aprendizagem automática.
  • Poupanças potenciais no custo total de propriedade de uma aplicação.
  • Melhorias potenciais na disponibilidade, resiliência, segurança ou desempenho, por exemplo, adicionando um site de recuperação de desastres (RD) na nuvem.
  • Potencial aceleração dos processos de desenvolvimento e lançamento, por exemplo, criando os seus ambientes de desenvolvimento e teste na nuvem.

Os seguintes fatores podem ajudar a avaliar os riscos de migração:

  • O potencial efeito das indisponibilidades causadas por uma migração.
  • A experiência que a sua equipa tem com implementações na nuvem pública ou com implementações para um novo ou segundo fornecedor de nuvem.
  • A necessidade de agir em conformidade com quaisquer restrições legais ou regulamentares existentes.

Os seguintes fatores podem ajudar a avaliar as dificuldades técnicas de uma migração:

  • O tamanho, a complexidade e a idade da aplicação.
  • O número de dependências com outras aplicações e serviços em diferentes ambientes de computação.
  • Quaisquer restrições impostas por licenças de terceiros.
  • Quaisquer dependências de versões específicas de sistemas operativos, bases de dados ou outras configurações do ambiente.

Depois de avaliar as cargas de trabalho iniciais, pode começar a dar-lhes prioridade e a definir as ondas de migração e as abordagens. Em seguida, pode identificar padrões de arquitetura aplicáveis e padrões de rede de apoio. Este passo pode exigir várias iterações, uma vez que a sua avaliação pode mudar ao longo do tempo. Por isso, vale a pena reavaliar as cargas de trabalho depois de fazer as suas primeiras implementações na nuvem.

Abordagens arquitetónicas para adotar uma arquitetura híbrida ou de várias nuvens

Este documento fornece orientações sobre abordagens e considerações comuns e comprovadas para migrar a sua carga de trabalho para a nuvem. Expande as orientações em Crie uma estratégia de arquitetura híbrida e multicloud, que aborda vários passos possíveis e recomendados para criar uma estratégia de adoção de uma arquitetura híbrida ou multicloud.

Baseada na nuvem

Uma forma comum de começar a usar a nuvem pública é a abordagem prioridade à nuvem. Nesta abordagem, implementa as suas novas cargas de trabalho na nuvem pública, enquanto as cargas de trabalho existentes permanecem onde estão. Nesse caso, considere uma implementação clássica num ambiente de computação privado apenas se uma implementação na nuvem pública for impossível por motivos técnicos ou organizacionais.

A estratégia baseada na nuvem tem vantagens e desvantagens. Por outro lado, é uma perspetiva de futuro. Pode implementar novas cargas de trabalho de forma modernizada, evitando (ou, pelo menos, minimizando) os problemas da migração de cargas de trabalho existentes.

Embora uma abordagem prioritária na nuvem possa oferecer determinadas vantagens, pode resultar em oportunidades perdidas para melhorar ou usar cargas de trabalho existentes. As novas cargas de trabalho podem representar uma fração da paisagem de TI geral e o respetivo efeito nas despesas e no desempenho de TI pode ser limitado. A atribuição de tempo e recursos à migração de uma carga de trabalho existente pode potencialmente gerar benefícios ou poupanças de custos mais substanciais em comparação com a tentativa de acomodar uma nova carga de trabalho no ambiente da nuvem.

Seguir uma abordagem baseada na nuvem rigorosa também corre o risco de aumentar a complexidade geral do seu ambiente de TI. Esta abordagem pode criar redundâncias, reduzir o desempenho devido a uma potencial comunicação excessiva entre ambientes ou resultar num ambiente de computação que não é adequado para a carga de trabalho individual. Além disso, a conformidade com os regulamentos da indústria e as leis de privacidade dos dados pode restringir as empresas de migrar determinadas aplicações que contêm dados confidenciais.

Considerando estes riscos, pode ser melhor usar uma abordagem baseada na nuvem apenas para cargas de trabalho selecionadas. A utilização de uma abordagem baseada na nuvem permite-lhe concentrar-se nas cargas de trabalho que podem beneficiar mais de uma implementação ou migração para a nuvem. Esta abordagem também considera a modernização das cargas de trabalho existentes.

Um exemplo comum de uma arquitetura híbrida baseada na nuvem é quando as aplicações e os serviços antigos que contêm dados críticos têm de ser integrados com novos dados ou aplicações. Para concluir a integração, pode usar uma arquitetura híbrida que modernize os serviços antigos através de interfaces de API, o que os desbloqueia para consumo por novos serviços e aplicações na nuvem. Com uma plataforma de gestão de APIs> na nuvem, como o Apigee, pode implementar estes exemplos de utilização com alterações mínimas à aplicação e adicionar segurança, estatísticas e escalabilidade aos serviços existentes.

Migração e modernização

A modernização de TI e a multinuvem híbrida são conceitos distintos que estão ligados num círculo virtuoso. A utilização da nuvem pública pode facilitar e simplificar a modernização das cargas de trabalho de TI. A modernização das suas cargas de trabalho de TI pode ajudar a tirar mais partido da nuvem.

Os principais objetivos da modernização das cargas de trabalho são os seguintes:

  • Alcançar uma maior agilidade para se poder adaptar aos requisitos em constante mudança.
  • Reduza os custos da sua infraestrutura e operações.
  • Aumente a fiabilidade e a resiliência para minimizar o risco.

No entanto, pode não ser viável modernizar todas as aplicações no processo de migração ao mesmo tempo. Conforme descrito em Migração para Google Cloud, pode implementar um dos seguintes tipos de migração ou até combinar vários tipos, conforme necessário:

  • Rehospedagem (recortar e guardar)
  • Mude de plataforma (transfira e otimize)
  • Refatorar (mover e melhorar)
  • Reestruturar (continuar a modernizar)
  • Reconstruir (remover e substituir, por vezes denominado rip and replace)
  • Recompra

Ao tomar decisões estratégicas sobre as suas arquiteturas híbridas e multicloud, é importante considerar a viabilidade da sua estratégia do ponto de vista dos custos e do tempo. Pondere uma abordagem de migração faseada, começando por transferir e mover ou mudar de plataforma e, em seguida, refatorar ou reestruturar como passo seguinte. Normalmente, a estratégia lift-and-shift ajuda a otimizar as aplicações do ponto de vista da infraestrutura. Depois de as aplicações serem executadas na nuvem, é mais fácil usar e integrar serviços na nuvem para as otimizar ainda mais através de arquiteturas e capacidades baseadas na nuvem. Além disso, estas aplicações podem continuar a comunicar com outros ambientes através de uma ligação de rede híbrida.

Por exemplo, pode refatorar ou reestruturar uma aplicação grande e monolítica baseada em VMs e transformá-la em vários microsserviços independentes, com base numa arquitetura de microsserviços baseada na nuvem. Neste exemplo, a arquitetura de microsserviços usa Google Cloud serviços de contentores geridos, como o Google Kubernetes Engine (GKE) ou o Cloud Run. No entanto, se a arquitetura ou a infraestrutura de uma aplicação não forem suportadas no ambiente de nuvem de destino tal como estão, pode considerar começar por reestruturar, refatorar ou reestruturar a sua estratégia de migração para ultrapassar essas restrições sempre que possível.

Quando usar qualquer uma destas abordagens de migração, pondere modernizar as suas aplicações (quando aplicável e viável). A modernização pode exigir a adoção e a implementação dos princípios de engenharia de fiabilidade do site (SRE) ou DevOps, pelo que também pode ter de estender a modernização da aplicação ao seu ambiente privado numa configuração híbrida. Embora a implementação dos princípios de EFS envolva engenharia na sua essência, é mais um processo de transformação do que um desafio técnico. Como tal, é provável que exija alterações processuais e culturais. Para saber mais sobre como o primeiro passo para implementar a SRE numa organização é obter a aprovação da liderança, consulte Com a SRE, não planear é planear falhar.

Combine abordagens de migração

Cada abordagem de migração abordada aqui tem determinadas vantagens e desvantagens. Uma vantagem fundamental de seguir uma estratégia híbrida e multicloud é que não é necessário optar por uma única abordagem. Em alternativa, pode decidir que abordagem funciona melhor para cada carga de trabalho ou conjunto de aplicações, conforme mostrado no diagrama seguinte.

Fluxograma que mostra diferentes abordagens para migrar cargas de trabalho do seu ambiente de nuvem.

Este diagrama conceptual ilustra os vários caminhos ou abordagens de migração e modernização que podem ser aplicados simultaneamente a diferentes cargas de trabalho, com base nos requisitos técnicos e empresariais únicos, bem como nos objetivos de cada carga de trabalho ou aplicação.

Além disso, não é necessário que os mesmos componentes da pilha de aplicações sigam a mesma abordagem ou estratégia de migração. Por exemplo:

  • A base de dados no local de uma aplicação pode ser replataformada do MySQL autoalojado para uma base de dados gerida através do Cloud SQL no Google Cloud.
  • As máquinas virtuais de front-end da aplicação podem ser refatoradas para serem executadas em contentores através do GKE Autopilot, em que a Google gere a configuração do cluster, incluindo nós, escalabilidade, segurança e outras definições pré-configuradas.
  • A solução de balanceamento de carga de hardware nas instalações e as capacidades de firewall de aplicações Web (WAF) podem ser substituídas pelo Cloud Load Balancing e pelo Google Cloud Armor.

Escolha a opção de rehost (lift and shift) se alguma das seguintes afirmações for verdadeira em relação às cargas de trabalho:

  • Têm um número relativamente pequeno de dependências no respetivo ambiente.
  • Não são consideradas dignas de refatoração ou a refatoração antes da migração não é viável.
  • Baseiam-se em software de terceiros.

Considere a refatorização (mover e melhorar) para estes tipos de cargas de trabalho:

  • Têm dependências que têm de ser resolvidas.
  • Dependem de sistemas operativos, hardware ou sistemas de bases de dados que não podem ser alojados na nuvem.
  • Não estão a usar de forma eficiente os recursos de computação ou armazenamento.
  • Não podem ser implementadas de forma automática sem algum esforço.

Considere se a reconstrução (remover e substituir) satisfaz as suas necessidades para estes tipos de cargas de trabalho:

  • Já não cumprem os requisitos atuais.
  • Podem ser incorporadas com outras aplicações que oferecem capacidades semelhantes sem comprometer os requisitos empresariais.
  • Baseiam-se em tecnologia de terceiros que atingiu o fim da vida útil.
  • Exigem taxas de licença de terceiros que já não são económicas.

O Programa de migração rápida mostra como Google Cloud ajuda os clientes a usar práticas recomendadas, reduzir o risco, controlar os custos e simplificar o caminho para o sucesso na nuvem.

Outras considerações

Este documento realça as principais considerações de design que desempenham um papel fundamental na definição da sua arquitetura híbrida e multicloud geral. Analise e avalie holisticamente estas considerações em toda a arquitetura da solução, abrangendo todas as cargas de trabalho e não apenas as específicas.

Refatorar

Numa migração de refatoração, modifica as suas cargas de trabalho para tirar partido das capacidades da nuvem, e não apenas para as fazer funcionar no novo ambiente. Pode melhorar cada carga de trabalho em termos de desempenho, funcionalidades, custo e experiência do utilizador. Conforme realçado em Refatoração: mover e melhorar, alguns cenários de refatoração permitem-lhe modificar cargas de trabalho antes de as migrar para a nuvem. Esta abordagem de refatoração oferece as seguintes vantagens, especialmente se o seu objetivo for criar uma arquitetura híbrida como uma arquitetura direcionada a longo prazo:

  • Pode melhorar o processo de implementação.
  • Pode ajudar a acelerar a cadência de lançamentos e encurtar os ciclos de feedback investindo em infraestrutura e ferramentas de integração contínua/implementação contínua (CI/CD).
  • Pode usar a refatorização como base para criar e gerir uma arquitetura híbrida com portabilidade de aplicações.

Para funcionar bem, esta abordagem requer normalmente determinados investimentos em infraestrutura e ferramentas no local. Por exemplo, configurar um registo de contentores local e aprovisionar clusters do Kubernetes para colocar aplicações em contentores. A edição Google Kubernetes Engine (GKE) Enterprise pode ser útil nesta abordagem para ambientes híbridos. Pode encontrar mais informações sobre o GKE Enterprise na secção seguinte. Também pode consultar a arquitetura de referência do ambiente híbrido do GKE Enterprise para mais detalhes.

Portabilidade da carga de trabalho

Com as arquiteturas híbridas e multicloud, pode querer mudar as cargas de trabalho entre os ambientes de computação que alojam os seus dados. Para ajudar a permitir a movimentação perfeita de cargas de trabalho entre ambientes, considere os seguintes fatores:

  • Pode mover uma aplicação de um ambiente de computação para outro sem modificar significativamente a aplicação e o respetivo modelo operacional:
    • A implementação e a gestão de aplicações são consistentes em todos os ambientes de computação.
    • A visibilidade, a configuração e a segurança são consistentes em todos os ambientes de computação.
  • A capacidade de tornar uma carga de trabalho portátil não deve entrar em conflito com o facto de a carga de trabalho ser baseada na nuvem.

Automatização de infraestruturas

A automatização da infraestrutura é essencial para a portabilidade em arquiteturas híbridas e multicloud. Uma abordagem comum para automatizar a criação de infraestruturas é através da infraestrutura como código (IaC). A IaC envolve a gestão da sua infraestrutura em ficheiros, em vez de configurar manualmente recursos, como uma VM, um grupo de segurança ou um equilibrador de carga, numa interface do utilizador. O Terraform é uma ferramenta de IaC popular para definir recursos de infraestrutura num ficheiro. O Terraform também lhe 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 a automatizar o aprovisionamento e a gestão de Google Cloud recursos, consulte Projetos e módulos do Terraform para Google Cloud.

Pode usar ferramentas de gestão de configuração, como o Ansible, Puppet, ou o Chef para estabelecer um processo de implementação e configuração comum. Em alternativa, pode usar uma ferramenta de incorporação de imagens, como o Packer, para criar imagens de VMs para diferentes plataformas. Ao usar um único ficheiro de configuração partilhado, pode usar o Packer e o Cloud Build para criar uma imagem de VM para utilização no Compute Engine. Por último, pode usar soluções como o Prometheus e o Grafana para ajudar a garantir uma monitorização consistente em todos os ambientes.

Com base nestas ferramentas, pode montar uma cadeia de ferramentas comum, conforme ilustrado no seguinte diagrama lógico. Esta cadeia de ferramentas comum abstrai as diferenças entre os ambientes de computação. Também lhe permite unificar o aprovisionamento, a implementação, a gestão e a monitorização.

Uma cadeia de ferramentas permite a portabilidade de aplicações.

Embora uma cadeia de ferramentas comum possa ajudar a alcançar a portabilidade, está sujeita a várias das seguintes limitações:

  • A utilização de VMs como base comum pode dificultar a implementação de aplicações verdadeiramente baseadas na nuvem. Além disso, a utilização exclusiva de VMs pode impedir a utilização de serviços geridos na nuvem. Pode perder oportunidades de reduzir os custos administrativos.
  • A criação e a manutenção de uma cadeia de ferramentas comum incorrem em custos gerais e operacionais.
  • À medida que a cadeia de ferramentas se expande, pode desenvolver complexidades únicas adaptadas às necessidades específicas da sua empresa. Esta maior complexidade pode contribuir para o aumento dos custos de formação.

Antes de decidir desenvolver ferramentas e automatização, explore os serviços geridos que o seu fornecedor de nuvem oferece. Quando o seu fornecedor oferece serviços geridos que suportam o mesmo exemplo de utilização, pode abstrair-se de parte da respetiva complexidade. Desta forma, pode concentrar-se na carga de trabalho e na arquitetura da aplicação, em vez de na infraestrutura subjacente.

Por exemplo, pode usar o modelo de recursos do Kubernetes para automatizar a criação de clusters do Kubernetes através de uma abordagem de configuração declarativa. Pode usar o comando Deployment Manager convert para converter as suas configurações e modelos do Deployment Manager noutros formatos de configuração declarativos que o Google Cloud suportam (como o Terraform e o Kubernetes Resource Model) para que sejam portáteis quando os publica.

Também pode considerar automatizar a criação de projetos e a criação de recursos nesses projetos. Esta automatização pode ajudar a adotar uma abordagem de infraestrutura como código para o aprovisionamento de projetos.

Contentores e Kubernetes

A utilização de capacidades geridas na nuvem ajuda a reduzir a complexidade da criação e manutenção de uma cadeia de ferramentas personalizada para alcançar a automatização e a portabilidade das cargas de trabalho. No entanto, a utilização apenas de VMs como base comum dificulta a implementação de aplicações verdadeiramente nativas da nuvem. Em alternativa, pode usar contentores e o Kubernetes.

Os contentores ajudam o seu software a ser executado de forma fiável quando o move de um ambiente para outro. Uma vez que os contentores desvinculam as aplicações da infraestrutura de anfitrião subjacente, facilitam a implementação em ambientes de computação, como híbridos e multinuvem.

O Kubernetes processa a orquestração, a implementação, o dimensionamento e a gestão das suas aplicações contentorizadas. É de código aberto e regido pela Cloud Native Computing Foundation. A utilização do Kubernetes fornece os serviços que formam a base de uma aplicação prioritária na nuvem. Uma vez que pode instalar e executar o Kubernetes em muitos ambientes de computação, também o pode usar para estabelecer uma camada de tempo de execução comum em ambientes de computação:

  • O Kubernetes oferece os mesmos serviços e APIs num ambiente de computação na nuvem ou privado. Além disso, o nível de abstração é muito superior ao do trabalho com VMs, o que geralmente se traduz em menos trabalho preparatório necessário e numa maior produtividade dos programadores.
  • Ao contrário de uma cadeia de ferramentas personalizada, o Kubernetes é amplamente adotado para a gestão de aplicações e desenvolvimento, pelo que pode tirar partido da experiência, documentação e apoio técnico de terceiros existentes.
  • O Kubernetes suporta todas as implementações de contentores que:

Quando uma carga de trabalho está a ser executada no Google Cloud, pode evitar o esforço de instalar e operar o Kubernetes usando uma plataforma Kubernetes gerida, como o Google Kubernetes Engine (GKE). Ao fazê-lo, a equipa de operações pode mudar o foco da criação e manutenção da infraestrutura para a criação e manutenção de aplicações.

Também pode usar o Autopilot, um modo de funcionamento do GKE que gere a configuração do seu cluster, incluindo os nós, o escalonamento, a segurança e outras definições pré-configuradas. Quando usar o GKE Autopilot, tenha em atenção os seus requisitos de escalabilidade e os respetivos limites de escalabilidade.

Tecnicamente, pode instalar e executar o Kubernetes em muitos ambientes de computação para estabelecer uma camada de tempo de execução comum. No entanto, na prática, a criação e a operação de uma arquitetura deste tipo podem gerar complexidade. A arquitetura torna-se ainda mais complexa quando requer um controlo de segurança ao nível do contentor (service mesh).

Para simplificar a gestão de implementações de vários clusters, pode usar o GKE Enterprise para executar aplicações modernas em qualquer lugar à escala. O GKE inclui componentes de código aberto geridos poderosos para proteger cargas de trabalho, aplicar políticas de conformidade e fornecer observabilidade de rede e resolução de problemas detalhadas.

Conforme ilustrado no diagrama seguinte, a utilização do GKE Enterprise significa que pode operar aplicações com vários clusters como frotas.

Diagrama de pilha que mostra as oportunidades de gestão de frotas oferecidas pelo GKE Enterprise.

O GKE Enterprise ajuda com as seguintes opções de design para suportar arquiteturas híbridas e de várias nuvens:

  • Conceba e crie experiências semelhantes à nuvem nas instalações ou soluções unificadas para a transição de aplicações 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.

  • Conceba e crie uma solução para resolver a complexidade de várias nuvens com uma postura de segurança, operações e governação 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 gestão de segurança, configuração e serviços consistentes. Por exemplo, o GKE Enterprise suporta uma arquitetura distribuída de confiança zero. Numa arquitetura distribuída de confiança zero, os serviços implementados nas instalações ou noutro ambiente de nuvem podem comunicar entre ambientes através de comunicações seguras de serviço a serviço mTLS ponto a ponto.

Considerações sobre a portabilidade das cargas de trabalho

O Kubernetes e o GKE Enterprise oferecem uma camada de abstração para cargas de trabalho que podem ocultar as muitas complexidades e diferenças entre ambientes de computação. A lista seguinte descreve algumas dessas abstrações:

  • Uma aplicação pode ser portátil para um ambiente diferente com alterações mínimas, mas isso não significa que a aplicação tenha um desempenho igualmente bom 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, podem levar a um desempenho substancialmente diferente.
  • A movimentação de uma carga de trabalho entre ambientes de computação também pode exigir que mova dados.
    • Os diferentes ambientes podem ter diferentes serviços e instalações de armazenamento e gestão de dados.
  • O comportamento e o desempenho dos balanceadores de carga aprovisionados com o Kubernetes ou o GKE Enterprise podem diferir entre ambientes.

Movimento de dados

Uma vez que pode ser complexo mover, partilhar e aceder a dados em grande escala entre ambientes de computação, as empresas de nível empresarial podem hesitar em criar uma arquitetura híbrida ou multinuvem. Esta hesitação pode aumentar se já estiverem a armazenar a maioria dos respetivos dados no local ou numa nuvem.

No entanto, as várias opções de movimentação de dados oferecidas pela Google Cloudoferecem às empresas um conjunto abrangente de soluções para ajudar a mover, integrar e transformar os respetivos dados. Estas opções ajudam as empresas a armazenar, partilhar e aceder a dados em diferentes ambientes de uma forma que satisfaça os respetivos exemplos de utilização específicos. Em última análise, essa capacidade facilita a adoção de arquiteturas híbridas e multicloud para os decisores empresariais e tecnológicos.

A movimentação de dados é um aspeto importante a ter em conta no planeamento da arquitetura e da estratégia híbrida e multicloud. A sua equipa tem de identificar os diferentes exemplos de utilização da empresa e os dados que os suportam. Também deve pensar no tipo de armazenamento, na capacidade, na acessibilidade e nas opções de movimento.

Se uma empresa tiver uma classificação de dados para setores regulamentados, essa classificação pode ajudar a identificar localizações de armazenamento e restrições de movimento de dados entre regiões para determinadas classes de dados. Para mais informações, consulte o artigo Proteção de dados confidenciais. A proteção de dados confidenciais é um serviço totalmente gerido concebido para ajudar a descobrir, classificar e proteger os seus recursos de dados.

Para explorar o processo, desde o planeamento de uma transferência de dados à utilização de práticas recomendadas na implementação de um plano, consulte o artigo Migração para Google Cloud: transferir os seus grandes conjuntos de dados.

Segurança

À medida que as organizações adotam arquiteturas híbridas e multicloud, a respetiva superfície de ataque pode aumentar consoante a forma como os sistemas e os dados são distribuídos por diferentes ambientes. Em combinação com o panorama de ameaças em constante evolução, as superfícies de ataque aumentadas podem levar a um risco acrescido de acesso não autorizado, perda de dados e outros incidentes de segurança. Considere cuidadosamente a segurança ao planear e implementar estratégias híbridas ou multicloud.

Para mais informações, consulte o artigo Gestão da superfície de ataque para o Google Cloud.

Quando cria a arquitetura para uma arquitetura híbrida, nem sempre é tecnicamente exequível ou viável estender as abordagens de segurança no local para a nuvem. No entanto, muitas das capacidades de segurança de rede dos dispositivos de hardware são funcionalidades baseadas na nuvem e funcionam de forma distribuída. Para mais informações sobre as capacidades de segurança de rede baseadas na nuvem do Google Cloud, consulte Segurança de rede na nuvem.

As arquiteturas híbridas e multicloud podem introduzir desafios de segurança adicionais, como a consistência e a observabilidade. Cada fornecedor de nuvem pública tem a sua própria abordagem à segurança, incluindo diferentes modelos, práticas recomendadas, capacidades de segurança de infraestrutura e aplicações, obrigações de conformidade e até os nomes dos serviços de segurança. Estas inconsistências podem aumentar o risco de segurança. Além disso, o modelo de responsabilidade partilhada de cada fornecedor de nuvem pode ser diferente. É essencial identificar e compreender a demarcação exata das responsabilidades numa arquitetura de várias nuvens.

A observabilidade é fundamental para obter estatísticas e métricas dos diferentes ambientes. Numa arquitetura de várias nuvens, cada nuvem oferece normalmente ferramentas para monitorizar a postura de segurança e as configurações incorretas. No entanto, a utilização destas ferramentas resulta numa visibilidade isolada, o que impede a criação de inteligência sobre ameaças avançada em todo o ambiente. Como tal, a equipa de segurança tem de alternar entre ferramentas e painéis de controlo para manter a nuvem segura. Sem uma visibilidade geral da segurança ponto a ponto para os ambientes híbridos e multicloud, é difícil priorizar e mitigar as vulnerabilidades.

Para obter a visibilidade e a postura completas de todos os seus ambientes, priorize as vulnerabilidades e mitigue as vulnerabilidades que identificar. Recomendamos um modelo de visibilidade centralizado. Um modelo de visibilidade centralizado evita a necessidade de correlação manual entre diferentes ferramentas e painéis de controlo de diferentes plataformas. Para mais informações, consulte o artigo Padrões de registo e monitorização híbridos e multicloud.

Como parte do seu planeamento para mitigar os riscos de segurança e implementar cargas de trabalho no Google Cloud, e para ajudar a planear e conceber a sua solução na nuvem para cumprir os seus objetivos de segurança e conformidade, explore o Google Cloud centro de práticas recomendadas de segurança e o projeto de base empresarial.

Os objetivos de conformidade podem variar, uma vez que são influenciados tanto pelos regulamentos específicos da indústria como pelos requisitos regulamentares variáveis de diferentes regiões e países. Para mais informações, consulte o Google Cloud centro de recursos de conformidade. Seguem-se algumas das principais abordagens recomendadas para criar uma arquitetura híbrida e multicloud segura:

  • Desenvolver uma estratégia e uma arquitetura de segurança na nuvem unificadas e personalizadas. As estratégias de segurança híbridas e multinuvem devem ser adaptadas às necessidades e aos objetivos específicos da sua organização.

    É essencial compreender a arquitetura e o ambiente segmentados antes de implementar controlos de segurança, porque cada ambiente pode usar diferentes funcionalidades, configurações e serviços.

  • Considere uma arquitetura de segurança unificada em ambientes híbridos e multicloud.

  • Uniformize a criação e as implementações na nuvem, especialmente a criação e as capacidades de segurança. Ao fazê-lo, pode melhorar a eficiência e ativar a governação e as ferramentas unificadas.

  • Use vários controlos de segurança.

    Normalmente, nenhum controlo de segurança único consegue resolver adequadamente todos os requisitos de proteção de segurança. Por conseguinte, as organizações devem usar uma combinação de controlos de segurança numa abordagem de defesa em camadas, também conhecida como defesa em profundidade.

  • Monitorize e melhore continuamente as posturas de segurança: a sua organização deve monitorizar os diferentes ambientes quanto a ameaças e vulnerabilidades de segurança. Também deve tentar melhorar continuamente a sua postura de segurança.

  • Considere usar a gestão da postura de segurança na nuvem (CSPM) para identificar e corrigir configurações incorretas de segurança e ameaças de cibersegurança. A CSPM também oferece avaliações de vulnerabilidades em ambientes híbridos e multicloud.

O Security Command Center é uma solução de segurança e gestão de riscos integrada para o Google Cloud que ajuda a identificar configurações incorretas, vulnerabilidades e muito mais. A Security Health Analytics é uma ferramenta de análise de avaliação de vulnerabilidades gerida. É uma funcionalidade do Security Command Center que identifica riscos de segurança e vulnerabilidades no seuGoogle Cloud ambiente e fornece recomendações para os corrigir.

O Mandiant Attack Surface Management for Google Cloud permite que a sua organização veja melhor os respetivos recursos de nuvem híbrida ou multinuvem. Descobre automaticamente recursos de vários fornecedores de nuvem, DNS e a superfície de ataque externa alargada para dar à sua empresa uma compreensão mais profunda do respetivo ecossistema. Use estas informações para dar prioridade à correção das vulnerabilidades e exposições que apresentam o maior risco.

  • Solução de informações de segurança e gestão de eventos (SIEM) na nuvem: ajuda a recolher e analisar registos de segurança de ambientes híbridos e de várias nuvens para detetar e responder a ameaças. O SIEM do Google Security Operations ajuda a fornecer informações de segurança e gestão de eventos através da recolha, análise, deteção e investigação de todos os seus dados de segurança num único local. Google Cloud

Crie arquiteturas híbridas e de várias nuvens com Google Cloud: o que se segue