Este é o segundo artigo da série sobre Windows Azure. Iniciei a série há alguns dias com dois objetivos fundamentais: desmitificar a plataforma Azure e, através da apresentação de seus recursos, apresentar o valor agregado da plataforma para desenvolvedores e empresas que pensam em migrar seus ambientes.
No primeiro artigo da série apresentei uma visão geral da ferramenta, disponibilizando uma rápida descrição sobre cada uma das features da plataforma Azure. Se você está chegando agora na série, recomendo fortemente a leitura do texto anterior a este, que pode ser encontrado seguindo este link.
Hoje, discutiremos em maior profundidade o conceito de compute ou computing (como preferir) do Windows Azure. Ao final, você deverá estar apto a:
- Entender as diferenças entre os modelos de compute disponibilizados pela plataforma.
- Identificar o modelo de computação mais adequado para cada cenário.
- Ter a ideia de como funciona a escala horizontal proporcionada pelo Windows Azure.
Windows Azure e a ideia de compute
Em português brasileiro compute significa “computar” (faz sentido, não?!). Considerando o fato de que estamos nos referindo há um ambiente de computação em nuvem, em termos práticos, esta palavra pode assumir diversas conotações. Neste texto ampliaremos a escala do zoom acerca de compute na plataforma Azure.
Falar em compute no contexto do Windows Azure é o mesmo que dizer “ambiente de execução”, isto é, compute se refere as formas ou mecanismos disponibilizados pela plataforma e que possibilitam a execução das aplicações neste ambiente.
Em termos de ambiente de execução, Windows Azure disponibiliza três modelos para realizar a “computação” das aplicações, a saber:
- Web Roles
- Worker Roles
- Virtual Machine Roles (VM Roles)
Voltaremos a falar sobre cada um destes modelos de execução em breve neste texto entretanto, antes é de fundamental importância o entender outro conceito chave – instâncias.
Instâncias
O termo “instância” no contexto do Windows Azure significa “servidor virtual”. Conforme mencionado no primeiro artigo da série, a plataforma Azure está distribuída ao longo de 8 datacenters ao redor do mundo e seus recursos são alocados de forma dinâmica utilizando o conceito de virtualização. Você pode encontrar um bom texto sobre virtualização seguindo este link.
O Windows Azure disponibiliza através de uma infraestrutura resiliente e virtualizada o conceito de elasticidade. Assim, sua aplicação pode crescer conforme a demanda sem se preocupar com aspectos estruturais. O termo “elasticidade” significa que sua aplicação pode demandar quantas instâncias de servidores forem necessárias. O Windows Azure estará lá para disponibilizá-las. A Figura 1 apresenta um esquema gráfico representando as instâncias que acabamos de descrever.
Figura 1. Uma tarefa alocando quatro instâncias de servidores
Existem diferentes configurações de instâncias disponíveis no Windows Azure. Você pode visualizar estas configurações e seus respectivos valores de computação no site oficial do produto, disponível neste link.
A alocação do número de instâncias por Role pode ser realizada através do portal de administração do Windows Azure, através do arquivo de configuração das aplicações (falaremos destes arquivos futuramente nesta série) na realização do processo de deploy ou ainda, pelo código de sua aplicação (se esta possuir inteligência suficiente para realizar o auto scalling). Não há limites quanto ao número de instâncias a serem utilizadas em uma Role e os recursos alocados podem ser desalocados a qualquer momento. Você deve estar ciente apenas de que, a cada nova instância alocada, um novo recurso será cobrado.
Observação: para que o uptime de 99,95% seja garantido pela plataforma Azure (e para que sua aplicação entre em SLA), é preciso que a aplicação demande no mínimo duas instâncias de processamento. Esta requisição faz todo sentido pois, é o cenário mais simples onde pode haver redundância e balanceamento de carga.
Web Roles
Agora que nos é familiar o conceito de instâncias, estamos aptos discutir os aspectos técnicos relacionados aos ambientes de execução do Windows Azure.
Como o próprio nome sugere, uma Web Role é um ambiente dedicado a execução de aplicações web. Uma Web Role possui a característica marcante de possuir instância(s) pré-configurada(s) com o Internet Information Services (IIS). Qualquer aplicação web que seja hospedada no Windows Azure, necessariamente utiliza uma Web Role e pode ser executada sob IIS (aplicações .NET e PHP as são).
A Figura 2 apresenta o esquema básico de funcionamento das Web Roles (internamente).
Figura 2. A estrutura básica de uma Web Role (fonte: http://blogs.southworks.net)
A Figura 2 apresenta o esquema gráfico de uma Web Role. Vamos aos principais aspectos:
-
IIS Web UI: é um template de site pré-configurado que consegue ler e escrever em qualquer dos serviços de armazenamento do Windows Azure (Blobs, Tables e Queues).
-
Sincronizador: mantém consistentes os dados trocados entre o IIS Web UI e os serviços de armazenamento.
-
IIS API: API interna ao IIS que possibilita gerenciar os sites hospedados. Através desta API é possível criar novos sites, removê-los, modificá-los, movê-los, etc. Esta API já encontra-se embarcada no IIS pré-configurado das Web Roles.
-
Local Storage: toda instância de computação no Windows Azure possui um ambiente de armazenamento local. Este espaço é disponibilizado para que as aplicações possam buscar informações/recursos de forma mais rápida (já que este espaço encontra-se na mesma instância). Uma observação importante em relação ao armazenamento local é: no Windows Azure as instâncias são “stateless” isto significa que, em algum momento, a máquina virtual que executa a aplicação pode ser reciclada (entenda-se “destruída” e recriada) e, neste caso, um nova máquina assumirá a responsabilidade de execução (este processo é automatizado pelo Windows Azure e você nem saberá que aconteceu). Dado este cenário, recomenda-se utilizar o armazenamento local com cuidado pois, os dados serão perdidos de tempos em tempos.
Worker Role
A exemplo das Web Roles, as Worker Roles são ambientes de execução que possuem número de instâncias variáveis. A diferença básica entre estes ambientes está na natureza do mesmos. Enquanto uma Web Role é um ambiente dedicado a execução de aplicações web as Worker Roles são ambientes dedicados a execução de códigos executáveis em background (a modelo do que acontece com os Windows Services).
Para que esta ideia fique mais clara, considere um cenário web imaginário para o processamento digital de áudio. Uma Web Role pode receber um arquivo de áudio qualquer como entrada (via processo de upload) e no instante seguinte, algum processamento mais pesado com este arquivo (para adicionar watermark, por exemplo) pode ser requerido. Neste contexto, uma Worker Role com uma ou mais instâncias associadas poderia ser alocada para hospedar o algoritmo de inserção de marca d’água e, quando este processamento finalizasse, uma mensagem de sucesso poderia ser transmitida como retorno a Web Role através de uma queue. A Figura 3 ilustra este processo.
Figura 3. Descrição visual do cenário apresentado
Uma dúvida muito comum quando se apresenta o conceito associado as Worker Roles é: mas na prática, como disponibilizo um ambiente para executar códigos em background? Neste contexto, a associação com os windows services é inevitável, já que uma Worker Role funciona apenas como um ambiente executor, sem interfaces gráficas. Uma vez concluída a escrita do código que será executado em background, basta publicar o pacote com as configurações adequadas e testar o serviço. Em um artigo futuro nesta série, apresentaremos a prática com cada uma das abordagens, criando um projeto do zero até sua publicação passando por todos os detalhes.
Outro importante princípio associado diretamente as Worker Roles é o de map/reduce. A ideia aqui é a de se dividir um grande processamento em diversos pequenos (uma aplicação comumente encontrada neste paradigma são cálculos matemáticos complexos). Com as Worker Roles é possível segregar um processamento pesado em diversas Worker Roles ou ainda em diversas instâncias de uma mesma utilizando metodologias como Hadoop, por exemplo.
Virtual Machine Role (VM Roles)
VM Role é o terceiro modelo de computação disponível na plataforma Azure. Trata-se de um modelo de máquina virtual dedicada que suporta a importação de máquinas virtuais prontas, provenientes de ambientes on-premisses.
A ideia aqui é proporcionar ao usuário final, a possibilidade de executar aplicações em ambientes personalizados, não propostos originalmente pelo Windows Azure.
A pergunta que pode surgir neste momento é: Fabrício, eu consigo personalizar o meu sistema operacional na nuvem com complementos, plugins e softwares adicionais? A resposta é “sim, é possível”. As VM Roles disponibilizam um ambiente que suporta a importação de máquinas virtuais em formato VHD, assim, você pode criar sua máquina virtual no ambiente on-premisses, realizar todas as configurações necessárias e, em seguida, realizar o “upload” da mesma para o amebiente do WindowsAzure. Ao ser finalizado o upload, Windows Azure o armazena em um blob. Após isso, o Windows Azure “sobe” a máquina de forma automática para o ambiente de produção (esta máquina pode estar distribuída ao longo de várias instâncias e as cargas são gerenciadas pelo load balancer da plataforma).
Vale lembrar que, para que um VHD funcione corretamente no Windows Azure, o sistema operacional aceito é o Windows Server 2008 R2. A Figura 4 apresenta o modelo de computação proporcionado pelas VM Roles.
Figura 4. O modelo de computação proporcionado pelas VM Roles
É sempre importante manter o mind set de que, máquinas virtuais no Windows Azure são stateless. Desta forma, toda vez que sua VM Role for “reciclada”, um novo upload de seu arquivo VHD deve ser realizado.
Em um artigo futuro desta série, apresentaremos o trabalho com VM Roles na prática.
Por hoje é só. Não se esqueça de deixar seus comentários ao final e até o próximo post.
Pingback: Windows Azure – Perguntas e respostas – Fabrício Sanchez