HET WINDOWS AZUREPROGRAMMEERMODEL DAVID CHAPPELL OKTOBER 2010
GESPONSORD DOOR MICROSOFT CORPORATION
INHOUD Waarom is er een nieuw programmeermodel ontwikkeld? ................................................................. 3 De drie regels van het Windows Azure-programmeermodel ................................................................ 3 Een Windows Azure-applicatie is samengeteld uit een of meer rollen ................................................... 4 Een Windows Azure-applicatie voert meerdere instances van elke rol uit ............................................. 5 Een Windows Azure-applicatie blijft correct functioneren wanneer een role instance uitvalt .............. 6 Wat biedt het Windows Azure-programmeermodel ............................................................................ 7 Wat achtergrondinformatie: de fabric-controller ................................................................................... 7 De voordelen: beter beheer, betere beschikbaarheid en betere schaalbaarheid .................................. 8 De implicaties van het Windows Azure-programmeermodel: wat verandert er verder nog? .............. 10 Interacties met het besturingssysteem ................................................................................................. 11 Interacties met permanente opslag ...................................................................................................... 11 Interacties tussen role instances ........................................................................................................... 13 Windows Server-applicaties verplaatsen naar Windows Azure .......................................................... 14 Conclusie .......................................................................................................................................... 16 Meer informatie ............................................................................................................................... 16 De auteur ......................................................................................................................................... 16
2
WAAROM IS ER EEN NIEUW PROGRAMMEERMODEL ONTWIKKELD? Miljoenen ontwikkelaars over de hele wereld weten hoe ze applicaties kunnen bouwen met het Windows Server-programmeermodel. En toch maken applicaties die zijn geschreven voor Windows Azure, het cloud-platform van Microsoft, niet volledig gebruik van dit bekende model. Er wordt nog steeds een beroep gedaan op de meeste vaardigheden van een Windows-ontwikkelaar, maar Windows Azure heeft een eigen programmeermodel. Hoe komt dat? Waarom wordt de bekende omgeving van Windows Server niet gewoon gekopieerd naar de cloud? Bij de cloud-platforms van een groot aantal leveranciers is dit inderdaad het geval en worden er virtuele machines (VM's) geboden die qua werking veel lijken op VM's in het eigen datacenter. Deze benadering, ook wel Infrastructure as a Service (IaaS) genoemd, heeft zeker waarde en is voor bepaalde applicaties ook de juiste benadering. Cloud-platforms vormen echter een nieuwe wereld, met nieuwe mogelijkheden waarmee moderne problemen op nieuwe manieren kunnen worden opgelost. Windows Azure biedt geen IaaS, maar een hogere mate van abstractie die Platform as a Service (PaaS) wordt genoemd. Deze abstractie lijkt in veel opzichten op de Windows-omgeving in het eigen datacenter, maar heeft een eigen programmeermodel waarmee ontwikkelaars betere applicaties kunnen bouwen. Het Windows Azure-programmeermodel is gericht op de verbetering van applicaties op drie gebieden: Beheer: bij PaaS-technologie voert het platform zelf de meeste beheertaken uit. Bij Windows Azure betekent dit dat het platform taken als het toepassen van Windows-patches en het installeren van nieuwe versies van systeemsoftware, automatisch uitvoert. Het doel hiervan is de inspanningen (en de kosten) voor het beheer van de applicatieomgeving te verminderen. Beschikbaarheid: bij conventionele applicaties doet zich geplande of niet-geplande downtime voor bij de installatie van Windows-patches en applicatie-upgrades, bij hardwarestoringen en in andere gevallen. Maar bij de redundantie die met cloud-platforms mogelijk is, is er echter geen enkele reden meer om hiermee genoegen te nemen. Het Windows Azure-programmeermodel is ontwikkeld met het oog op de voortdurende beschikbaarheid van applicaties, ook wanneer er software-upgrades worden uitgevoerd of hardwarestoringen optreden. Schaalbaarheid: cloud-applicaties zijn vaak bestemd voor grote aantallen gebruikers. Het traditionele Windows Server-programmeermodel is echter niet specifiek ontwikkeld om applicaties op internetschaal te kunnen ondersteunen. Het Windows Azure-programmeermodel is hier echter vanaf de ontwerpfase wel op afgestemd. Het is ontwikkeld voor het cloud-platform en biedt ontwikkelaars de mogelijkheid schaalbare applicaties te bouwen die enorme datacenters in de cloud kunnen ondersteunen. En met Windows Azure kunnen applicaties desgewenst ook worden ingeperkt, zodat alleen de resources die nodig zijn worden gebruikt. Of een ontwikkelaar nu gebruikmaakt van een IaaS-technologie of van een PaaS-product zoals Windows Azure, het maken van applicaties op een cloud-platform biedt een aantal inherente voordelen. Bij beide benaderingen betaalt u bijvoorbeeld alleen voor de computerresources die u gebruikt en hoeft u niet te wachten totdat uw IT-afdeling servers implementeert. Hoe belangrijk deze voordelen ook zijn, ze zijn niet het hoofdonderwerp van deze tekst. In deze tekst richten we ons namelijk volledig op de eigenschappen en voordelen van het Windows Azure-programmeermodel.
DE DRIE REGELS VAN HET WINDOWS AZURE-PROGRAMMEERMODEL Bij het realiseren van de beloofde voordelen legt het Windows Azure-programmeermodel drie regels op aan applicaties: Een Windows Azure-applicatie is samengesteld uit een of meer rollen.
3
Een Windows Azure-applicatie voert meerdere instances van elke rol uit. Een Windows Azure-applicatie blijft correct functioneren wanneer een role instance uitvalt. Het is belangrijk erop te wijzen dat Windows Azure ook applicaties kan uitvoeren die niet aan al deze regels voldoen, en dat deze regels niet worden afgedwongen. Het platform gaat er gewoon van uit dat elke applicatie aan deze drie regels voldoet. Wanneer u echter een applicatie onder Windows Azure uitvoert die niet aan een of meer van deze regels voldoet, moet u er rekening mee houden dat die applicatie niet het Windows Azure-programmeermodel volgt. Tenzij u de regels van het model begrijpt en volgt, wordt de applicatie wellicht niet naar verwachting uitgevoerd.
EEN WINDOWS AZURE-APPLICATIE IS SAMENGETELD UIT EEN OF MEER ROLLEN Of een applicatie nu in de cloud of in uw eigen datacenter wordt uitgevoerd, de applicatie kan bijna altijd worden verdeeld in logische eenheden. Windows Azure formaliseert deze eenheden in rolllen. Een rol bevat een specifieke codeset, zoals een .NET-assembly, en definieert de omgeving waarin die code wordt uitgevoegd. Met Windows Azure kunnen ontwikkelaars nu drie verschillende soorten rollen maken: Web role: zoals de naam het al zegt, zijn web roles vooral bestemd voor logica die met de buitenwereld communiceert via HTTP. Code die is geschreven als een web role, ontvangt doorgaans invoer via Internet Information Services (IIS) en kan worden gemaakt met verschillende technologieën, zoals ASP.NET, Windows Communication Foundation (WCF), PHP en Java. Worker role: logica die wordt geschreven als een worker role kan op verschillende manieren communiceren met de buitenwereld, en niet uitsluitend via HTTP. Zo kan een worker role code bevatten waarmee video's worden omgezet in een standaardindeling, het risico van een beleggingsportefeuille wordt berekend of een bepaald type gegevensanalyse wordt uitgevoerd. VM role (Virtual Machine): een VM role voert een image, een virtuele harde schijf (VHD), van een virtuele machine met Windows Server 2008 R2 uit. Deze VHD wordt met een Windows Servermachine in het eigen datacenter gemaakt en vervolgens geüpload naar Windows Azure. Wanneer de VHD in de cloud is opgeslagen, kan deze op aanvraag in een VM role worden geladen en uitgevoerd. Alle drie de rollen zijn nuttig. De VM role is echter pas onlangs beschikbaar gesteld, dus op dit moment worden web roles en worker roles het meest gebruikt. In figuur 1 wordt een eenvoudige Windows Azureapplicatie weergegeven, die bestaat uit één web role en één worker role.
Figuur 1: een Windows Azure-applicatie bestaat uit een of meer rollen, bijvoorbeeld de combinatie van een web role en een worker role, zoals hier wordt weergegeven. Deze applicatie kan een web role gebruiken om HTTP-aanvragen van gebruikers te accepteren en vervolgens de aangevraagde handelingen, zoals het aanpassen van de indeling van een videobestand en
4
het beschikbaar stellen van de video voor weergave, aan een worker role over te dragen. Een belangrijke reden voor deze splitsing is dat een dergelijke verdeling van taken ertoe leidt dat een applicatie beter schaalbaar is. Maar een Windows Azure-applicatie kan ook gewoon uit één web role of één worker role bestaan, u hoeft niet beide rollen te gebruiken. Een enkele applicatie kan zelfs verschillende soorten web roles en worker roles bevatten. Zo kan een applicatie één web role bevatten voor de implementatie van een browserinterface (die misschien met ASP.NET is gemaakt) en een andere web role waarmee een interface voor webservices wordt geboden (die is gemaakt met WCF). En een Windows Azure-applicatie die twee verschillende soorten gegevensanalyse uitvoert, kan bijvoorbeeld een aparte worker role voor elk soort analyse gebruiken. Maar om de zaken eenvoudig houden, gaan we ervan uit dat de applicatie in dit voorbeeld slechts één web role en één worker role bevat. Tijdens het bouwen van een Windows Azure-applicatie maakt een ontwikkelaar een servicedefinitiebestand waarin de rollen in de applicatie worden benoemd en beschreven. Dit bestand kan ook andere informatie bevatten, zoals de poorten waarop elke rol kan luisteren. Windows Azure gebruikt deze informatie om de juiste omgeving voor het uitvoeren van de applicatie samen te stellen.
EEN WINDOWS AZURE-APPLICATIE VOERT MEERDERE INSTANCES VAN ELKE ROL UIT Elke Windows Azure-applicatie bestaat uit een of meer rollen. Bij een applicatie die voldoet aan het Windows Azure-programmeermodel moeten minstens twee exemplaren (twee aparte instances) van elke rol in de applicatie worden uitgevoerd. Elke role instance wordt als een eigen VM uitgevoerd, zoals getoond in afbeelding 2.
Figuur 2: een Windows Azure-applicatie voert meerdere role instances uit. Zoals eerder is beschreven, bevat de voorbeeldapplicatie één web role en één worker role. Een ontwikkelaar kan via een serviceconfiguratiebestand aan Windows Azure doorgeven hoeveel instances van elke rol moeten worden uitgevoerd. (Een serviceconfiguratiebestand is niet hetzelfde als het eerder
5
genoemde servicedefinitiebestand.) In dit voorbeeld heeft de ontwikkelaar vier instances van de web role en drie instances van de worker role aangevraagd. In elke instance van een specifieke rol wordt precies dezelfde code uitgevoerd. Bij de meeste Windows Azure-applicaties is elke instance identiek aan alle andere instances van die rol; dit betekent dat ze uitwisselbaar zijn. Windows Azure verdeelt bijvoorbeeld automatisch HTTP-aanvragen over de web role instances van een applicatie. Deze load balancing biedt geen ondersteuning voor sticky sessies, dus het is niet mogelijk om alle aanvragen van een client naar dezelfde web role instance te sturen. Er kan geen clientspecifieke status, zoals een winkelwagen, in een specifieke web role instance worden opgeslagen, omdat Windows Azure niet kan garanderen dat alle aanvragen van een client door die instance worden verwerkt. Dit type status moet dan ook extern worden opgeslagen, zoals later wordt beschreven.
EEN WINDOWS AZURE-APPLICATIE BLIJFT CORRECT FUNCTIONEREN WANNEER EEN ROLE INSTANCE UITVALT Een applicatie die het Windows Azure-programmeermodel volgt, moet zijn samengesteld uit rollen, en de applicatie moet twee of meer instances van elke rol uitvoeren. De applicatie moet bovendien correct functioneren wanneer een van die role instances uitvalt. Dit idee wordt geïllustreerd in figuur 3.
Figuur 3: een Windows Azure-applicatie functioneert correct wanneer een role instance uitvalt. In de applicatie in figuur 2 zijn twee web role instances en één worker role instance uitgevallen. Mogelijk zijn de computers waarop ze werden uitgevoerd uitgevallen of wellicht is de fysieke netwerkverbinding met deze computers verbroken. Wat de reden ook is, de kans is groot dat de prestaties van de applicatie zullen afnemen, omdat er minder instances zijn om de taken van de applicatie uit te voeren. Maar de applicatie blijft actief en functioneert naar behoren.
6
Als alle instances van een bepaalde rol uitvallen, werkt een applicatie niet meer naar behoren; dit is onvermijdelijk. Maar de noodzaak om correct te functioneren bij gedeeltelijke uitval, is echter cruciaal voor het Windows Azure-programmeermodel. In de service level agreement (SLA) voor Windows Azure wordt zelfs vereist dat er minimaal twee instances van elke rol worden uitgevoerd. Voor applicaties die slechts één instance van een rol uitvoeren, kunnen de garanties in deze SLA niet worden geboden. Dit kan het beste worden bereikt door elke role instance equivalent te maken, net zoals bij web roles met load balancing die gebruikersaanvragen accepteren. Dit is echter geen strikte vereiste, zolang het uitvallen van één role instance de applicatie niet ontregelt. Een applicatie kan bijvoorbeeld een groep worker role instances gebruiken om gegevens voor web role instances in de cache op te slaan, waarbij elk worker role instance andere gegevens bevat. Wanneer een worker role instance uitvalt, functioneert een web role instance die probeert toegang te krijgen tot de opgeslagen gegevens in de cache op dezelfde manier als wanneer de gegevens niet in de cache konden worden gevonden (d.w.z. de instance gebruikt dan permanente opslag om die gegevens te zoeken). Het uitvallen kan ertoe leiden dat de applicatie langzamer wordt uitgevoerd, maar in de ogen van de gebruiker functioneert de applicatie correct. Bedenk verder dat de beschreven voorbeeldapplicatie alleen web roles en worker roles bevat, maar dat deze regels ook van toepassing zijn op applicaties die gebruikmaken van VM roles. Net als de andere rollen moeten van elke VM role minimaal twee instances worden uitgevoerd om te voldoen aan de vereisten in de SLA voor Windows Azure, en de applicatie moet correct blijven functioneren als een van deze instances uitvalt. Ook bij VM roles biedt Windows Azure nog steeds een vorm van PaaS, en is er geen sprake van een traditionele IaaS.
WAT BIEDT HET WINDOWS AZURE-PROGRAMMEERMODEL Het Windows Azure-programmeermodel is gebaseerd op Windows en voor deze nieuwe omgeving wordt gebruikgemaakt van de meeste vaardigheden van een Windows-ontwikkelaar. Maar het werkt toch iets anders dan het conventionele Windows Server-programmeermodel. Waarom is het belangrijk om Windows Azure te leren begrijpen? Hoe kan ik er betere applicaties mee maken? Voordat we deze vragen beantwoorden, is het een goed idee om wat nader in te gaan op de manier waarop Windows Azure werkt. Daarna is het gemakkelijk om te zien hoe het Windows Azure-programmeermodel u kan helpen betere software te ontwerpen.
WAT ACHTERGRONDINFORMATIE: DE FABRIC-CONTROLLER Windows Azure is ontwikkeld voor datacenters met een groot aantal computers. Elke Windows Azureapplicatie wordt dan ook op meerdere computers tegelijk uitgevoerd. In figuur 4 ziet u een eenvoudig voorbeeld hiervan.
7
Figuur 4: de fabric-controller van Windows Azure maakt instances van de rollen in een applicatie op verschillende computers, en houdt vervolgens toezicht op de uitvoering hiervan. In figuur 4 is te zien dat alle computers in een bepaald Windows Azure-datacenter worden beheerd door een applicatie die de fabric-controller wordt genoemd. De fabric-controller is een gedistribueerde applicatie die op meerdere computers wordt uitgevoerd. Wanneer een ontwikkelaar op Windows Azure een applicatie plaatst die moet worden uitgevoerd, levert hij of zij de code voor de rollen in de applicatie, en de servicedefinitie- en serviceconfiguratiebestanden voor de applicatie aan. Aan de hand van deze informatie kan de fabric-controller bijvoorbeeld bepalen hoeveel instances van elke rol moeten worden gemaakt. De fabric-controller kiest voor elke instance een fysieke computer, genereert daarop een VM, en start vervolgens de uitvoering van de instance. Zoals te zien is in de figuur, zijn de role instances voor een afzonderlijke applicatie verdeeld over verschillende computers in dit datacenter. Nadat de fabric-controller deze instances heeft gemaakt, blijft de controller toezicht houden op deze instances. Valt een instance om een bepaalde reden (hardware of software) uit, dan start de fabriccontroller een nieuwe instance van die rol. Hoewel uitval kan betekenen dat het aantal instances van een applicatie tijdelijk lager is dan het aantal dat door de ontwikkelaar is aangevraagd, zal de fabric-controller altijd nieuwe instances starten om het bedoelde aantal voor elke rol van de applicatie te handhaven. Hoewel in figuur 4 alleen web roles en worker roles worden weergegeven, worden VM roles op dezelfde manier behandeld, waarbij elke instance van de rol op een andere fysieke computer wordt uitgevoerd.
DE VOORDELEN: BETER BEHEER, BETERE BESCHIKBAARHEID EN BETERE SCHAALBAARHEID Applicaties die zijn gemaakt volgens het Windows Azure-programmeermodel kunnen eenvoudiger worden beheerd en hebben een grotere beschikbaarheid en schaalbaarheid dan applicaties op traditionele Windows-servers. Het is de moeite waard om nader in te gaan op deze drie kenmerken.
8
De voordelen van Windows Azure op het gebied van beheer vloeien vooral voort uit de fabric-controller. Net als bij elk ander besturingssysteem moeten ook op Windows patches worden geïnstalleerd. In het eigen datacenter betekent dit doorgaans dat medewerkers bepaalde handelingen moeten uitvoeren. In Windows Azure wordt het proces echter volledig automatisch uitgevoerd: de fabric-controller verwerkt updates voor web role instances en worker role instances (maar niet voor VM role instances). Waar nodig werkt de fabric-controller eveneens de onderliggende Windows-servers bij waarop die VM's worden uitgevoerd. Dit resulteert in lagere kosten, omdat er geen beheerders nodig zijn om deze taken uit te voeren. Lagere kosten door minder beheer is een goede zaak. Een grotere beschikbaarheid van applicaties is ook een goede zaak en dus zorgt het Windows Azure-programmeermodel ervoor dat de beschikbaarheid van applicaties op verschillende manieren wordt verbeterd: Bescherming tegen hardwarestoringen. Aangezien elke applicatie uit meerdere instances van elke rol bestaat, betekent dit dat hardwarestoringen (een kapotte schijf, een netwerkstoring of het vastlopen van een server), niet leiden tot downtime voor de applicatie. Dit is mogelijk doordat de fabriccontroller de computers voor de instances van een applicatie niet willekeurig kiest. Verschillende instances van dezelfde rol worden geplaatst in verschillende foutdomeinen. Een foutdomein is een set hardware-onderdelen (computers, switches enz.) met één gemeenschappelijk point of failure. (Bijvoorbeeld: alle computers in een foutdomein zijn afhankelijk van dezelfde switch om verbinding met het netwerk te maken.) Hiermee wordt voorkomen dat bij één hardwarestoring de complete applicatie vastloopt. Mogelijk verliest de applicatie tijdelijk een aantal instances, maar de applicatie blijft wel correct functioneren. Bescherming tegen softwarestoringen. De fabric-controller detecteert niet alleen hardwarestoringen, maar kan ook storingen vaststellen die worden veroorzaakt door software. Als de code in een instance een storing vertoont of de VM waarin de code wordt uitgevoerd vastloopt, start de fabriccontroller alleen de code of, indien nodig, een nieuwe VM voor die rol. Het werk dat door de instance werd uitgevoerd toen de storing zich voordeed gaat verloren, maar de nieuwe instance maakt deel uit van de applicatie vanaf het moment dat die instance wordt gestart. Mogelijkheid om applicaties bij te werken zonder downtime. Of het nu gaat om routineonderhoud of om de installatie van een compleet nieuwe versie, elke applicatie moet worden bijgewerkt. Applicaties die zijn gemaakt volgens het Windows Azure-programmeermodel, kunnen worden bijgewerkt terwijl ze worden uitgevoerd. Ze hoeven niet buiten bedrijf te worden gesteld. Dit is mogelijk omdat de verschillende instances van elke rol in een applicatie in verschillende updatedomeinen worden geplaatst. (Dit zijn andere domeinen dan de foutdomeinen die eerder aan de orde kwamen). Wanneer een nieuwe versie van de applicatie moet worden geïmplementeerd, kan de fabric-controller de instances in één updatedomein afsluiten, de code voor deze instances bijwerken, en vervolgens nieuwe instances maken op basis van die nieuwe code. Als die instances eenmaal worden uitgevoerd, kan de fabric-controller hetzelfde doen voor de instances in het volgende updatedomein enzovoort. Afhankelijk van de instance die ze gebruiken, zien gebruikers tijdens dit proces mogelijk verschillende versies van de applicatie, maar de applicatie zelf blijft voortdurend beschikbaar. Mogelijkheid om Windows-software en andere ondersteunende software bij te werken zonder downtime van de applicatie. De fabric-controller gaat ervan uit dat elke Windows Azure-applicatie de drie eerder genoemde regels volgt. De controller weet dus dat het mogelijk is een aantal instances van een applicatie op elk gewenst moment af te sluiten, de onderliggende systeemsoftware bij te werken en vervolgens nieuwe instances te starten. Aangezien deze taak in delen wordt uitgevoerd, waarbij op geen enkel moment alle instances van een rol worden afgesloten, kunnen Windowssoftware en andere software op de achtergrond worden bijgewerkt, terwijl de applicatie actief blijft.
9
Beschikbaarheid is belangrijk voor de meeste applicaties (u hebt immers weinig aan software die niet beschikbaar is wanneer u die nodig hebt), maar schaalbaarheid kan ook een belangrijke rol spelen. Met het Windows Azure-programmeermodel kunnen ontwikkelaars op twee manieren beter schaalbare applicaties bouwen: Automatisch een specifiek aantal role instances maken en onderhouden. We hebben gezien dat een ontwikkelaar aan Windows Azure doorgeeft hoeveel instances van elke rol moeten worden uitgevoerd, en dat de fabric-controller de aangevraagde instances genereert en hier toezicht op houdt. Schaalbaarheid van de applicatie is dus heel eenvoudig: u hoeft alleen aan Windows Azure door te geven wat u nodig hebt. Aangezien dit cloud-platform in zeer grote datacenters wordt uitgevoerd, kan in de meeste gevallen de gewenste mate van schaalbaarheid zonder problemen worden bereikt. Een manier bieden om het aantal uitvoerende role instances van een actieve applicatie aan te passen. Bij applicaties met een wisselende belasting, is schaalbaarheid niet zo eenvoudig. Hier is het eenmalig opgeven van het aantal gewenste instances geen goede oplossing, omdat bij variërende workloads het ideale aantal instances sterk kan toenemen of afnemen. Windows Azure omzeilt dit probleem met een webportal voor ontwikkelaars en een API voor applicaties, waarmee het gewenste aantal instances voor elke rol kan worden gewijzigd terwijl een applicatie wordt uitgevoerd. Wanneer applicaties eenvoudiger kunnen worden beheerd en een grotere beschikbaarheid en schaalbaarheid bieden, levert dit grote voordelen op. Gebruik van het Windows Azureprogrammeermodel is doorgaans dan ook een goede beslissing. Maar het is dus ook mogelijk om applicaties onder Windows Azure uit te voeren die dit model niet volgen. U maakt bijvoorbeeld een applicatie met één rol (waarmee u de regels volgt), maar vervolgens voert u slechts één instance van die rol uit (waarmee u de tweede en derde regel overtreedt). U doet dit wellicht om uw kosten te verlagen, aangezien Windows Azure voor elke instance die wordt uitgevoerd, apart kosten in rekening brengt. Als u voor deze optie kiest, moet u er echter rekening mee houden dat de fabric-controller niet weet dat deze applicatie niet alle drie de regels voldoet. De fabric-controller zal deze ene instance op onverwachte momenten afsluiten om patches voor de onderliggende software uit te voeren, en vervolgens een nieuwe instance starten. Voor gebruikers betekent dit dat de applicatie van tijd tot tijd niet beschikbaar is, omdat er geen andere instance is die de taken van de applicatie kan overnemen. Dit is geen fout in Windows Azure, maar een fundamenteel aspect van de manier waarop de technologie werkt. Wanneer u wilt profiteren van alle voordelen die Windows Azure biedt, moet u zich houden aan alle regels van het Windows Azure-programmeermodel. Voor het verplaatsen van bestaande applicaties van Windows Server naar Windows Azure is mogelijk enig werk vereist; we zullen hier elders in dit document naar kijken. Voor nieuwe applicaties is het argument voor het gebruik van het Windows Azure-model echter duidelijk. Waarom zou u geen applicatie maken die goedkoper kan worden beheerd? Waarom zou u geen applicatie maken die geen downtime heeft? Waarom zou u geen applicatie maken die gemakkelijk kan worden opgeschaald en ingeperkt? Het is waarschijnlijk dat er in de loop van de tijd steeds meer applicaties zullen worden gemaakt volgens het Windows Azure-programmeermodel.
DE IMPLICATIES VAN HET WINDOWS AZURE-PROGRAMMEERMODEL: WAT VERANDERT ER VERDER NOG? Bij het maken van applicaties voor Windows Azure moeten de drie regels van het Windows Azureprogrammeermodel worden gevolgd. Maar er is meer nodig: ook in andere onderdelen zijn aanpassingen vereist. De veranderingen die het Windows Azure-programmeermodel teweegbrengt in de bredere ontwikkelomgeving kunnen worden gegroepeerd in drie gebieden: De manier waarop interactie tussen role instances en het besturingssysteem plaatsvindt. De manier waarop interactie tussen role instances en permanente opslag plaatsvindt.
10
De manier waarop interactie tussen role instances en andere role instances plaatsvindt. In dit gedeelte komt elk gebied aan de orde.
INTERACTIES MET HET BESTURINGSSYSTEEM Bij een applicatie die op een standaard Windows Server-computer wordt uitgevoerd, heeft de beheerder van die computer de touwtjes in handen. Hij of zij kan VM's of de computer waarop ze worden uitgevoerd opnieuw opstarten, Windows-patches installeren en alle andere benodigde taken uitvoeren om die computer beschikbaar te houden. In Windows Azure worden alle servers echter beheerd door de fabriccontroller. De fabric-controller bepaalt wanneer VM's of computers opnieuw moeten worden opgestart, en voor web roles en worker roles (maar niet voor VM roles) installeert de fabric-controller eveneens patches en andere updates van de systeemsoftware in elke instance. Zoals we hebben gezien, levert deze benadering fantastische voordelen op. Maar er zijn ook beperkingen. Aangezien de fabric-controller de fysieke en virtuele machines beheert die door Windows Azureapplicaties worden gebruikt, kan de fabric-controller hierop willekeurige taken uitvoeren. Dit betekent dat het niet zo makkelijk is om ervoor te zorgen dat een Windows Azure-applicatie wijzigingen kan aanbrengen in het systeem waarop deze wordt uitgevoerd (m.a.w. de applicatie in de beheermodus laten weken in plaats van de gebruikersmodus). Aangezien de fabric-controller het besturingssysteem naar wens kan aanpassen, is er geen garantie dat de wijzigingen die een role instance aanbrengt in het systeem waarop de instance wordt uitgevoerd, niet worden overschreven. Bovendien veranderen de specifieke virtuele (en fysieke) machines waarop een applicatie wordt uitgevoerd na verloop van tijd. Dit betekent dat elke wijziging die in de standaard lokale omgeving wordt aangebracht, elke keer dat een role instance wordt gestart moet worden doorgevoerd. In de eerste release van Windows Azure konden applicaties geen wijzigingen aanbrengen in de systemen waarop ze werden uitgevoerd en werden applicaties alleen in de gebruikersmodus uitgevoerd. Deze beperking is sindsdien minder streng geworden en zowel web roles als worker roles bieden ontwikkelaars nu de mogelijkheid applicaties in de beheermodus uit te voeren. Het algehele programmeermodel is echter ongewijzigd gebleven. Iedere ontwikkelaar die een Windows Azure-applicatie bouwt, moet inzicht hebben in wat de fabric-controller doet en zijn applicaties op basis daarvan ontwerpen.
INTERACTIES MET PERMANENTE OPSLAG Applicaties zijn meer dan alleen code, ze maken ook gebruik van gegevens. En net zoals het programmeermodel moet worden aangepast om de beschikbaarheid en schaalbaarheid van applicaties te vergroten, moet ook de manier waarop gegevens worden opgeslagen en benaderd, worden gewijzigd. Dit zijn de belangrijke wijzigingen: Opslag moet buiten role instances plaatsvinden. Hoewel elke instance een eigen VM met een eigen bestandssysteem vormt, worden gegevens die in dat bestandssysteem zijn opgeslagen niet automatisch permanent gemaakt. Als een instance uitvalt, kunnen alle gegevens die hierin aanwezig zijn, verloren gaan. Dit betekent dat applicaties bij storingen alleen correct kunnen functioneren wanneer gegevens permanent en buiten de role instance worden opgeslagen. Een andere role instance kan dan toegang krijgen tot gegevens die verloren zouden zijn gegaan als de gegevens lokaal op de uitgevallen instance waren opgeslagen. Opslag moet worden gerepliceerd. Net zoals een Windows Azure-applicatie meerdere role instances uitvoert met het oog op mogelijke storingen, moet Windows Azure-opslag voorzien in meerdere exemplaren van gegevens. Is dat niet het geval, dan heeft een enkele storing al tot gevolg dat gegevens niet beschikbaar zijn, en dit is onaanvaardbaar bij applicaties met hoge beschikbaarheid. De opslag moet geschikt zijn voor zeer grote hoeveelheden gegevens. Traditionele relationele systemen zijn niet altijd de beste keuze voor zeer grote gegevenssets. Windows Azure is deels ontworpen met het oog op zeer schaalbare applicaties en het moet daarom opslagmechanismen bieden die geschikt zijn voor zulke enorme hoeveelheden gegevens. Hiertoe biedt het platform blobs voor de opslag van binaire gegevens, in combinatie met tabellen, een niet-SQL-benadering voor de opslag van grote, gestructureerde gegevenssets.
11
In figuur 5 worden deze drie eigenschappen geïllustreerd en wordt getoond hoe Windows Azure-opslag er voor een applicatie uitziet.
Figuur 5: applicaties zien één exemplaar, maar Windows Azure-opslag repliceert alle blobs en tabellen drie keer. In dit voorbeeld maakt een Windows Azure-applicatie gebruik van twee blobs en één tabel uit de Windows Azure-opslag. De applicatie ziet elke blob en tabel als één entiteit, maar achter de schermen onderhoudt Windows Azure-opslag drie instances van elke blob en elke tabel. Deze kopieën bevinden zich op verschillende fysieke computers die zich, net zoals het geval is bij role instances, op hun beurt weer in verschillende foutdomeinen bevinden. Dit betekent dat de beschikbaarheid van de applicatie wordt vergroot, omdat gegevens nog steeds beschikbaar zijn, ook als bepaalde kopieën niet toegankelijk zijn. En omdat permanente gegevens buiten de role instances van de applicatie worden opgeslagen, gaan bij het uitvallen van een instance alleen de gegevens verloren die op dat moment worden gebruikt. Een van de vereisten van het Windows Azure-programmeermodel is dat een applicatie correct moet functioneren wanneer een role instance uitvalt. Hiertoe moet elke instance in een applicatie alle permanente gegevens opslaan in Windows Azure-opslag of in een ander mechanisme voor externe opslag (zoals SQL Azure, de cloud-service voor relationele gegevens van Microsoft). Er is echter nog één andere belangrijke voorziening: Windows Azure-drives. We hebben gezien dat gegevens die een applicatie op het lokale bestandssysteem van de eigen VM opslaat, verloren kunnen gaan wanneer die VM uitvalt. Met Windows Azure-drives verandert dit en wordt een blob gebruikt om permanente opslag te bieden voor het bestandssysteem van een bepaalde instance. Er gelden enkele beperkingen voor deze drives. Zo kan slechts één instance tegelijk lezen en schrijven op een bepaalde Windows Azure-drive; alle andere instances in de applicatie hebben dan alleen-lezentoegang. Toch kunnen zulke drives in bepaalde situaties nuttig zijn.
12
INTERACTIES TUSSEN ROLE INSTANCES Als een applicatie uit meerdere onderdelen bestaat, moet interactie tussen die onderdelen kunnen plaatsvinden. In een Windows Azure-applicatie wordt dit geregeld door communicatie tussen role instances. Zo kan een web role instance aanvragen van gebruikers accepteren en deze vervolgens doorsturen naar een worker role instance voor verdere verwerking. De manier waarop deze interactie plaatsvindt, wijkt af van de manier waarop dit bij normale Windowsapplicaties gebeurt. Het is wederom belangrijk om in gedachten te houden dat (in de meeste gevallen) alle instances van een bepaalde rol identiek en dus uitwisselbaar zijn. Dit betekent dat, als een web role instance bijvoorbeeld werk doorstuurt naar een worker role instance, het niet van belang is welke specifieke instance het werk krijgt. De web role instance hoeft eigenlijk geen rekening te houden met instance-specifieke zaken zoals het IP-adres van een worker role instance om te kunnen communiceren met die instance. Er zijn algemenere mechanismen nodig. De meest voorkomende manier waarop role instances communiceren in Windows Azure-applicaties is via Windows Azure-wachtrijen. Dit idee wordt geïllustreerd in figuur 6.
Figuur 6: role instances kunnen communiceren via wachtrijen en elke wachtrij repliceert de berichten in die specifieke wachtrij drie keer. In het bovenstaande voorbeeld krijgt een web role instance werk van een gebruiker van de applicatie, bijvoorbeeld via aanvraag van een browser (stap 1). Deze instance genereert vervolgens een bericht dat dit werk bevat en plaatst dit in een Windows Azure-wachtrij (stap 2). Deze wachtrijen worden geïmplementeerd als onderdeel van Windows Azure-opslag en elke wachtrij wordt, net als blobs en tabellen, drie keer gerepliceerd (zie afbeelding). Op die manier wordt fouttolerantie gerealiseerd en zijn de berichten in de wachtrij nog steeds beschikbaar wanneer zich een storing voordoet.
13
Vervolgens leest een worker role instance het bericht in de wachtrij (stap 3). Het is voor de web role instance die het bericht heeft gegenereerd niet van belang welke worker role instance het bericht krijgt, omdat in deze applicatie alle instances uitwisselbaar zijn. De desbetreffende worker role instance voert de vereiste werkzaamheden in het bericht uit (stap 4) en verwijdert het bericht daarna uit de wachtrij (stap 5). Deze laatste stap (het expliciet verwijderen van het bericht uit de wachtrij) wijkt af van de gebruikelijke werkwijze van wachtrijtechnologieën in het eigen datacenter. In Microsoft Message Queuing (MSMQ) kan een applicatie bijvoorbeeld een leesbewerking uitvoeren binnen een atomische transactie. Als de applicatie uitvalt voordat het werk is voltooid, wordt de transactie afgebroken en verschijnt het bericht automatisch weer in de wachtrij. Met deze benadering kan worden gegarandeerd dat elk bericht dat naar een MSMQ-wachtrij is verzonden, exact één keer wordt afgeleverd in de volgorde waarin het is verzonden. Windows Azure-wachtrijen bieden geen ondersteuning voor transactionele leesbewerkingen en bieden dus geen garantie voor eenmalige aflevering in de juiste volgorde. In het voorbeeld in figuur 6 is het dus mogelijk dat de worker role instance het bericht heeft verwerkt en vervolgens vastloopt net voordat deze het bericht uit de wachtrij verwijdert. In dat geval wordt het bericht na een configureerbare timeoutperiode automatisch weer in de wachtrij weergegeven en door een andere worker role instance verwerkt. In tegenstelling tot MSMQ, maken Windows Azure-wachtrijen gebruik van het 'at-least-once' principe: een bericht kan een of meer keren worden gelezen en verwerkt. Dit leidt tot een voor de hand liggende vraag: waarom bieden Windows Azure-wachtrijen geen ondersteuning voor transactionele leesbewerkingen? Het antwoord op deze vraag is dat voor transacties vergrendeling vereist is, waardoor onvermijdelijk vertraging optreedt (vooral bij de berichtenreplicatie van Windows Azure-wachtrijen). Gegeven de primaire doelstellingen van het platform, hebben de ontwerpers van het platform gekozen voor de snelste, meest schaalbare oplossing. In de meeste gevallen zijn wachtrijen de beste manier waarop role instances binnen een applicatie kunnen communiceren. Instances kunnen echter ook rechtstreeks communiceren, zonder gebruik van een wachtrij. Hiertoe biedt Windows Azure een API waarmee een instance alle andere instances in dezelfde applicatie kan onderzoeken die aan specifieke vereisten voldoen, en rechtstreeks een aanvraag naar een van die instances kan sturen. In het meest voorkomende geval, waarbij alle instances van een bepaalde rol identiek zijn, moet de aanroeper willekeurig een doel-instance kiezen uit de set die de API retourneert. Dit is niet altijd het geval; mogelijk implementeert een worker role een in-memory cache bij elke role instance die bepaalde gegevens bevat, en de aanroeper moet dan een specifieke instance benaderen. In de meeste gevallen kunnen alle instances van een rol echter als uitwisselbaar worden beschouwd.
WINDOWS SERVER-APPLICATIES VERPLAATSEN NAAR WINDOWS AZURE Iedereen die een nieuwe Windows Azure-applicatie maakt, moet de regels van het Windows Azureprogrammeermodel volgen. Bij het verplaatsen van een bestaande applicatie van Windows Server naar Windows Azure moet de betreffende applicatie deze regels ook volgen. Daarnaast moeten wellicht wijzigingen worden aangebracht in de communicatie tussen de applicatie en het besturingssysteem, het gebruik van permanente opslag, en de onderlinge communicatie tussen de onderdelen. Hoe gemakkelijk deze wijzigingen kunnen worden aangebracht, hangt af van de applicatie. Hieronder vindt u een paar voorbeelden:
14
Een ASP.NET-applicatie met meerdere instances met een gedeelde status die is opgeslagen in SQL Server. Dit type applicatie kan doorgaans gemakkelijk worden overgezet naar Windows Azure, waarbij elke instance van de originele applicatie een instance wordt van een web role of worker role. Zulke applicaties maken geen gebruik van sticky sessies, waardoor ze bij uitstek geschikt zijn voor Windows Azure. (Het gebruik van ASP.NET-sessiestatus is echter acceptabel, omdat Windows Azure een optie biedt om een sessiestatus permanent op te slaan in Windows Azure-opslagtabellen.) Ook het overbrengen van een SQL Server-database in het eigen datacenter naar SQL Azure is doorgaans een eenvoudig proces. Een ASP.NET-applicatie met meerdere instances die een status per instance onderhoudt en afhankelijk is van sticky sessies. Aangezien deze applicatie in elke instance tussen aanvragen een clientspecifieke status onderhoudt, zijn voor de applicatie een aantal wijzigingen vereist. Windows Azure biedt geen ondersteuning voor sticky sessies en om de applicatie op dit cloud-platform te kunnen uitvoeren, moet de manier waarop de applicatie statussen verwerkt, worden aangepast. Een Silverlight- of WPF-client (Windows Presentation Foundation) die gebruikmaakt van WCF-services die in een middenlaag worden uitgevoerd. Als de services tussen aanroepen geen status per client onderhouden, kunnen ze eenvoudig naar Windows Azure worden overgebracht. De client wordt nog steeds uitgevoerd op desktops van gebruikers, maar de client roept nu services aan die op Windows Azure worden uitgevoerd. Als de huidige services echter een status per client onderhouden, moeten ze worden aangepast. Een applicatie met één instance die wordt uitgevoerd op Windows Server en die status op de eigen computer onderhoudt. Of de clients nu browsers of iets anders zijn, veel bedrijfsapplicaties zijn tegenwoordig op deze manier opgebouwd. Ze kunnen met een paar aanpassingen onder Windows Azure worden uitgevoerd. Mogelijk kan deze applicatie zonder aanpassingen in één VM role instance worden uitgevoerd, maar de kans is groot dat de gebruikers niet tevreden zullen zijn met de resultaten. In ieder geval is de SLA voor Windows Azure bijvoorbeeld niet van toepassing op applicaties met slechts één instance. Vergeet bovendien niet dat de fabric-controller op elk willekeurig moment de machine waarop deze instance wordt uitgevoerd, opnieuw kan opstarten om de software van die machine bij te werken. De applicatie heeft geen controle over het moment waarop dit gebeurt; het zou midden op de werkdag kunnen zijn. Omdat er geen tweede instance is om taken over te nemen (de applicatie is immers niet ontwikkeld volgens de regels van het Windows Azure-programmeermodel), is de applicatie tijdelijk niet beschikbaar. Voor iedereen die de applicatie gebruikt, betekent dit dat hun werk wordt onderbroken wanneer de machine opnieuw wordt opgestart. Hoewel met de VM role een binair Windows Server-bestand gemakkelijk naar Windows Azure kan worden overgebracht, biedt dit geen garantie dat de applicatie goed wordt uitgevoerd op deze nieuwe locatie. De applicatie moet ook voldoen aan de regels van het Windows Azure-programmeermodel. Een Visual Basic 6-applicatie die rechtstreeks toegang heeft tot een SQL Server-database, d.w.z. een traditionele client-serverapplicatie. Als deze applicatie onder Windows Azure moet worden uitgevoerd, moet zeer waarschijnlijk minimaal de bedrijfslogica van de client worden herschreven. Wellicht is het mogelijk de database (met inbegrip van stored procedures) naar SQL Azure over te brengen en daarna de clients naar deze nieuwe locatie door te verwijzen, maar de desktopcomponent van de applicatie wordt dan niet uitgevoerd zoals onder Windows Azure. Windows Azure biedt geen lokale gebruikersinterface, en het biedt evenmin ondersteuning voor het gebruik van Remote Desktop Services (voorheen bekend als Terminal Services) om te voorzien in externe gebruikersinterfaces. Met Windows Azure kunnen ontwikkelaars betere applicaties maken. Maar voor de verbeteringen die het platform biedt, zijn aanpassingen vereist. Voor het overbrengen van bestaande software naar dit nieuwe platform zijn dus zekere inspanningen vereist. Voor weloverwogen beslissingen is inzicht nodig in zowel de zakelijke voordelen als de technische uitdagingen die het overbrengen van een applicatie naar Windows Azure met zich mee kan brengen.
15
CONCLUSIE Cloud-platforms vormen een nieuwe wereld en bieden nieuwe mogelijkheden. Dit komt tot uiting in het Windows Azure-programmeermodel, waarmee ontwikkelaars applicaties kunnen bouwen die gemakkelijker kunnen worden beheerd en die een grotere beschikbaarheid en schaalbaarheid bieden dan de applicaties die in de traditionele Windows Server-omgeving zijn gebouwd. Hiervoor moeten drie regels worden gevolgd: Een Windows Azure-applicatie is samengesteld uit een of meer rollen. Een Windows Azure-applicatie voert meerdere instances van elke rol uit. Een Windows Azure-applicatie blijft correct functioneren wanneer een role instance uitvalt. Voor succesvol gebruik van dit programmeermodel is bovendien inzicht vereist in de veranderingen die het model met zich meebrengt voor de interactie tussen applicaties en het besturingssysteem, het gebruik van permanente opslag en de onderlinge communicatie tussen role instances. Voor ontwikkelaars die hiertoe bereid zijn, liggen de voordelen voor de hand. Het Windows Azure-programmeermodel is misschien niet geschikt voor elk scenario, maar het kan een belangrijke oplossing zijn voor iedereen die applicaties wil bouwen die gemakkelijker kunnen worden beheerd en een grotere beschikbaarheid en schaalbaarheid bieden.
MEER INFORMATIE Kennismaking met Windows Azure: http://go.microsoft.com/?linkid=9682907 Kennismaking met het Windows Azure-platform: http://go.microsoft.com/fwlink/?LinkId=158011
DE AUTEUR David Chappell is directeur van Chappell & Associates (www.davidchappell.com) in San Francisco, Californië (V.S.). Via zijn toespraken, publicaties en consultancywerk helpt hij mensen overal ter wereld nieuwe technologieën beter te begrijpen en te gebruiken, en de besluitvorming te verbeteren.
16
