Levando aplicações .NET para a Cloud

Uma de nossas mais recentes pesquisas e projetos de desenvolvimento foi uma aplicação bancária on-line, a qual utilizamos para demonstrar a última tendência em desenvolvimento .NET.

Quando chegou a hora de implantar, não encontramos uma máquina adequada para a publicação. Mas espere! Nestes tempos isto já não é mais um problema. Quando você necessita implantar uma nova aplicação pode simplesmente fazê-la na cloud mais próxima.

Obviamente, a melhor escolha caiu sobre plataforma Azure. A questão apenas foi o nível de dificuldade que esta implantação traria?  Levaria dias para adaptar a aplicação para esta plataforma?

Na verdade, o processo de mudança fluiu muito melhor do que imaginávamos e dentro de uma hora fomos capazes de configurar as partes necessárias e já executar a aplicação na cloud.

Mas a plataforma Azure oferece muito mais do que uma plataforma de execução para as suas aplicações web. Oferece também várias formas distintas de armazenamento. E uma destas opções é o Azure Blob Storage.

E após a tranquila implantação, pensamos: e se utilizássemos Azure Blob Storage para implementar uma das novas funcionalidades o qual estava em nosso to-do list, e que se encaixa perfeitamente neste tipo de armazenamento?

E é o objetivo deste blog, que descreve a nossa experiência com Azure e que estará dividido em duas partes.

Na primeira parte, veremos como implantar uma aplicação .NET existente na plataforma Azure. Na segunda parte, que será postada brevemente, demonstrará como fazer o uso do Azure Blob Storage para desenvolver funcionalidades simples de gerenciamento de conteúdo para a aplicação (Eletronic Vault).

Antes de mergulharmos em detalhes mais técnicos, vamos apenas apresentar a plataforma Azure e seus serviços oferecidos, para que possamos entender melhor quais partes da plataforma serão descritos neste artigo.

Visão Geral da Plataforma Azure

Windows Azure foi liberado comercialmente desde Fevereiro de 2010 e oferece a oportunidade a desenvolvedores de construir aplicações escaláveis usando várias e distintas tecnologias e linguagens. Além de uma plataforma de execução para diferentes tipos de aplicações escritas em diferentes tipos de linguagens, Azure também oferece serviços adicionais. Segue um resumo sobre a plataforma:

  • Runtime plataform
    • Existem dois tipos de aplicações que podem ser hospedadas:
      • Web Role: preparado para hospedar aplicações web
      • Worker Role: preparado para hospedar qualquer aplicação que não trata chamadas HTTPs (exemplo: tarefas comuns de tratamento de dados)
  • Hosting virtual machines
  • Cloud based storage
    • Azure SQL storage
    • Azure NoSQL storage
      • BLOB storage
      • Queue
      • Table (key-value)
  • Content Delivery Network

 

Esta é uma visão simplificada e geral da plataforma, muito mais descrições detalhadas podem ser encontradas no site oficial Windows Azure Page. Agora que vimos os serviços oferecidos vamos continuar com a descrição da aplicação.

Arquitetura da Aplicação

Como foi dito anteriormente, a aplicação que decidimos por implantar é uma aplicação bancária simples e on-line. É composta de um cliente Silverlight que consome serviços WCF  hospedados em um servidor IIS 7 e utiliza SQL Server 2008 como seu principal armazenador de dados.

Vamos dar uma olhada na arquitetura e nas alterações que serão realizadas para a mudança para o Azure.

As setas vermelhas neste diagrama representam as migrações que serão feitas quando for mudado para o Azure.

Para resumir o que o digrama quer dizer: a aplicação até o momento foi hospedada em um servidor IIS e depois da transição será hospedada por um Azure Web Role. SQL Server será trocado pelo Azure SQL storage. Na segunda parte deste artigo, vamos mostrar como adicionar  Azure Blob Storage nesta arquitetura.

Como você pode notar no diagrama, a aplicação utiliza NHibernate as ORM(Object Relational Mapping) para acessar os dados. Uma das questões que tínhamos era: NHibernate irá funcionar com Azure SQL, bom, a resposta é sim. Porque Azure SQL é muito similar ao SQL Server 2008, nenhuma mudança de configuração é necessária e o mesmo provedor de dados pode ser utilizado. Apenas mude a sua connection string e você está pronto para continuar.

Entendendo a arquitetura das aplicações Web no Azure

 

Vejamos em mais detalhes a arquitetura da aplicação Web comum implantada no Azure.

 

Uma aplicação web típica pode ter um ou vários Input Endpoints. Para um Web Role, um Input Endpoint é uma porta HTTP em um endereço IP atribuído pelo Azure. O tráfego sempre tem carga balanceada, mesmo se houver apenas uma instância de um Web Role. Na verdade, o acordo de nível de serviço do Azure dispõe que cada aplicação deve ter, no mínimo, duas instâncias – caso contrário, o Azure não garante o on-time mencionado no acordo de nível de serviço. O número de instâncias que devem ser criadas pode ser facilmente alterado na configuração do projeto “cloud” no Visual Studio.

No diagrama, podemos visualizar Worker Roles; na verdade, nossa aplicação não contém nenhum, mas podemos visualizar uma aplicação console simples operando regularmente, realizando tratamento de background nos dados armazenados no banco de dados. Esse tipo de aplicação seria executado em uma instância de Worker Role. Note que não especifiquei o tipo de armazenamento, já que é possível utilizar qualquer tipo de armazenamento proposto pelo Azure.

Tanto os Web Roles, quanto os Worker Roles, são executados em nodos dentro da Azure Fabric.

Azure Fabric é o nome da rede do Azure. Essa rede é composta por nodos interconectados, cada um executando Windows Server 2008, de modo dedicado ou composto, para criar um ambiente virtualizado.

Preparando a aplicação para a Cloud

Antes de começar, certifique-se de que instalou o Visual Studio 2010 Azure Toolkit. Isso instalará os modelos de projetos “em Cloud” do Visual Studio, bem como o Azure Emulator.

O Azure Emulator permite que você experimente em seu computador os recursos que, normalmente, só estão disponíveis em cloud, bem como experimentar balancear sua aplicação em várias instâncias de role. Mais especificamente: O Azure Emulator não contém Azure SQL, pois é possível “emulá-lo” simplesmente utilizando sua versão local do SQL Server. Por outro lado, não há versões locais para outros tipos de armazenamento (Blob, Queue e Table), os quais, portanto, são apresentados no emulador.

Para implantar a solução no Azure, o projeto de implantação do Azure deve ser adicionado à solução.

Octo.Bank.Web é a aplicação web ASP.NET que expõe diversos serviços WCF e hospeda o cliente Silverlight. O recém-criado projeto Octo.Bank.CloudService tem um Role – mencionado anteriormente no projeto Web. Se o projeto tiver outros roles (web ou worker), eles serão adicionados a essa lista.

Há dois arquivos de configuração (em formato XML), que permitem a definição de endpoints de aplicações, número e tipos de instâncias role que devem ser criadas e diversas outras opções. Essa configuração pode ser alterada também editando a página de Propriedades de cada role.

O Visual Studio permite a implantação direta na plataforma Azure (selecionando Publicar no menu de contexto do projeto Cloud). O seguinte diálogo especifica os detalhes da publicação: as credenciais do desenvolvedor que está realizando a publicação, o serviço hospedado no qual a aplicação será implantada e a conta de armazenamento que será utilizada para fazer o upload do pacote da aplicação.

Antes que isso possa ser feito, várias partes devem ser configuradas no Portal de Gerenciamento Azure.

Portal de Gerenciamento Azure

O Portal de Gerenciamento Azure é uma aplicação web que permite a configuração de todos os Serviços Azure. Assim, é possível utilizar o Portal de Gerenciamento Azure para criar e gerenciar aplicações, bancos de dados e todos os tipos disponíveis de armazenamento. Esse portal está disponível no seguinte endereço: https://windows.azure.com/.

Conectando o Visual Studio com Azure

Para que o desenvolvedor seja capaz de Publicar diretamente para o Azure, terá que gerar um certificado na sua máquina de desenvolvimento, que o Visual Studio utilizará ao fazer o upload dos arquivos para o Azure. Na segunda etapa, esse certificado deve ser adicionado à lista de certificados no Portal de Gerenciamento Azure. A imagem a seguir mostra a parte de gerenciamento de certificados do portal azure. É possível ver que há dois certificados. Cada desenvolvedor que desejar utilizar o Visual Studio para interagir com o Azure deve criar e fazer o upload do seu certificado.

Movendo a aplicação

Antes de publicarmos a aplicação do Visual Studio, temos que criar um contêiner para a aplicação. Esse contêiner é chamado Serviço Hospedado. Cada Serviço Hospedado tem duas “implantações”: produção e ordenamento.
A tela a seguir mostra a lista de serviços hospedados no portal de gerenciamento. É possível ver que há uma implantação com dois ambientes (ordenamento e produção). Cada ambiente tem apenas um web role e há apenas uma instância para cada web role.

Movendo o banco de dados

Antes de mover o banco de dados, temos que Criar um novo banco de dados no Portal de Gerenciamento Azure. Ao criar o banco de dados, o desenvolvedor deve definir qual endereço IP será capaz de acessar o banco de dados. Geralmente, o banco de dados é acessado a partir do Web Role ou Worker Role, que estão na mesma Rede Virtual criada pelo Azure. Porém, para fins de desenvolvimento, por vezes é necessário acessar o banco de dados diretamente, utilizando o SQL Server Management Studio, ou outra ferramenta. Para essas situações, o Azure oferece um firewall que pode ser personalizado para controlar o tráfego de entrada.

Após a criação do banco de dados, uma connection string é gerada e pode ser utilizada para acessar o banco de dados. A tela a seguir vem do portal de gerenciamento do banco de dados, destacando a regra de firewall que permite acesso remoto ao banco de dados.

Caso já haja um banco de dados em produção, há diversas possibilidades para fazer a migração: exportar os scripts do banco de dados e executá-los no banco de dados Azure SQL, ou utilizar uma das ferramentas de migração existentes. A lista completa de possibilidade pode ser encontrada nesta página oficial.

Conclusão

Se sua solução for bem estruturada, a implantação de uma aplicação existente na plataforma Azure pode levar vários minutos. Após criar o projeto em cloud do Azure, preparar o banco de dados e o serviço hospedado, é possível intercambiar facilmente as connection strings e realizar a implantação na cloud.

Uma das peças faltantes poderia ser a possibilidade de implantação automática a partir do Team Foundation Server. Esse recurso não está disponível inicialmente, mas há uma API que permite a implantação e configuração a partir da aplicação .NET ou do script PowerShell. Essa API pode ser utilizada para desenvolver atividades personalizadas que podem ser adicionadas ao processo de desenvolvimento do Team Foundation Server. Há um projeto open source em andamento com o objetivo de disponibilizar esse recurso, acessível no codeplex.

Caso tenha interesse no Azure e queira saber mais, aguarde a segunda parte deste artigo, que discutirá o Azure Blob Storage.