Daar ben ik dan: op de PDC09 (Professional Developer Conference) van Microsoft. Hét event op het gebied van software ontwikkeling. Jetlag valt niet mee, maar ik heb er zin in als ik het Los Angeles Convention Center binnenloop. De conferentie begint morgen pas officieel, maar vandaag woon ik de Pre-conference Workshop bij met als onderwerp 'Architecting and developping for Windows Azure'.

Daar ben ik dan: op de PDC09 (Professional Developer Conference) van Microsoft. Hét event op het gebied van software ontwikkeling. Jetlag valt niet mee, maar ik heb er zin in als ik het Los Angeles Convention Center binnenloop. De conferentie begint morgen pas officieel, maar vandaag woon ik de Pre-conference Workshop bij met als onderwerp 'Architecting and developping for Windows Azure'.
PDC09: Azure pre-conference workshop
Windows Azure
Microsoft zet groot in op Azure. Het hele 'Cloud computing' is behoorlijk hot en misschien niet geheel onterecht. Als ik eerlijk ben wist ik een jaar geleden niet wat ik met Azure aanmoest. Wat heb je er aan en waarom zou ik m’n spullen bij Microsoft hosten? Maar inmiddels zie ik er de lol wel van in. Azure is niet het antwoord op al je vragen, maar wel een oplossing voor een aantal specifieke situaties.
Het inzet gebied van Azure bevindt zich bij de zeer grote webapplicaties. Daar waar je meerdere webservers en meerdere database servers nodig hebt. Windows Azure neem alles uit handen rondom load-balancing, fail-over, mirroring, etc.
Een ander probleem waarvoor Windows Azure een oplossing kan zijn is elasticiteit. De meeste websites hebben niet altijd eenzelfde aantal bezoekers. Veel websites hebben gedurende de dag duidelijke pieken en dalen in bezoekersaantallen. Andere websites hebben juist sommige dagen van de week/maand/jaar veel meer bezoekers of gebruikers dan op andere dagen. Dat betekent dat je servers het grootste gedeelte van de dag nauwelijks iets aan het doen zijn (je gooit dus capaciteit weg) of je servers kunnen de pieken niet goed aan en de prestaties gaan er onder leiden.
Idealiter zou de capaciteit van de servers mee moeten groeien en krimpen met het gebruik van de webapplicatie. Windows Azure is in deze situaties zeker een goede oplossing die je eens zou moeten bekijken.
Pay as you go
Bij Azure is het idee dat je betaalt voor je gebruik. Afhankelijk van de technieken die je gebruikt, betaal je bedragen voor dataverkeer, dataopslag en processortijd. Naast dat je de initiële aanschaf van je serveromgeving (hardware en software) niet hoeft te bekostigen, denk ik dat de prijzen zo zijn dat je het zelf niet goedkoper voor kunt bouwen.
Over Windows Azure is genoeg te vertellen en dit is simpelweg te uitgebreid om in deze blog helemaal uit te leggen. Hopelijk geeft bovenstaande je een beetje een idee of je in een omgeving zit waarin het de moeite waard is om er in ieder geval eens naar te kijken. Kijk voor meer info ook op http://www.azure.com.
Architecting and developping for Windows Azure
Vandaag heb ik dus een workshop bijgewoond over Azure. Deze workshop ging hoofdzakelijk over Architectuur, ofwel: hoe moet het één en ander ontworpen worden.
PDC09: Azure pre-conference workshop
Technisch gezien zijn er enkele zaken waar je rekening mee moet houden als je ontwikkelt voor Azure. Zo zit de data opslag zit anders in elkaar en je moet er (net als bij andere web-farm omgevingen) rekening mee houden dat het ene request op een andere server-instantie uitgevoerd kan worden dan het volgende request. Maar dit is nog wel te overzien.
Vandaag ging het met name over de keuzes die je moet maken om de performance hoog, en de kosten laag te houden. Alles in Azure kost geld, vaak maar fracties van centen, maar omdat je Azure inzet bij grote applicaties met veel gebruikers kan een bepaalde beslissing je veel geld kosten.. of juist besparen.
Zo kun je data bijvoorbeeld opslaan in SQL Azure of Azure Table Storage. De eerste is duur qua opslag, maar zeer geschikt om data in op te zoeken (indexen). De tweede is qua opslag veel goedkoper, maar je betaalt per transactie op deze data.
Als voorbeeld gaf de spreker een Facebook-achtige applicatie. Een gebruiker heeft een lijst met 'vrienden' en van deze vrienden worden de naam en foto getoond. De naam van de vrienden zou je bijvoorbeeld het beste op kunnen slaan in SQL Azure aangezien deze goed te doorzoeken is. Terwijl de fotootjes beter in een Azure Table storage kunnen staan omdat dit goedkoper is.
Een andere manier om geld te besparen is om je data extreem te de-normaliseren. Aangezien je betaalt per transactie, wil je liever niet 50 keer een foto uit de Azure Table Storage halen. Door te de-normaliseren zou je per gebruiker een record kunnen maken met daarin alle foto's van de betreffende vrienden. De extra kosten voor de extra data zouden dan lager kunnen zijn dan de kosten die kunt besparen op de transacties.
Dergelijke ontwerpkeuzes vergt toch een behoorlijk andere denkwijze dan dat we gewend zijn. Het was dan ook een zeer interessante dag.
Nieuwe SDK
Afgelopen vrijdag is er een nieuwe versie van de Azure SDK (Software Development Kit) uitgebracht. Uiteraard werd hier ook op in gegaan. Één van de opvallende dingen was dat naar scale-out (meerdere server-instanties erbij zetten) nu ook scale-up ondersteund wordt. Ofwel: je kunt nu aangeven of je 'kleine' servers (1,7 GB RAM, 1 processor core) wilt draaien, of op zwaardere configuraties zoals een 15GB RAM machine met 8 processor cores.
Daarnaast zijn er een aantal flinke uitbreidingen op het gebied van Diagnostics. Door je applicatie beter in de gaten te houden is het onder andere mogelijk om regels te schrijven waarop het systeem automatisch capaciteit toevoegt of juist vrijgeeft. Ook zeer interessant dus!