APRESENTANDO O WINDOWS AZURE

Transcrição

1 APRESENTANDO O WINDOWS AZURE DAVID CHAPPELL OUTUBRO DE 2010 PATROCINADO PELA MICROSOFT CORPORATION

2 SUMÁRIO Visão geral do Windows Azure... 2 Computação... 4 Armazenamento... 6 Controle da malha... 7 Content Delivery Network... 9 Conexão Usando cenários do Windows Azure Criando um aplicativo Web escalonável Criando um aplicativo com processamento paralelo Criando um aplicativo Web escalonável com processamento em segundo plano Criando um aplicativo Web com dados relacionais Migração de um Aplicativo Web In Loco com Dados Relacionais Usando o armazenamento na nuvem a partir de um aplicativo local ou hospedado Entendendo o Windows Azure: uma visão mais detalhada Criação de Aplicativos do Windows Azure Examinando o serviço de computação Examinando o serviço de armazenamento Blobs Tabelas Filas Examinando o Controlador da Malha O futuro Conclusões Leitura adicional Sobre o autor

3 VISÃO GERAL DO WINDOWS AZURE A computação em nuvem chegou. A execução de aplicativos e o armazenamento de dados em máquinas em um data center acessível via Internet podem oferecer uma série de vantagens. Mas onde quer que sejam executados, esses aplicativos são criados em algum tipo de plataforma. Para aplicativos locais, como aqueles executados dentro do data center de uma organização, essa plataforma geralmente inclui um sistema operacional, alguma forma de armazenar dados e talvez algo mais. Aplicativos em execução na nuvem também precisam de uma base semelhante. O objetivo do Windows Azure é oferecer essa base. O Windows Azure é parte de algo maior, a plataforma Windows Azure, e funciona como uma base para a execução de aplicativos Windows e armazenamento de dados na nuvem. A figura 1 ilustra essa ideia. Negócios Consumidores Internet Aplicativos Dados Windows Azure Data Centers da Microsoft Figura 1: os aplicativos do Windows Azure são executados nos data centers da Microsoft e são acessados pela Internet. Em vez de fornecer software que os clientes da Microsoft possam instalar e executar por conta própria em seus computadores, hoje o Windows Azure é um serviço: os clientes fazem uso dele para executar aplicativos e armazenar dados em máquinas acessíveis pela Internet e que pertencem à Microsoft. Esses aplicativos podem oferecer serviços para empresas, para os consumidores ou para ambos. Veja alguns exemplos dos tipos de aplicativos que podem ser criados com o Windows Azure: 2

4 Um fornecedor de software independente (ISV) pode criar um aplicativo voltado para usuários corporativos, abordagem muitas vezes rotulada como Software como um Serviço (SaaS). O Windows Azure foi projetado em parte para suportar os próprios aplicativos SaaS da Microsoft, então os ISVs também podem usá-lo como base para uma série de softwares na nuvem de caráter empresarial. Um ISV pode criar um aplicativo SaaS voltado para os consumidores em vez de empresas. O Windows Azure foi feito para suportar software muito escalonável, e com isso uma empresa que pretenda atender a um amplo mercado de consumidores pode escolhê-lo como plataforma para um novo aplicativo. As empresas podem usar o Windows Azure para criar e executar aplicativos usados por seus próprios funcionários. Ainda que essa situação dificilmente vá exigir a enorme escalabilidade de um aplicativo voltado para os consumidores, a confiabilidade e a capacidade de gerenciamento oferecidas pelo Windows Azure continuam fazendo dele uma oferta atraente. Para suportar dados e aplicativos na nuvem, o Windows Azure possui cinco componentes, como mostra a Figura 2. Aplicativos e Dados CDN Conectar Computação Armazenamento Malha Controlador Windows Azure Figura 2: o Windows Azure tem cinco partes principais: Computação, Armazenamento, Controlador da Malha, CDN e Conexão. Esses componentes são: Computação: executar aplicativos na nuvem Esses aplicativos enxergam um ambiente do Windows Server, apesar de o modelo de programação do Windows Azure não ser exatamente o mesmo que o modelo do Windows Server in loco. Armazenamento: armazena dados binários e estruturados na nuvem. Controlador da malha: implanta, gerencia e monitora aplicativos. O controlador da malha também lida com as atualizações no software do sistema por toda a plataforma. Content Delivery Network (CDN): acelera o acesso global a dados binários no armazenamento do Windows Azure ao manter cópias em cache daqueles dados no mundo inteiro. 3

5 Conexão: permite a criação de conexões no nível de IP entre computadores in loco e aplicativos Windows Azure. O restante desta seção apresenta cada uma dessas tecnologias. COMPUTAÇÃO O serviço de computação do Windows Azure pode executar muitos tipos diferentes de aplicativos. Independente do que fizer, um aplicativo deve ser implementado como uma ou mais funções. Então, o Windows Azure geralmente executa múltiplas instâncias de cada função, usando balanceamento embutido para distribuir as solicitações entre elas. A figura 3 ilustra isso. Instâncias de Web Role Instâncias de Worker Role Instâncias de função da VM IIS Balanceador de carga HTTP/HTTPS, TCP Máquinas Virtuais Aplicativos e Dados CDN Conectar Computação Armazenamento Malha Controlador Figura 3: um aplicativo Windows Azure em execução consiste em qualquer combinação de instâncias da Web Role, instâncias da Worker Role e instâncias da função VM. Na versão atual do Windows Azure, os desenvolvedores podem escolher entre três tipos de função: Web Roles, cuja principal finalidade é facilitar a criação de aplicativos baseados na Web. Cada instância da Web Role traz o Internet Information Services (IIS) 7 pré-configurado, o que simplifica a criação de aplicativos usando ASP.NET, Windows Communication Foundation (WCF) ou outra tecnologia Web. Os desenvolvedores também podem criar aplicativos em código nativo o uso do.net Framework não é obrigatório. Isso significa que eles também podem instalar e executar outras tecnologias, não pertencentes à Microsoft, incluindo PHP e Java. 4

6 As Worker Roles, projetadas para executar uma série de códigos baseados no Windows. A maior diferença entre uma Web Role e uma Worker Role é que esta não traz o IIS configurado, então o código que ela executa não é hospedado pelo IIS. Uma Worker Role pode, por exemplo, executar uma simulação, manipular um processamento de vídeo ou fazer praticamente qualquer coisa. É comum um aplicativo interagir com usuários por meio de uma Web Role e então entregar as tarefas para que sejam processadas por uma Worker Role. Mais uma vez, o desenvolvedor é livre para usar o.net Framework ou outro software que seja executado no Windows, incluindo tecnologias não pertencentes à Microsoft. Funções VM, cada uma delas executa uma imagem do Windows Server fornecida pelo usuário. Entre outras coisas, uma função VM às vezes pode ser útil na migração de um aplicativo in loco do Windows Server para o Windows Azure. Para enviar um aplicativo para o Windows Azure, um desenvolvedor pode usar o portal do Windows Azure. Junto com o aplicativo são enviadas informações de configuração que informam à plataforma quantas instâncias de cada função devem ser executadas. O controlador da malha do Windows Azure cria então uma máquina virtual (VM) para cada instância, executando o código para a função apropriada naquela VM. Como mostra a Figura 3, as solicitações de usuários do aplicativo podem ser feitas usando protocolos como HTTP, HTTPS e TCP. Independente de como chegarem, as solicitações são balanceadas entre todas as instâncias de uma função. O balanceador de carga não permite a criação de uma afinidade com instância específica da função - não há suporte a sessões aderentes - e por isso não é possível garantir que múltiplas solicitações de um mesmo usuário serão enviadas para a mesma instância de uma função. Isso implica que as instâncias de funções do Windows Azure não mantêm seu estado entre uma solicitação e outra. Em vez disso, qualquer estado específico do cliente deve ser gravado no armazenamento do Windows Azure, armazenado no SQL Azure (outro componente da plataforma Windows Azure) ou mantido externamente de alguma outra maneira. Um desenvolvedor pode usar qualquer combinação de instâncias de Web Role, instâncias de Worker Role e instâncias de função VM para criar um aplicativo do Windows Azure. Se a carga do aplicativo aumentar, ele pode usar o portal do Windows Azure para solicitar mais instâncias para qualquer uma das funções do seu aplicativo. Se a carga diminuir, ele pode reduzir a quantidade de instâncias em execução. O Windows Azure também expõe uma API que permite realizar tudo isso de forma programática mudando a quantidade de instâncias em execução que não exigem intervenção manual mas a plataforma não escala automaticamente aplicativos com base em sua carga. Para criar aplicativos para o Windows Azure, o desenvolvedor usa as mesmas linguagens e ferramentas que usaria em qualquer aplicativo para o Windows. Ele pode criar uma Web Role usando ASP.NET e Visual Basic, por exemplo, ou usar WCF e C#. De forma semelhante, o desenvolvedor pode criar uma Worker Role em uma dessas linguagens.net, trabalhar diretamente em C++ sem o.net Framework ou usar Java. E embora o Windows Azure ofereça suplementos para o Visual Studio, não é necessário usar esse ambiente de desenvolvimento. Um desenvolvedor que tenha o PHP instalado, por exemplo, pode optar por usar outra ferramenta para criar aplicativos. Para permitir o monitoramento e a depuração de aplicativos do Windows Azure, cada instância pode chamar uma API de registro em log que escreve informações em um log de aplicativos em comum. O desenvolvedor também pode configurar o sistema para coletar contadores de desempenho de um aplicativo, medir sua utilização de CPU, armazenar despejos de memória caso ele falhe e mais. Essas 5

7 informações são mantidas no armazenamento do Windows Azure, e o desenvolvedor pode criar código para examiná-las. Por exemplo, se uma Worker Role parar de responder três vezes em uma hora, um código personalizado pode enviar um para o administrador do aplicativo. A capacidade de executar código é parte fundamental de uma plataforma na nuvem, mas não é o suficiente. Aplicativos também precisam de armazenamento persistente. Atender a essa necessidade é o objetivo do serviço de armazenamento do Windows Azure, descrito a seguir. ARMAZENAMENTO Os aplicativos trabalham com dados de diversas maneiras. Da mesma forma, o serviço de armazenamento do Windows Azure oferece várias opções. A figura 4 mostra as escolhas. Blobs Tabelas Filas HTTP/HTTPS, OData Aplicativos e Dados CDN Conectar Computação Armazenamento Malha Controlador Figura 4: o armazenamento do Windows Azure oferece blobs, tabelas e filas. A maneira mais simples de armazenar dados no armazenamento do Windows Azure é com a utilização de blobs. Um blob contém dados binários, e como a Figura 4 sugere, há uma hierarquia simples: cada contêiner pode ter um ou mais blobs. Os blobs podem ser grandes - com até 1 terabyte - e ter metadados associados, como informações sobre onde uma fotografia JPEG foi tirada, ou o nome do cantor em um arquivo MP3. Os blobs também fornecem armazenamento subjacente para drives do Windows Azure, um mecanismo que permite que uma instância de função do Windows Azure interaja com o armazenamento persistente como se fosse um sistema local de arquivos NTFS. Blobs se encaixam bem em algumas situações, mas têm pouca estrutura para outras. Para que os aplicativos trabalhem com os dados de forma mais apurada, o armazenamento do Windows Azure oferece tabelas. Não se deixe enganar pelo nome: não se tratam de tabelas relacionais. Os dados que 6

8 cada função traz são armazenados em um grupo de entidades que contêm propriedades. E em vez de usar SQL, um aplicativo pode consultar os dados de uma tabela usando as convenções definidas nos serviços de dados OData. Esta abordagem permite armazenamento de escalabilidade horizontal - com dados espalhados por muitas máquinas - mais eficiente que um banco de dados relacional padrão. Uma única tabela do Windows Azure pode conter bilhões de entidades armazenando terabytes de dados. Os blobs e tabelas se concentram tanto no armazenamento quanto no acesso aos dados. A terceira opção de armazenamento do Windows Azure, as filas, tem um propósito bastante diferente. Uma das funções principais das filas é a de fornecer uma maneira de instâncias de Web Roles se comunicar de forma assíncrona com instâncias de Worker Roles. Por exemplo, um usuário pode enviar uma solicitação para a realização de alguma tarefa computacional intensiva por meio de uma interface Web implementada por uma Web Role do Windows Azure. A instância da Web Role que recebe a solicitação pode escrever uma mensagem em uma fila descrevendo o trabalho a ser realizado. Uma instância de Worker Role aguardando nessa fila poderá ler a mensagem e realizar a tarefa especificada. Quaisquer resultados podem ser retornados por meio de outra fila ou tratados de outra maneira. Seja como for a maneira de armazenar os dados em blobs, tabelas ou filas todas as informações mantidas no armazenamento do Windows Azure são replicadas três vezes. Essa replicação permite tolerância a falhas, já que a perda de uma cópia não é fatal. No entanto, o sistema oferece uma forte consistência, e um aplicativo que leia imediatamente dados que acabou de gravar tem a garantia de obter de volta aquilo que acabou de gravar. O Windows Azure também mantém uma cópia de backup de todos os dados em outro data center na mesma parte do mundo. Se o data center que armazena a cópia principal não estiver disponível ou for destruído, o backup continua acessível. O armazenamento do Windows Azure pode ser acessado por um aplicativo do Windows Azure, por um aplicativo local ou por um aplicativo executado em um provedor de hospedagem ou em outra plataforma na nuvem. Em todos esses casos, os três estilos de armazenamento do Windows Azure usarão as convenções do REST para identificar e expor os dados, como sugere a figura 4. Blobs, tabelas e filas são nomeados usando URIs e acessados por meio de operações HTTP comuns. Um cliente.net pode usar uma biblioteca fornecida pelo Windows Azure para fazer isso, mas não é uma exigência - um aplicativo também pode fazer chamadas brutas HTTP. Criar um aplicativo para o Windows Azure que use blobs, tabelas e filas certamente pode ser útil. Os aplicativos podem contar com um armazenamento relacional em vez de usar o SQL Azure, outro componente da plataforma Windows Azure. Aplicativos sendo executados no Windows Azure (ou em outros lugares) podem usar essa tecnologia para se familiarizar com o acesso baseado no SQL ao armazenamento relacional na nuvem. CONTROLE DA MALHA Todos os aplicativos do Windows Azure e todos os dados no armazenamento do Windows Azure residem em algum data center da Microsoft. No data center, o conjunto de máquinas dedicadas ao Windows Azure e o software nelas executado são gerenciados pelo controlador da malha. A figura 5 ilustra essa ideia. 7

9 Armazenamento Função Instâncias Agente da malha Agente da malha Malha Controlador Aplicativos e Dados CDN Conectar Computação Armazenamento Malha Controlador Figura 5: o controlador da malha interage com os aplicativos do Windows Azure por meio de um agente de malha. O controlador da malha é um aplicativo distribuído que é replicado entre um grupo de máquinas. Ele detém todos os recursos de seu ambiente: computadores, comutadores, balanceadores de carga e outros. Como pode se comunicar com um agente de malha em cada computador, ele também está ciente de todos os aplicativos do Windows Azure nessa malha (é interessante notar que o controlador de malha enxerga o armazenamento do Windows Azure como qualquer outro aplicativo, e, portanto os detalhes do gerenciamento e da replicação de dados não são visíveis ao controlador). Esse amplo conhecimento permite que o controlador de malha faça várias coisas úteis. Ele monitora todos os aplicativos em execução, por exemplo, oferecendo uma visão atualizada do que está acontecendo. Ele também decide onde os novos aplicativos devem ser executados, escolhendo servidores físicos para otimizar a utilização de hardware. Para fazer isso, o controlador de malha depende das informações de configuração que são carregadas com cada aplicativo do Windows Azure. Esse arquivo fornece uma descrição baseada em XML do que o aplicativo precisa: quantas instâncias de Web Roles, quantas instâncias de Worker Roles e mais. Quando o controlador da malha implanta um novo aplicativo, ele usa este arquivo de configuração para determinar quantas VMs devem ser criadas. Depois de criar essas VMs, o controlador de malha monitora cada um deles. Se um aplicativo exigir cinco instâncias de uma Web Role e uma delas for encerrada, por exemplo, o controlador de malha iniciará uma nova automaticamente. De maneira semelhante, se a máquina na qual uma VM estiver sendo executada for desativada, o controlador de malha irá iniciar uma nova instância da função em outra máquina, redefinindo o balanceador de carga conforme a necessidade para apontar para essa nova VM. Atualmente o Windows Azure oferece aos desenvolvedores cinco tamanhos de VMs. As opções são: 8

10 Pequena, com CPU de núcleo único de 1,0 GHz, 768 MB de memória e 20 GB de armazenamento de instância. Pequena, com CPU de núcleo único de 1,6 GHz, 1,75 GB de memória e 225 GB de armazenamento de instância. Média, com CPU de núcleo duplo de 1,6 GHz, 3,5 GB de memória e 490 GB de armazenamento de instância. Grande, com CPU de quatro núcleos de 1,6 GHz, 7 GB de memória e GB de armazenamento de instância. Extra grande, com CPU de oito núcleos de 1,6 GHz, 14 GB de memória e GB de armazenamento de instância. Uma instância extra-pequena compartilha um núcleo de processador com outras instâncias extrapequenas. Para os demais tamanhos, em cada instância há ou mais núcleos dedicados. Isso significa que o desempenho dos aplicativos é previsível, sem um limite arbitrário de tempo pelo qual uma instância pode ser executada. Uma instância de Web Role, por exemplo, pode demorar o tempo que precisar para tratar de uma solicitação de um usuário, enquanto uma Worker Role pode computar o valor de pi em um milhão de dígitos. Para Web Roles e Worker Roles (mas não para funções VM), o controlador da malha também gerencia o sistema operacional em cada instância. Isso inclui coisas como aplicação de patches no sistema operacional e atualização de outros softwares do sistema. Dessa forma os desenvolvedores podem se concentrar apenas na criação de aplicativos - eles não precisam se preocupar com o gerenciamento da plataforma em si. No entanto, é importante entender que o controlador da malha sempre assume que pelo menos duas instâncias de cada função estão sendo executadas. Isso permite desligar uma delas para atualizar o software sem que o aplicativo seja interrompido. Por essa e outras razões, geralmente não é uma boa ideia executar uma única instância de qualquer função do Windows Azure. CONTENT DELIVERY NETWORK Um uso comum dos blobs é armazenar informações que serão acessadas de muitos lugares diferentes. Pense em um aplicativo que forneça vídeos, por exemplo, a clientes Flash, HTML 5 ou Silverlight ao redor do mundo. Para melhorar o desempenho em uma situação como essa, o Windows Azure oferece uma rede de fornecimento de conteúdo (CDN). A CDN armazena cópias de um blob em locais mais próximos dos clientes que as utilizam. A figura 6 ilustra essa ideia. 9

11 Blobs Windows Azure Aplicativos e Dados CDN Conectar Computação Armazenamento Malha Controlador Figura 6: o CDN do Windows Azure faz cópias em cache de blobs no mundo inteiro, permitindo aos usuários acessar as informações mais rapidamente. Não observe a figura de forma muito literal na verdade, o CDN do Windows Azure tem muito mais localidades de caching global do que mostra a figura mas o conceito é correto. Na primeira vez que um blob específico for acessado por usuário, o CDN armazena uma cópia daquele blob em uma localidade geograficamente mais próxima ao usuário. Da próxima vez que o blob for acessado, o seu conteúdo será fornecido a partir do cache em vez do original, mais remotamente localizado. Por exemplo, imagine que o Windows Azure seja usado para fornecer vídeos de eventos de esporte a um público amplamente distribuído. O primeiro usuário a acessar esse vídeo não terá o benefício do CDN, já que aquele blob ainda não está em cache numa localidade mais próxima. No entanto, os demais usuários na mesma localidade geográfica verão um desempenho melhor, já que a cópia em cache permite ver o vídeo mais rapidamente. CONEXÃO Executar aplicativos na nuvem Microsoft pode ser útil. Mas os aplicativos e dados que usamos em nossas organizações não vão desaparecer tão cedo. Neste caso, é importante que a conexão de ambientes in loco com o Windows Azure seja eficiente. O componente de Conexão do Windows Azure foi criado para isso. O componente pode facilitar essa combinação ao oferecer conectividade no nível de IP entre um aplicativo do Windows Azure e as máquinas em execução fora da nuvem Microsoft. A Figura 7 ilustra a ideia. 10

12 Aplicativos e Dados Função Instâncias Agente de endpoint IPsec Computador Windows in-loco Windows Azure Computação Aplicativos e Dados CDN Conectar Computação Armazenamento Malha Controlador Figura 7: o componente de Conexão do Windows Azure permite comunicação no nível de IP entre uma máquina Windows in loco e um aplicativo do Windows Azure. Como a figura mostra, o uso do componente de Conexão do Windows Azure requer a instalação de um agente de endpoint em todos os computadores in loco que estiverem conectados a um aplicativo do Windows Azure. (Como a tecnologia usa o IP v6, o agente de endpoint está disponível atualmente apenas para o Windows Server 2008, Windows Server 2008 R2, Windows Vista e Windows 7.) O aplicativo Windows Azure também precisa ser configurado para trabalhar com o componente de Conexão do Windows Azure. Assim que isso for feito, o agente pode usar o IPsec para interagir com uma função específica do aplicativo. Note que não se trata de uma rede virtual privada (VPN) completa. Apesar de a Microsoft ter anunciado planos para esta oferta, o componente de Conexão do Windows Azure é uma solução mais simples. A configuração não requer contato com o seu administrador de rede, por exemplo. A única coisa necessária é a capacidade de instalar o agente de endpoint na máquina local. Essa abordagem também oculta o potencial de complexidade da configuração do IPsec isso é feito para você pelo componente de Conexão do Windows Azure. Assim que a tecnologia for configurada, funções de um aplicativo do Windows Azure parecem estar na mesma rede de IP que as máquinas locais. Isso permite coisas como: Um aplicativo do Windows Azure pode acessar diretamente um banco de dados local. Suponhamos, por exemplo, que uma organização migre um aplicativo existente do Windows Server criado com a tecnologia ASP.NET para uma Web Role do Windows Azure. Se o banco de dados que o aplicativo usa precisar ficar no local, uma conexão do componente de Conexão do Windows Azure pode deixar o aplicativo agora executado no Windows Azure acessar o banco de dados in loco como sempre o fez. Nem mesmo a sequência da conexão precisa ser alterada. 11

13 Um aplicativo do Windows Azure pode ter domínio associado ao ambiente in loco. Isso permite que usuários no local façam login único ao aplicativo na nuvem. Isso também permite que o aplicativo use os grupos e contas existentes do Active Directory para controle de acesso. É importante fazer a nuvem se ajustar ao ambiente in loco atual. Ao permitir conectividade direta no nível de IP, o componente de Conexão do Windows Azure facilita a vida de seus aplicativos USANDO CENÁRIOS DO WINDOWS AZURE É importante entender os componentes do Windows Azure, mas isso não é o suficiente. A melhor maneira de entender o que esta plataforma pode fazer é analisar alguns exemplos de como você pode usá-la. Assim, esta seção examina diversos cenários do Windows Azure: a criação de um aplicativo Web escalonável, a criação de um aplicativo de processamento paralelo, a criação de um aplicativo Web com processamento em segundo plano, a criação de um aplicativo Web com dados relacionais, a migração de um aplicativo Web in loco com dados relacionais e o uso de armazenamento em nuvem a partir de um aplicativo hospedado ou in loco. CRIANDO UM APLICATIVO WEB ESCALONÁVEL Vamos supor que uma organização queira criar um aplicativo Web acessível via Internet. Hoje em dia, a opção mais comum é executar esse aplicativo em um data center dentro da organização ou em um provedor de hospedagem. Em muitos casos, porém, uma plataforma na nuvem como o Windows Azure é uma escolha melhor. Por exemplo, se o aplicativo tiver que tratar de um grande número de usuários simultâneos, faz sentido criá-lo em uma plataforma feita expressamente para dar suporte a isso. O suporte intrínseco a aplicativos e dados escalonáveis oferecido pelo Windows Azure pode lidar com cargas muito maiores do que tecnologias Web mais convencionais. Ou vamos supor que a carga do aplicativo vá variar expressivamente, com ocasionais picos em meio a longos períodos de baixa utilização. Um site de tickets online pode exibir esse padrão, por exemplo, como sites de vídeos de notícias com eventuais notícias de destaque, um aplicativo que é mais utilizado em certas horas do dia e outros. Executar esse tipo de aplicativo em um data center convencional sempre exige um número suficiente de máquinas disponíveis para lidar com os picos, mesmo que a maioria desses sistemas passe a maior parte do tempo sem uso. Porém, se o aplicativo for criado para o Windows Azure, a organização que o executar pode expandir a quantidade de instâncias que usa apenas quando for necessário, e depois voltar para uma quantidade menor. Como o Windows Azure é cobrado com base no uso você paga por hora para cada instância isso provavelmente vai sair mais barato do que manter muitas máquinas praticamente sem uso. Para criar um aplicativo Web escalonável no Windows Azure, um desenvolvedor pode usar Web Roles e tabelas. A figura 8 ilustra isso de maneira simples. 12

14 Aplicativo da Web escalonável Web Role Instância Tabelas Usuários Figura 8: um aplicativo Web escalonável pode usar tabelas e instâncias de Web Roles. No exemplo mostrado aqui, os clientes são navegadores, e a lógica do aplicativo pode ser implementada usando ASP.NET ou outra tecnologia Web. Também é possível criar um aplicativo Web escalonável que exponha serviços Web baseados em SOAP e/ou RESTful usando WCF, e então chamar esses serviços a partir de um cliente Silverlight, por exemplo. Em qualquer dos casos, o desenvolvedor especifica quantas instâncias da Web Role devem ser executadas, e o controlador de malha do Windows Azure cria essa quantidade de VMs. Conforme descrito anteriormente, o controlador de malha também monitora essas instâncias, certificando-se de que a quantidade selecionada esteja sempre disponível. Para o armazenamento de dados, o aplicativo usa as tabelas de armazenamento do Windows Azure, que oferecem armazenamento de escalabilidade horizontal capaz de lidar com quantidades muito grandes de dados. CRIANDO UM APLICATIVO COM PROCESSAMENTO PARALELO Aplicativos Web escalonáveis são úteis, mas não é só para eles que o Windows Azure faz sentido. Pense em uma organização que ocasionalmente precise de muito poder computacional para um aplicativo de processamento paralelo. Há muitos exemplos desse tipo de situação: modelagem financeira em um banco, renderização em um estúdio de efeitos especiais para filmes, desenvolvimento de novas drogas em uma empresa farmacêutica e muito mais. Embora seja possível manter um grande cluster de máquinas para atender a essa necessidade ocasional, isso sai caro. O Windows Azure pode fornecer esses recursos conforme a necessidade, oferecendo um cluster computacional sob demanda. Um desenvolvedor pode usar Worker Roles para criar esse tipo de aplicativo. E embora e essa não seja a única opção, aplicativos em paralelo geralmente usam grandes conjuntos de dados, que podem ser armazenados em blobs do Windows Azure. A Figura 9 ilustra esse tipo de aplicativo. 13

15 Aplicativo de processamento paralelo Web Role Instância Filas Worker Role Instância Blobs Usuário Figura 9: um aplicativo com processamento paralelo pode usar uma instância de Web Role, muitas instâncias de Worker Roles, filas e blobs. No cenário mostrado aqui, o trabalho paralelo é feito por várias instâncias de Worker Roles em execução simultaneamente, cada uma usando dados de blob. Como o Windows Azure não impõe limite de tempo de duração de execução de uma instância, cada uma pode realizar uma quantidade arbitrária de trabalho. Para interagir com o aplicativo, o usuário depende de uma única instância de Web Role. Por meio dessa interface, o usuário pode determinar quantas instâncias de funcionário devem ser executadas, iniciar e interromper essas instâncias, acessar resultados e mais. A comunicação entre a instância da Web Role e as instâncias de Worker Roles depende das filas do armazenamento do Windows Azure. Dada a enorme capacidade de processamento disponível na nuvem, esta nova abordagem tende a transformar a computação de alto desempenho. Por exemplo, o Microsoft Windows HPC Server agora permite a criação de um cluster computacional usando instâncias da Worker Role do Windows Azure junto com ou em vez de servidores físicos locais. Independente de como for feito, faz sentido usar esta nova fonte de poder computacional em algumas situações. CRIANDO UM APLICATIVO WEB ESCALONÁVEL COM PROCESSAMENTO EM SEGUNDO PLANO É provável que a maioria dos aplicativos criados hoje ofereça uma interface para navegadores. Embora aplicativos que não façam nada além de aceitar e responder a solicitações do navegador sejam úteis, eles também são limitados. Há muitas situações nas quais um software acessível via Web precisa iniciar um trabalho que será executado em segundo plano, independente da parte de solicitação/resposta do aplicativo. Tomemos como exemplo um aplicativo Web de compartilhamento de vídeos. Ele tem que aceitar solicitações do navegador, talvez vindas de um grande número de usuários ao mesmo tempo. Algumas dessas solicitações irão carregar novos vídeos, e cada vídeo terá que ser processado e armazenado para acesso posterior. Não faz sentido fazer o usuário esperar enquanto ocorre esse processamento. Em vez 14

16 disso, a parte do aplicativo que aceita solicitações do navegador deve ser capaz de iniciar uma tarefa em segundo plano para realizar esse trabalho. As Web Roles e Worker Roles do Windows Azure podem ser usadas juntas para lidar com essa situação. A figura 10 mostra como pode ser esse tipo de aplicativo. Aplicativo da Web escalonável com processamento em segundo plano Tabelas Web Role Instância Filas Worker Role Instância Blobs Usuários Figura 10: um aplicativo Web escalonável com processamento em segundo plano pode usar muitas das capacidades do Windows Azure. Assim como o aplicativo Web escalonável mostrado anteriormente, este aplicativo usa algumas instâncias de Web Role para tratar das solicitações do usuário. Para suportar um grande número de usuários simultâneos, ele usa tabelas para armazenar informações de perfil. Para o processamento em segundo plano, ele depende das instâncias de Worker Role, passando tarefas a elas por meio das filas. Neste exemplo, as instâncias de Worker Role trabalham com dados em blobs, mas outras abordagens também são possíveis. Este exemplo mostra como um aplicativo pode combinar muitas capacidades básicas expostas pelo Windows Azure: instâncias de Web Roles, instâncias de Worker Roles, blobs, tabelas e filas. E, embora não seja mostrado na figura, um aplicativo de compartilhamento de vídeo também pode usar o CDN do Windows Azure para acelerar o acesso. Nem todos os aplicativos vão precisar disso tudo, mas ter essas capacidades à disposição é essencial para suportar cenários mais complexos, como este. CRIANDO UM APLICATIVO WEB COM DADOS RELACIONAIS Os blobs e as tabelas do Windows Azure são ideais para algumas situações. Em outras, no entanto, é melhor usar dados relacionais. Suponhamos que uma corporação queira construir e executar um aplicativo para seus próprios funcionários no Windows Azure. Talvez a vida útil do aplicativo seja curta ou imprevisível, então não valerá à pena alocar um servidor no data center da corporação. Ou talvez o aplicativo tenha que ser executado o mais rapidamente possível, o que impossibilitaria a espera pelo 15

17 provisionamento de um servidor pelo departamento de TI interno. Ou talvez a organização acredite que executar o aplicativo no Windows Azure seja mais simples e barato. Independente da razão, esse aplicativo provavelmente não precisa de toda a escalabilidade que as tabelas do Windows Azure proporcionam. Em vez delas, o criador do aplicativo pode preferir a abordagem relacional que já conhece, com direito ao uso de ferramentas familiares de relatórios. Em um caso como esse, o aplicativo pode usar o Windows Azure junto com o SQL Azure, como mostra a figura 11. Novo aplicativo da Web com dados relacionais Web Role Instância SQL Azure Usuários Figura 11: um aplicativo do Windows Azure pode usar o SQL Azure para trabalhar com dados relacionais. O SQL Azure proporciona um grande subconjunto de funcionalidades do SQL Server, incluindo relatórios, como um serviço de nuvem gerenciado. Os aplicativos podem criar bancos de dados, executar consultas SQL e mais, mas sem que você tenha que administrar o sistema de banco de dados ou o hardware sobre o qual ele opera a Microsoft cuida disso. Um banco de dados do SQL Azure pode ser acessado usando o protocolo TDS (Tabular Data Stream), assim como na versão in loco do SQL Server. Dessa forma um aplicativo do Windows Azure pode acessar dados relacionais usando mecanismos familiares como o Entity Framework e o ADO.NET. E como o SQL Azure é um serviço na nuvem, a cobrança é baseada no uso. Como o Windows Azure e o SQL Azure oferecem na nuvem duplicatas de suas contrapartes locais, é simples mover o código e os dados desse tipo de aplicativo entre os dois mundos. As coisas não são exatamente iguais o aplicativo Windows Azure deve ser capaz de executar múltiplas instâncias, mas os ambientes in loco e na nuvem são bastante similares. Essa portabilidade é útil nas situações em que fizer sentido criar um aplicativo com código e dados que possam existir no local ou na nuvem. 16

18 MIGRAÇÃO DE UM APLICATIVO WEB IN LOCO COM DADOS RELACIONAIS Suponhamos que em vez de criar um novo aplicativo Web para o Windows Azure, uma organização queira migrar um aplicativo Windows Server já existente para essa plataforma na nuvem. Uma maneira de abordar essa questão é usando a função VM do Windows Azure. A imagem é muito similar ao caso anterior, como mostra a Figura 12. Aplicativo da Web in-loco migrado com dados relacionais Função da VM Instância SQL Azure Usuários Figura 12: alguns aplicativos in loco podem ser migrados para o Windows Azure usando a função VM e o SQL Azure. Para usar uma função VM, uma organização cria um disco rígido virtual (VHD) a partir de uma máquina in loco executando o Windows Server 2008 R2. Esta imagem pode ser carregada no Windows Azure e executada em uma função VM. Como exibe a figura, o aplicativo pode acessar dados relacionais no SQL Azure. Outra opção é deixar os seus dados no local, acessando-os diretamente via o componente de Conexão do Windows Azure, como foi descrito anteriormente. A função VM pode ser útil. No entanto, é importante entender que a migração de um aplicativo do Windows Server para o Windows Azure pode exigir mais do que o simples empacotamento em VHD e a sua execução em uma função VM. Em primeiro lugar, lembre-se que o controlador da malha do Windows Azure assume que pelo menos duas instâncias de cada função estão sempre em execução. (A qualificação para o Service Level Agreement SLA do Windows Azure requer isso.) Lembre-se também que o Windows Azure balanceia a carga de todas as solicitações de usuários entre as instâncias das funções. Se o aplicativo sendo migrado tiver sido construído para funcionar dessa maneira - talvez já esteja em execução em um Web farm balanceado, por exemplo ele pode ser bem executado no Windows Azure sem mudanças significativas. Porém, se o aplicativo tiver que ser executado em uma única instância, ele provavelmente irá exigir alguma alteração para que sua execução no Windows Azure possa ser bemsucedida. 17

19 USANDO O ARMAZENAMENTO NA NUVEM A PARTIR DE UM APLICATIVO LOCAL OU HOSPEDADO O Windows Azure oferece diversas capacidades, mas às vezes um aplicativo só precisa de uma delas. Pense, por exemplo, em um aplicativo local ou hospedado que precise armazenar uma quantidade expressiva de dados. Uma empresa pode querer arquivar s antigos, por exemplo, poupando dinheiro com armazenamento, mas ainda assim mantendo esses s acessíveis. Um site de notícias executado em um hoster pode precisar de um local globalmente acessível e dimensionável para armazenar grandes quantidades de textos, gráficos, vídeos e informações de perfis de seus usuários. Um site de compartilhamento de fotos pode querer passar os desafios do armazenamento de suas informações para terceiros nos quais possa confiar. O armazenamento do Windows Azure pode lidar com todas essas situações, como mostra a Figura 13. Blobs Tabelas Aplicativos locais ou hospedados Figura 13: um aplicativo local ou hospedado pode usar blobs ou tabelas do Windows Azure para armazenar seus dados na nuvem. Conforme mencionamos anteriormente, um aplicativo hospedado ou in loco pode acessar diretamente o armazenamento do Windows Azure. Esse acesso provavelmente vai ser mais lento do que quando se trabalha com armazenamento local, mas provavelmente também vai ser mais barato, escalonável e confiável. Para alguns aplicativos, essa troca definitivamente vale à pena. E apesar disso não aparecer na figura, os aplicativos podem usar o SQL Azure da mesma maneira. ENTENDENDO O WINDOWS AZURE: UMA VISÃO MAIS DETALHADA Para entender o Windows Azure, é necessário conhecer o básico da plataforma, e ver os cenários típicos nos quais esses pontos básicos podem ser aplicados. Mas essa tecnologia vai muito além disso. Esta seção lança um olhar mais aprofundado sobre alguns de seus aspectos mais interessantes. 18

20 CRIAÇÃO DE APLICATIVOS DO WINDOWS AZURE Para os desenvolvedores, criar um aplicativo para o Windows Azure é como criar um aplicativo tradicional para o Windows. Como a plataforma suporta tanto aplicativos.net quanto aplicativos criados com código não gerenciado, um desenvolvedor pode usar o que for mais adequado para o problema ser resolvido. Para facilitar sua vida, o Visual Studio fornece modelos de projetos para criar aplicativos do Windows Azure. Também é possível carregar aplicativos diretamente no Windows Azure a partir do Visual Studio. Uma diferença óbvia entre o mundo da nuvem e o mundo local é que os aplicativos do Windows Azure não são executados localmente. Essa diferença tem potencial para tornar o desenvolvimento mais desafiador. Para minimizar essa questão, a Microsoft fornece o emulador de malha, uma versão do ambiente do Windows Azure executada na máquina de um desenvolvedor. O emulador de malha é executado em uma única estação de trabalho ou máquina de servidor. Ele emula a funcionalidade do Windows Azure na nuvem, completa, com Web Roles, Worker Roles, funções de VM e as três opções de armazenamento do Windows Azure. Um desenvolvedor pode criar um aplicativo para o Windows Azure, implantá-lo no emulador de malha de desenvolvimento e executá-lo da mesma maneira que faria na hora da verdadeira implantação. Ele pode determinar quantas instâncias de cada função devem ser executadas, usar filas para comunicação entre essas instâncias e fazer quase tudo o que é possível fazer usando o próprio Windows Azure Assim que o aplicativo for desenvolvido e testado localmente, o desenvolvedor pode carregar o código e suas informações de configuração, e então executá-lo. Independente de como for criado, um aplicativo do Windows Azure geralmente é disponibilizado na nuvem em duas etapas. Primeiro o desenvolvedor carrega o aplicativo para a área de testes da plataforma. Quando o desenvolvedor estiver pronto para pôr o aplicativo em produção, ele usa o portal do Windows Azure para fazer essa solicitação. Esta mudança da etapa de teste para a de produção pode ser feita sem tempo de indisponibilidade, o que permite que um aplicativo seja atualizado para uma nova versão sem interromper os usuários. O aplicativo em testes tem um nome DNS no formato <GUID>.cloudapp.net, onde <GUID> representa um identificador global exclusivo atribuído pelo Windows Azure. Para produção, o desenvolvedor escolhe um nome DNS no mesmo domínio, como myazureservice.cloudapp.net. Para usar um domínio personalizado em vez do domínio Microsoft cloudapp.net, o proprietário do aplicativo pode criar um alias do DNS usando um CNAME padrão. Depois que o aplicativo estiver acessível para acesso externo, seus usuários provavelmente vão precisar de algum meio de identificação. Para cuidar disso, o Windows Azure permite que os desenvolvedores usem qualquer mecanismo de autenticação baseado em HTTP que eles preferirem. Um aplicativo ASP.NET pode usar um provedor de associação para armazenar seu próprio ID de usuário e senha, por exemplo, ou pode usar outro método, como o serviço Windows Live ID da Microsoft. Os aplicativos do Windows Azure também podem usar o Windows Identity Foundation (WIF) para implementar a identidade com base em reivindicações. A escolha cabe totalmente ao criador do aplicativo. 19

21 EXAMINANDO O SERVIÇO DE COMPUTAÇÃO Como a maioria das tecnologias, o Windows Azure evoluiu desde que foi lançado. A principio, por exemplo, o código nas funções da Web e Funcionário só podia ser executado no modo usuário. Hoje, no entanto, ambos oferecem uma opção de privilégios elevados, permitindo que os aplicativos sejam executados no modo administrador. Isso pode ser útil para aplicativos que precisem instalar um componente COM, por exemplo, algo que era problemático na primeira versão do Windows Azure. Entretanto, cada instância em execução de uma Web Role ou Worker Role começa a partir de uma placa limpa: o sistema operacional subjacente na VM é uma imagem padrão definida pelo Windows Azure. Isso significa que qualquer instalação de software executada pela função deve ser feita sempre que uma nova instância for criada. Isso não é um problema para instalações simples, como a adição de um único componente COM. Mas suponha-se que a instância tenha que instalar uma série de softwares para desempenhar seu objetivo. É provável que fazer isso sempre que uma nova instância da função for criada tornará o processo muito lento. Evitar essa lentidão é a principal finalidade das funções de VM. Em vez de exigir uma nova instalação a cada instância criada, todos os softwares exigidos podem ser incluídos em um VHD, com o VHD sendo usado para criar uma instância da função VM. Isso pode ser significativamente mais rápido que o uso de Web Roles e Worker Roles com privilégios elevados. Essa também pode ser a solução certa quando o processo de instalação exigir intervenção manual, algo que o Windows Azure não permite. Outra mudança da versão original do Windows Azure é que a plataforma agora suporta acesso via Remote Desktop Protocol (RDP). Isso é útil em depurações, por exemplo, para permitir que um desenvolvedor acesse diretamente uma instância específica. Mas não espere usar essa infraestrutura de área de trabalho virtual (VDI), o Windows Azure (hoje, pelo menos) não foi projetado para suportar esse tipo de cenário. Outros aspectos importantes da computação do Windows Azure foram disponibilizados desde que o primeiro lançamento da tecnologia. Para tornar isso possível, o Windows Azure permite que um desenvolvedor indique em qual data center um aplicativo deve ser executado, e onde seus dados devem ser armazenados. Ele também pode especificar que um grupo específico de aplicativos e dados (incluindo dados no SQL Azure Database) devem residir no mesmo data center. Inicialmente, a Microsoft disponibiliza data centers para o Windows Azure nos Estados Unidos, na Europa e na Ásia, mas outros virão. EXAMINANDO O SERVIÇO DE ARMAZENAMENTO Para usar o armazenamento do Windows Azure, primeiro o desenvolvedor tem que criar uma conta de armazenamento. Para controlar o acesso às informações nessa conta, o Windows Azure dá ao seu criador uma chave secreta. Cada solicitação que um aplicativo faz às informações nessa conta de armazenamento blobs, tabelas e filas carrega uma assinatura criada com essa chave secreta. Em outras palavras, a autorização é no nível da conta (embora blobs tenham outra opção, descrita mais adiante). O armazenamento do Windows Azure não fornece listas de controle de acesso e nem outras maneiras mais minuciosas de se controlar quem pode acessar os dados que ele contém. 20

22 Blobs Os objetos binários grandes blobs muitas vezes são exatamente o que um aplicativo precisa. Seja armazenando vídeo, áudio, mensagens de arquivadas ou qualquer outra coisa, eles permitem que os aplicativos armazenem e acessem dados de um modo bastante genérico. Para usar blobs, primeiro o desenvolvedor cria um ou mais contêineres em alguma conta de armazenamento. Cada um desses contêineres pode armazenar um ou mais blobs. Para identificar um blob específico, um aplicativo pode fornecer uma URI no formato: <ContadeArmazenamento> é um identificador exclusivo atribuído quando uma nova conta de armazenamento é criada, enquanto <Contêiner> e <NomeDoBlob> são os nomes de um contêiner específico e de um blob dentro desse contêiner. Há duas formas de blobs: Blobs de bloco, que podem armazenar até 200 gigabytes de dados cada. Para tornar a transferência mais eficiente, um blob de bloco é subdividido em blocos. Se ocorrer uma falha, a retransmissão pode ser retomada com o bloco mais recente, não sendo necessário enviar o blob todo outra vez. Depois que todos os blocos de um blob forem carregados, o blob inteiro pode ser confirmado de uma vez. Blobs de página, que podem ter até um terabyte cada. Um blob de página é dividido em páginas de 512 bytes, e um aplicativo é livre para ler e escrever em páginas individuais aleatoriamente no blob. Seja qual for o tipo de blob que armazenam, os contêineres podem ser marcados como particulares ou públicos. Para blobs em um contêiner particular, tanto as solicitações de leitura quanto de escrita precisam ser assinadas usando a chave da conta de armazenamento de blob. Para blobs em um contêiner público, apenas solicitações de escrita precisam ser assinadas; qualquer aplicativo pode ler o blob. Isso pode ser útil para disponibilizar vídeos, fotos e outros dados não estruturados na Internet. Na verdade, o CDN do Windows Azure funciona somente com dados armazenados em contêineres de blobs públicos. Outro aspecto importante dos blobs é sua função no suporte a unidades do Windows Azure. Para entender essa função, observe primeiro que as instâncias da função são livres para acessar o sistema de arquivos local. Por padrão, no entanto, esse armazenamento não é persistente. Quando a instância é encerrada, a VM e seu armazenamento local vão embora. A montagem de uma unidade do Windows Azure para a instância pode fazer com que um blob da página se pareça com uma unidade local completa com um sistema de arquivos NTFS. Gravações na unidade podem ser feitas imediatamente no blob subjacente. Quando a instância não está em execução, esses dados são armazenados de forma persistente no blob de página, pronto para ser montado novamente. Estes são alguns dos possíveis usos das unidades: Um desenvolvedor pode carregar um VHD contendo um sistema de arquivos NTFS e então montá-lo como uma unidade do Windows Azure. Isso proporciona uma maneira direta de mover dados de um sistema de arquivos entre o Windows Azure e um sistema Windows Server local. 21

23 Um desenvolvedor do Windows Azure pode instalar e executar um sistema de banco de dados MySQL em uma instância de função do Windows Azure, usando uma unidade do Windows Azure como armazenamento subjacente. Tabelas Um blob é fácil de entender ele é apenas uma placa de bytes mas as tabelas são um pouco mais complexas. A figura 14 ilustra como as partes de uma tabela se encaixam. Tabela Tabela Tabela... Entidade Entidade Entidade... Propriedade Propriedade Propriedade... Nome Tipo Valor Figura 14: as tabelas fornecem armazenamento baseado em entidades. Como mostra a figura, cada tabela armazena uma certa quantidade de entidades. Uma entidade contém zero ou mais propriedades, cada uma com um nome, um tipo e um valor. Vários tipos são suportados, incluindo: Binary, Bool, DateTime, Double, GUID, Int, Int64, e String. Uma propriedade pode aceitar tipos diferentes em momentos diferentes, dependendo do valor armazenado nela, e não há exigência de que todas as propriedades em uma entidade sejam do mesmo tipo o desenvolvedor pode fazer o que fizer mais sentido para o aplicativo. Seja qual for seu conteúdo, uma entidade pode ter tamanho de até um megabyte, e sempre é acessada como uma unidade. A leitura de uma entidade retorna todas as suas propriedades, e a gravação de uma pode substituir todas as suas propriedades. Também é possível atualizar um grupo de entidades dentro de uma mesma tabela atomicamente, garantindo que todas as atualizações tenham êxito ou que todas fracassem. As tabelas de armazenamento do Windows Azure são diferentes das tabelas relacionais em diversos aspectos. O mais óbvio é que elas não são tabelas no sentido comum da palavra. Além disso, elas não podem ser acessadas por meio de ADO.NET comum, nem contam com suporte a consultas SQL. E as 22