Azure para Google Cloud Professionals
Este artigo ajuda os especialistas do Google Cloud a compreender as noções básicas 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 era anteriormente chamado de Google Cloud Platform (GCP).)
Irá aprender:
- Como são organizadas as contas e os recursos no Azure.
- Como são estruturadas as soluções disponíveis no Azure.
- Como os principais serviços do Azure diferem dos serviços do Google Cloud.
O Azure e o Google Cloud criaram as suas capacidades de forma independente ao longo do tempo, para que cada um tenha diferenças importantes de implementação e design.
Visão geral do Azure para Google Cloud
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 oferecem 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 Linux ou Windows. Por isso, se está habituado à programação com tecnologia Linux e OSS, ambas as plataformas servem para o efeito.
Embora as capacidades de ambas as plataformas sejam semelhantes, os recursos que fornecem essas funcionalidades estão, muitas vezes, organizados de forma diferente. As relações um-para-um exatas entre os serviços necessários para criar uma solução nem sempre são claras. Noutros casos, um determinado serviço poderá ser disponibilizado numa plataforma, mas não na outra.
Gerir contas e subscrições
O Azure tem uma hierarquia de grupos e subscrições de Gestão e de grupos de recursos para gerir os recursos de forma eficaz. Isto é semelhante à hierarquia de Pastas e Projetos dos recursos no Google Cloud.
Níveis de âmbito de gestão do Azure
- Grupos de gerenciamento: esses grupos são contêineres que ajudam a gerenciar o acesso, a política e a conformidade de várias assinaturas. Todas as subscrições num grupo de gestão herdam automaticamente as condições aplicadas ao grupo de gestão.
- Subscrições: uma subscrição associa logicamente as contas de utilizador e os recursos que foram criados por essas contas de utilizador. Cada subscrição tem limites ou quotas no que se refere à quantidade de recursos que pode criar e utilizar. As organizações podem utilizar as subscrições para gerir os custos e os recursos criados por utilizadores, equipas ou projetos.
- Grupos de recursos: um grupo de recursos é um contêiner lógico no qual 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 com várias opções de preços, dependendo do tamanho e das necessidades da sua organização. Veja a página de descrição geral dos preços para obter mais detalhes.
As subscrições do Azure são um agrupamento de recursos com um proprietário atribuído responsável pela faturação e gestão de permissões.
Um projeto do Google Cloud é conceitualmente semelhante à assinatura do Azure, em termos de cobrança, cotas e limites. No entanto, de uma perspetiva funcional, um projeto do Google Cloud é mais parecido com um grupo de recursos no Azure. É uma unidade lógica na qual os recursos de nuvem são implantados.
Observe que, ao contrário do Google Cloud, não há um número máximo de assinaturas do Azure. Cada assinatura do Azure é vinculada a um único locatário do Microsoft Entra (uma conta, nos 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.
Às subscrições são atribuídas três tipos de contas de administrador:
- Administrador de Conta. O proprietário da subscrição e a conta em que são faturados os recursos utilizados na subscrição. O administrador de conta só pode ser alterado mediante a transferência da propriedade da subscrição.
- Administrador de Serviços. Esta conta tem direitos de criação e gestão de recursos na subscrição, mas não é responsável pela faturação. Por predefinição, o administrador de conta e o administrador de serviços são atribuídos à mesma conta. O administrador de conta pode atribuir outro utilizador à conta de administrador de serviços para gerir os aspetos técnicos e operacionais de uma subscrição. Existe apenas um administrador de serviços atribuído por subscrição.
- Coadministrador. Podem existir várias contas de coadministrador atribuídas a uma subscrição. Os coadministradores não podem alterar o administrador de serviços, mas têm controlo total sobre os recursos e utilizadores da subscrição.
Para um gerenciamento de acesso refinado aos recursos do Azure, você pode usar o controle de acesso baseado em função do Azure (Azure RBAC), que inclui mais de 70 funções internas. Pode também criar as suas próprias funções personalizadas.
Abaixo do nível da subscrição, também podem ser atribuídas funções de utilizador e permissões individuais a recursos específicos. No Azure, todas as contas de usuário são associadas a uma Conta da Microsoft ou Conta Organizacional (uma conta gerenciada por meio da ID do Microsoft Entra).
As subscrições têm limites e quotas de serviço predefinidas. Para obter uma lista completa destes limites, veja Subscrição do Azure e limites de serviço, quotas e restrições. Estes limites podem ser aumentados até o máximo através da apresentação de um pedido de suporte no portal de gestão.
Consulte também
- Como adicionar ou alterar funções de administrador do Azure
- Como transferir a fatura e os dados de utilização diária do Azure
Gestão de recursos
O termo "recurso" no Azure significa qualquer instância de computação, objeto de armazenamento, dispositivo de rede ou outra entidade que pode criar ou configurar na plataforma.
Os recursos do Azure são implementados e geridos através de um de dois modelos: Azure Resource Manager ou o modelo de implementação clássica do Azure mais antigo. Todos os novos recursos são criados com o modelo Resource Manager.
Grupos de recursos
Adicionalmente, o Azure tem uma entidade denominada "grupos de recursos", a qual organiza recursos como VMs, armazenamento e dispositivos de rede virtual. Um recurso do Azure está sempre associado a um grupo de recursos. Um recurso criado num grupo de recursos pode ser movido para outro grupo, mas só pode existir num grupo de recursos de cada vez. Para obter mais informações, consulte Mover recursos do Azure entre grupos de recursos, assinaturas ou regiões. Os grupos de recursos são o agrupamento fundamental utilizado pelo Azure Resource Manager.
Os recursos também podem ser organizados com etiquetas. As etiquetas são pares chave-valor que lhe permitem agrupar recursos na sua subscrição, independentemente da associação ao grupo de recursos.
Interfaces de gestão
O Azure disponibiliza várias formas para gerir os seus recursos:
- Interface Web. O portal do Azure fornece uma interface de gestão completa baseada na Web para os recursos do Azure.
- API REST. A API REST do Azure Resource Manager proporciona acesso programático à maioria das funcionalidades disponíveis no portal do Azure.
- Linha de Comandos. A CLI do Azure fornece uma interface de linha de comandos capaz de criar e gerir recursos do Azure. A CLI do Azure está disponível para Windows, Linux e macOS.
- PowerShell. Os módulos do Azure para PowerShell permitem-lhe executar tarefas de gestão automatizadas com um script. O PowerShell está disponível para Windows, Linux e macOS.
- Modelos. Os modelos do Azure Resource Manager fornecem capacidades de gestão de recursos baseadas em modelos JSON.
- SDK. Os SDKs são uma coleção de bibliotecas que permite aos usuários gerenciar e interagir programaticamente com os serviços do Azure.
Em cada uma destas interfaces, o grupo de recursos é fundamental para a forma como os recursos do Azure são criados, implementados ou modificados.
Além disso, muitas ferramentas de gestão de terceiros, como o Terraform da Hashicorp e o Spinnaker da Netflix, também estão disponíveis no Azure.
Consulte também
Regiões e Zonas de Disponibilidade
As falhas podem variar no âmbito do respetivo impacto. Algumas falhas de hardware, como um disco com falhas, podem afetar um único computador anfitrião. Um comutador de rede com falhas pode afetar todo um rack de servidores. As menos comuns são as falhas que afetam um datacenter completo, como a perda de energia num datacenter. Em situações raras, uma região inteira pode ficar indisponível.
Uma das principais formas que permitem tornar uma aplicação resiliente é a 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 precisa depende dos seus requisitos de negócio. Nem todas as aplicações precisam de redundância em todas as regiões para se protegerem de uma indisponibilidade a nível regional. Em geral, existe um compromisso entre maior redundância e fiabilidade versus maiores custos 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árias funcionalidades que garantem a redundância das aplicações a todos os níveis de uma potencial falha, incluindo conjuntos de disponibilidade, zonas de disponibilidade e regiões emparelhadas.
A tabela seguinte resume a cada opção.
| Conjunto de Disponibilidade | Zona de Disponibilidade | Região emparelhada | |
|---|---|---|---|
| Âmbito do incumprimento | Rack | Datacenter | País/Região |
| Roteamento de solicitações | Balanceador de Carga | Balanceador de Carga entre zonas | Gestor de Tráfego |
| Latência da rede | Muito baixa | Baixo | Média a alta |
| Rede virtual | VNet | VNet | VNet peering entre regiões |
Conjuntos de disponibilidade
Para proteger contra falhas de hardware localizadas, como, por exemplo, a falha de um comutador de rede ou de disco, implemente duas ou mais VMs num conjunto de disponibilidade. Um conjunto de disponibilidade é constituído por dois ou mais domínios de falha que partilham o mesmo comutador de rede e fonte de energia. As VMs num conjunto de disponibilidade estão distribuídas pelos domínios de falha, pelo que se uma falha de hardware afetar um domínio de falha, continua a ser possível encaminhar o tráfego de rede para as VMs dos outros domínios de falha. Para obter mais informações sobre Conjuntos de Disponibilidade, veja Gerir a disponibilidade das máquinas virtuais do Windows no Azure.
Quando as instâncias de VM são adicionadas a conjuntos de disponibilidade, também lhes são atribuídas um domínio de atualização. Um domínio de atualização é um grupo de VMs que estão definidas para eventos de manutenção planeada ao mesmo tempo. A distribuição das VMs por vários domínios de atualização garante que os eventos de aplicação de patches e de atualização planeados afetam apenas um subconjunto destas VMs a qualquer momento.
Os conjuntos de disponibilidade devem ser organizados pela função da instância na sua aplicação para garantir que uma instância em cada função está operacional. Por exemplo, numa aplicação web de três camadas, crie conjuntos de disponibilidade separados para o front-end, aplicação e camadas de dados.
Conjuntos de disponibilidade
Zonas de Disponibilidade
Como o Google Cloud, as regiões do Azure podem ter zonas de disponibilidade. Uma Zona de Disponibilidade é uma zona separada fisicamente numa região do Azure. Cada Zona de Disponibilidade tem uma fonte de energia, uma rede e um sistema de refrigeração distintos. A implementação de VMs por zonas de disponibilidade ajuda a proteger uma aplicação contra falhas ao nível de todo o datacenter.
Implementação de VMs com redundância entre zonas no Azure
Para obter mais informações, consulte - Recomendações para usar zonas e regiões de disponibilidade.
Regiões emparelhadas
Para proteger uma aplicação face a uma falha regional, pode implementar a aplicação em várias regiões, utilizando o Gestor de Tráfego do Azure para distribuir o tráfego da Internet para as diferentes regiões. Cada região do Azure está emparelhada com outra região. Em conjunto, as duas regiões formam um par regional. Com a exceção do Sul do Brasil, os pares regionais encontram-se dentro da mesma área geográfica para satisfazer os requisitos de residência dos dados para efeitos de jurisdição fiscal e jurídica.
Ao contrário das Zonas de Disponibilidade, que são datacenters separados fisicamente, mas podem estar em áreas geográficas relativamente próximas, as regiões emparelhadas estão normalmente separadas por, pelo menos, 483 quilómetros. Este design assegura que os desastres de grande escala afetam apenas uma das regiões do par. Os pares vizinhos podem ser definidos para sincronizar dados dos serviços de armazenamento e base de dados e são configurados de modo a que as atualizações de plataforma sejam implementadas apenas numa região do par de cada vez.
É automaticamente feita uma cópia de segurança do armazenamento georredundante do Azure para a região emparelhada adequada. Para todos os outros recursos, criar uma solução totalmente redundante com regiões emparelhadas significa criar uma cópia completa da sua solução em ambas as regiões.
Pares de Região no Azure
Consulte também
- Regiões das máquinas virtuais no Azure
- Opções de disponibilidade das máquinas virtuais no Azure
- Elevada disponibilidade para aplicações do Azure (High availability for Azure applications)
- Falha e recuperação após desastre para aplicações do Azure
- Manutenção planeada para máquinas virtuais do Linux no Azure
Serviços
Para obter uma lista de como os serviços são mapeados entre plataformas, consulte Comparação de serviços do Google Cloud para o Azure.
Nem todos os produtos e serviços do Azure estão disponíveis em todas as regiões. Consulte a página Produtos por Região para obter mais detalhes. Pode encontrar as garantias de tempo de disponibilidade e as políticas de crédito de períodos de indisponibilidade para cada produto ou serviço do Azure na página Contratos de Nível de Serviço.