Prepare seu ambiente para um cenário híbrido e multicloud

A metodologia Cloud Adoption Framework Ready orienta os clientes à medida que preparam seu ambiente para a adoção da nuvem. A metodologia inclui aceleradores técnicos, como zonas de aterrissagem do Azure, que são os blocos de construção de qualquer ambiente de adoção de nuvem do Azure.

Este guia pode ajudá-lo a escolher a zona de aterrissagem certa para implantar em sua organização.

Híbrido e multicloud em zonas de aterragem

As zonas de aterrissagem do Azure são a saída de um ambiente do Azure com várias assinaturas que responde:

• Escala
• Governação da segurança
• Rede
• Identidade
• Gestão de custos
• Monitorização

Suas considerações de ambiente podem ser ligeiramente diferentes quando você está se preparando para uma implantação híbrida e multicloud. Um ambiente consistente para qualquer implantação híbrida e multicloud requer que você considere:

• Topologia e conectividade de rede
• Controles de processo operacional unificados para operações, governança, segurança e conformidade
• Disciplinas de automação unificadas e consistentes, experiência de desenvolvimento e práticas de DevOps em ambientes heterogêneos

O Azure Arc habilita arquiteturas híbridas e multicloud e contém um conjunto de tecnologias. Cada arquitetura que ele habilita inclui todas as áreas críticas de design e considerações necessárias para criar uma implantação bem-sucedida.

Avalie sua combinação de nuvens

A escolha de um ambiente híbrido e multicloud envolve uma gama de decisões em vez de uma única decisão binária. Antes de configurar seu ambiente do Azure, identifique como seu ambiente de nuvem dará suporte à sua combinação específica de opções de hospedagem na nuvem. O diagrama a seguir contém alguns exemplos de misturas de nuvens comuns:

Neste diagrama, cada ponto azul escuro é uma carga de trabalho e cada círculo azul claro é um processo de negócios suportado por um ambiente distinto.

Cada combinação de nuvens requer uma configuração de ambiente do Azure diferente. Você pode ver isso com nossos três clientes de referência:

• Cliente híbrido-primeiro: a maioria das cargas de trabalho permanece no local, muitas vezes em uma mistura de modelos de hospedagem de ativos tradicionais, híbridos e portáteis. Algumas cargas de trabalho específicas são implantadas na borda, no Azure ou em outros provedores de nuvem.

  • A Fabrikam é um cliente híbrido com um investimento pesado em datacenters envelhecidos. As suas maiores prioridades são os custos e a governação. As prioridades de TI legadas e a infraestrutura de tecnologia envelhecida prejudicam a inovação da Fabrikam, o que impulsiona alguma adoção precoce da nuvem.

• Cliente do Azure-first: a maioria das cargas de trabalho é movida para o Azure, enquanto algumas cargas de trabalho permanecem no local. As decisões estratégicas levam a que algumas cargas de trabalho vivam na borda ou em ambientes multicloud.

  • A Contoso é um cliente do Azure-first . Como a Fabrikam, completou sua primeira onda de transformação digital, adquiriu algumas empresas e adicionou clientes em setores regulamentados. Sua maior prioridade ainda é a inovação, mas com seu ambiente multicloud, está focada no gerenciamento de operações. Precisa de operações eficientes e escaláveis para continuar sua estratégia de aquisição.

• Cliente multicloud-first: a maioria das cargas de trabalho é hospedada em uma nuvem pública diferente, como o Google Cloud Platform (GCP) ou a Amazon Web Services (AWS). As decisões estratégicas levam a algumas cargas de trabalho vivendo no Azure ou na borda. Os clientes mudam frequentemente de uma combinação híbrida-primeiro para uma combinação Azure-first à medida que sua estratégia de nuvem amadurece, mas também damos suporte aos clientes que decidem tornar as combinações híbridas ou multicloud sua prioridade. O Azure desempenha um papel em cada tipo de mistura.

  • A Tailwind Traders é um cliente multicloud-first . Como a Contoso, ela foi movida para a nuvem, mas não usou o Azure para fazer isso. Ele tem alguns ativos de datacenter locais e dispositivos de borda. A Tailwind Traders é uma das primeiras a adotar outras nuvens em uma fase inicial de inicialização, e sua maior prioridade é o crescimento. Os requisitos de varejo do cliente e a necessidade de operações aprimoradas que permitam um dimensionamento eficiente impulsionam o crescimento híbrido e multicloud.

Algumas considerações são críticas para preparar qualquer ambiente de nuvem para híbrido e multicloud. Sua estratégia híbrida e multicloud para aplicativos e dados direciona suas respostas para as seguintes perguntas. Identifique claramente qual combinação de nuvens você precisa e, em seguida, considere a melhor configuração para seus ambientes.

• Que mistura de ambientes híbridos, de borda e multicloud você suporta hoje?
• Qual a mistura que melhor se alinha com a sua estratégia para o futuro?
• Você deseja operar cada plataforma de forma independente ou por meio de operações unificadas e uma abordagem de painel único?

Descrição geral do Azure Arc

Talvez você queira simplificar ambientes complexos e distribuídos no local, na borda e em várias nuvens. O Azure Arc permite implantar serviços do Azure em qualquer lugar e estende o gerenciamento do Azure a qualquer infraestrutura.

• Organize e administre entre ambientes: obtenha bancos de dados, clusters Kubernetes e servidores que se espalham por ambientes locais, de borda e multicloud sob controle por meio da organização central e da governança de um único local.

• Gerenciar aplicativos Kubernetes em escala: use técnicas de DevOps para implantar e gerenciar aplicativos Kubernetes em todos os ambientes. Certifique-se de implantar e configurar aplicativos consistentemente a partir do controle do código-fonte.

• Execute os serviços do Azure em qualquer lugar: obtenha patches, atualizações, segurança e dimensionamento automatizados sob demanda em ambientes locais, de borda e multicloud para seu conjunto de dados.

• Habilite o acesso de autoatendimento às suas máquinas virtuais: use o RBAC (controle de acesso baseado em função) do Azure para conceder a capacidade de autoatendimento aos recursos do VMware vSphere e do System Center Virtual Machine Manager por meio do Azure. Execute operações de ciclo de vida e ciclo de energia da VM a partir do portal do Azure e crie automação usando modelos, APIs e SDKs do Azure.

Instantâneo do cliente do Azure Arc

Todos os três clientes de referência mencionados anteriormente executam cargas de trabalho em hardware diferente. Eles também executam cargas de trabalho em datacenters locais e vários provedores de nuvem pública e suportam cargas de trabalho de IoT implantadas na borda. Suas cargas de trabalho incluem vários serviços e são baseadas em servidores bare-metal, máquinas virtuais, serviços de plataforma gerenciada como serviço (PaaS) ou aplicativos baseados em contêiner nativos da nuvem.

Todos os três clientes percebem que precisam ter práticas híbridas e multicloud estabelecidas para alcançar o sucesso do negócio. A necessidade de cargas de trabalho modernizadas está se tornando crucial para a relevância dos três clientes em suas áreas respeitadas.

Com o Azure Arc como seu plano de controle híbrido e multicloud, esses clientes podem usar os investimentos de TI existentes e as práticas operacionais atuais de forma não distributiva. Para continuar usando suas práticas atuais, os clientes integram estes recursos:

• Servidores habilitados para Azure Arc, VMware vSphere habilitado para Azure Arc ou System Center Virtual Machine Manager habilitado para Azure Arc
• Servidores SQL
• Clusters do Kubernetes

Eles usam serviços de dados habilitados para Azure Arc, serviços de aplicativos e serviços de aprendizado de máquina para modernizar suas cargas de trabalho e, ao mesmo tempo, garantir que ainda atendam aos requisitos de soberania de dados.

O Azure Arc estende as APIs do Azure Resource Manager (ARM) para que você possa representar qualquer carga de trabalho como um cidadão de primeira classe no Azure. Essa extensão fornece a base para você implementar operações, gerenciamento, conformidade, segurança e governança unificados em escala. É implementado com:

• Monitorização centralizada
• Registo
• Telemetria
• Políticas
• Gestão de patches
• Registo de alterações
• Gestão de inventário
• Deteção de ameaças
• Gestão e auditoria de vulnerabilidades de segurança

Configurar seu ambiente inicial do Azure

Para cada combinação de nuvens, você precisará de um ambiente do Azure para dar suporte, governar e gerenciar seus recursos de nuvem. A metodologia Ready do Cloud Adoption Framework fornece algumas etapas para ajudá-lo a preparar seu ambiente:

• Revisão O que é uma zona de aterrissagem do Azure?

• Considere cada uma das áreas de design da zona de aterrissagem do Azure e avalie adequadamente seus requisitos técnicos.

• Compare seus requisitos com as opções de implementação da zona de aterrissagem do Azure para localizar e implementar o modelo mais adequado para sua configuração.

• Saiba como Fazer a transição de ambientes existentes do Azure para a arquitetura conceitual da zona de aterrissagem do Azure.

Azure Arc como um acelerador de zona de aterrissagem

Os recursos do Azure Arc podem fazer parte de qualquer aplicativo. Exemplos incluem:

• Servidores habilitados para Azure Arc, VMware vSphere habilitado para Azure Arc e System Center Virtual Machine Manager habilitado para Azure Arc, que representam ativos de TI implantados fora do Azure. Serviços criados especificamente para o Azure Arc, como o VMware vSphere habilitado para Azure Arc e o System Center Virtual Machine Manager habilitado para Azure Arc, ativos de TI de projeto implantados no VMware vCenter e System Center Virtual Machine Manager gerenciados datacenters locais no Azure.
• Clusters Kubernetes gerenciados pelo cliente em um ambiente multicloud.
• Serviços de dados, aplicativos e aprendizado de máquina habilitados para o Azure Arc trabalhando na borda.

As assinaturas da zona de aterrissagem do aplicativo também podem conter recursos do Azure Arc e recursos regulares do Azure.

Como os recursos do Azure Arc estão localizados fora do Azure, você pode considerá-los um recurso de metadados da maneira como são representados no Azure. Trate os recursos do Azure Arc como qualquer outro recurso do Azure que possa fazer parte da sua zona de aterrissagem. Não importa se é uma plataforma ou aplicativo, e ele segue a democratização da assinatura e os princípios de design centrados em aplicativos e arquétipos neutros .

Exemplos comuns de recursos do Azure Arc em zonas de aterrissagem do Azure

Os exemplos a seguir mostram como você pode projetar recursos do Azure Arc como recursos de metadados nas zonas de aterrissagem do Azure.

Exemplo um: Projetando controladores de domínio fora do Azure

Muitos clientes têm implantações dos Serviços de Domínio Ative Directory (AD DS) em seus ambientes. Os controladores de domínio são um componente crítico do AD DS e da arquitetura geral dos clientes.

Na arquitetura conceitual da zona de aterrissagem do Azure, há uma assinatura dedicada da zona de aterrissagem de identidade projetada para hospedar recursos baseados em identidade. Você pode hospedar essa assinatura no Azure usando máquinas virtuais (VMs) do controlador de domínio (DC) do AD DS. Você também pode projetá-lo no Azure de qualquer outro local por meio de servidores habilitados para Azure Arc.

Exemplo dois: Projetando datacenters locais no Azure

A maioria dos clientes ainda tem datacenters locais presentes em seus ambientes. As pegadas desses datacenters podem variar de servidores únicos a grandes ambientes virtualizados.

Os clientes podem tratar seus datacenters locais como zonas de pouso normais e colocá-los em zonas de pouso novas ou existentes como acharem melhor. Algumas abordagens comuns incluem:

• Movendo recursos do projeto para assinaturas de zona de aterrissagem dedicadas para recursos de datacenter locais.
  • Em ambientes maiores com vários datacenters em todo o mundo, os clientes podem ter uma zona de pouso por região geopolítica. Essas zonas de aterrissagem também contêm os recursos dessa região para fornecer uma separação lógica dos datacenters locais no Azure.
  • Essa abordagem também pode ajudar com os requisitos de segurança, governança e conformidade para diferentes datacenters locais.
• Mover recursos do projeto para subscrições de zona de aterragem separadas com base noutros recursos do Azure que suportam a mesma aplicação ou serviço.

Exemplo três: Projetando recursos de aplicativos remotos no Azure

Os clientes podem desenvolver aplicativos sensíveis à latência ou aplicativos com requisitos de soberania de dados. Esses aplicativos podem precisar hospedar recursos que fazem parte de seu aplicativo fora do Azure. Os clientes ainda querem controlar, governar, proteger e operar centralmente todos os recursos que criam seus aplicativos. O Azure Arc permite que os clientes atinjam esse objetivo.

Nesse cenário, os clientes devem projetar os recursos do Azure Arc para seu aplicativo na mesma assinatura da zona de aterrissagem do aplicativo na qual implantam recursos do Azure. Os clientes podem então aplicar um conjunto de controles a todos os recursos a partir de um único plano de controle, não importa onde os recursos estejam.

Exemplo quatro: Projetando servidores locais que atingiram o fim do suporte no Azure para usar as Atualizações de Segurança Estendidas entregues por meio do Azure Arc

Muitos clientes têm versões do Windows Server que estão perto do fim do suporte e não conseguem cumprir o prazo de fim do suporte, mas precisam permanecer no local. Nesse cenário, eles procurariam comprar as Atualizações de Segurança Estendidas habilitadas pelo Azure Arc.

Se os clientes estiverem implantando uma Zona de Aterrissagem do Azure ou já tiverem uma implantada, os clientes poderão tratar seus datacenters locais como zonas de aterrissagem normais e colocá-las em zonas de aterrissagem novas ou existentes como acharem melhor. Algumas abordagens comuns incluem:

• Movendo recursos do projeto para assinaturas de zona de aterrissagem dedicadas para recursos de datacenter locais.

• Em ambientes maiores com vários datacenters em todo o mundo, os clientes podem ter uma zona de pouso por região geopolítica. Essas zonas de aterrissagem também contêm os recursos dessa região para fornecer uma separação lógica dos datacenters locais no Azure.

• Essa abordagem também pode ajudar com os requisitos de segurança, governança e conformidade para diferentes datacenters locais.

• Mover recursos do projeto para subscrições de zona de aterragem separadas com base noutros recursos do Azure que suportam a mesma aplicação ou serviço.

• Os clientes devem rever as diretrizes do acelerador de zona de aterrissagem dos Servidores habilitados para Arco do Azure para revisar as considerações e recomendações de design em áreas críticas de design.

Se os clientes não tiverem ou não planejarem implantar uma Zona de Aterrissagem do Azure no momento:

• Os clientes devem rever as diretrizes do acelerador de zona de aterrissagem dos Servidores habilitados para Arco do Azure para revisar as considerações e recomendações de design em áreas críticas de design.

Próximos passos

Para obter mais informações sobre sua jornada de nuvem híbrida e multicloud, consulte os artigos a seguir.

• Analise a Introdução ao acelerador de zona de aterrissagem de servidores habilitados para Azure Arc para híbrido e multicloud.

• Saiba como Implantar o Azure Arc sandbox para acelerar a adoção de arquiteturas híbridas ou multicloud.