Preparar seu ambiente para um cenário híbrido e multinuvem
A metodologia Preparar do Cloud Adoption Framework orienta os clientes enquanto eles preparam o ambiente para a adoção da nuvem. A metodologia inclui aceleradores técnicos, como as zonas de destino do Azure, que são os blocos de construção de qualquer ambiente de adoção da nuvem do Azure.
Este guia pode ajudá-lo a escolher a zona de destino certa para implantar em sua organização.
Zonas de destino híbridas e multinuvem
As zonas de destino do Azure são a saída de um ambiente de várias assinaturas do Azure que responde por:
- Escala
- Governança de segurança
- Rede
- Identidade
- Gerenciamento de custos
- Monitoramento
Suas considerações sobre o ambiente podem ser um pouco diferentes quando você está se preparando para uma implantação híbrida e multinuvem. Um ambiente consistente para qualquer implantação híbrida e multinuvem exige que você considere:
- Topologia de rede e conectividade
- Controles unificados de processo operacional 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 multinuvem e contém um conjunto de tecnologias. Cada arquitetura habilitada por ele inclui todas as áreas de design críticas e as considerações necessárias para criar uma implantação bem-sucedida.
Avaliar sua combinação de nuvem
Escolher um ambiente híbrido e multinuvem envolve uma série de decisões em vez de uma só decisão binária. Antes de configurar seu ambiente do Azure, identifique como o seu ambiente de nuvem dará suporte à combinação específica de decisões sobre hospedagem na nuvem. O seguinte diagrama contém alguns exemplos de combinações comuns de nuvem:
Nesse diagrama, cada ponto azul-escuro é uma carga de trabalho e cada círculo azul-claro é um processo empresarial, com suporte em um ambiente distinto.
Cada combinação de nuvem exige uma configuração de ambiente do Azure diferente. Você pode ver isso com nossos três clientes de referência:
Primeiro cliente híbrido: A maioria das cargas de trabalho permanecem locais, geralmente em uma combinação de modelos tradicionais, híbridos e portáteis de hospedagem de ativos. Algumas cargas de trabalho específicas são implantadas na borda, no Azure ou em outros provedores de nuvem.
- A Fabrikam é um cliente que prioriza a computação híbrida, com um grande investimento em datacenters obsoletos. As prioridades mais altas dela são custo e governança. As prioridades de TI herdadas e a infraestrutura de tecnologia obsoleta prejudicam a inovação da Fabrikam, o que levou a uma adoção antecipada da nuvem.
Cliente que prioriza o Azure: a maioria das cargas de trabalho é migrada para o Azure, enquanto algumas permanecem no local. As decisões estratégicas fizeram com que algumas cargas de trabalho ficassem na borda ou em ambientes de multinuvem.
- A Contoso é um cliente que prioriza o Azure. Assim como a Fabrikam, ela concluiu a primeira onda de transformação digital, adquiriu algumas empresas e adicionou clientes em setores regulamentados. A maior prioridade dela ainda é a inovação, mas com o ambiente multinuvem, ela se concentra no gerenciamento de operações. Ela precisa ter operações eficientes e escalonáveis para continuar a estratégia de aquisição.
Cliente que prioriza a multinuvem: a maioria das cargas de trabalho é hospedada em outra nuvem pública, como o GCP (Google Cloud Platform) ou a AWS (Amazon Web Services). As decisões estratégicas fizeram com que algumas cargas de trabalho ficassem no Azure ou na borda. Os clientes frequentemente passam de uma combinação que prioriza o híbrido para uma que prioriza o Azure à medida que a estratégia de nuvem amadurece, mas também damos suporte aos clientes que ter como prioridade as combinações de híbrido ou multinuvem. O Azure desempenha uma função em cada tipo de combinação.
- A Tailwind Traders é um cliente que prioriza a multinuvem. Assim como a Contoso, ela migrou para a nuvem, mas não usou o Azure para fazer isso. Ela tem alguns ativos de datacenter local e dispositivos de borda. A Tailwind Traders foi um dos usuários pioneiros de outras nuvens em uma fase inicial de start-up, e o crescimento é a maior prioridade. Os requisitos de varejo do cliente e a necessidade de operações aprimoradas que permitam uma escala eficiente impulsionam o crescimento do uso híbrido e de multinuvem.
Algumas considerações são essenciais para preparar qualquer ambiente de nuvem para o uso híbrido e de multinuvem. Sua estratégia de uso híbrido e de multinuvem para aplicativos e dados orienta as respostas para as perguntas a seguir. Identifique claramente a combinação de nuvem necessária e considere a melhor configuração para seus ambientes.
- Atualmente, você dá suporte a qual combinação de ambientes híbridos, de borda e de multinuvem?
- Qual combinação se alinha melhor à sua estratégia para o futuro?
- Você deseja operar cada plataforma de maneira independente ou por meio de operações unificadas e uma abordagem de painel de controle único?
Visão geral do Azure Arc
O ideal é simplificar ambientes complexos e distribuídos em ambientes locais, de borda e de multinuvem. O Azure Arc permite a implantação de serviços do Azure em qualquer lugar e estende o gerenciamento do Azure para qualquer infraestrutura.
Organizar e administrar em vários ambientes: tenha controle sobre bancos de dados, clusters do Kubernetes e servidores distribuídos em ambientes locais, de borda e de multinuvem, por meio da organização e da governança centrais em um só lugar.
Gerenciar aplicativos do Kubernetes em escala: use técnicas de DevOps para implantar e gerenciar aplicativos do Kubernetes em vários ambientes. Lembre-se de implantar e configurar os aplicativos de maneira consistente por meio do controle do código-fonte.
Executar serviços do Azure em qualquer lugar: obtenha aplicação de patch automatizada, atualizações, segurança e escala sob demanda em ambientes locais, de borda e de multinuvem para seu patrimônio 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 capacidade de autoatendimento aos recursos do VMware vSphere e do System Center Virtual Machine Manager por meio do Azure. Execute o ciclo de vida da VM e as operações de ciclo de energia do portal do Azure e crie a automação usando modelos, APIs e SDKs do Azure.
Instantâneo do cliente do Azure Arc
Os três clientes de referência mencionados anteriormente executam cargas de trabalho em um hardware diferente. Eles também executam cargas de trabalho em datacenters locais e vários provedores de nuvem pública e dão suporte a cargas de trabalho de IoT implantadas na borda. As cargas de trabalho incluem vários serviços e são baseadas em servidores bare-metal, máquinas virtuais, serviços PaaS (plataforma gerenciada como serviço) ou aplicativos nativos de nuvem e baseados em contêiner.
Os três clientes percebem que precisam ter práticas estabelecidas de uso híbrido e de multinuvem para alcançar o sucesso dos negócios. A necessidade de cargas de trabalho modernizadas está se tornando crucial para a relevância dos três clientes nas respectivas áreas.
Com o Azure Arc como seu plano de controle híbrido e multinuvem, esses clientes podem usar os investimentos de TI existentes e as práticas operacionais atuais de maneira 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 machine learning para modernizar cargas de trabalho, garantindo que ainda atendam aos requisitos de soberania de dados.
O Azure Arc estende as APIs do ARM (Azure Resource Manager) 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 unificadas, gerenciamento, conformidade, segurança e governança em escala. Ela é implementada com:
- Monitoramento centralizado
- Logging
- Telemetria
- Políticas
- Gerenciamento de patch
- Controle de Alterações
- Gerenciamento de estoque
- Detecção de ameaças
- Gerenciamento e auditoria de vulnerabilidades de segurança
Configurar seu ambiente inicial do Azure
Para cada combinação de nuvem, você precisará ter um ambiente do Azure para dar suporte, controlar e gerenciar seus recursos de nuvem. A metodologia Ready do Cloud Adoption Framework fornece algumas etapas para ajudá-lo a preparar seu ambiente:
Considere cada uma das áreas de design da zona de destino do Azure e avalie corretamente seus requisitos técnicos.
Compare seus requisitos com as opções de implementação de zona de destino do Azure para encontrar 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 de zona de destino do Azure.
Azure Arc como acelerador de zona de destino
Os recursos do Azure Arc podem fazer parte de qualquer aplicativo. Os 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. Os serviços do Azure Arc criados para fins específicos, como o VMware vSphere habilitado para Azure Arc e o System Center Virtual Machine Manager habilitado para Azure Arc, projetam ativos de TI implantados no VMware vCenter e no System Center Virtual Machine Manager gerenciados em datacenters locais no Azure.
- Clusters do Kubernetes gerenciados pelo cliente em um ambiente multinuvem.
- Dados, aplicativos e serviços de machine learning habilitados para Azure Arc que funcionam na borda.
As assinaturas da zona de destino do aplicativo também podem conter recursos do Azure Arc e recursos comuns 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 zona de destino. Não importa se ele é uma plataforma ou um aplicativo e segue a democratização da assinatura e os princípios de design com neutralidade de arquétipo e centrados no aplicativo.
Exemplos comuns de recursos do Azure Arc nas zonas de destino do Azure
Os exemplos a seguir mostram como projetar recursos do Azure Arc como recursos de metadados em zonas de destino do Azure.
Primeiro exemplo: como projetar controladores de domínio fora do Azure
Muitos clientes têm implantações do AD DS (Active Directory Domain Services) nos 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 destino do Azure, há uma assinatura da zona de destino de identidade dedicada projetada para hospedar recursos baseados em identidade. Você pode hospedar essa assinatura no Azure usando VMs (máquinas virtuais) de controlador de domínio do AD DS. Você também pode projetá-la no Azure de qualquer outro local por meio de servidores habilitados para Azure Arc.
Segundo exemplo: como projetar datacenters locais no Azure
A maioria dos clientes ainda tem datacenters locais presentes nos ambientes. Os volumes desses datacenters podem variar de servidores individuais a ambientes virtualizados grandes.
Os clientes podem tratar os datacenters locais como zonas de destino normais e colocá-los em zonas de destino novas ou existentes conforme achem adequado. Duas abordagens comuns incluem:
- Migrar os recursos do projeto para assinaturas de zona de destino dedicadas de recursos do datacenter local.
- Em ambientes maiores com vários datacenters em todo o mundo, os clientes podem ter uma zona de destino por região geopolítica. Essas zonas de destino 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 nos requisitos de segurança, de governança e de conformidade para diferentes datacenters locais.
- Migrar os recursos de projeto para assinaturas de zona de destino separadas com base em outros recursos do Azure que dão suporte ao mesmo aplicativo ou serviço.
Terceiro exemplo: como projetar 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 do aplicativo fora do Azure. Os clientes ainda desejam controlar, administrar, proteger e operar centralmente todos os recursos que compõem o aplicativo. O Azure Arc permite que os clientes alcancem essa meta.
Nesse cenário, os clientes devem projetar os recursos do Azure Arc para o aplicativo na mesma assinatura da zona de destino do aplicativo na qual implantam os recursos do Azure. Em seguida, os clientes podem aplicar um conjunto de controles a todos os recursos em um só painel de controle, independentemente do local em que estejam os recursos.
Exemplo quatro: projetar servidores locais que atingiram o fim do suporte no Azure para usar as Atualizações de Segurança Estendidas fornecidas por meio do Azure Arc
Muitos clientes têm versões do Windows Server que estão chegando ao fim do suporte e não podem cumprir o prazo de fim do suporte, mas precisam permanecer no local. Nesse cenário, eles procurariam comprar Atualizações de Segurança Estendidas habilitadas pelo Azure Arc.
Se os clientes estiverem implantando uma Zona de Destino do Azure ou já tiverem uma implantada, os clientes poderão tratar seus datacenters locais como zonas de destino normais e colocá-los em zonas de destino novas ou existentes conforme acharem adequado. Duas abordagens comuns incluem:
Migrar os recursos do projeto para assinaturas de zona de destino dedicadas de recursos do datacenter local.
Em ambientes maiores com vários datacenters em todo o mundo, os clientes podem ter uma zona de destino por região geopolítica. Essas zonas de destino 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 nos requisitos de segurança, de governança e de conformidade para diferentes datacenters locais.
Migrar os recursos de projeto para assinaturas de zona de destino separadas com base em outros recursos do Azure que dão suporte ao mesmo aplicativo ou serviço.
Os clientes devem examinar as diretrizes do acelerador de zona de destino de servidores habilitados para Azure Arc para examinar 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 Destino do Azure no momento:
- Os clientes devem examinar as diretrizes do acelerador de zona de destino de servidores habilitados para Azure Arc para examinar as considerações e recomendações de design em áreas críticas de design.
Próximas etapas
Para obter mais informações sobre seu percurso na nuvem híbrida e multinuvem, confira os artigos a seguir.