Já tem algum tempo que eu estou para escrever este post, entretanto, por conta dos muitos assuntos na pauta (eles vão se acumulando em cada novo projeto que atuo), acabei postergando sua escrita. Isso (de querer escrever sobre este tema) porque o tema é quente e ainda hoje gera muitas perguntas para quem chega para utilizar o Microsoft Azure pela primeira vez. Me refiro aos dois diferentes modelos arquiteturais de deployment existentes no Azure: Classic (ou Azure Service Manager – ASM) e Resource Manager (ou Azure Resource Manager – ARM). Com este texto pretendo abordar o tema em quatro diferentes plots:
- Um pouco de contexto;
- O porque da existência dos dois diferentes modelos;
- Diferenças estruturais entre eles;
- Quando usar um ou outro (ou ambos);
Um pouco de contexto
Quem trabalha com nuvem (independente do provedor) sabe: existem algumas perguntas que são comuns por parte dos clientes (e isso é perfeitamente normal, afinal de contas, estamos falando de um novo modelo de gestão de IT e boa parte das empresas estão sendo apresentadas a este cenário apenas agora). Questões relacionadas a custos, alta disponibilidade da infraestrutura, replicação entre regiões, escalabilidade, IaaS x PaaS, etc., estão no grupo daquelas usualmente encontradas. Quando falamos sobre Azure não é diferente: estas mesmas questões também se apresentam. Entretanto, existe um aspecto arquitetural da plataforma da Microsoft que, em um primeiro momento, gera uma outra pergunta que também entra no grupo daquelas recorrentes: “Quais são as diferenças entre os modelos Classic e Resource Manager do Azure? Qual eu devo utilizar no meu cenário?“.
Para responder de maneira efetiva a estas perguntas (e outras associadas a elas) precisamos, de verdade, de ter uma visão mais ampla do que simplesmente tecnologia. Precisamos olhar com cuidado as visões (estratégias) que cada empresa provedora de nuvem tem para suas plataformas. Neste caso especificamente (Azure), precisamos falar sobre como a Microsoft estruturou a construção de sua nuvem e para isso, precisamos recorrer a um pouco da história.
Quando a Microsoft anunciou sua plataforma de nuvem em 2008 o objetivo parecia claro: ser uma plataforma de nuvem com os melhores serviços de plataforma (PaaS). Serviços de plataforma, como você bem sabe, tendem a ter maior nível de abstração e portanto, um nível de mais alto também em termos de automatização. Claro que, abstração + automatização = pouca granularidade. Isso é proposital, uma vez que a ideia principal é que você possa focar na aplicação e não na infraestrutura (diferente do que propõe IaaS, provendo recursos para que seja possível implementar na nuvem pública ambientes semelhantes aqueles implementados on-premisse).
Naquele momento (imagino eu) como a Microsoft entendia que a nuvem pública deveria automatizar os processos fazendo assim com que as empresas pudessem ter um custo benefício mais efetivo com a nuvem, o modelo arquitetural de deployment proposto foi o “Azure Service Manager”, hoje formalizado como “Classic”.
O porque da existência dos dois diferentes modelos
Os dois modelos existem por uma razão muito simples: com o passar do tempo, ao ir aprendendo com o mercado, a Microsoft entendeu que, muito embora PaaS seja o melhor dos caminhos para a nuvem pública (eu pessoalmente acredito muito nisso), ele ainda é algo não tão trivial, especialmente para empresas de maior porte, que possuem alto volume de aplicações legadas.
Dessa forma, algo precisava ser feito no sentido de disponibilizar serviços de infraestrutura (para cenários onde serviços de plataforma não fossem adequados), como AWS já fazia, por exemplo. Ficou claro também, que o modelo arquitetural vigente (ASM) não seria adequado para a construção destes serviços por conta do modelo estrutural implementado pelo ASM.
Dessa forma, a Microsoft optou então (acertadamente, é importante que se diga) por criar um novo modelo de arquitetura de deployment que serviria como base para sua nova geração de serviços de nuvem (PaaS ou IaaS) – Azure Resource Manager (ARM). E neste mesmo momento, visando evitar possíveis confusões de nomenclatura, convencionou-se que todos os recursos provisionados sobre a arquitetura “ASM”, seriam chamados de “Recursos Classic”. De igual forma, todos aqueles serviços provisionados sobre a nova plataforma “ARM” seriam chamados de “Resource Manager”.
Não é incomum encontrar por aí quem diga que ASM é a v1 do Azure, enquanto ARM, é a v2. Não há nada convencionado formalmente pela Microsoft quanto a isso, entretanto, faz bastante sentido pensar dessa maneira :-). Outra observação importante aqui é: o ARM do Azure nada tem a ver com o modelo arquitetural dos processadores modernos ARM (Advanced RISC Machine), que possuem grupo reduzido de instruções em relação a outras arquiteturas. É apenas uma (in)feliz coincidência.
Diferenças operacionais e estruturais entre os modelos
Ok. Agora que já possuímos uma visão um pouco mais clara sobre o porque de os recursos estarem estruturados dessa maneira dentro do Azure, podemos falar de maneira mais técnica sobre as diferenças entre eles. Tais diferenças servirão de insumo para que possamos falar sobre quando optar por uma arquitetura ou outra. Para iniciarmos nossa sobre as diferenças estruturais entre os modelos, considere a Figura 1.
Figura 1. Comparação entre modelos estruturais
A Figura 1 é emblemática. Isso porque, apenas olhando para ela, é possível entender o quão diferentes os modelos são e mais, é possível entender porque a criação de um novo modelo (no caso ARM) se fazia necessário para o Azure no sentido de prover recursos de infraestrutura. Vamos aos elementos importantes que diferenciam tanto essas duas abordagens:
- AGRUPAMENTO. No modelo clássico (esquerda), como é possível perceber, não existe agrupamento de recursos lógicos relacionados. Se você notar, todos os três elementos apresentados pela imagem são individuais, não estão abaixo de um elemento principal agregador. Eles existem apenas individualmente. Agora pense: sua infra vai crescendo exponencialmente. Com o tempo, você terá centenas, milhares de storage accounts, cloud services e redes virtuais. Imagine gerenciar isso sem um agrupamento lógico de recursos. Seria complicado, não? Este é um primeiro aspecto que diferencia as duas abordagens. Como é possível visualizar na Figura 1, vários elementos individualizados estão agrupados abaixo de um resource group (que também é um recurso ARM). Você pode entender um resource group como sendo uma entidade de agrupamento, que pode receber qualquer tipo de conteúdo ARM em seu interior e que, por também ser um recurso ARM, possui os mesmo benefícios dos quais falaremos a seguir. Dessa forma, você pode agrupar recursos por aplicação, por grupo de aplicações ou por qualquer outra unidade lógica que faça sentido.
- GRANULARIDADE. Esta é a maior e mais importante entre as diferenças dos modelos. Como é possível visualizar na Figura 1, o modelo clássico segmenta os recursos em grupos maiores e independentes. Por exemplo, o cloud service agrupa em seu interior uma máquina virtual (para que uma VM exista no modelo clássico ela necessariamente precisa estar abaixo de um cloud service) já com endereço IP e um load balancer L3 de forma nativa. Já no modelo de resource manager, os mesmos recursos são quebradas em várias pequenas partes: VM, placa de rede, endereço IP da VM, load balancer, IP do load balancer. Ou seja, um bloco maior de recursos foi quebrado em pelo menos 5 bloquinhos menores. Porque isso é feito? Simples, para que você possa administrar as coisas de maneira minimalista. Assim, se você quiser, por exemplo, delegar a gestão das redes virtuais apenas para um profissional da sua estrutura, por exemplo, você poderá fazê-lo sem problemas.
- PERMISSIONAMENTO. O permissionamento, i. e., o nível de acesso (o que um usuário pode ou não fazer) que os usuários do Azure possuem em relação aos recursos criados, é outra importante diferença entre os modelos. No modelo clássico só existe “co-administrator” e “administrator”. Ambos conseguem efetuar qualquer tipo de operação em termos de provisionamento de serviços dentro da assinatura. Já no modelo implementado pelo resource manager (conhecido como RBAC), existem diferentes perfis com diferentes níveis de acesso e ainda, é possível criar níveis personalizados de acesso.
- APIs. Este é outro sensível ponto de diferença entre os modelos. Tanto recursos “Clássicos” quanto aqueles baseados em “Resource Manager” utilizam APIs completamente diferentes de provisionamento e gerenciamento de recursos. Ambos podem ser acessadas programaticamente, via Azure CLI ou PowerShell.
- TEMPLATES. Recursos provisionados sob o guarda-chuvas ARM possuem uma característica importante em relação aqueles provisionados sob o do clássico: eles podem ser criados através de templates (em formato JSON). Dessa forma, é possível criar templates genéricos que criam estruturas inteiras, simples ou complexas, já respeitando a dependência entre os recursos das mesmas, apenas passando o referido template JSON como padrão para o Azure. Recursos clássicos não possuem esta flexibilidade e somente podem ser gerenciados via CLI, Powershel ou portal.
- PORTAIS. Esta é a razão de uma das maiores confusões (e é completamente compreensível que seja) por parte de quem está chegando ao Azure pela primeira vez: os dois diferentes portais web existentes. Os portais podem ser acessados através dos links abaixo. O primeiro portal é mais antigo e permite a criação e gestão apenas de recursos clássicos e utiliza as APIs mais antigas, enquanto o segundo, é o portal atual e permite a gestão de recursos ARM e também clássicos, conectando-se as diferentes gerações de APIs. É importante mencionar que o portal recomendado pela Microsoft para a gestão de todos os recursos, é o portal atual.
- Portal Antigo (recursos clássicos): http://manage.windowsazure.com/
- Portal Atual (recursos ARM e clássicos): http://portal.azure.com/
- GRUPOS DE AFINIDADE. Os grupos de afinidade (ou affinity groups) foram criados para otimizar a utilização dos recursos clássicos dentro de um datacenter do Azure colocando recursos provisionados juntos em uma mesma unidade de deployment. Recursos ARM continuam usufruindo deste benefício, entretanto, é uma rotina realizada apenas internamente pelo fabric do Azure. Não é mais possível explicitar esta informação.
- SEPARAÇÃO TOTAL. Serviços ARM não se integram com recursos clássicos. Isto é, você não pode, por exemplo, adicionar uma máquina ARM abaixo de um cloud service clássico. De igual forma, você não pode adicionar no backend pool de um Application Gateway uma máquina clássica. Isso por conta das diferenças estruturais (granularidade, etc.) existentes entre eles. É possível fazer a migração de vários recursos clássicos para os “equivalentes” ARM, entretanto, não são todos os recursos que permitem esta migração. Você pode encontrar uma lista com estas possibilidades através deste link.
O modelo ARM foi o grande responsável por possibilitar a criação de serviços de alto nível no Azure. Toda a nova geração de recursos oferecidos pela plataforma estão on top do mesmo – resource manager. Apenas para citar alguns: App Services (todos eles), Cosmos DB, Virtual Machine Scale Set (VMSS), Application Gateway, dentre outros.
Quando utilizar um ou outro?
Depende. E eu explico o porque.
Diante de todas as características mencionadas anteriormente, você pode ser levado a pensar que o ideal é sempre optar pelo resource manager. E você está certo em pensar dessa maneira, dadas as enormes vantagens apresentadas por este modelo desde o início do texto até aqui. O caminho é esse mesmo. Oficialmente, a Microsoft recomenda que, ao fazer um novo deployment no Azure, o modelo resource manager seja o escolhido.
Entretanto, existem situações em que recursos disponíveis apenas no modelo clássico podem fazer muito sentido (e eu diria mais, podem fazer toda a diferença em termos de custo e performance da aplicação). Destaco aqui dois desses serviços: Web Roles e Worker Roles. Não vou entrar em detalhes sobre cada um destes serviços para não alongar demais este texto, entretanto, você pode encontrar mais informações sobre eles seguindo este link.
Certa vez trabalhei em um projeto em que uma aplicação ASP.NET (Web API) legada precisava ser levada para a nuvem. Ela precisava escalar de maneira linear e eficiente, dado o enorme volume de requisições atendidas por ela. Web App não era uma opção viável por conta de algumas dependências da aplicação com features do Windows. Tinhamos então duas opções: 1) recorrer ao modelo de VM Scale Sets (VMSS); 2) criar alguns scripts de configuração para rodar no startup tasks do servidor e utilizar as Web Roles. Fizemos então uma estimativa de preços e identificamos que VMSS estava pelo menos US$ dólares mais caro ao mês e, por esse motivo, optamos por testar a segunda opção com as Web Roles primeiro.
Após algum esforço para ajustar a aplicação para funcionar de maneira stateless e ainda, construir alguns scripts para “ligar” e configurar alguns recursos do sistema operacional, pudemos visualizar a aplicação funcionando de maneira adequada e escalando da maneira como gostaríamos através das Web Roles, que são recursos clássicos e que por tratarem de um “PaaS like” tem um custo reduzido em comparação com VMs tradicionais.
Coloco esta situação para dizer que, em arquiteturas de cloud, não existe bala de prata. Existem sim melhores práticas e recomendações oficiais, entretanto, análises cuidadosas caso-a-caso precisam ser realizadas no sentido de encontrar a melhor alternativa com os melhores custos. Neste caso, tratava-se de uma aplicação legada, que podia ser gerenciada de maneira apartada, com baixo esforço de manutenção e ainda, deveria apresentar o menor custo possível. Fez sentido!
É isso. Espero que este texto possa lhe ajudar a entender um pouco melhor os modelos arquiteturais do Azure e auxiliá-lo na melhor escolha quando for criar sua infraestrutura de aplicações e dados.
Pingback: Resource Group, O que é? Como criar? [#Scriptando] – Gustavo Magella Blog