MODELO DE PROGRAMAÇÃO DO WINDOWS AZURE

MODELO DE PROGRAMAÇÃO DO WINDOWS AZURE DAVID CHAPPELL OUTUBRO DE 2010 PATROCINADO PELA MICROSOFT CORPORATION

SUMÁRIO Pr que criar um nv mdel de prgramaçã?... 3 Três regras d mdel de prgramaçã d Windws Azure... 4 Um aplicativ Windws Azure é criad a partir de uma u mais funções.... 4 Um aplicativ Windws Azure executa várias instâncias para cada funçã.... 5 Um aplicativ d Windws Azure se cmprta crretamente quand qualquer instância de funçã falha.... 6 O que mdel de prgramaçã d Windws Azure frnece... 8 Históric: Cntrle da malha... 8 Benefícis: Melhr Administraçã, Dispnibilidade e Escalabilidade... 9 Implicações d Mdel de Prgramaçã d Windws Azure: O que mais muda?... 11 Interações cm Sistema Operacinal... 11 Interações cm Armazenament Persistente... 12 Interações nas Instâncias de Funçã... 14 Cm mver Aplicativs d Windws Server para Windws Azure... 15 Cnclusã... 17 Para leitura adicinal... 17 Sbre Autr... 17 2

POR QUE CRIAR UM NOVO MODELO DE PROGRAMAÇÃO? Milhões de desenvlvedres d mund inteir sabem cm criar aplicativs usand mdel de prgramaçã d Windws Server. N entant, s aplicativs escrits para Windws Azure, platafrma em nuvem da Micrsft, nã usam exatamente este mdel familiar. Embra a mairia das cmpetências ds desenvlvedres d Windws ainda se aplique, Windws Azure frnece seu mdel de prgramaçã própri. Pr quê? Pr que nã apenas replicar mund familiar d Windws Server na nuvem? Muits frnecedres de platafrmas em nuvem fazem iss, frnecend máquinas virtuais (VMs) que agem cm em VMs lcais. Esta abrdagem, cmumente chamada Infraestrutura cm um Serviç (IaaS), certamente tem valr, e é a esclha certa para alguns aplicativs. N entant, platafrmas em nuvem cnstituem um nv mund, cm ptencial para reslver s prblemas de hje de nvas frmas. Em vez de IaaS, Windws Azure ferece um nível mais alt de abstraçã que é tipicamente categrizad cm Platafrma cm um Serviç (PaaS). A mesm temp em que ela é similar de muitas frmas cm mund d Windws instalad lcalmente, essa abstraçã tem seu própri mdel de prgramaçã direcinad a ajudar desenvlvedres a criar aplicativs melhres. O mdel de prgramaçã d Windws Azure fca a melhria de aplicativs em três áreas: Administraçã: Nas tecnlgias PaaS, a própria platafrma reslve a mair parte das tarefas administrativas. Cm Windws Azure, iss significa que a platafrma reslve autmaticamente questões tais cm a aplicaçã de Windws patches e a instalaçã de nvas versões d sftware de sistema. O bjetiv é reduzir esfrç e cust da administraçã d ambiente d aplicativ. Dispnibilidade: Seja planejad u nã, s aplicativs de hje nrmalmente têm temp de inatividade para Windws patches, atualizações de aplicativs, falhas de hardware, e utras razões. N entant, dada a redundância que platafrmas em nuvem trnam pssíveis, nã há mais qualquer razã para aceitar iss. O mdel de prgramaçã d Windws Azure é criad para deixar s aplicativs dispníveis permanentemente, mesm em face de atualizações de sftware e falhas de hardware. Escalabilidade: Os tips de aplicativs que as pessas querem escrever em nuvem sã, frequentemente, destinads a lidar cm muits usuáris. Prém, mdel de prgramaçã tradicinal d Windws Server nã fi criad explicitamente para suprtar aplicativs escalnáveis para Internet. O mdel de prgramaçã d Windws Azure fi, n entant, criad desde iníci cm bjetiv de fazer iss. Criad para a Era da nuvem, fi desenvlvid para permitir que desenvlvedres criassem aplicativs escalnáveis que grandes centrs de dads pdem suprtar. Tã imprtante quant iss, ele também permite que s aplicativs sejam escalnads para baix quand necessári, permitind-s utilizar apenas s recurss de que necessitam. Se desenvlvedr usar uma tecnlgia IaaS u ferecer PaaS, tal cm Windws Azure, criar aplicativs em platafrmas em nuvem tem alguns benefícis inerentes. As duas abrdagens permitem que vcê pague apenas pels recurss de cmputaçã que usar, pr exempl, e que vcê nã tenha que esperar pel seu departament de TI para implantar servidres. Apesar de serem tã imprtantes, esses benefícis nã sã nss tópic. Em vez diss, fc é deixar clar que é mdel de prgramaçã d Windws Azure e que ele ferece. 3

TRÊS REGRAS DO MODELO DE PROGRAMAÇÃO DO WINDOWS AZURE Para bter s benefícis que ele prmete, mdel de prgramaçã d Windws Azure impõe três regras as aplicativs: Um aplicativ Windws Azure é criad a partir de uma u mais funções. Um aplicativ Windws Azure executa várias instâncias para cada funçã. Um aplicativ Windws Azure se cmprta crretamente quand qualquer instância de funçã falha. Vale enfatizar que Windws Azure pde executar aplicativs que nã seguem tdas essas regras ele, na verdade, nã as exige. A cntrári, a platafrma simplesmente presume que tds s aplicativs seguem as três. Apesar de pder ptar pr executar um aplicativ n Windws Azure que vile uma u mais regras, esteja ciente de que esse aplicativ nã está, na verdade, utilizand mdel de prgramaçã d Windws Azure. A mens que vcê entenda e siga as regras d mdel, aplicativ pde nã funcinar cm vcê espera. UM APLICATIVO WINDOWS AZURE É CRIADO A PARTIR DE UMA OU MAIS FUNÇÕES. Se um aplicativ é executad em nuvem u n seu centr de dads, ele pde certamente ser dividid em partes lógicas. O Windws Azure frmaliza essas três divisões cm funções. Uma funçã inclui um cnjunt específic de códigs, tais cm um cnjunt.net, e define ambiente n qual tal códig funcina. O Windws Azure hje permite que desenvlvedres criem três tips diferentes de funções: Web Rle: Cm nme sugere, Web Rles sã essencialmente destinadas à lógica que interage cm mund exterir via HTTP. O códig escrit cm uma Web Rle geralmente recebe sua entrada pr mei ds Serviçs de Infrmações da Internet (IIS), e pde ser criad usand várias tecnlgias, incluind ASP.NET, Windws Cmmunicatin Fundatin (WCF), PHP e Java. Wrker Rle: Lógica escrita cm uma funçã de funcinári pde interagir cm mund exterir de maneiras diversas nã é limitad a HTTP. Pr exempl, uma Wrker Rle pde cnter códigs que cnvertem vídes para um frmat padrã u calculam risc de uma carteira de investiments u realizam algum tip de análise de dads. Funçã de Máquina Virtual (VM): Uma funçã de VM executa uma imagem um disc rígid virtual (VHD) de uma máquina virtual d Windws Server 2008 R2. Esse VHD é criad utilizand uma máquina lcal d Windws Server e, em seguida, carregad para Windws Azure. Depis de armazenad na nuvem, VHD pde ser carregad sb demanda em uma funçã de VM e executad. As três funções sã úteis. A funçã de VM ficu dispnível recentemente, n entant e, pr iss, é just dizer que as pções usadas hje cm mais frequência sã Web Rles e Wrker Rles. A Figura 1 mstra um aplicativ simples d Windws Azure criad cm uma Web Rle e uma Wrker Rle. 4

A Figura 1: Um aplicativ d Windws Azure é criad a partir de uma u mais funções, tais cm a cmbinaçã de Web Rles e Wrker Rles aqui mstradas. Esse aplicativ pde usar uma Web Rle para aceitar slicitações HTTP de usuáris, e deixar de lad trabalh que esses usuáris slicitam, tais cm frmatar nvamente um arquiv de víde e trná-l dispnível para visualizaçã para uma Wrker Rle. A principal razã para esta divisã em duas partes é que dividir tarefas dessa frma pde trnar aplicativ mais fácil de escalnar. Um aplicativ d Windws Azure também pde cnsistir em apenas uma Web Rle u uma Wrker Rle vcê nã precisa usar as duas. Um únic aplicativ pde até cnter diferentes tips de Web Rles e Wrker Rles. Pr exempl, um aplicativ pde ter uma funçã da Web que implemente uma interface de navegadr, talvez criada utilizand ASP.NET, e utra Web Rle que apresente interfaces de serviçs da Web implementadas utilizand WCF. D mesm md, um aplicativ d Windws Azure que tenha executad dis tips diferentes de análise de dads pde definir uma Wrker Rle diferente da utra. Para manter as cisas simples, n entant, vams cnsiderar que exempl de aplicativ aqui descrit tem apenas uma Web Rle e uma Wrker Rle. Cm parte da criaçã d aplicativ d Windws Azure, um desenvlvedr cria um arquiv de definiçã de serviç que nmeia e descreve as funções d aplicativ. Esse arquiv também pde especificar utra infrmaçã, tal cm as prtas que cada funçã pde escutar. O Windws Azure utiliza essa infrmaçã para criar ambiente crret para executar aplicativ. UM APLICATIVO WINDOWS AZURE EXECUTA VÁRIAS INSTÂNCIAS PARA CADA FUNÇÃO. Cada aplicativ d Windws Azure cnsiste em uma u mais funções. Quand ele executa, um aplicativ em cnfrmidade cm mdel de prgramaçã d Windws Azure deve rdar, pel mens, duas cópias duas instâncias distintas de cada funçã que ele cntém. Cada instância rda cm sua própria VM, cm mstra a Figura 2. 5

Figura 2: Um aplicativ Windws Azure executa várias instâncias para cada funçã. Cm descrit anterirmente, exempl de aplicativ aqui mstrad tem apenas uma Web Rle e uma Wrker Rle. Um desenvlvedr pde dizer a Windws Azure quantas instâncias de cada funçã executar pr mei de um arquiv de cnfiguraçã d serviç (que é diferente d arquiv de definiçã d serviç mencinad na seçã anterir). Aqui, desenvlvedr slicitu quatr instâncias da Web Rle d aplicativ e três instâncias da Wrker Rle. Tdas as instâncias de uma funçã específica executam exatamente mesm códig. Na verdade, cm a mairia ds aplicativs d Windws Azure, cada instância é exatamente igual a tdas as utras instâncias daquela funçã elas sã intercambiáveis. Pr exempl, Windws Azure carrega autmaticamente slicitações de balançs de carga HTTP nas instâncias das Web Rles d aplicativ. Esse balanç de carga nã suprta sessões agrupadas, pr iss nã é pssível direcinar tdas as slicitações d cliente para a mesma instância de Web Rle. Armazenar estad específic d cliente, tal cm um carrinh de cmpras em uma instância específica de Web Rle nã vai funcinar prque Windws Azure nã garante que tds s pedids de um cliente serã reslvids pr essa instância. Em vez diss, esse tip de estad deve ser armazenad externamente, cm descrit mais adiante. UM APLICATIVO DO WINDOWS AZURE SE COMPORTA CORRETAMENTE QUANDO QUALQUER INSTÂNCIA DE FUNÇÃO FALHA. Um aplicativ que segue mdel de prgramaçã d Windws Azure deve ser criad utilizand funções, e deve executar duas u mais instâncias de cada uma dessas funções. Ele também deve se cmprtar crretamente quand qualquer uma das instâncias de funçã falhar. A Figura 3 ilustra essa ideia. 6

Figura 3: Um aplicativ d Windws Azure se cmprta crretamente até mesm quand uma instância de funçã falha. Aqui, aplicativ mstrad na Figura 2 perdeu duas de suas instâncias de Web Rle e uma de suas instâncias de Wrker Rle. Talvez s cmputadres em que elas estavam send executadas tenham falhad, u a cnexã física da rede cm essas máquinas tenha caíd. Seja qual fr a razã, desempenh d aplicativ tende a cair, uma vez que há mens instâncias para realizar seu trabalh. Ainda assim, aplicativ permanece ligad e funcinand crretamente. Se tdas as instâncias de uma funçã particular falham, aplicativ vai deixar de se cmprtar cm deveria iss nã pde ser evitad. N entant, a brigaçã de funcinar crretamente durante falhas parciais é fundamental para mdel de prgramaçã d Windws Azure. Na verdade, cntrat de nível de serviç (SLA) para Windws Azure requer a execuçã de, pel mens, duas instâncias para cada funçã. Aplicativs que executam apenas uma instância de qualquer funçã nã pdem bter as garantias que SLA frnece. A frma mais cmum de cnseguir iss é trnar cada instância de funçã equivalente, cm cm as Web Rles cm carga equilibrada aceitand slicitações d usuári. N entant, iss nã é estritamente necessári, desde que a falha de uma simples instância de funçã nã prvque falhas n aplicativ. Pr exempl, um aplicativ pde usar um grup de instâncias de Wrker Rle para cultar dads para instâncias de Web Rle, cm cada instância de Wrker Rle guardand dads diferentes. Se qualquer instância de Wrker Rle falhar, uma instância de Web Rle tentand acessar s dads armazenads em cache se cmprta exatamente cm seria se s dads nã tivessem sid encntrads n cache (pr exempl, ele acessa armazenament persistente para lcalizar s dads). A falha pde prvcar lentidã na execuçã d aplicativ, mas cnfrme bservad pr um usuári, ainda se cmprta crretamente. 7

Mais um pnt imprtante a ser lembrad é que mesm que exempl de aplicativ descrit até agra cntenha apenas Web Rles e Wrker Rles, tdas essas regras também se aplicam a aplicativs que utilizam funções de VM. Assim cm s utrs, cada funçã VM deve executar pel mens duas instâncias para se qualificar para Windws Azure SLA, e aplicativ deve cntinuar funcinand crretamente se uma dessas instâncias falhar. Mesm cm as funções de VM, Windws Azure ainda frnece uma frma de PaaS nã é um IaaS tradicinal. O QUE O MODELO DE PROGRAMAÇÃO DO WINDOWS AZURE FORNECE O mdel de prgramaçã d Windws Azure é basead n Windws, e a mair parte das cmpetências ds desenvlvedres Windws sã aplicáveis a este nv ambiente. Mesm assim, nã é igual a mdel cnvencinal de prgramaçã d Windws Server. Entã pr que se precupar em entender iss? Cm iss ajuda a criar melhres aplicativs? Para respnder a essas questões, vale a pena primeir explicar um puc mais sbre funcinament d Windws Azure. Uma vez que iss esteja clar, entender cm mdel de prgramaçã d Windws Azure pde ajudar a criar melhr sftware é simples. HISTÓRICO: CONTROLE DA MALHA O Windws Azure é prjetad para funcinar em data centers cntend grandes quantidades de cmputadres. Assim, cada aplicativ d Windws Azure é executad em várias máquinas simultaneamente. A Figura 4 mstra um exempl simples de cm iss parece. Figura 4: O Cntrle da malha d Windws Azure cria instâncias de funções de um aplicativ em diferentes máquinas e, em seguida, mnitra sua execuçã. 8

Cm ilustrad na Figura 4, tds s cmputadres de um data center específic d Windws Azure sã gerenciads pr um aplicativ chamad cntrle da malha. O cntrle da malha é um aplicativ distribuíd e funcina em váris cmputadres. Quand um desenvlvedr clca um aplicativ para ser executad n Windws Azure, ele frnece códig para funções d aplicativ, juntamente cm a definiçã de serviç e s arquivs de cnfiguraçã d serviç para este aplicativ. Entre utras cisas, essa infrmaçã rienta cntrle da malha sbre quantas instâncias de cada funçã devem ser criadas. O cntrle da malha esclhe uma máquina física para cada instância, em seguida, cria uma VM nessa máquina e cmeça a execuçã da instância. Cm a figura sugere, as instâncias de funçã para um únic aplicativ sã distribuídas pr diferentes máquinas dentr deste data center. Depis de criar essas instâncias, cntrle da malha cntinua a mnitrá-las. Se uma instância falhar pr algum mtiv hardware u sftware cntrle da malha iniciará uma nva instância para essa funçã. Apesar das falhas pderem causar a queda temprária da cntagem da instância de um aplicativ para um valr abaix d que desenvlvedr slicitu, cntrle da malha cmeçará sempre nvas instâncias cnfrme a necessidade para manter a meta de númers de cada uma das funções d aplicativ. E mesm que a Figura 4 mstre apenas Web Rles e Wrker Rles, as funções de VM sã tratadas da mesma maneira, cm cada uma das instâncias de funçã send executadas em uma máquina física diferente. BENEFÍCIOS: MELHOR ADMINISTRAÇÃO, DISPONIBILIDADE E ESCALABILIDADE Os aplicativs criads usand mdel de prgramaçã d Windws Azure pdem ser mais fáceis de administrar, mais dispníveis e mais escalnáveis que aqueles criads em servidres Windws tradicinais. Vale a pena lhar para esses três atributs separadamente. Benefícis administrativs d alt flux d Windws Azure n cntrle da malha. Cm td sistema peracinal, Windws deve ser crrigid, assim cm utrs sistemas de sftware. Em ambientes lcais, fazer iss geralmente requer algum esfrç human. N Windws Azure, entretant, prcess é ttalmente autmatizad: O cntrle da malha faz as atualizações para as instâncias de Web Rle e Wrker Rles (embra nã para as instâncias de funçã de VM). Quand necessári, ele também atualiza s servidres Windws subjacentes em que as VMs estã rdand. O resultad é a reduçã de custs, uma vez que nã sã necessáris administradres para essa funçã. Reduzir custs exigind mens administraçã é bm. Ajudar s aplicativs a estarem mais acessíveis também é bm, e pr iss mdel de prgramaçã d Windws Azure ajuda a melhrar a dispnibilidade ds aplicativs de várias maneiras. Aqui estã elas: Prteçã cntra falhas de hardware. Cm cada aplicativ é cmpst de múltiplas instâncias de cada funçã, falhas de hardware pane de disc, falha na rede, u a mrte de um servidr da máquina nã derrubarã aplicativ. Para ajudar cm iss, cntrle da malha nã esclhe máquinas para as instâncias de um aplicativ de frma aleatória. Em vez diss, diferentes instâncias da mesma funçã sã clcadas em diferentes dmínis cm falhas. Um dmíni cm falhas é um cnjunt de hardware cmputadres, switches, e mais que cmpartilham um únic pnt de falha. (Pr exempl, tds s cmputadres em um únic dmíni cm falhas pdem depender d mesm switch para se cnectarem à rede.) Pr iss, uma única falha n hardware nã é capaz de derrubar um aplicativ inteir. O aplicativ pde perder temprariamente algumas instâncias, mas cntinuará a se cmprtar crretamente. 9

Prteçã cntra falhas de sftware. Além dessas falhas de hardware, cntrle da malha também pde detectar falhas causadas pel sftware. Se códig em uma instância trava u a VM na qual ele está send executad sfre uma pane, cntrle da malha iniciará apenas códig u, se necessári, uma nva VM para aquela funçã. A mesm temp em que qualquer trabalh que a instância desenvlvia n mment da falha será perdid, a nva instância se trnará parte d aplicativ assim que ele cmeçar a ser executad. Capacidade de atualizar aplicativs sem que eles tenham um períd de inatividade. Seja para manutençã de rtina u para instalar uma versã cmpletamente nva, tds s aplicativs precisam ser atualizads. Um aplicativ criad utilizand mdel de prgramaçã d Windws Azure pde ser atualizad enquant está send executad nã é necessári desligá-l. Para que iss seja pssível, diferentes instâncias para cada uma das funções d aplicativ sã clcadas em diferentes dmínis de atualizaçã, (que nã sã s mesms que s dmínis cm falhas descrits anterirmente). Quand uma nva versã d aplicativ precisa ser implantada, cntrle da malha pde desligar as instâncias em apenas um dmíni de atualizaçã, atualizar códig para eles, e criar nvas instâncias a partir daquele nv códig. Uma vez que aquelas instâncias estã send executadas, ele pde fazer mesm cm instâncias d próxim dmíni de atualizaçã, e assim pr diante. Enquant s usuáris pdem visualizar diferentes versões d aplicativ durante esse prcess, dependend de cm qual instância eles interagem, aplicativ cm um td permanece cntinuamente dispnível. Capacidade de atualizar Windws e utrs sftwares de api sem que aplicativ tenha um períd de inatividade. O cntrle da malha cnsidera que td aplicativ d Windws Azure segue as três regras listadas anterirmente, e pr iss, sabe que ele pde desligar algumas das instâncias d aplicativ quand quiser, atualizar sistema de sftware subjacente, e iniciar nvas instâncias. A fazer iss pr partes, nunca desligand tdas as instâncias de uma funçã a mesm temp, Windws e utr sftware pdem ser atualizads enquant um aplicativ é executad cntinuamente. Dispnibilidade é imprtante para a mairia ds aplicativs sftware nã é útil se nã funcinar quand vcê precisa mas escalabilidade também imprta. O mdel de prgramaçã d Windws Azure ajuda desenvlvedres a criar mais aplicativs escalnáveis de duas frmas diferentes: Criand e mantend um númer específic de instâncias de funçã autmaticamente. Cm descrit anterirmente, um desenvlvedr infrma Windws Azure quantas instâncias de cada funçã executar, e cntrle da malha cria e mnitra as instâncias slicitadas. Iss trna a escalabilidade de aplicativs bem simples: Apenas diga a Windws Azure que vcê precisa. Uma vez que platafrmas em nuvem executam data centers muit grandes, bter nível de escalabilidade que um aplicativ precisa nã é, nrmalmente, um prblema. Prprcinar uma frma de mdificar númer ativ de instâncias de funçã para um aplicativ em execuçã: Para aplicativs de carga variável a escalabilidade é mais cmplicada. Definir númer de instâncias apenas uma vez nã é uma ba sluçã, uma vez que diferentes cargas pdem fazer a cntagem ideal da instância aumentar u diminuir de frma significativa. Para reslver essa situaçã, Windws Azure frnece tant um prtal da Web para pessas, quant uma API para aplicativs para permitir alterar númer desejad de instâncias para cada funçã enquant um aplicativ está send executad. 10

Trnar aplicativs mais simples de administrar, mais dispníveis, e mais escalnáveis é útil, e pr iss, usar mdel de prgramaçã d Windws Azure geralmente faz sentid. Mas cm mencinad anterirmente, é pssível executar aplicativs n Windws Azure que nã seguem este mdel. Supnha, pr exempl, que vcê criu um aplicativ usand uma única funçã ( que é permitid), mas executand apenas uma instância daquela funçã (viland a segunda e a terceira regra). Vcê pde fazer iss para ecnmizar, uma vez que Windws Azure tarifa separadamente cada instância em execuçã. Qualquer pessa que esclha essa pçã deveria entender, entretant, que cntrle da malha nã saberá que seu aplicativ nã segue as três regras. Ele desligará essa instância em mments imprevisíveis para crrigir sftware subjacente, e em seguida, reiniciar um nv. Para s usuáris, iss significa que aplicativ desligará peridicamente, uma vez que nã há utra instância para assumir cntrle. Iss nã é um err d Windws Azure; é um aspect fundamental de cm a tecnlgia funcina. Obter tds s benefícis que Windws Azure ferece requer cnfrmidade cm as regras de seu mdel de prgramaçã. Mver aplicativs existentes d Windws Server para Windws Azure pde dar um puc de trabalh, um tópic abrdad cm mais detalhes psterirmente neste dcument. Para aplicativs nvs, n entant, argument para utilizar mdel d Windws Azure é clar. Pr que nã criar um aplicativ que custe mens a administradr? Pr que nã criar um aplicativ que nunca precisa ficar inativ? Pr que nã criar um aplicativ que pde facilmente ser dimensinad cnfrme necessári? Cm temp, é razável esperar que mais e mais aplicativs sejam criads utilizand mdel de prgramaçã d Windws Azure. IMPLICAÇÕES DO MODELO DE PROGRAMAÇÃO DO WINDOWS AZURE: O QUE MAIS MUDA? Criar aplicativs para Windws Azure significa seguir as três regras de seu mdel de prgramaçã. Mas seguir essas três regras nã é suficiente utras partes d mund d desenvlvedr também devem ser ajustadas. As mudanças que mdel de prgramaçã d Windws Azure traz para ambiente de desenvlviment de frma mais abrangente pdem ser agrupadas em três áreas: De que frma instâncias de funçã interagem cm sistema peracinal. De que frma instâncias de funçã interagem cm armazenament persistente. De que frma instâncias de funçã interagem cm utras instâncias de funçã. Essa seçã abrda as três áreas. INTERAÇÕES COM O SISTEMA OPERACIONAL Para um aplicativ executad em uma máquina típica d Windws Server, administradr da máquina está n cntrle. Ela pde reiniciar VMs u a máquina em que eles sã executads, instalar patches d Windws, e fazer que mais fr necessári para manter cmputadr dispnível. N Windws Azure, n entant, tds s servidres sã de prpriedade d cntrle da malha. Ele decide quand as VMs u máquinas devem ser reiniciadas, e para Web Rles e Wrker Rles (embra nã para funções da VM), cntrle da malha também instala patches e utras atualizações n sftware d sistema em tdas as instâncias. 11

Cnfrme descrit anterirmente, essa abrdagem tem benefícis reais. N entant, ela também cria restrições. Cm cntrladr da malha pssui máquinas físicas e virtuais utilizadas pels aplicativs d Windws Azure, ele é livre para fazer que quiser cm elas. Iss significa deixar um aplicativ d Windws Azure mdificar sistema em que é executad deixá-l rdar em md de administradr, em vez de md de usuári apresenta alguns desafis. Uma vez que cntrle da malha pde mdificar sistema peracinal à vntade, nã há garantias de que mudar uma instância de funçã nã fará cm que sistema em que ele está send executad seja substituíd. Além diss, as máquinas virtuais (e físicas) específicas em que aplicativ é executad mudam cm temp. Iss significa que qualquer mudança n ambiente de desenvlviment padrã deve ser feita cada vez que uma instância de funçã cmeça a ser executada. Em seu primeir lançament, Windws Azure simplesmente nã permitia que s aplicativs mdificassem s sistemas em que funcinavam s aplicativs só rdavam n md de usuári. Esta restriçã fi reduzida agra tant Web Rles quant Wrker Rles dã as desenvlvedres a pçã de executar aplicativs n md de administradr mas, em geral, mdel de prgramaçã nã mudu. Qualquer pessa que crie um aplicativ d Windws Azure precisa entender que cntrle da malha está fazend, e desenvlver s aplicativs de acrd. INTERAÇÕES COM O ARMAZENAMENTO PERSISTENTE Aplicativs nã sã apenas códigs eles também usam dads. E assim cm mdel de prgramaçã deve mudar para trnar s aplicativs mais dispníveis e mais escalnáveis, a frma cm s dads sã armazenads e acessads também deve mudar. As grandes mudanças sã: O armazenament deve ser extern a instâncias de funçã. Mesm que cada instância seja sua própria VM cm seu própri sistema de arquivs, dads armazenads nesses sistemas de arquiv nã se trnam permanentes autmaticamente. Se uma instância falhar, qualquer dad que ela cntenha pde ser perdid. Iss significa que para que s aplicativs funcinem crretamente em cass de falhas, s dads devem ser armazenads de frma permanente fra das instâncias de funçã. Outra instância de funçã pde agra acessar dads que teriam sid perdids cas aqueles dads tivessem sid armazenads lcalmente em uma instância cm defeit. O armazenament deve ser duplicad. Assim cm um aplicativ d Windws Azure executa múltiplas instâncias de funçã cnsiderand falhas, armazenament d Windws Azure deve fazer múltiplas cópias de dads. Sem iss, uma única falha trnaria s dads indispníveis, alg que nã é aceitável para aplicativs altamente dispníveis. O armazenament deve ser capaz de lidar cm quantidades muit grandes de dads. Sistemas relacinais tradicinais nã sã necessariamente a melhr pçã para cnjunts muit grandes de dads. Uma vez que Windws Azure fi criad em parte para aplicativs escalnáveis em massa, ele deve frnecer mecanisms de armazenament capazes de trabalhar cm dads nessa escala. Para trnar iss pssível, a platafrma ferece blbs para armazenar dads bináris cm uma abrdagem diferente da SQL chamada tabelas para armazenament de grandes cnjunts de dads estruturads. A figura 5 ilustra essas três características, mstrand cm armazenament d Windws Azure funcina para um aplicativ. 12

Figura 5: Enquant aplicativs veem uma única cópia, armazenament d Windws Azure replica tds s blbs e tabelas três vezes. Nesse exempl, um aplicativ d Windws Azure está usand dis blbs e uma tabela d armazenament d Windws Azure. O aplicativ vê cada blb e tabela cm uma única entidade, mas na verdade armazenament d Windws Azure mantém três instâncias de cada uma. Essas cópias estã distribuídas em diferentes máquinas físicas, e assim cm instâncias de funçã, essas máquinas estã em diferentes dmínis cm falhas. Iss melhra a dispnibilidade d aplicativ, uma vez que s dads ainda sã acessíveis mesm quand algumas cópias nã estã dispníveis. E devid as dads permanentes estarem armazenads fra de qualquer uma das instâncias de funçã d aplicativ, uma falha da instância perde smente s dads que estavam send utilizads n mment da falha. O mdel de prgramaçã d Windws Azure requer que aplicativ se cmprte crretamente quand uma instância de funçã falha. Para fazer iss, cada instância de um aplicativ deve armazenar tds s dads permanentes n armazenament d Windws Azure u utr mecanism de armazenament intern (tal cm SQL Azure, serviç em nuvem da Micrsft para dads relacinais). Existe, n entant, utra pçã que vale a pena mencinar: as unidades d Windws Azure. Cm descrit anterirmente, qualquer dad que um aplicativ escreva n sistema lcal de arquivs de sua própria VM pde ser perdid quand aquela VM para de funcinar. As unidades d Windws Azure alteram iss utilizand um blb para frnecer armazenament permanente para sistema de arquivs de uma instância em particular. Essas unidades têm algumas limitações apenas uma instância de cada vez pde ler de, e escrever para uma unidade específica d Windws Azure, pr exempl, send que tdas as utras instâncias nesse aplicativ têm permissã de acess apenas para leitura mas elas pdem ser úteis em algumas situações. 13

INTERAÇÕES NAS INSTÂNCIAS DE FUNÇÃO Quand um aplicativ é dividid em várias partes, essas partes nrmalmente devem interagir umas cm as utras. Em um aplicativ d Windws Azure iss é expressad cm cmunicaçã entre instâncias de funçã. Pr exempl, uma instância de Web Rle pde aceitar slicitações de usuáris, e transmiti-las para uma instância de Wrker Rle para prcessament. A frma cm essa interaçã acntece nã é idêntica à frma cm é feita cm aplicativs cmuns d Windws. Mais uma vez, um fatr-chave que deve ser lembrad é que, cm mais frequência, tdas as instâncias de uma funçã específica sã equivalentes elas sã intercambiáveis. Iss significa que quand, digams, uma instância de Web Rle transfere trabalh para uma instância de Wrker Rle, nã imprta que instância em particular recebe trabalh. Na verdade, a instância de Web Rle nã deveria depender de elements específics da instância, tais cm um endereç IP da instância de funçã de Funcinári, para se cmunicar cm aquela instância. Sã necessáris mais mecanisms genérics. A frma mais cmum das instâncias de funçã se cmunicarem ns aplicativs d Windws Azure é pr mei de enfileiraments d Windws Azure. A Figura 6 ilustra a ideia. Figura 6: Instâncias de Funçã pdem se cmunicar pr mei de enfileiraments, cada uma replica as mensagens que cntém três vezes. N exempl aqui mstrad, uma instância de Web Rle btém trabalh de um usuári d aplicativ, tal cm uma pessa fazend uma slicitaçã a partir de um navegadr (etapa 1). Essa instância cria uma mensagem cntend este trabalh e escreve em um enfileirament d Windws Azure (etapa 2). Esses enfileiraments sã implementads cm parte d armazenament d Windws Azure, e cm blbs e tabelas, cada enfileirament é replicad três vezes, cm mstra a figura. Cm usual, iss prprcina tlerância a falhas, garantind que as mensagens enfileiradas ainda estejam dispníveis se crrer uma falha. 14

A seguir, uma instância de funçã de Funcinári lê a mensagem a partir d enfileirament (etapa 3). Observe que a instância de Wrker Rle que criu esta mensagem nã se imprta cm qual instância de Wrker Rle faz iss nesse aplicativ tdas sã equivalentes. A instância de Wrker Rle faz qualquer trabalh que a mensagem slicite (etapa 4), e apaga a mensagem d enfileirament (etapa 5). Essa última etapa remçã explícita da mensagem da fila é diferente d que tecnlgias de enfileirament lcais fazem nrmalmente. N Micrsft Message Queuing (MSMQ), pr exempl, um aplicativ é capaz de fazer uma leitura durante uma transaçã atômica. Se aplicativ falhar antes de cmpletar seu trabalh, a transaçã é anulada, e a mensagem aparece autmaticamente na fila. Essa abrdagem garante que tda mensagem enviada para uma fila MSMQ é entregue exatamente uma vez na rdem em que fi enviada. As filas d Windws Azure nã suprtam leituras transacinais, e pr iss nã garantem exatamente priridade na rdem de entrega. N exempl mstrad na Figura 6, pr exempl, a instância de Wrker Rle pde encerrar prcessament da mensagem e sfrer uma pane antes de apagá-la da fila. Se iss acntecer, a mensagem reaparecerá autmaticamente após um temp limite cnfigurável, e utra instância de Wrker Rle vai prcessá-la. A cntrári d MSMQ, as filas d Windws Azure têm, pel mens, uma semântica: Uma mensagem pde ser lida e prcessada uma u mais vezes. Iss gera uma questã óbvia: Pr que as filas d Windws Azure nã suprtam leituras transacinais? A respsta é que transações requerem blquei, e pr iss, elas necessariamente trnam as cisas mais lentas (especialmente cm a duplicaçã de mensagens feita pelas filas d Windws Azure). Dads s bjetivs primáris da platafrma, seus desenvlvedres ptaram pela abrdagem mais rápida e mais escalnável. Na mair parte d temp, enfileiraments sã a melhr frma de instâncias de funçã se cmunicarem dentr de um aplicativ. N entant, também é pssível que instâncias interajam diretamente, sem passar pel enfileirament. Para permitir iss, Windws Azure frnece uma API que permite que uma instância descubra tdas as utras instâncias n mesm aplicativ que atendem requisits específics, e em seguida, envia uma slicitaçã diretamente para uma delas. Ns cass mais cmuns, em que tdas as instâncias de uma funçã particular sã equivalentes, chamadr deveria esclher uma instância alv aleatriamente a partir desse cnjunt de retrns da API. Iss nã é sempre verdade talvez uma funçã de Funcinári implemente um cache na memória cm cada instância de funçã prcessand dads específics, e chamadr deve acessar um em particular. Cm mais frequência, n entant, a abrdagem crreta é tratar tdas as instâncias de uma funçã cm intercambiáveis. COMO MOVER APLICATIVOS DO WINDOWS SERVER PARA O WINDOWS AZURE Qualquer pessa a criar um nv aplicativ d Windws Azure deveria seguir as regras d mdel de prgramaçã d Windws Azure. Para mver um aplicativ existente d Windws Server para Windws Azure, n entant, esse aplicativ também deve ser feit para seguir as mesmas regras. Além diss, pde ser necessária a mdificaçã de cm aplicativ interage cm sistema peracinal, cm ele utiliza armazenament persistente, e da frma cm seus cmpnentes interagem uns cm s utrs. O quã fácil é fazer essas mudanças depende d aplicativ. Aqui estã alguns exempls representativs: Um aplicativ ASP.NET cm várias instâncias de balanceament de carga que cmpartilha estad armazenad n SQL Server. Este tip de aplicativ nrmalmente migra facilmente para Windws Azure, cm cada instância d aplicativ riginal se trnand uma instância de Web Rle u Wrker 15

Rle. Aplicativs cm este nã utilizam sessões agrupadas, que s ajuda a serem adequads para Windws Azure. (Usar estad da sessã ASP.NET é aceitável, prém, desde que Windws Azure frneça uma pçã para armazenar estad de sessã de frma permanente em tabelas de Armazenament d Windws Azure.) E mver um banc de dads SQL Server lcal para SQL Azure, nrmalmente, é simples. Um aplicativ ASP.NET cm várias instâncias que mantêm estad pr instância e dependem de seções agrupadas. Devid à manutençã d estad d cliente específic em cada instância entre as slicitações, aplicativ precisará de algumas mudanças. O Windws Azure nã suprta seções agrupadas, entã para fazer aplicativ rdar nessa platafrma em nuvem, será necessári prjetar nvamente a frma cm ele cntrla estad. Um cliente Silverlight u d Windws Presentatin Fundatin (WPF) que acessa serviçs WCF rdand em uma camada intermediária. Se s serviçs nã mantêm estad pr cliente entre as chamadas, transferi-ls para Windws Azure será simples. Cm sempre, cliente cntinuará a executar na área de trabalh d usuári, mas agra irá chamar s serviçs em execuçã n Windws Azure. Se, n entant, s serviçs atuais mantiverem estad pr cliente, eles precisarã ser prjetads nvamente. Um aplicativ cm uma única instância em execuçã n Windws Server que mantém estad sbre a sua própria máquina. Se s clientes frem navegadres u qualquer utra cisa, e atualmente váris aplicativs crprativs sã cnstruíds desta frma, e eles nã funcinarem bem n Windws Azure sem nenhuma refrmulaçã. Talvez seja pssível rdar esse aplicativ nã mdificad em uma única instância de funçã de VM, mas seus usuáris prvavelmente nã ficarã felizes cm s resultads. Pr um lad Windws Azure SLA nã se aplica as aplicativs cm apenas uma instância. Além diss, lembre-se que cntrle da malha pde, a qualquer mment, reiniciar a máquina em que essa instância está send executada para atualizar sftware da mesma. O aplicativ nã tem cntrle sbre quand iss acntece. Pde acntecer bem n mei da jrnada de trabalh. Cm nã há segunda instância para assumir aplicativ nã fi criad para seguir as regras d mdel de prgramaçã d Windws Azure ele ficará indispnível pr um cert períd de temp, e assim qualquer um que estiver usand aplicativ terá seu trabalh interrmpid enquant a máquina é reiniciada. Embra a funçã de VM trne mais fácil mver um binári d Windws Server para Windws Azure, iss nã garante que aplicativ será executad cm sucess em seu nv ambiente. O aplicativ também deve bedecer às regras d mdel de prgramaçã d Windws Azure. Um aplicativ Visual Basic 6 que acessa diretamente um banc de dads d SQL Server, pr exempl, um aplicativ tradicinal cliente/servidr. Para fazer este aplicativ rdar n Windws Azure, prvavelmente será necessári reescrever pel mens a lógica cmercial d cliente. Embra pssa ser pssível mver banc de dads (incluind tds s prcediments armazenads) para SQL Azure, e redirecinar s clientes para este nv lcal, s cmpnentes d aplicativ da área de trabalh nã serã executads cm se estivessem n Windws Azure. O Windws Azure nã frnece uma interface de usuári lcal, e também nã ferece suprte usand Serviçs de Área de Trabalh Remta (antig Serviç de Terminal) para frnecer interfaces cm usuári remt. O Windws Azure pde ajudar s desenvlvedres a criar aplicativs melhres. Para bter tais melhrias sã necessárias algumas mudanças, e migrar um sftware existente para esta nva platafrma pde gerar 16

algum esfrç. Tmar bas decisões exige cmpreensã tant d valr ptencial cmercial quant ds desafis técnics que a migraçã de um aplicativ para Windws Azure pde trazer. CONCLUSÃO As platafrmas em nuvem sã um mund nv, e abrem nvas pssibilidades. Refletind iss, mdel de prgramaçã d Windws Azure ajuda s desenvlvedres a criar aplicativs mais fáceis de administrar, mais dispníveis e mais escalnáveis d que aqueles criads n ambiente tradicinal d Windws Server. A fazer iss é necessári seguir três regras: Um aplicativ d Windws Azure é criad a partir de uma u mais funções. Um aplicativ d Windws Azure rda várias instâncias de cada funçã. Um aplicativ d Windws Azure se cmprta crretamente quand qualquer instância de funçã falha. Usar esse mdel de prgramaçã cm sucess também requer a cmpreensã das mudanças que ele traz à frma cm s aplicativs interagem cm sistema peracinal, cm usam armazenament persistente, e cm se cmunicam entre instâncias de funçã. Para desenvlvedres dispsts a fazer iss, n entant, valr é clar. Embra nã seja adequad para tds s cenáris, mdel de prgramaçã d Windws Azure pde ser útil para quem quer criar aplicativs mais fáceis de administrar, mais dispníveis e mais escalnáveis. PARA LEITURA ADICIONAL Intrduzind Windws Azure: http://g.micrsft.cm/?linkid=9682907 Intrduzind a platafrma Windws Azure: http://g.micrsft.cm/fwlink/?linkid=158011 SOBRE O AUTOR David Chappell é Diretr da Chappell & Assciates (www.davidchappell.cm) em Sã Francisc, Califórnia. Cm sua fala, escrita, e cnsultria, ele ajuda pessas de td mund a entender, usar e tmar melhres decisões sbre as nvas tecnlgias. 17