Não vou reinventar a roda, já há recurso em português se você quer ver o Azure funcionando. O Waldemir Cambiucci, arquiteto da Microsoft, já publicou dois posts bem legais sobre Azure, e eu recomendo que vocês dêem uma olhada lá. É uma ótima introdução.

No primeiro post, chamado Azure Services Platform : falando sobre o sistema operacional Windows Azure, ele apresenta os conceitos e um pouco da tecnologia.

No segundo post, chamado Azure Services Platform : seu primeiro “Hello Cloud” para o Windows Azure, ele faz um projeto simples, e ensina a colocar na nuvem.

Tendo em mente que você já leu estes posts, e sabe fazer uma aplicação simples com Azure (por simples entenda: não faz nada), vou colocar algumas observações interessantes que eu notei sobre o Azure.

1. Para o desenvolvimento local há um “mini Windows Azure” instalado na sua máquina (é instalado junto com o Azure SDK), chamado de “Development Fabric”. Ele interage com o SQL Server Express, ou seja, o ele precisa estar ligado (e está por padrão).
2. Por causa dessa interação com o Development Fabric, o Visual Studio tem que ser aberto com privilégio de administrador no Vista. Isso é bem ruim, até porque não dá para usar o Windows 7 onde UAC não é tão chado. Mas é um CTP, então tudo bem.
3. O projeto web é um projeto de web application normal como qualquer outro. Puxei os ProjectTypeGuids do projeto (descarregue o projeto e clique com o botão direito, selecionando “Edit <nomeDoArquivoDoProjeto>”), e os GUIDs são os seguintes:
   {349c5851-65df-11da-9384-00065b846f21} – Identifica um projeto web application
   {fae04ec0-301f-11d3-bf4b-00c04f79efbc} – Identifica um projeto C#
   Estes são os mesmos GUIDs de uma web application normal.
   Ainda assim, há dois elementos novos no nó  <PropertyGroup>, e são os seguintes:
   <RoleType>Web</RoleType>
   <ServiceHostingSDKInstallDir Condition=” ‘$(ServiceHostingSDKInstallDir)’ == ” “>
   $(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\ServiceHosting\v1.0@InstallPath)
   </ServiceHostingSDKInstallDir>
   Estes elementos são novos, não existiam antes. O primeiro aponta o tipo de role, que pode ser web ou worker, o segundo aponta um caminho no registro do Windows,e esse caminho de registro aponta para o diretório de instalação do SDK do Azure, que no meu PC é “C:\Program Files\Windows Azure SDK\v1.0\”:
   
4. Há uma referência ao assembly Microsoft.ServiceHosting.ServiceRuntime, que fica no diretório “ref”, debaixo do diretório do SDK. Este componente é um componente comum, dependente de .Net 3.5. Você pode ver isso nas referências do projeto:
   
   Abri o componente no Reflector. Aí apareceram algumas coisas interessantes, uma delas é uma dependência de um assembly que não existe em lugar nenhum, um tal de RDManagedAPI. Procurei esta dll nos diretórios do SDK e no GAC e nada. Nos caminhos de procura do Visual Studio ela também não existe. Deve existir somente no sistema operacional na nuvem. Esse componente não gerenciado, o fusion.dll eu também não conheço, deve ser do Azure também.
   Vejam abaixo o Reflector com o assembly aberto, e logo abaixo meu projeto web.
   
   Vejam como meu projeto web sequer referencia o componente Microsoft.ServiceHosting.ServiceRuntime. Como eu não usei ele para nada, o compilador removeu a referência. (Isso é padrão, qualquer projeto funciona assim.)
5. Volte na figura do Solution Explorer e veja qual o startup project (em negrito). Notou que é o projeto HelloClearSky, e não o HelloClearSky_WebRole (que é o projeto web app)?  Pois é, se você configurar o webrole como projeto de startup, ele roda! Afinal é um projeto simples ASP.Net. Não só roda como funciona. Quer dizer, vai funcionar enquanto você não acrescentar código específico do Azure, mas enfim, funciona. Para quem sabe fazer uma aplicação com baixo acoplamento isso abre possibilidades excelentes de ter uma aplicação web que roda no Azure, ou não. Se você rodar a aplicação do jeito padrão, com o projeto do Azure como o padrão, então o servidor do ASP.Net (antigo Cassini) não roda, e a aplicação web é hospedada no development fabric.
6. O projeto de configuração, como ficou claro, é que manda. Nele há alguns arquivos de configuração, todos em XML e ainda sem editor (será que vai ter um editor?). É lá que você fala o número de instâncias do serviço, os endpoints, etc. Este projeto, como vocês podem ver na imagem, tem uma referência ao projeto de webrole, e pode também ter ao projeto de workerrole. Ao compilar este projeto, ele toma o output do projeto webrole e coloca em um subdiretório. Fica assim:
   Diretório bin/debug:
   
   Diretório bin/debug/HelloClearkSky.csx:
   
   Por fim, diretório bin/debug/HelloClearkSky.csxroles/WebRole:
   
   Vejam como esta pasta contém, nada mais nada menos, que o output do projeto web app.
   O diretório bin/debug/publish não tem nada de mais, apenas arquivos de configuração xml.

Bom, com isso dá para desmistificar um pouco o que está acontecendo no Azure, principalmente na estação de desenvolvimento. Para ver tudo isso você não precisa ter a conta online, basta baixar o SDK e as ferramentas para o Visual Studio.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.