Após falar sobre os fundamentos dos Azure, nesse post vou descrever de forma bem sucinta como ele funciona na sua máquina. Quando instalamos o SDK do Azure é adicionado ao Visual Studio um novo grupo de templates de projetos chamado Cloud Service, contendo:

  • ASP.NET Web Role
  • WCF Service Web Role
  • Worker Role
  • Cache Worker Role
  • Worker Role with Service Bus Queue

Além disso o Azure instala o Fabric Service e o Storage Service. Eles trazem consigo serviços já citados antes, como o de Load Balancing. Todos esses serviços trabalham juntos com uma instância de SQL Server Express para assim simular o ambiente de Storage do Azure. Não se preocupe, quando em produção, o Azure não vai guardar tudo em tabelas!

Em um post anterior foi mostrado como criar uma aplicação muito simples para exemplificar seu conteúdo. Vou me basear nessa aplicação para continuar o post, então se você ainda não a criou, crie-a agora para poder fazer sua própria análise.

Ao rodar a aplicação o Visual Studio inicia os seviços do Azure localmente e abre a página no browser – Lembrando que o Visual Studio deve ser executado como administrador para que ele possa iniciar esses serviços. Repare que o código da web role não tem nada de diferente comparado ao de um projeto comum, exceto por ser um projeto Azure e pelo arquivo WebRole.cs, o qual é um manipulador de eventos global da aplicação, parecido com o Global.asax. O que temos de diferente são os arquivos encontrados no mesmo nível da pasta do projeto web, dentro da pasta Roles. São os arquivos:

  • Arquivo de definição de serviço – ServiceDefinition.csdef
  • Arquivo de configuração de serviço – ServiceConfiguration.XXX.cscfg

O ServiceDefinition.csdef define as roles e os endpoints de comunicação do serviço. Isso inclui tráfico HTTP para um site ou os detalhes de um web service. Também é possível configurar o serviço para usar local storage, ou para adicionar algumas configurações personalizadas. A definição do serviço não pode ser mudada em tempo de execução,  qualquer mudança vai requerer um novo deploy. Você pode pensar nas configurações desse arquivo como uma definição da infraestrutura do serviço, e como suas partes funcionam juntas.

Os ServiceConfiguration.XXX.cscfg incluem toda a configuração necessária para as instâncias das roles do serviço. O conteúdo desses arquivos podem ser alterados em tempo de execução, então não é necessário redeploy para alterar essas configurações. Essas configurações também podem ser acessadas através do código, da mesma forma que podemos ler o arquivo Web.config em uma aplicação asp.net mvc. Cada ambiente possui um arquivo dedicado para suas configurações em ambiente local ou na nuvem, então seus nomes reais seriam ServiceConfiguration.Local.cscfg e ServiceConfiguration.Cloud.cscfg.

O conjunto de configurações definem o modelo de serviço. Cada projeto possui um modelo de serviço para a aplicação, o qual define como fazer o deploy da aplicação e como rodá-la na nuvem. Olhando para o modelo de serviço o Azure sabe o que fazer com o código, resumindo o processo de deploy a alguns cliques.

No próximo post vou falar como e porque escalar nossa aplicação. Não perca!

tags

AzureCloud

Juliano Alves

Juliano Alves é formado em Ciência da Computação e Especializado em Engenharia de Software pela PUC-SP e considera desenvolvimento de software uma arte. Trabalha com desenvolvimento a 6 anos, focado em métodos ágeis, possuindo experiência com Java, Scala, Ruby e Python, falando sobre elas no twitter @vonjuliano de vez em quando. Contribuinte do framework opensource Mirror, criado para simplificar o uso de reflection e commiter do VidaGeek Games, uma plataforma que mistura prática deliberada e Gamefication para ensino. Hoje trabalha na Lambda3, empresa envolvida no meio ágil desde que foi criada.