Sei que esse é um YAWAP (yet another Windows Azure post) já que existem por aí bom artigos sobre o Azure, mas talvez possa trazer alguns elementos novos para quem, assim como eu, está começando a viver nas nuvens!

O Windows Azure

Para quem ainda não conhece, o Windows Azure é uma plataforma da Microsoft para rodar aplicações em esquema de Cloud Computing, ou seja, rodando em um farm de servidores. Obviamente não basta pegar qualquer aplicação é subí-la para o datacenter: ela precisa estar preparada para rodar na nuvem. No caso específico do Windows Azure, essas aplicações deverão ser feitas em .Net. Quem já tem aplicações muito bem estruturadas em termos de arquitetura não terá muito problema para rodar sua aplicação na nuvem, apenas terá um trabalho pesado na layer de persistência.

A aplicação que pretendo fazer

Pretendo colocar nas nuvens uma aplicação que modelei a quase 10 anos atrás e da qual já existe uma versão rodando feita em Delphi e que é mantida pela empresa onde fui sócio. Tenho toda análise pronta, incluindo algoritmos (sim, milagre!), então não precisarei me preocupar com regras de negócio. Como na  época a OO ainda era algo novo para mim, talvez tenha que fazer alguns ajustes agora.

Essa aplicação calcula os custos de uma empresa de serviços utilizando a metodologia RKW. Essa metodologia também é conhecida como Método dos Centros de Custos, Método das Seções Homogêneas, Mapa de Localização de Custos ou ainda, Custeio Pleno. Essa metodologia foi criada na primeira metade do século 20 na Alemanha, por isso tem como nome as iniciais do conselho governamental alemão para assuntos econômicos (Reichskuratorium für Wirtschaftlichtkeit).

Saliento que esse post é focado na descrição da minha experiência com o Azure em uma aplicação LoB e não em detalhes da implementação da solução em si, já que necessitaria de vários posts para isso!

Esse post estou escrevendo enquanto desenvolvo a aplicação, então ainda não sei se tudo que pretendo funcionará no Azure.

Preparando o ambiente de desenvolvimento

A idéia do Windows Azure é “desenvolva localmente, publique globalmente”. Dessa forma é necessário que você tenha algumas ferramentas da Microsoft: Visual Studio, Sql Server,  o SDK do Azure, etc. Como acredito que a maioria da minha “audiência” seja de programadores .Net, isso não será problema.

De qualquer forma, para quem ainda não tem as ferramentas, recomendo utilizar o mais novo lançamento da Microsoft, o Microsoft Web Plataform ( http://www.microsoft.com/web/ ) , que instala para você todas as ferramentas necessárias: Visual Studio Express, IIS, Sql Server Express, etc. Como disse meu amigo Marcos, o Microsoft Web Plataform é uma espécie de “easyPhP” para .Net.

Você precisará instalar também o Windows Azure SDK e o Windows Azure Tools for Visual Studio. Fique atento pois esses links poderão indicar a instalação de alguns hotfix para resolver problemas pontuais do Visual Studio.

O SDK é a parte mais interessante da brincadeira: ele emula localmente o ambiente do Azure, permitindo o desenvolvimento e debug local:

Recomendo também a instalação do Training Kit do Azure, que possui muita documentação.

Detalhe importantíssimo: para publicar seus projetos nos servidores da Microsoft é necessário uma conta. Essa conta não é liberada imediatamente, então o quanto antes você solicitar, melhor. A solicitação pode ser feita aqui: http://www.microsoft.com/azure/register.mspx. Note que para desenvolver a aplicação localmente não é necessário esse token.

A Arquitetura da aplicação

Como em todos meus projetos, esse também será baseado em DDD (Domain Driven Design). Grosso modo, a arquitetura pode ser dividida dessa forma:

Como deixo completamente desacoplada as camadas, caso algo não funcione com o Azure, posso transformar a aplicação em uma aplicação “clássica” asp.net.

A interface do usuário será feita com Asp.Net MVC. O Silverlight 3 me pareceu uma boa pedida, mas eu teria uma curva de aprendizado que me tiraria do foco nesse momento.

Windows Azure Storage e Sql Data Services

Acredito que a maior mudança que o Azure nos impõe é na persistência dos dados. Para isso existem dois serviços: Windows Azure Storage e Sql Data Services

No momento, o Windows Azure Storage é hierárquico, não relacional. O modelo lembra os antigos IMS que reinavam nos Mainframes. Confesso que para mim esse modelo também traz mais dúvidas que certezas, principalmente no que diz respeito à performance. Também podemos “esquecer” a forma como executamos queries em um RDBMS.

Por outro lado temos algumas vantagens. A primeira é a facilidade com que podemos acessar os dados através de uma interface REST. Para aplicações WEB isso é fantástico.
Outras vantagens dependem de termos fé no marketing da Microsoft que garante a alta escalabilidade das bases de dados, bem como a disponibilidade dos dados, já que eles são replicados por diversos servidores no FARM do Azure. Fisicamente, os dados são gravados em bases Sql Server.

Alternativamente existe o serviços Sql Data Services, cujo objetivo é trazer uma experiência mais próxima dos Bancos de Dados Relacionais.

Pelo que entendi, o SDS é indicado para quem precisa manter na nuvem um grande volume de dados, independente de possuir uma aplicação rodando em Cloud, enquanto o Windows Azure Storage é um serviço mais simples.

Para acessar o Azure Storage você pode usar SOAP ou REST. Como isso não é nada amigável, a Microsoft enviou junto como SDK um projeto chamado StorageClient (está em $diretoriosdk\samples\StorageClient). Esse projeto é um “wrapper” que permite acessar as tabelas Azure com queries Linq. Creio que quando sairmos da fase CTP ou Beta tenhamos algo mais garantido. Por outro lado vejo uma inclinação por parte da Microsoft de impor o Astoria para acessar o storage do Azure.

Sinceramente essa parte de storage do Azure me desanimou um pouco. Tudo muito bonito em teoria, mas na prática ainda me pareceu improdutivo para gerenciar(pode parecer frescura, mas um “Azure Storage Management Studio” faz falta), além do que está tudo em fase  beta ou pré-beta ainda.
Acho compliado desenvolver algo sério por enquanto pois corremos o risco de termos as definições alteradas a qualquer momento.

E agora, José?

Fiquei boa parte deste final de semana estudando o Azure. Não havia tido nenhum contato prévio e minha idéia era utilizá-lo na aplicação que eu propus acima, mas a conclusão a que eu cheguei é de que o Azure ainda está muito cru para algo real.

Existe uma grande questão ainda não resolvida que é o billing do serviço, ou seja, como e quanto a Microsoft irá cobrar pelos serviços.

Resolvi tocar minha aplicação no modo “clássico” por enquanto, já que as layers de Domínio e Apresentação são independentes da plataforma utilizada (web clássica ou Azure) e quando o Azure passar da fase CTP e entrar em RC ou RTM bastará que eu imlemente os repositórios específicos.

Recursos

Alguns links interessantes:

http://www.microsoft.com/azure/default.mspx – Página oficial do Azure

http://wm.microsoft.com/ms/msdn/azure/scalablestoragetables.wmv:Exemplo screncast sobre como criar uma tabela  no Azure Storage

http://www.aaronlerch.com/blog/2008/11/01/run-aspnet-mvc-on-windows-azure/- Como rodar aplicações ASP.Net MVC no Azure

http://unplugged.giggio.net/unplugged/category/Azure.aspx- Série de posts do Giovanni Bassi sobre o Azure.

http://blogs.msdn.com/ssds/- Blog da Equipe do SDS

http://blogs.msdn.com/windowsazure – Blog da Equipe do Azure