MODELO DE PROGRAMAÇÃO
DO WINDOWS AZURE
DAVID CHAPPELL
OUTUBRO DE 2010
SUMÁRIO
Por que criar um novo modelo de programação? ... 3
Três regras do modelo de programação do Windows Azure ... 4
Um aplicativo Windows Azure é criado a partir de uma ou mais funções. ... 4
Um aplicativo Windows Azure executa várias instâncias para cada função. ... 5
Um aplicativo do Windows Azure se comporta corretamente quando qualquer instância de função falha. ... 6
O que o modelo de programação do Windows Azure fornece ... 8
Histórico: Controle da malha ... 8
Benefícios: Melhor Administração, Disponibilidade e Escalabilidade ... 9
Implicações do Modelo de Programação do Windows Azure: O que mais muda? ... 11
Interações com o Sistema Operacional ... 11
Interações com o Armazenamento Persistente ... 12
Interações nas Instâncias de Função ... 14
Como mover Aplicativos do Windows Server para o Windows Azure ... 15
Conclusão ... 17
Para leitura adicional ... 17
POR QUE CRIAR UM NOVO MODELO DE PROGRAMAÇÃO?
Milhões de desenvolvedores do mundo inteiro sabem como criar aplicativos usando o modelo de
programação do Windows Server. No entanto, os aplicativos escritos para Windows Azure, plataforma em nuvem da Microsoft, não usam exatamente este modelo familiar. Embora a maioria das competências dos desenvolvedores do Windows ainda se aplique, o Windows Azure fornece seu modelo de programação próprio.
Por quê? Por que não apenas replicar o mundo familiar do Windows Server na nuvem? Muitos
fornecedores de plataformas em nuvem fazem isso, fornecendo máquinas virtuais (VMs) que agem como em VMs locais. Esta abordagem, comumente chamada Infraestrutura como um Serviço (IaaS), certamente tem valor, e é a escolha certa para alguns aplicativos. No entanto, plataformas em nuvem constituem um novo mundo, com potencial para resolver os problemas de hoje de novas formas. Em vez de IaaS, o Windows Azure oferece um nível mais alto de abstração que é tipicamente categorizado como Plataforma como um Serviço (PaaS). Ao mesmo tempo em que ela é similar de muitas formas com o mundo do Windows instalado localmente, essa abstração tem seu próprio modelo de programação direcionado a ajudar desenvolvedores a criar aplicativos melhores.
O modelo de programação do Windows Azure foca a melhoria de aplicativos em três áreas:
o Administração: Nas tecnologias PaaS, a própria plataforma resolve a maior parte das tarefas administrativas. Com o Windows Azure, isso significa que a plataforma resolve automaticamente questões tais como a aplicação de Windows patches e a instalação de novas versões do software de sistema. O objetivo é reduzir esforço —e custo—da administração do ambiente do aplicativo.
o Disponibilidade: Seja planejado ou não, os aplicativos de hoje normalmente têm tempo de inatividade para Windows patches, atualizações de aplicativos, falhas de hardware, e outras razões. No entanto, dada a redundância que plataformas em nuvem tornam possíveis, não há mais qualquer razão para aceitar isso. O modelo de programação do Windows Azure é criado para deixar os aplicativos disponíveis permanentemente, mesmo em face de atualizações de software e falhas de hardware.
o Escalabilidade: Os tipos de aplicativos que as pessoas querem escrever em nuvem são, frequentemente, destinados a lidar com muitos usuários. Porém, o modelo de programação tradicional do Windows Server não foi criado explicitamente para suportar aplicativos escalonáveis para Internet. O modelo de programação do Windows Azure foi, no entanto, criado desde o início com o objetivo de fazer isso. Criado para a Era da nuvem, foi desenvolvido para permitir que desenvolvedores criassem aplicativos escalonáveis que grandes centros de dados podem suportar. Tão importante quanto isso, ele também permite que os aplicativos sejam escalonados para baixo quando necessário, permitindo-os utilizar apenas os recursos de que necessitam.
Se o desenvolvedor usar uma tecnologia IaaS ou oferecer PaaS, tal como Windows Azure, criar aplicativos em plataformas em nuvem tem alguns benefícios inerentes. As duas abordagens permitem que você pague apenas pelos recursos de computação que usar, por exemplo, e que você não tenha que esperar pelo seu departamento de TI para implantar servidores. Apesar de serem tão importantes, esses
benefícios não são nosso tópico. Em vez disso, o foco é deixar claro o que é o modelo de programação do Windows Azure e o que ele oferece.
TRÊS REGRAS DO MODELO DE PROGRAMAÇÃO DO WINDOWS AZURE Para obter os benefícios que ele promete, o modelo de programação do Windows Azure impõe três regras aos aplicativos:
o Um aplicativo Windows Azure é criado a partir de uma ou mais funções.
o Um aplicativo Windows Azure executa várias instâncias para cada função.
o Um aplicativo Windows Azure se comporta corretamente quando qualquer instância de função falha.
Vale enfatizar que o Windows Azure pode executar aplicativos que não seguem todas essas regras—ele, na verdade, não as exige. Ao contrário, a plataforma simplesmente presume que todos os aplicativos seguem as três. Apesar de poder optar por executar um aplicativo no Windows Azure que viole uma ou mais regras, esteja ciente de que esse aplicativo não está, na verdade, utilizando o modelo de
programação do Windows Azure. A menos que você entenda e siga as regras do modelo, o aplicativo pode não funcionar como você espera.
UM APLICATIVO WINDOWS AZURE É CRIADO A PARTIR DE UMA OU MAIS FUNÇÕES.
Se um aplicativo é executado em nuvem ou no seu centro de dados, ele pode certamente ser dividido em partes lógicas. O Windows Azure formaliza essas três divisões como funções. Uma função inclui um conjunto específico de códigos, tais como um conjunto .NET, e define o ambiente no qual tal código funciona. O Windows Azure hoje permite que desenvolvedores criem três tipos diferentes de funções:
o Web Role: Como o nome sugere, Web Roles são essencialmente destinadas à lógica que interage com o mundo exterior via HTTP. O código escrito como uma Web Role geralmente recebe sua entrada por meio dos Serviços de Informações da Internet (IIS), e pode ser criado usando várias tecnologias, incluindo ASP.NET, Windows Communication Foundation (WCF), PHP e Java.
o Worker Role: Lógica escrita como uma função de funcionário pode interagir com o mundo exterior de maneiras diversas—não é limitado ao HTTP. Por exemplo, uma Worker Role pode conter códigos que convertem vídeos para um formato padrão ou calculam o risco de uma carteira de investimentos ou realizam algum tipo de análise de dados.
o Função de Máquina Virtual (VM): Uma função de VM executa uma imagem—um disco rígido virtual (VHD)—de uma máquina virtual do Windows Server 2008 R2. Esse VHD é criado utilizando uma máquina local do Windows Server e, em seguida, carregado para o Windows Azure. Depois de armazenado na nuvem, o VHD pode ser carregado sob demanda em uma função de VM e executado.
As três funções são úteis. A função de VM ficou disponível recentemente, no entanto e, por isso, é justo dizer que as opções usadas hoje com mais frequência são Web Roles e Worker Roles. A Figura 1 mostra um aplicativo simples do Windows Azure criado com uma Web Role e uma Worker Role.
A Figura 1: Um aplicativo do Windows Azure é criado a partir de uma ou mais funções, tais como a combinação de Web Roles e Worker Roles aqui mostradas.
Esse aplicativo pode usar uma Web Role para aceitar solicitações HTTP de usuários, e deixar de lado o trabalho que esses usuários solicitam, tais como formatar novamente um arquivo de vídeo e torná-lo disponível para visualização para uma Worker Role. A principal razão para esta divisão em duas partes é que dividir tarefas dessa forma pode tornar o aplicativo mais fácil de escalonar.
Um aplicativo do Windows Azure também pode consistir em apenas uma Web Role ou uma Worker Role —você não precisa usar as duas. Um único aplicativo pode até conter diferentes tipos de Web Roles e Worker Roles. Por exemplo, um aplicativo pode ter uma função da Web que implemente uma interface de navegador, talvez criada utilizando ASP.NET, e outra Web Role que apresente interfaces de serviços da Web implementadas utilizando WCF. Do mesmo modo, um aplicativo do Windows Azure que tenha executado dois tipos diferentes de análise de dados pode definir uma Worker Role diferente da outra. Para manter as coisas simples, no entanto, vamos considerar que o exemplo de aplicativo aqui descrito tem apenas uma Web Role e uma Worker Role.
Como parte da criação do aplicativo do Windows Azure, um desenvolvedor cria um arquivo de definição de serviço que nomeia e descreve as funções do aplicativo. Esse arquivo também pode especificar outra informação, tal como as portas que cada função pode escutar. O Windows Azure utiliza essa informação para criar o ambiente correto para executar o aplicativo.
UM APLICATIVO WINDOWS AZURE EXECUTA VÁRIAS INSTÂNCIAS PARA CADA FUNÇÃO.
Cada aplicativo do Windows Azure consiste em uma ou mais funções. Quando ele executa, um aplicativo em conformidade com o modelo de programação do Windows Azure deve rodar, pelo menos, duas cópias—duas instâncias distintas —de cada função que ele contém. Cada instância roda como sua própria VM, como mostra a Figura 2.
Figura 2: Um aplicativo Windows Azure executa várias instâncias para cada função.
Como descrito anteriormente, o exemplo de aplicativo aqui mostrado tem apenas uma Web Role e uma Worker Role. Um desenvolvedor pode dizer ao Windows Azure quantas instâncias de cada função executar por meio de um arquivo de configuração do serviço (que é diferente do arquivo de definição do serviço mencionado na seção anterior). Aqui, o desenvolvedor solicitou quatro instâncias da Web Role do aplicativo e três instâncias da Worker Role.
Todas as instâncias de uma função específica executam exatamente o mesmo código. Na verdade, com a maioria dos aplicativos do Windows Azure, cada instância é exatamente igual a todas as outras instâncias daquela função—elas são intercambiáveis. Por exemplo, o Windows Azure carrega automaticamente solicitações de balanços de carga HTTP nas instâncias das Web Roles do aplicativo. Esse balanço de carga não suporta sessões agrupadas, por isso não é possível direcionar todas as solicitações do cliente para a mesma instância de Web Role. Armazenar o estado específico do cliente, tal como um carrinho de compras em uma instância específica de Web Role não vai funcionar porque o Windows Azure não garante que todos os pedidos de um cliente serão resolvidos por essa instância. Em vez disso, esse tipo de estado deve ser armazenado externamente, como descrito mais adiante.
UM APLICATIVO DO WINDOWS AZURE SE COMPORTA CORRETAMENTE QUANDO QUALQUER INSTÂNCIA DE FUNÇÃO FALHA.
Um aplicativo que segue o modelo de programação do Windows Azure deve ser criado utilizando funções, e deve executar duas ou mais instâncias de cada uma dessas funções. Ele também deve se comportar corretamente quando qualquer uma das instâncias de função falhar. A Figura 3 ilustra essa ideia.
Figura 3: Um aplicativo do Windows Azure se comporta corretamente até mesmo quando uma instância de função falha.
Aqui, o aplicativo mostrado na Figura 2 perdeu duas de suas instâncias de Web Role e uma de suas instâncias de Worker Role. Talvez os computadores em que elas estavam sendo executadas tenham falhado, ou a conexão física da rede com essas máquinas tenha caído. Seja qual for a razão, o desempenho do aplicativo tende a cair, uma vez que há menos instâncias para realizar seu trabalho. Ainda assim, o aplicativo permanece ligado e funcionando corretamente.
Se todas as instâncias de uma função particular falham, o aplicativo vai deixar de se comportar como deveria—isso não pode ser evitado. No entanto, a obrigação de funcionar corretamente durante falhas parciais é fundamental para o modelo de programação do Windows Azure. Na verdade, o contrato de nível de serviço (SLA) para Windows Azure requer a execução de, pelo menos, duas instâncias para cada função. Aplicativos que executam apenas uma instância de qualquer função não podem obter as garantias que o SLA fornece.
A forma mais comum de conseguir isso é tornar cada instância de função equivalente, como com as Web Roles com carga equilibrada aceitando solicitações do usuário. No entanto, isso não é estritamente necessário, desde que a falha de uma simples instância de função não provoque falhas no aplicativo. Por exemplo, um aplicativo pode usar um grupo de instâncias de Worker Role para ocultar dados para instâncias de Web Role, com cada instância de Worker Role guardando dados diferentes. Se qualquer instância de Worker Role falhar, uma instância de Web Role tentando acessar os dados armazenados em cache se comporta exatamente como seria se os dados não tivessem sido encontrados no cache (por exemplo, ele acessa o armazenamento persistente para localizar os dados). A falha pode provocar lentidão na execução do aplicativo, mas conforme observado por um usuário, ainda se comporta corretamente.
Mais um ponto importante a ser lembrado é que mesmo que o exemplo de aplicativo descrito até agora contenha apenas Web Roles e Worker Roles, todas essas regras também se aplicam a aplicativos que utilizam funções de VM. Assim como os outros, cada função VM deve executar pelo menos duas instâncias para se qualificar para o Windows Azure SLA, e o aplicativo deve continuar funcionando corretamente se uma dessas instâncias falhar. Mesmo com as funções de VM, o Windows Azure ainda fornece uma forma de PaaS— não é um IaaS tradicional.
O QUE O MODELO DE PROGRAMAÇÃO DO WINDOWS AZURE FORNECE
O modelo de programação do Windows Azure é baseado no Windows, e a maior parte das competências dos desenvolvedores Windows são aplicáveis a este novo ambiente. Mesmo assim, não é igual ao modelo convencional de programação do Windows Server. Então por que se preocupar em entender isso? Como isso ajuda a criar melhores aplicativos? Para responder a essas questões, vale a pena primeiro explicar um pouco mais sobre o funcionamento do Windows Azure. Uma vez que isso esteja claro, entender como o modelo de programação do Windows Azure pode ajudar a criar o melhor software é simples.
HISTÓRICO: CONTROLE DA MALHA
O Windows Azure é projetado para funcionar em data centers contendo grandes quantidades de computadores. Assim, cada aplicativo do Windows Azure é executado em várias máquinas simultaneamente. A Figura 4 mostra um exemplo simples de como isso parece.
Como ilustrado na Figura 4, todos os computadores de um data center específico do Windows Azure são gerenciados por um aplicativo chamado controle da malha. O controle da malha é um aplicativo
distribuído e funciona em vários computadores.
Quando um desenvolvedor coloca um aplicativo para ser executado no Windows Azure, ele fornece o código para funções do aplicativo, juntamente com a definição de serviço e os arquivos de configuração do serviço para este aplicativo. Entre outras coisas, essa informação orienta o controle da malha sobre quantas instâncias de cada função devem ser criadas. O controle da malha escolhe uma máquina física para cada instância, em seguida, cria uma VM nessa máquina e começa a execução da instância. Como a figura sugere, as instâncias de função para um único aplicativo são distribuídas por diferentes máquinas dentro deste data center.
Depois de criar essas instâncias, o controle da malha continua a monitorá-las. Se uma instância falhar por algum motivo—hardware ou software— o controle da malha iniciará uma nova instância para essa função. Apesar das falhas poderem causar a queda temporária da contagem da instância de um aplicativo para um valor abaixo do que o desenvolvedor solicitou, o controle da malha começará sempre novas instâncias conforme a necessidade para manter a meta de números de cada uma das funções do aplicativo. E mesmo que a Figura 4 mostre apenas Web Roles e Worker Roles, as funções de VM são tratadas da mesma maneira, com cada uma das instâncias de função sendo executadas em uma máquina física diferente.
BENEFÍCIOS: MELHOR ADMINISTRAÇÃO, DISPONIBILIDADE E ESCALABILIDADE
Os aplicativos criados usando o modelo de programação do Windows Azure podem ser mais fáceis de administrar, mais disponíveis e mais escalonáveis que aqueles criados em servidores Windows tradicionais. Vale a pena olhar para esses três atributos separadamente.
Benefícios administrativos do alto fluxo do Windows Azure no controle da malha. Como todo sistema operacional, o Windows deve ser corrigido, assim como outros sistemas de software. Em ambientes locais, fazer isso geralmente requer algum esforço humano. No Windows Azure, entretanto, o processo é totalmente automatizado: O controle da malha faz as atualizações para as instâncias de Web Role e Worker Roles (embora não para as instâncias de função de VM). Quando necessário, ele também atualiza os servidores Windows subjacentes em que as VMs estão rodando. O resultado é a redução de custos, uma vez que não são necessários administradores para essa função.
Reduzir custos exigindo menos administração é bom. Ajudar os aplicativos a estarem mais acessíveis também é bom, e por isso o modelo de programação do Windows Azure ajuda a melhorar a
disponibilidade dos aplicativos de várias maneiras. Aqui estão elas:
o Proteção contra falhas de hardware. Como cada aplicativo é composto de múltiplas instâncias de cada função, falhas de hardware—pane de disco, falha na rede, ou a morte de um servidor da máquina—não derrubarão o aplicativo. Para ajudar com isso, o controle da malha não escolhe máquinas para as instâncias de um aplicativo de forma aleatória. Em vez disso, diferentes instâncias da mesma função são colocadas em diferentes domínios com falhas. Um domínio com falhas é um conjunto de hardware—computadores, switches, e mais—que compartilham um único ponto de falha. (Por exemplo, todos os computadores em um único domínio com falhas podem depender do mesmo switch para se conectarem à rede.) Por isso, uma única falha no hardware não é capaz de derrubar um aplicativo inteiro. O aplicativo pode perder temporariamente algumas instâncias, mas
o Proteção contra falhas de software. Além dessas falhas de hardware, o controle da malha também pode detectar falhas causadas pelo software. Se o código em uma instância trava ou a VM na qual ele está sendo executado sofre uma pane, o controle da malha iniciará apenas o código ou, se necessário, uma nova VM para aquela função. Ao mesmo tempo em que qualquer trabalho que a instância desenvolvia no momento da falha será perdido, a nova instância se tornará parte do aplicativo assim que ele começar a ser executado.
o Capacidade de atualizar aplicativos sem que eles tenham um período de inatividade. Seja para manutenção de rotina ou para instalar uma versão completamente nova, todos os aplicativos precisam ser atualizados. Um aplicativo criado utilizando o modelo de programação do Windows Azure pode ser atualizado enquanto está sendo executado—não é necessário desligá-lo. Para que isso seja possível, diferentes instâncias para cada uma das funções do aplicativo são colocadas em diferentes domínios de atualização, (que não são os mesmos que os domínios com falhas descritos anteriormente). Quando uma nova versão do aplicativo precisa ser implantada, o controle da malha pode desligar as instâncias em apenas um domínio de atualização, atualizar o código para eles, e criar novas instâncias a partir daquele novo código. Uma vez que aquelas instâncias estão sendo executadas, ele pode fazer o mesmo com instâncias do próximo domínio de atualização, e assim por diante. Enquanto os usuários podem visualizar diferentes versões do aplicativo durante esse processo, dependendo de com qual instância eles interagem, o aplicativo como um todo permanece continuamente disponível.
o Capacidade de atualizar o Windows e outros softwares de apoio sem que o aplicativo tenha um período de inatividade. O controle da malha considera que todo aplicativo do Windows Azure segue as três regras listadas anteriormente, e por isso, sabe que ele pode desligar algumas das instâncias do aplicativo quando quiser, atualizar o sistema de software subjacente, e iniciar novas instâncias. Ao fazer isso por partes, nunca desligando todas as instâncias de uma função ao mesmo tempo, o Windows e outro software podem ser atualizados enquanto um aplicativo é executado continuamente.
Disponibilidade é importante para a maioria dos aplicativos— o software não é útil se não funcionar quando você precisa—mas escalabilidade também importa. O modelo de programação do Windows Azure ajuda desenvolvedores a criar mais aplicativos escalonáveis de duas formas diferentes:
o Criando e mantendo um número específico de instâncias de função automaticamente. Como descrito anteriormente, um desenvolvedor informa o Windows Azure quantas instâncias de cada função executar, e o controle da malha cria e monitora as instâncias solicitadas. Isso torna a escalabilidade de aplicativos bem simples: Apenas diga ao Windows Azure o que você precisa. Uma vez que plataformas em nuvem executam data centers muito grandes, obter o nível de escalabilidade que um aplicativo precisa não é, normalmente, um problema.
o Proporcionar uma forma de modificar o número ativo de instâncias de função para um aplicativo em execução: Para aplicativos de carga variável a escalabilidade é mais complicada. Definir o número de instâncias apenas uma vez não é uma boa solução, uma vez que diferentes cargas podem fazer a contagem ideal da instância aumentar ou diminuir de forma significativa. Para resolver essa situação, o Windows Azure fornece tanto um portal da Web para pessoas, quanto uma API para aplicativos
Tornar aplicativos mais simples de administrar, mais disponíveis, e mais escalonáveis é útil, e por isso, usar o modelo de programação do Windows Azure geralmente faz sentido. Mas como mencionado anteriormente, é possível executar aplicativos no Windows Azure que não seguem este modelo. Suponha, por exemplo, que você criou um aplicativo usando uma única função (o que é permitido), mas executando apenas uma instância daquela função (violando a segunda e a terceira regra). Você pode fazer isso para economizar, uma vez que o Windows Azure tarifa separadamente cada instância em execução. Qualquer pessoa que escolha essa opção deveria entender, entretanto, que o controle da malha não saberá que seu aplicativo não segue as três regras. Ele desligará essa instância em momentos imprevisíveis para corrigir o software subjacente, e em seguida, reiniciar um novo. Para os usuários, isso significa que o aplicativo desligará periodicamente, uma vez que não há outra instância para assumir o controle. Isso não é um erro do Windows Azure; é um aspecto fundamental de como a tecnologia funciona.
Obter todos os benefícios que o Windows Azure oferece requer conformidade com as regras de seu modelo de programação. Mover aplicativos existentes do Windows Server para o Windows Azure pode dar um pouco de trabalho, um tópico abordado com mais detalhes posteriormente neste documento. Para aplicativos novos, no entanto, o argumento para utilizar o modelo do Windows Azure é claro. Por que não criar um aplicativo que custe menos ao administrador? Por que não criar um aplicativo que nunca precisa ficar inativo? Por que não criar um aplicativo que pode facilmente ser dimensionado conforme necessário? Com o tempo, é razoável esperar que mais e mais aplicativos sejam criados utilizando o modelo de programação do Windows Azure.
IMPLICAÇÕES DO MODELO DE PROGRAMAÇÃO DO WINDOWS AZURE: O QUE MAIS MUDA?
Criar aplicativos para o Windows Azure significa seguir as três regras de seu modelo de programação. Mas seguir essas três regras não é suficiente—outras partes do mundo do desenvolvedor também devem ser ajustadas. As mudanças que o modelo de programação do Windows Azure traz para o ambiente de desenvolvimento de forma mais abrangente podem ser agrupadas em três áreas:
o De que forma instâncias de função interagem com o sistema operacional.
o De que forma instâncias de função interagem com armazenamento persistente.
o De que forma instâncias de função interagem com outras instâncias de função.
Essa seção aborda as três áreas.
INTERAÇÕES COM O SISTEMA OPERACIONAL
Para um aplicativo executado em uma máquina típica do Windows Server, o administrador da máquina está no controle. Ela pode reiniciar VMs ou a máquina em que eles são executados, instalar patches do Windows, e fazer o que mais for necessário para manter o computador disponível. No Windows Azure, no entanto, todos os servidores são de propriedade do controle da malha. Ele decide quando as VMs ou máquinas devem ser reiniciadas, e para Web Roles e Worker Roles (embora não para funções da VM), o controle da malha também instala patches e outras atualizações no software do sistema em todas as instâncias.
Conforme descrito anteriormente, essa abordagem tem benefícios reais. No entanto, ela também cria restrições. Como o controlador da malha possui máquinas físicas e virtuais utilizadas pelos aplicativos do Windows Azure, ele é livre para fazer o que quiser com elas. Isso significa deixar um aplicativo do
Windows Azure modificar o sistema em que é executado—deixá-lo rodar em modo de administrador, em vez de modo de usuário— apresenta alguns desafios. Uma vez que o controle da malha pode modificar o sistema operacional à vontade, não há garantias de que mudar uma instância de função não fará com que o sistema em que ele está sendo executado seja substituído. Além disso, as máquinas virtuais (e físicas) específicas em que o aplicativo é executado mudam com o tempo. Isso significa que qualquer mudança no ambiente de desenvolvimento padrão deve ser feita cada vez que uma instância de função começa a ser executada.
Em seu primeiro lançamento, o Windows Azure simplesmente não permitia que os aplicativos modificassem os sistemas em que funcionavam—os aplicativos só rodavam no modo de usuário. Esta restrição foi reduzida—agora tanto Web Roles quanto Worker Roles dão aos desenvolvedores a opção de executar aplicativos no modo de administrador—mas, em geral, o modelo de programação não mudou. Qualquer pessoa que crie um aplicativo do Windows Azure precisa entender o que o controle da malha está fazendo, e desenvolver os aplicativos de acordo.
INTERAÇÕES COM O ARMAZENAMENTO PERSISTENTE
Aplicativos não são apenas códigos—eles também usam dados. E assim como o modelo de programação deve mudar para tornar os aplicativos mais disponíveis e mais escalonáveis, a forma como os dados são armazenados e acessados também deve mudar. As grandes mudanças são:
o O armazenamento deve ser externo a instâncias de função. Mesmo que cada instância seja sua própria VM com seu próprio sistema de arquivos, dados armazenados nesses sistemas de arquivo não se tornam permanentes automaticamente. Se uma instância falhar, qualquer dado que ela contenha pode ser perdido. Isso significa que para que os aplicativos funcionem corretamente em casos de falhas, os dados devem ser armazenados de forma permanente fora das instâncias de função. Outra instância de função pode agora acessar dados que teriam sido perdidos caso aqueles dados tivessem sido armazenados localmente em uma instância com defeito.
o O armazenamento deve ser duplicado. Assim como um aplicativo do Windows Azure executa múltiplas instâncias de função considerando falhas, o armazenamento do Windows Azure deve fazer múltiplas cópias de dados. Sem isso, uma única falha tornaria os dados indisponíveis, algo que não é aceitável para aplicativos altamente disponíveis.
o O armazenamento deve ser capaz de lidar com quantidades muito grandes de dados. Sistemas relacionais tradicionais não são necessariamente a melhor opção para conjuntos muito grandes de dados. Uma vez que o Windows Azure foi criado em parte para aplicativos escalonáveis em massa, ele deve fornecer mecanismos de armazenamento capazes de trabalhar com dados nessa escala. Para tornar isso possível, a plataforma oferece blobs para armazenar dados binários com uma abordagem diferente da SQL chamada tabelas para o armazenamento de grandes conjuntos de dados estruturados.
Figura 5: Enquanto aplicativos veem uma única cópia, o armazenamento do Windows Azure replica todos os blobs e tabelas três vezes.
Nesse exemplo, um aplicativo do Windows Azure está usando dois blobs e uma tabela do armazenamento do Windows Azure. O aplicativo vê cada blob e tabela como uma única entidade, mas na verdade o armazenamento do Windows Azure mantém três instâncias de cada uma. Essas cópias estão distribuídas em diferentes máquinas físicas, e assim como instâncias de função, essas máquinas estão em diferentes domínios com falhas. Isso melhora a disponibilidade do aplicativo, uma vez que os dados ainda são acessíveis mesmo quando algumas cópias não estão disponíveis. E devido aos dados permanentes estarem armazenados fora de qualquer uma das instâncias de função do aplicativo, uma falha da instância perde somente os dados que estavam sendo utilizados no momento da falha.
O modelo de programação do Windows Azure requer que o aplicativo se comporte corretamente quando uma instância de função falha. Para fazer isso, cada instância de um aplicativo deve armazenar todos os dados permanentes no armazenamento do Windows Azure ou outro mecanismo de armazenamento interno (tal como o SQL Azure, serviço em nuvem da Microsoft para dados relacionais). Existe, no entanto, outra opção que vale a pena mencionar: as unidades do Windows Azure. Como descrito anteriormente, qualquer dado que um aplicativo escreva no sistema local de arquivos de sua própria VM pode ser perdido quando aquela VM para de funcionar. As unidades do Windows Azure alteram isso utilizando um blob para fornecer armazenamento permanente para o sistema de arquivos de uma instância em particular. Essas unidades têm algumas limitações—apenas uma instância de cada vez pode ler de, e escrever para uma unidade específica do Windows Azure, por exemplo, sendo que todas as outras instâncias nesse aplicativo têm permissão de acesso apenas para leitura—mas elas podem ser úteis em
INTERAÇÕES NAS INSTÂNCIAS DE FUNÇÃO
Quando um aplicativo é dividido em várias partes, essas partes normalmente devem interagir umas com as outras. Em um aplicativo do Windows Azure isso é expressado como comunicação entre instâncias de função. Por exemplo, uma instância de Web Role pode aceitar solicitações de usuários, e transmiti-las para uma instância de Worker Role para processamento.
A forma como essa interação acontece não é idêntica à forma como é feita com aplicativos comuns do Windows. Mais uma vez, um fator-chave que deve ser lembrado é que, com mais frequência, todas as instâncias de uma função específica são equivalentes—elas são intercambiáveis. Isso significa que quando, digamos, uma instância de Web Role transfere trabalho para uma instância de Worker Role, não importa que instância em particular recebe o trabalho. Na verdade, a instância de Web Role não deveria depender de elementos específicos da instância, tais como um endereço IP da instância de função de Funcionário, para se comunicar com aquela instância. São necessários mais mecanismos genéricos. A forma mais comum das instâncias de função se comunicarem nos aplicativos do Windows Azure é por meio de enfileiramentos do Windows Azure. A Figura 6 ilustra a ideia.
Figura 6: Instâncias de Função podem se comunicar por meio de enfileiramentos, cada uma replica as mensagens que contém três vezes.
No exemplo aqui mostrado, uma instância de Web Role obtém trabalho de um usuário do aplicativo, tal como uma pessoa fazendo uma solicitação a partir de um navegador (etapa 1). Essa instância cria uma mensagem contendo este trabalho e o escreve em um enfileiramento do Windows Azure (etapa 2). Esses enfileiramentos são implementados como parte do armazenamento do Windows Azure, e como blobs e tabelas, cada
A seguir, uma instância de função de Funcionário lê a mensagem a partir do enfileiramento (etapa 3). Observe que a instância de Worker Role que criou esta mensagem não se importa com qual instância de Worker Role faz isso—nesse aplicativo todas são equivalentes. A instância de Worker Role faz qualquer trabalho que a mensagem solicite (etapa 4), e apaga a mensagem do enfileiramento (etapa 5).
Essa última etapa—remoção explícita da mensagem da fila —é diferente do que tecnologias de enfileiramento locais fazem normalmente. No Microsoft Message Queuing (MSMQ), por exemplo, um aplicativo é capaz de fazer uma leitura durante uma transação atômica. Se o aplicativo falhar antes de completar seu trabalho, a transação é anulada, e a mensagem aparece automaticamente na fila. Essa abordagem garante que toda mensagem enviada para uma fila MSMQ é entregue exatamente uma vez na ordem em que foi enviada.
As filas do Windows Azure não suportam leituras transacionais, e por isso não garantem exatamente prioridade na ordem de entrega. No exemplo mostrado na Figura 6, por exemplo, a instância de Worker Role pode encerrar o processamento da mensagem e sofrer uma pane antes de apagá-la da fila. Se isso acontecer, a mensagem reaparecerá automaticamente após um tempo limite configurável, e outra instância de Worker Role vai processá-la. Ao contrário do MSMQ, as filas do Windows Azure têm, pelo menos, uma semântica: Uma mensagem pode ser lida e processada uma ou mais vezes.
Isso gera uma questão óbvia: Por que as filas do Windows Azure não suportam leituras transacionais? A resposta é que transações requerem bloqueio, e por isso, elas necessariamente tornam as coisas mais lentas (especialmente com a duplicação de mensagens feita pelas filas do Windows Azure). Dados os objetivos primários da plataforma, seus desenvolvedores optaram pela abordagem mais rápida e mais escalonável.
Na maior parte do tempo, enfileiramentos são a melhor forma de instâncias de função se comunicarem dentro de um aplicativo. No entanto, também é possível que instâncias interajam diretamente, sem passar pelo enfileiramento. Para permitir isso, o Windows Azure fornece uma API que permite que uma instância descubra todas as outras instâncias no mesmo aplicativo que atendem requisitos específicos, e em seguida, envia uma solicitação diretamente para uma delas. Nos casos mais comuns, em que todas as instâncias de uma função particular são equivalentes, o chamador deveria escolher uma instância alvo aleatoriamente a partir desse conjunto de retornos da API. Isso não é sempre verdade—talvez uma função de Funcionário implemente um cache na memória com cada instância de função processando dados específicos, e o chamador deve acessar um em particular. Com mais frequência, no entanto, a abordagem correta é tratar todas as instâncias de uma função como intercambiáveis.
COMO MOVER APLICATIVOS DO WINDOWS SERVER PARA O WINDOWS AZURE Qualquer pessoa ao criar um novo aplicativo do Windows Azure deveria seguir as regras do modelo de programação do Windows Azure. Para mover um aplicativo existente do Windows Server para o Windows Azure, no entanto, esse aplicativo também deve ser feito para seguir as mesmas regras. Além disso, pode ser necessária a modificação de como o aplicativo interage com o sistema operacional, como ele utiliza o armazenamento persistente, e da forma como seus componentes interagem uns com os outros.
O quão fácil é fazer essas mudanças depende do aplicativo. Aqui estão alguns exemplos representativos:
o Um aplicativo ASP.NET com várias instâncias de balanceamento de carga que compartilha o estado armazenado no SQL Server. Este tipo de aplicativo normalmente migra facilmente para o Windows
Role. Aplicativos como este não utilizam sessões agrupadas, o que os ajuda a serem adequados para o Windows Azure. (Usar o estado da sessão ASP.NET é aceitável, porém, desde que o Windows Azure forneça uma opção para armazenar o estado de sessão de forma permanente em tabelas de Armazenamento do Windows Azure.) E mover um banco de dados SQL Server local para o SQL Azure, normalmente, é simples.
o Um aplicativo ASP.NET com várias instâncias que mantêm o estado por instância e dependem de seções agrupadas. Devido à manutenção do estado do cliente específico em cada instância entre as solicitações, o aplicativo precisará de algumas mudanças. O Windows Azure não suporta seções agrupadas, então para fazer o aplicativo rodar nessa plataforma em nuvem, será necessário projetar novamente a forma como ele controla o estado.
o Um cliente Silverlight ou do Windows Presentation Foundation (WPF) que acessa serviços WCF rodando em uma camada intermediária. Se os serviços não mantêm o estado por cliente entre as chamadas, transferi-los para o Windows Azure será simples. Como sempre, o cliente continuará a executar na área de trabalho do usuário, mas agora irá chamar os serviços em execução no Windows Azure. Se, no entanto, os serviços atuais mantiverem o estado por cliente, eles precisarão ser projetados novamente.
o Um aplicativo com uma única instância em execução no Windows Server que mantém o estado sobre a sua própria máquina. Se os clientes forem navegadores ou qualquer outra coisa, e atualmente vários aplicativos corporativos são construídos desta forma, e eles não funcionarem bem no Windows Azure sem nenhuma reformulação. Talvez seja possível rodar esse aplicativo não modificado em uma única instância de função de VM, mas seus usuários provavelmente não ficarão felizes com os resultados. Por um lado o Windows Azure SLA não se aplica aos aplicativos com apenas uma instância. Além disso, lembre-se que o controle da malha pode, a qualquer momento, reiniciar a máquina em que essa instância está sendo executada para atualizar o software da mesma. O aplicativo não tem controle sobre quando isso acontece. Pode acontecer bem no meio da jornada de trabalho. Como não há segunda instância para assumir—o aplicativo não foi criado para seguir as regras do modelo de programação do Windows Azure—ele ficará indisponível por um certo período de tempo, e assim qualquer um que estiver usando o aplicativo terá seu trabalho interrompido enquanto a máquina é reiniciada. Embora a função de VM torne mais fácil mover um binário do Windows Server para o Windows Azure, isso não garante que o aplicativo será executado com sucesso em seu novo ambiente. O aplicativo também deve obedecer às regras do modelo de programação do Windows Azure.
o Um aplicativo Visual Basic 6 que acessa diretamente um banco de dados do SQL Server, por exemplo, um aplicativo tradicional cliente/servidor. Para fazer este aplicativo rodar no Windows Azure, provavelmente será necessário reescrever pelo menos a lógica comercial do cliente. Embora possa ser possível mover o banco de dados (incluindo todos os procedimentos armazenados) para o SQL Azure, e redirecionar os clientes para este novo local, os componentes do aplicativo da área de trabalho não serão executados como se estivessem no Windows Azure. O Windows Azure não fornece uma interface de usuário local, e também não oferece suporte usando Serviços de Área de Trabalho Remota (antigo Serviço de Terminal) para fornecer interfaces com o usuário remoto.
algum esforço. Tomar boas decisões exige compreensão tanto do valor potencial comercial quanto dos desafios técnicos que a migração de um aplicativo para o Windows Azure pode trazer.
CONCLUSÃO
As plataformas em nuvem são um mundo novo, e abrem novas possibilidades. Refletindo isso, o modelo de programação do Windows Azure ajuda os desenvolvedores a criar aplicativos mais fáceis de
administrar, mais disponíveis e mais escalonáveis do que aqueles criados no ambiente tradicional do Windows Server. Ao fazer isso é necessário seguir três regras:
o Um aplicativo do Windows Azure é criado a partir de uma ou mais funções.
o Um aplicativo do Windows Azure roda várias instâncias de cada função.
o Um aplicativo do Windows Azure se comporta corretamente quando qualquer instância de função falha.
Usar esse modelo de programação com sucesso também requer a compreensão das mudanças que ele traz à forma como os aplicativos interagem com o sistema operacional, como usam o armazenamento persistente, e como se comunicam entre instâncias de função. Para desenvolvedores dispostos a fazer isso, no entanto, o valor é claro. Embora não seja adequado para todos os cenários, o modelo de
programação do Windows Azure pode ser útil para quem quer criar aplicativos mais fáceis de administrar, mais disponíveis e mais escalonáveis.
PARA LEITURA ADICIONAL
Introduzindo o Windows Azure: http://go.microsoft.com/?linkid=9682907
Introduzindo a plataforma Windows Azure: http://go.microsoft.com/fwlink/?LinkId=158011
SOBRE O AUTOR
David Chappell é Diretor da Chappell & Associates (www.davidchappell.com) em São Francisco, Califórnia. Com sua fala, escrita, e consultoria, ele ajuda pessoas de todo o mundo a entender, usar e tomar
