Azure para profissionais do Google Cloud
Este artigo ajuda os especialistas do Google Cloud a compreender os conceitos básicos das contas, da plataforma e dos serviços do Microsoft Azure. Também aborda as principais semelhanças e diferenças entre as plataformas Google Cloud e Azure. (Observe que o Google Cloud foi anteriormente chamado de GCP (Google Cloud Platform).)
O que você aprenderá:
- Como contas e recursos são organizados no Azure.
- Como as soluções disponíveis são estruturadas no Azure.
- As principais diferenças entre os serviços do Azure e do Google Cloud.
O Azure e o Google Cloud desenvolveram as respectivas funcionalidades independentemente ao longo do tempo, de modo que têm diferenças importantes de design e implementação.
Visão geral do Azure para Google Cloud
Assim como o Google Cloud, o Microsoft Azure é construído em torno de um conjunto básico de serviços de computação, armazenamento, banco de dados e rede. Em muitos casos, ambas as plataformas têm uma equivalência básica entre os produtos e serviços que oferecem. Tanto o Google Cloud quanto o Azure permitem que você crie soluções altamente disponíveis com base em hosts do Linux ou do Windows. Portanto, se você estiver acostumado ao desenvolvimento com tecnologia OSS e Linux, as duas plataformas são eficazes.
Embora elas tenham funcionalidades semelhantes, os recursos que as fornecem são, em geral, organizados de forma diferente. As relações um-para-um entre os serviços necessários para compilar uma solução nem sempre são claras. Em outros casos, um serviço específico pode ser oferecido em uma plataforma, mas não na outra.
Gerenciamento de contas e assinatura
O Azure tem uma hierarquia de grupo de gerenciamento e assinaturas e grupos de recursos para gerenciar recursos com eficiência. Isso é semelhante à hierarquia de pastas e projeto para recursos no Google Cloud.
Níveis de escopo de gerenciamento do Azure
- Grupos de gerenciamento: esses grupos são contêineres que ajudam a gerenciar o acesso, a política e a conformidade para várias assinaturas. Todas as assinaturas em um grupo de gerenciamento herdam automaticamente as condições aplicadas ao grupo de gerenciamento.
- Assinaturas: uma assinatura associa logicamente as contas de usuários e os recursos que foram criados pelas contas de usuário. Cada assinatura tem limites ou cotas na quantidade de recursos que você pode criar e usar. As organizações podem usar assinaturas para gerenciar os custos e os recursos criados por usuários, equipes ou projetos.
- Grupos de recursos: é um contêiner lógico no qual os recursos do Azure, como aplicativos Web, bancos de dados e contas de armazenamento, são implantados e gerenciados.
- Recursos: recursos são instâncias de serviços que você cria, como máquinas virtuais, armazenamento ou bancos de dados SQL.
Os serviços do Azure podem ser adquiridos em várias opções de preços, dependendo do tamanho e das necessidades da sua organização. Confira os detalhes na página de visão geral de preços.
As assinaturas do Azure são um agrupamento de recursos com um proprietário atribuído, responsável por gerenciar cobranças e permissões.
Um projeto do Google Cloud é conceitualmente semelhante à assinatura do Azure, em termos de cobrança, cotas e limites. No entanto, de uma perspectiva funcional, um projeto do Google Cloud é mais parecido com um grupo de recursos no Azure. Ele é uma unidade lógica na qual os recursos de nuvem são implantados.
Observe que, ao contrário do que ocorre no Google Cloud, não há nenhum número máximo de assinaturas do Azure. Cada assinatura do Azure é vinculada a um único locatário do Microsoft Entra (uma conta, usando os termos do Google Cloud). Um locatário do Microsoft Entra pode conter um número ilimitado de assinaturas, enquanto o Google Cloud tem um limite padrão de 30 projetos por conta.
As assinaturas são atribuídas a três tipos de contas de administrador:
- Administrador da Conta. É o proprietário da assinatura, e também a conta responsável pelo pagamento dos recursos usados na assinatura. O administrador da conta só pode ser alterado transferindo-se a propriedade da assinatura.
- Administrador de Serviços. Esta conta tem direitos para criar e gerenciar recursos na assinatura, mas não é responsável pela cobrança. Por padrão, o administrador da conta e o administrador de serviços são atribuídos à mesma conta. O administrador da conta pode atribuir um usuário separado à conta de administrador de serviços para gerenciar os aspectos técnicos e operacionais de uma assinatura. Somente um administrador de serviços é atribuído por assinatura.
- Coadministrador. Pode haver várias contas de coadministrador atribuídas a uma assinatura. Os coadministradores não podem mudar o administrador de serviços, mas, quanto ao mais, têm controle total sobre os recursos de assinatura e os usuários.
Para o gerenciamento de acesso refinado aos recursos do Azure, você pode usar o RBAC do Azure (controle de acesso baseado em função do Azure), que inclui mais de 70 funções internas. Você também pode criar suas funções personalizadas.
Abaixo do nível de assinatura, as permissões individuais e de funções de usuário também podem ser atribuídas a recursos específicos. No Azure, todas as contas de usuário são associadas a uma Conta da Microsoft ou Conta Organizacional (gerenciada por meio do Microsoft Entra ID).
As assinaturas têm cotas e limites de serviço padrão. Para obter uma lista completa desses limites, confira Limites, cotas e restrições em assinaturas e serviços do Azure. Esses limites podem ser aumentados até o máximo preenchendo-se uma solicitação de suporte no portal de gerenciamento.
Confira também
- Como adicionar ou alterar funções de administrador do Azure
- Como baixar sua fatura de cobrança e dados de uso diário do Azure
Gerenciamento de recursos
O termo "recurso" no Azure significa qualquer instância de computação, objeto de armazenamento, dispositivo de rede ou outra entidade que você pode criar ou configurar na plataforma.
Os recursos do Azure são implantados e gerenciados com um destes dois modelos: Azure Resource Manager ou o antigo modelo de implantação clássico do Azure. Todos os recursos novos são criados com o modelo Resource Manager.
Grupos de recursos
Além disso, o Azure tem uma entidade chamada "grupos de recursos". Esses grupos organizam recursos como VMs, armazenamento e dispositivos de rede virtuais. Um recurso do Azure sempre está associado a um grupo de recursos. Um recurso criado em um grupo de recursos pode ser movido para outro, mas só pode ficar em um grupo por vez. Para obter mais informações, confira Migrar os recursos do Azure entre grupos de recursos, assinaturas e regiões. Os grupos de recursos são o agrupamento fundamental usado pelo Azure Resource Manager.
Os recursos também podem ser organizados usando-se marcas. Marcas são pares chave-valor que permitem agrupar recursos na assinatura, independentemente da associação ao grupo de recursos.
Interfaces de gerenciamento
O Azure oferece várias maneiras de gerenciar seus recursos:
- Interface da Web. O portal do Azure fornece uma interface de gerenciamento completa baseada na Web para os recursos do Azure.
- API REST. A REST API do Azure Resource Manager fornece acesso programático à maioria dos recursos disponíveis no portal do Azure.
- Linha de Comando. A CLI do Azure fornece uma interface de linha de comando capaz de criar e gerenciar recursos do Azure. A CLI do Azure está disponível para Windows, Linux e macOS.
- PowerShell. Os módulos do Azure para PowerShell permitem executar tarefas de gerenciamento automatizado usando um script. O PowerShell está disponível para Windows, Linux e macOS.
- Modelos. Os modelos do Azure Resource Manager fornecem funcionalidades de gerenciamento de recursos baseadas em modelo JSON.
- SDK. Os SDKs são uma coleção de bibliotecas que permitem que os usuários gerenciem e interajam por meio de programação com os serviços do Azure.
Em cada uma dessas interfaces, o grupo de recursos é fundamental para o modo como os recursos do Azure são criados, implantados ou modificados.
Além disso, muitas ferramentas de gerenciamento de terceiros, como o Terraform da HashiCorp e o Spinnaker da Netflix, também estão disponíveis no Azure.
Confira também
Regiões e Zonas de Disponibilidade
Falhas podem variar quanto ao escopo do seu impacto. Algumas falhas de hardware, como um disco com falha, podem afetar um único computador host. Um comutador de rede com falha pode afetar um rack de servidor inteiro. Menos comumente, vemos falhas que interrompem um data center inteiro, tais como uma queda de energia em um data center. Em raras situações, uma região inteira pode ficar indisponível.
Uma das principais maneiras de se tornar um aplicativo resiliente é por meio de redundância. No entanto, você precisa planejar essa redundância ao projetar o aplicativo. Além disso, o nível de redundância de que você precisa depende de seus requisitos de negócios. Nem todo aplicativo precisa de redundância entre regiões para se proteger contra uma interrupção regional. Em geral, há um equilíbrio entre mais redundância e confiabilidade em relação a maiores custo e complexidade.
No Google Cloud, uma região tem duas ou mais Zonas de Disponibilidade. Uma Zona de Disponibilidade corresponde a um datacenter fisicamente isolado na região geográfica. O Azure tem vários recursos para fornecer redundância de aplicativo em cada nível de uma possível falha, incluindo conjuntos de disponibilidade, zonas de disponibilidade e regiões emparelhadas.
A tabela a seguir resume cada opção.
| Conjunto de disponibilidade | Zona de Disponibilidade | Região emparelhada | |
|---|---|---|---|
| Escopo da falha | Rack | Datacenter | Region |
| Roteamento de solicitação | Load Balancer | Load Balancer entre zonas | Gerenciador de Tráfego |
| Latência da rede | Muito baixa | Baixo | Média a alta |
| Rede Virtual | VNET | VNET | Emparelhamento VNET entre regiões |
Conjuntos de disponibilidade
Para se proteger contra falhas de hardware localizadas, como falha em um comutador de rede ou de disco, implante duas ou mais VMs em um conjunto de disponibilidade. Um conjunto de disponibilidade consiste em dois ou mais domínios de falha que compartilham um comutador de rede e uma fonte de energia comuns. Máquinas virtuais em um conjunto de disponibilidade são distribuídas entre os domínios de falha, portanto, se uma falha de hardware afeta um domínio de falha, o tráfego de rede ainda poderá ser roteado para as VMs nos outros domínios de falha. Para obter mais informações sobre conjuntos de disponibilidade, consulte Gerenciar a disponibilidade das máquinas virtuais do Windows no Azure.
Quando instâncias de VM são adicionadas a conjuntos de disponibilidade, elas também recebem um domínio de atualização. Um domínio de atualização é um grupo de VMs definidas para eventos de manutenção planejada ao mesmo tempo. A distribuição de VMs em vários domínios de atualização garante que os eventos de atualização planejada e de aplicação de patch afetem apenas um subconjunto dessas VMs em determinado momento.
Os conjuntos de disponibilidade devem ser organizados pela função da instância no seu aplicativo, para garantir que uma instância de cada função esteja operacional. Por exemplo, em um aplicativo web de três camadas, crie conjuntos de disponibilidade separados para as camadas de front-end, aplicativos e camadas de dados.
Conjuntos de disponibilidade
Zonas de Disponibilidades
Assim como no Google Cloud, as regiões do Azure podem ter Zonas de Disponibilidade. Uma Zona de Disponibilidade é uma zona fisicamente separada em uma região do Azure. Cada zona de disponibilidade tem uma rede, resfriamento e fonte de energia distintos. A implantação de VMs em zonas de disponibilidade ajuda a proteger um aplicativo contra falhas em todo o datacenter.
Implantação de VM com redundância de zona no Azure
Para obter mais informações, consulte - Recomendações para usar zonas e regiões de disponibilidade.
Regiões emparelhadas
Para proteger um aplicativo contra uma interrupção regional, você pode implantar o aplicativo em várias regiões usando o Gerenciador de Tráfego do Azure a fim de distribuir o tráfego de Internet para as diferentes regiões. Cada região do Azure é emparelhada com outra. Juntas, elas formam um par regional. Com a exceção do Sul do Brasil, pares regionais estão localizados na mesma região geográfica para atender aos requisitos de residência de dados para fins de jurisdição de imposição fiscal e legal.
Diferentemente das Zonas de Disponibilidade, que, embora sejam datacenters fisicamente separados, podem estar em áreas geográficas relativamente próximas, as regiões emparelhadas ficam normalmente distantes no mínimo 300 milhas (cerca de 480 km). Esse design assegura que desastres em grande escala afetem somente uma das regiões do par. Os pares vizinhos podem ser definidos para sincronizar dados de serviços de armazenamento e de bancos de dados, e são configurados para que as atualizações de plataforma sejam distribuídas em apenas uma região do par de cada vez.
O backup do armazenamento com redundância geográfica do Azure é feito automaticamente na região emparelhada apropriada. Em todos os outros recursos, criar uma solução totalmente redundante usando regiões emparelhadas significa gerar uma cópia completa da sua solução em ambas as regiões.
Pares de regiões no Azure
Confira também
- Regiões para máquinas virtuais no Azure
- Opções de disponibilidade para máquinas virtuais no Azure
- Alta disponibilidade para os aplicativos do Azure
- Recuperação de desastre e falha para aplicativos do Azure
- Manutenção planejada para máquinas virtuais Linux no Azure
Serviços
Para ver uma lista que mostra como os serviços são mapeados entre as plataformas, confira a comparação entre os serviços do Google Cloud e do Azure.
Nem todos os produtos e serviços do Azure estão disponíveis em todas as regiões. Confira a página Produtos por região para obter detalhes. Você pode encontrar as garantias de tempo de atividade e políticas de crédito de tempo de inatividade para cada produto ou serviço do Azure na página Contratos de nível de serviço.