Windows Azure: Gebruik een queue!

Recent heb ik een post geschreven over de ideale Windows Azure architectuur gebaseerd op het Starbucks model. Dit is een vervolg post over een speciaal onderdeel in deze architectuur: de queue.


De queue is in het Starbucks model een zeer essentieel onderdeel. De queue is de verbinding tussen de intake en de worker. In het model van de Starbucks neemt de intake de bestelling op, de persoon achter de kassa verzamelt voldoende informatie om het product te produceren. In principe heb je als klant alleen contact met de persoon achter de kassa. De intake schrijft de bestelling op een beker, en plaatst de beker in een queue. Om de bestelling kracht bij te zetten “schreeuwt” de intaker de bestelling ook door naar de worker.

De queue verzorgt eenrichtingsverkeer richting de worker. Wanneer de beker eenmaal in de queue staat ontstaat voor de gemiddelde IT-er een interessante situatie. De Starbucks queue kent namelijk niet het principe First-In-First-Out (FIFO) zoals we in de software land meestal gewend zijn. Bij de verwerking van de queue houdt de worker min-of-meer rekening met de volgorde, maar niet altijd. Hierbij lijkt het mondeling doorgeven van de bestelling een belangrijke rol te spelen. Wanneer er bijvoorbeeld twee cappuccino’s dicht bij elkaar in de queue staan, dan beslist de worker om deze samen op te pakken, ongeacht de werkelijke volgorde in de queue. De reden hiervoor is eenvoudig: het is efficiënter. De worker luistert dus goed naar de berichten die naast de queue ook mondeling worden doorgegeven.

Wanneer het druk wordt schakelt Starbucks een tweede worker in. Wat hierbij opvalt, is dat de tweede worker selectief zoekt in de queue naar speciale berichten of bestellingen. Denk hierbij aan thee, en koude koffie dranken. De warme koffie dranken worden nog steeds afgehandeld door dezelfde worker. Er ontstaat een tweede queue waarin *speciale* opdrachten worden afgehandeld.

Kunnen we hiermee ook iets in onze Windows Azure architectuur? Wanneer we schaalbaar willen zijn in de cloud is het verstandig om een aantal principes uit het Starbucks model toe te passen in onze software architectuur. De queue is een essentieel ontkoppel moment. De web role ontvangt de opdracht, verzamelt voldoende informatie en geeft de terugkoppeling dat de opdracht is binnen gekomen. De meeste webwinkels werken al op deze manier. De web role plaatst vervolgens de een bericht in een Windows Azure queue. Een worker role pakt het bericht weer op vanuit de queue en gaat het werkelijke werk uitvoeren. Wanneer het te druk wordt kan er een extra worker role worden ingezet. Dit past natuurlijk uitstekend binnen het Windows Azure model. In tegenstelling tot Starbucks ga je bij Microsoft wel extra betalen voor de tweede worker. Op zich hoeft dit geen probleem te zijn, je hebt tenslotte meer werk te doen en meer werk betekend vaak meer omzet, toch? Dat principe komt dan wel weer overeen met Starbucks, wanneer er meer werk is wordt er een extra worker ingezet. Gezien de prijs van een kopje koffie bij Starbucks vermoed ik dat ze er al lange tijd rekening mee houden dat ze een extra worker moeten inzetten…

Ook voor je software architectuur kan het zinvol zijn om de soort opdrachten van elkaar te scheiden en te laten afhandelen door verschillende workers. Hiervoor kan een tweede queue worden gebruikt. Zo is het bijvoorbeeld mogelijk om het verkeer te scheiden tussen *high priority* klanten en de rest. Je kunt eventueel aparte afspraken (SLA) maken per type klant. Door het scheiden van het verkeer zitten de resources elkaar ook niet in de weg. Net als bij Starbucks. De ene worker maakt koffie, de ander zorgt voor alle andere dranken (thee, fris) en hierdoor lopen ze elkaar, ondanks de beperkte ruimte niet in de weg.

Werken met queues in een Azure wereld is anders! Het geeft je het gevoel van “andere tijden”, zeker wanneer je gewend bent om te werken met een product als MSMQ of MQSeries. Zoals eerder vermeld geeft de queue geen FIFO garanties, meestal gaat het goed. Daarnaast ken de queue ook geen transacties. Wanneer een worker een bericht uit de queue pakt, dan is dit bericht tijdelijk “gelocked” voor andere lezeres. De worker gaat zijn werk doen, maar moet zelf expliciet het bericht verwijderen uit de queue. Wanneer dit niet gebeurt dan is het bericht na een aantal seconde (bijvoorbeeld 30) weer zichtbaar voor een andere werker, die het dan ook kan oppakken. Een eenvoudig mechanisme, dat goed schaalbaar is. Waarom hebben we niet alle functionaliteiten zoals we die gewend zijn van een queue? In de basis is het moeilijk te realiseren functionaliteit in een schaalbare omgeving zoals Azure. Daarnaast is het maar de vraag of je de desbetreffende functionaliteit ook werkelijk nodig hebt. Veel business scenario’s kunnen prima werken zonder al deze functionaliteit. In de praktijk gaan veel webshops al uit van een “piepsysteem”. Wanneer jij een bestelling hebt geplaatst, het bedrag van je rekening is afgeschreven, maar je het product nooit hebt ontvangen…dan ga je contact opnemen. Kortom wij zorgen voor de nodige extra functionaliteit, en we zijn er best goed in. Wie maakt zich nog zorgen omdat ene bericht? Natuurlijk zijn er uitzondering scenario’s denkbaar, maar voor veel scenario’s is de Azure queue net goed genoeg.

De queue architectuur werkt prima bij Starbucks. Ik krijg bijna altijd de juiste koffie binnen een acceptabele tijd. Met mij denken er veel meer mensen zo over, want zoals altijd staat er een lange rij bij de Starbucks. Geef me wel weer de tijd om na te denken over een volgende blog post…eerst maar eens koffie!

Staat Starbucks model voor de ideale Azure architectuur?

Laatst heb ik een paar uur mogen doorbrengen bij de Starbucks op Utrecht CS. Sinds lange tijd reis ik regelmatig naar de USA, sindsdien ben ik een fan van Starbucks. Om de één of andere reden trekt deze winkel mij enorm aan. Misschien heeft dit iets te maken met het feit dat we beiden in het zelfde jaar het levenslicht zagen? Daarnaast zal mijn koffie verslaving een rol spelen… Ik lijk niet de enige te zijn die wordt aangetrokken door Starbucks. Toen ik vorige week bij de Starbucks in Utrecht tijdelijk mijn werkplek had ingericht stond er continu een rij om koffie te kopen. Rondom de Starbucks zijn diverse andere koffiewinkels waar ook goede koffie kan worden gekocht. Waarom staat dan toch iedereen bij de Starbucks? Wat is de aantrekkingskracht? Wat trekt mij aan? Naast de lekkere koffie wordt ik ook aangetrokken door de manier van werken, het systeem!


Ik weet dat er meerdere winkels met een dergelijk systeem werken, maar dat van Starbucks spreekt mij het meeste aan. Koffiezetten bij Starbucks is een intensief en bewerkelijk proces waarbij de hoeveelheid aan keuzes geen goed lijkt te doen aan de doorstroming van de mensen. Toch werkt het goed, en heb je niet het idee dat je lang moet wachten op je koffie. Het systeem, de architectuur van het proces bij Starbucks werkt uitstekend.

Hoe zit dit systeem in elkaar? In bijgevoegd figuur vind je een eenvoudige opzet van iedere Starbucks winkel. Je komt binnen door de deur(1), waarna je in de rij aansluit richting de kassa. Bij de kassa(2) wordt je bestelling opgenomen en wordt er voldoende informatie gevraagd zodat je product kan worden geproduceerd. Wat wilt u? Een cappuccino, prima welk formaat? Nog een extra shot? De verkregen informatie wordt op een beker geschreven (3) en vaak doorgeroepen naar de persoon die de koffie werkelijk maakt. Je rekent af en gaat in de volgende rij staan. De beker wordt opgepakt door de koffiemaker en je product wordt vervaardigd(4). Wanneer je koffie klaar is wordt je beker op de balie gezet en wordt het type product door de winkel geroepen(5). Je bent klaar en kunt gaan genieten van je koffie.

Wat kun je herkennen in dit Starbucks systeem? Wat heeft dat te maken met applicaties ontwikkelen voor Windows Azure? Allereerst is er natuurlijk de duidelijke scheiding tussen intake en werk. Eén persoon neemt de bestelling op, de ander maakt het product. Dit basisprincipe is overduidelijk aanwezig binnen Windows Azure in de vorm van een web role (intake) en een worker role (werk). Belangrijk hierbij is de scheiding van het werk, de twee rollen zijn ontkoppeld: loosely coupling.

Hoe wisselen de twee rollen informatie met elkaar uit? Eigenlijk is er slechts eenrichtingsverkeer, de intake zorgt ervoor dat de werker weet wat hij/zij moet doen. Er is geen terugkoppeling van het werk. De intake plaatst de opdracht in een queue. Bij Starbucks is de queue heel zichtbaar omdat er een aantal lege, maar beschreven, bekers in een rij klaar staan. Windows Azure heeft standaard een queuing mechanisme wat kan worden gebruikt voor de ontkoppeling. De werker haalt de opdrachten uit de queue en produceert het gewenste product.

Wat moet je doen wanneer het te druk wordt? Plaats er gewoon een werker bij en de productie capaciteit wordt verdubbeld. De twee werkers pakken het werk op uit dezelfde queue. Is het te druk bij de intake? Plaats er een extra intake rol bij. Ook dit komt exact overeen met het Windows Azure model, via configuratie kan een extra web of worker role worden geïnitieerd.

In de basis zijn er dus veel overeenkomsten tussen de Starbucks manier van werken en de primaire architectuur van een Windows Azure applicatie. Maar ook in de details zijn er veel overeenkomsten. Ik hoop hier binnenkort meer over te bloggen. Hiervoor moet ik echter eerst de details nader onderzoeken, binnenkort kun je me dus weer vinden in de Starbucks op Utrecht CS…

Azure: De balans opmaken...

Inmiddels ben ik op verschillende manieren een aantal maanden bezig met het Azure. Ik ben betrokken bij een paar projecten die voorzichtig van start zijn gegaan met Windows Azure. Verder heb ik de laatste tijd veel mogen schrijven en spreken over dit onderwerp. Nog belangrijker: ik heb er met veel mensen over mogen spreken. Het is tijd om een balans op te maken…

De technologie
Ik heb een aantal proef projecten gedaan met het Azure Services Platform, voornamelijk met Windows Azure. De technologie werkt de meeste tijd prima, en is verassend volwassen. Natuurlijk zijn er problemen maar er valt heel goed te werken met de huidige versie van het Azure Services Platform. Ik was, en ben blij verrast.

Vertrouwen
Het grootste obstakel blijft vertrouwen. Kortweg: de meeste mensen vertrouwen Microsoft niet met hun code, of nog erger met de data. Ze hebben het idee dat data en code veiliger zijn in een eigen rekencentrum. Persoonlijk vind ik dit een misvatting, maar de angst leeft wel. Voorlopig kost het mij de nodige moeite om mensen “over te halen” en het gevoel van wantrouwen weg te nemen.

Hoeveel gaat het kosten?
Waarom is het interessant om gebruik te gaan maken van cloud computing? Meestal worden mensen overtuigd door het kosten argument: cloud computing is veel goedkoper. Is dit werkelijk zo? In het geval van het Azure Services Platform weten we het niet omdat er nog geen prijzen bekend zijn. Microsoft heeft toegezegd om dit op korte termijn wel te gaan doen. Tot die tijd is het een lastige discussie met potentiële Azure klanten.

Cloud computing : oude wijn in nieuwe zakken!?
Voor veel mensen is er niets nieuws onder de zon. Cloud computing gaat over virtualisatie, centralisatie en hosting. Wat is het verschil met een standaard hosting partner? Het besef dat er iets bestaat als utility-based computing en een cloud platform dringt maar langzaam door. De cloud leveranciers slagen er op dit moment niet in om de verschillen tussen bestaande hosting en cloud computing duidelijk uit te leggen. Ik moet toegeven dat dit mij in presentaties meestal ook maar matig lukt. Achteraf komt vaak de standaard vraag: “wat is er nu anders dan met hosting?”. Kortom, werk aan de winkel!

Hoe nu verder? Ik verwacht de komende tijd nog veel meer tijd te besteden aan cloud computing en Azure. Er valt nog veel te leren. Ik hoop dat ik de komende maanden betrokken kan raken bij praktijk situaties. Ik merk dat er veel aandacht is voor cloud computing en het Azure Services Platform. Het wordt tijd dat we die aandacht gaan omzetten in concrete projecten, en nog belangrijker in oplossingen!

Waarom geen Azure?

Ik ben de laatste tijd meer en meer bezig met het Azure Services Platform. En waar het hart vol van is, loopt de mond van over... Ook ik praat met diverse mensen om mij heen over Azure. Helaas blijkt niet iedereen even enthousiast te zijn als ik. Eerst dacht ik dat dit kwam door het "onbekende", of onwetendheid. Dit is zeker voor een aantal mensen het geval, maar er is ook een duidelijke lijn te herkennen in de bezwaren. Langzaam maar zeker begint het ook bij mij door te dringen dat er mogelijke blokkades zijn om het Azure Services Platform te gaan gebruiken. De meest gehoorde blokkades heb ik op een rijtje gezet.

1. Vertrouwen. Alles valt of staat met vertrouwen. Van wie is mijn applicatie die in the cloud draait? Wie mag er aan mijn data in de cloud komen? Waar staat mijn data, in de USA of in Nederland? Vertrouw ik Microsoft met mijn applicatie en mijn data? Kortom, vertrouwen is een zeer belangrijk aspect.
2. Beschikbaarheid. Kan Azure een 7x 24 uur operatie ondersteunen met een beschikbaarheid van 99,99%? Hoe gaat Microsoft dit garanderen? Wat is het fallback scenario? Op dit punt is er natuurlijk nog nauwelijks informatie beschikbaar. Ik heb ergens gehoord dat er voor betrouwbaarheid moet worden betaald. Hoe meer je betaald, des te hoger de gegarandeerde beschikbaarheid. Voor het vertrouwen zou het goed zijn wanneer Microsoft en flink aantal serieuze eigen services in the cloud gaat draaien, zoals Amazon bijvoorbeeld doet.
3. Vendor lock in. Wanneer je eenmaal hebt gekozen voor het Azure Services Platform dan zit je eraan vast. Je kunt niet eenvoudig overstappen naar een concurrent platform van bijvoorbeeld Google of Amazon. Ik zie dit niet als een groot probleem, volgens mij is dit niet anders dan de problemen die wie nu hebben? Daarnaast steunt Azure op diverse open standaarden zodat integratie goed mogelijk is.
4. Nieuwe API. Microsoft doet haar best om software ontwikkeling voor het Azure Services Platform hetzelfde te laten lijken als "normale" .NET ontwikkeling. Voor een deel is dit ook werkelijk zo, je maakt bijvoorbeeld gewoon gebruik van Visual Studio. Maar er zijn ook aspecten anders, hiervoor is een nieuwe API. Deze API moet je leren kennen en gebruiken voordat er succesvolle Azure applicaties kunnen worden ontwikkeld. Verder moeten applicaties op een andere manier worden ontworpen. Persoonlijk vind ik dit niet erg omdat de design principes 1 : 1 toepasbaar zijn voor je normale applicatie ontwikkeling.
5. Geen lokale cloud beschikbaar. Het platform is alleen in de cloud beschikbaar. Een organisatie kan er niet voor kiezen om het platform op een eigen infrastructuur te draaien. Microsoft claimt dat het platform op zeer complexe schaalbaarheids principes leunt die niet eenvoudig te realiseren zijn in je eigen infrastructuur. Waarschijnlijk is dit ook zo voor de meeste organisaties. Daarnaast is het hele idee gebaseerd op utility computing, je betaald voor wat je gebruikt zodat je niet zelf een complete infrastructuur hoeft in te richten. Overigens kan het ook anders, IBM kiest voor het model van hybrid cloud computing...

Moet je het Azure Services Platform dan maar niet gebruiken? Ik denk dat er heel veel mogelijkheden en kansen zijn om wel degelijk gebruik te maken van het platform. Natuurlijk is het niet geschikt voor iedere vorm van software ontwikkeling, maar wel voor veel vormen. Wanneer je eenmaal per jaar een pensioenberekening moet doen, dan kan het best interessant zijn om gebruik te maken van de Azure cloud. Of wanneer je een leuk , nieuw "web" idee ontwikkeld (twitter 2.0) is het best interessant om klein te beginnen en daarna mateloos populair te worden op dezelfde infrastructuur: Azure Services Platform. Zo zijn er nog veel meer voorbeelden denkbaar die interessant zijn om the combineren met het Azure Services Platform.

Doen de concurrenten het beter met betrekking tot de beschreven blokkades? Nee, het volledige lijstje is toepasbaar op de concurrenten van het Azure Services Platform. Op het laatste punt (5) doet IBM het anders, maar is dit ook beter?

Green computing

Het begrip green computing speelt de laatste tijd meer en meer in onze IT-wereld. Wat mij betreft is dit volkomen terecht, en kan de nadruk voorlopig niet genoeg liggen op green computing. Het gaat hier tenslotte over een onderwerp wat ons allemaal aangaat, het gaat over onze wereld.


De laatste tijd heb ik mij wat meer verdiept in het idee van green computing, en dit tegen meerdere personen in mijn omgeving aangehouden. Tot mijn schrikt lijkt dit onderwerp bij de meeste ontwikkelaars helemaal niet te spelen. De meeste ontwikkelaars hebben nog nooit van de term green computing gehoord. Zo slecht zijn wij als IT-ers toch ook weer niet voor het milieu, is vaak de reactie? Ok, de meeste van ons rijden dan wel in een grote lease auto, maar daar blijft het dan ook bij. Toch?

De werkelijkheid is anders. Op dit moment gebruiken data/reken centra ongeveer 2% van de totale geleverde hoeveelheid energie in West-Europa. Dit is een groot getal. Helaas groeit dit getal nog steeds, en wordt de hoeveelheid energie die we gebruiken voor de data centra iedere 5 jaar verdubbeld. Hopelijk is dit met name groene energie, maar zelfs dat blijkt niet het geval te zijn. De laatste jaren lijken de servers in de diverse data centra op konijnen, ze vermeerderen zich gestaag in een vlot tempo. Hiervoor betalen we een prijs: een hoge energie rekening. Op dit moment is het zo dat menig reken centra een energie rekening heeft die groter is dan de hardware die wordt aangeschaft...

Wat moeten wij hiermee als software ontwikkelaars, dit is toch een probleem van de IT-afdeling? Er staat nergens in mijn set aan eisen iets over green computing, of energie zuinig ontwikkelen. Wel staan er keiharde eisen over de beschikbaarheid van de oplossing: 99,9%. Dit is dan ook direct een probleem. Green computing is zelden een eis, beschikbaarheid is altijd opgenomen en gekwalificeerd als eis. Beschikbaarheid is nu net een eis die slecht is in het kader van green computing. Beschikbaarheid vraagt om redundantie, en hiervoor is weer meer energie nodig. Kunnen we deze neerwaartse spiraal doorbreken? Ja, het antwoord is: share. Deel de resources met elkaar. Waarom een server installeren die alleen overdag file en print server is en 's avonds en 's nachts niets staat te doen?

Het delen van de infrastructuur wordt vaak gerealiseerd door virtualisatie. Dit is een begrip wat de laatste jaren steeds meer aan populariteit heeft gewonnen. In basis is virtualisatie niets anders dan het idee om met elkaar resources te delen. Virtualisatie kan klein beginnen en uiteindelijk eindigen in cloud computing. Ik kom de laatste tijd steeds vaker een tabel tegen waarin verschillende niveaus van virtualisatie worden beschreven. Laats kwam ik de tabel als volgt tegen in The Architecture Journal:

Maturity    Name               Applications         Infrastrcuture          Location           Ownership
Level 0        Local                 Dedicated              Fixed                        Distributed          Internal
Level 1        Logical               Shared                  Fixed                        Centralized          Internal
Level 2        Data center        Shared                   Virtual                      Centralized          Internal
Level 3        Cloud                SaaS                      Virtual                      Virtual                 Virtual

Veel organisaties bevinden zich op niveau 0 en 1. Wanneer een organisatie meer virtualisatie toepast, dan is dit beter binnen het kader van green computing. Wat betekenen de vier verschillende niveaus?

Level 0 - Local
Dit is het niveau waarop geen virtualisatie plaats vindt. We hebben het hier over applicaties die lokaal draaien, en gebruik maken van de locale resources. Kan hier niets gebeuren? Wel degelijk zijn hier verbeteringen mogelijk. Begin eens dichtbij, is het nodig dat je PC dag en nacht aan staat? De applicaties die je schrijft zijn die instaat om transparant om te gaan met sleep/wake mode van je PC? Of houdt je diverse connecties op waardoor de PC niet naar een slaapstand kan over gaan? Kortom voor de ontwikkelaar voldoende uitdaging!

Level 1 - Logical
Het niveau waarop de eerste virtualisatie gaat plaats vinden. Dit is de wereld van client/server en N-Tier applicaties. We delen resources zoals bijvoorbeeld een database en een web server. Dit kan op afdelingsniveau gebeuren, maar ook op het niveau van je bedrijf. Dit is reeds een flinke stap voorwaarts. Op dit niveau kan natuurlijk nog de nodige consolidatie plaatsvinden. Heb je echt al die servers nodig? Zorg ervoor dat jouw software de omgeving kan delen met andere applicaties, verwacht geen exclusiviteit!

Dit is ook het niveau waarop ik de mogelijkheid tot thuiswerken zie. Maak het mogelijk om thuis te werken. Zorg dat je remote bij mail, files en andere resources kan. Maak bijvoorbeeld gebruik van VPN. Thuiswerken past prima in het plaatje van green computing!

Level 2 - Data center
Dit is het niveau waaraan de meeste mensen denken wanneer ze het woord virtualisatie horen. Dit is het niveau waarop alle data wordt geconsolideerd op een SAN in een rekencentrum. Dit is het niveau waar virtualisatie software zoals Microsoft Virtual Sever of VMWare wordt gebruikt. Op dit niveau gaan we nadenken over het optimaal gebruiken van onze servers. Een zeer aansprekend voorbeeld voor software ontwikkelaars is de virtualisatie van de OTAP omgeving. Het is toch niet noodzakelijk om voor iedere omgeving binnen de OTAP een fysieke server beschikbaar te hebben, logisch toch?

Level 3 - Cloud computing
Op dit moment het ultieme niveau van delen. We delen resources in de cloud en richten niet meer onze eigen rekencentra in. We maken gebruik van de schaal grootte die voordeling is voor het totale energie gebruik. Heel eenvoudig, twee servers die voor 50% zijn belast zijn nadeliger voor het milieu dan een server waarop twee virtuele omgevingen draaien waardoor de machine voor 100% is belast.

Met de komst van het Azure Services Platform bestaat nu ook binnen de Microsoft familie de mogelijkheid om na te denken over cloud computing Naast Microsoft zijn ook Amazon en Google sterk bezig met cloud computing. Op dit moment richt Microsoft enorme data centra in om de cloud ook werkelijkheid te laten worden. Je kunt hierover verschillende video's vinden. Een interessante ontwikkeling. Een ontwikkeling waarbij een volgend niveau van virtualisatie, oftewel delen, ontstaat. De rekencentra zijn schaalbaar, er wordt gebruikt gemaakt van containers met daarin ongeveer 200 PCs. Waarneer er meer rekenkracht nodig is, dan wordt er een container bijgezet. Deze rekencentra draaien op groene stroom en zijn ingericht om efficiënt om te gaan met koeling en elektriciteit.

Wat betekent dit allemaal voor de software ontwikkelaar?

De eerste stap die we moeten maken is green computing een wezenlijk onderdeel maken van het pakket van eisen die we aan de applicatie stellen. Net zoals we eisen opstellen rondom beveiliging, schaalbaarheid, performance en beschikbaarheid. Hiervoor is een mind shift nodig. Dit is niet eenvoudig, we zijn jaren lang verwend. de prijs en capaciteit van PCs zijn nauwelijks een belemmering geweest om er nog maar eentje meer te nemen.

Het is als in een hotelkamer. Ik betrap me er altijd op dat ik heel veel handdoeken gebruik wanneer ik logeer in een hotel, ondanks de waarschuwingen die overal hangen. Wanneer er vijf handdoeken zijn dan blijkt dat ik ze op wonderbaarlijke wijze alle vijf nodig heb. Ik denk wanneer er slechts twee zouden liggen dit voor mij ook ruim voldoende zou zijn. Zo is het ook gegaan met servers. We moeten weer meer gaan denken en ontwerpen vanuit de beperking en niet de overvloed.

Zo zouden we bijvoorbeeld goed kunnen kijken naar onze read-only data. Deze data hoeft geen gebruik te maken van ons fail-over cluster, maar kan rustig ergens in de cloud draaien, Wanneer we de data meerdere keren dupliceren dan is dit nog steeds voordeliger voor de energierekening. In onze applicaties moeten we er meer rekening mee gaan houden dat de services tijdelijk niet beschikbaar zijn. Ga denken in het "shopping basket" model. Dit werkt uitstekend voor de meeste websites. Er is nog veel meer mogelijk, maar veel moet nog worden bedacht. Hier zijn heel veel kansen…

Gaat dit werken?

Gaan software ontwikkelaars nadenken over green computing? Worden er eisen gesteld aan een applicatie in het kader van green computing? Ik denk dat dit vroeg of laat gaat gebeuren. De reden hiervoor is dat green computing ook een kostenbesparing betekend. En wie wil dat momenteel niet? Minder energie gebruiken, betekent een lagere rekening...

Het is nu het moment om na te gaan denken over green computing en cloud computing. Zorg dat je voorbereid bent. Een interessant rapport kun je hier vinden. Ook hiervoor geld, een betere wereld begint bij jezelf!

Eén van de grote onderwerpen van de afgelopen PDC (2008) was het Azure Services Platform. Ik heb de laatste weken de tijd genomen om dit platform wat beter te bekijken. Het Azure Services Platform heeft alles te maken met cloud computing. Nadat Amazon en Google al eerder initiatieven hebben gebracht rondom cloud computing, komt Microsoft nu ook met een initiatief. Het is interessant om een applicatie in de cloud te laten leven, maar bijvoorbeeld ook om data in de cloud te laten leven. Met het Azure initiatief gaat Microsoft verder, zij biedt ook diverse services aan in de cloud die gebruikt kunnen worden. Het platform staat open voor een Service + Software applicatie model. Vanuit je .NET applicaties is het dus mogelijk om gebruik te maken van de services die het Azure Services Platform biedt.

Wat is het Azure Services Platform?

Het Microsoft Azure Services Platform is groep van cloud technologieën. Iedere technologie geeft een specifieke set services die kunnen worden gebruikt door ontwikkelaars. Het is mogelijk om applicaties te draaien op het Azure Services Platform, maar je kunt ook alleen gebruik maken van de services. Het platform bestaat uit de volgende onderdelen:

• Windows Azure

Om applicaties te draaien heb je een omgeving nodig, Windows Azure geeft deze omgeving. Naast het draaien van applicaties heeft Windows Azure ook de mogelijkheid om data te bewaren, zoals een operating systeem een file system heeft. Windows Azure maakt een onderscheid in Queues, Tables en blobs.

•  Microsoft .NET Services

Services die gebruikt kunnen worden door applicaties die draaien in de cloud, of door “traditionele” applicaties. In basis worden er drie services geleverd: access control, service bus en workflow. De services zorgen voor een cloud based infrastructuur.

• SQL Services

Een set van cloud-based services om data te bewaren die eerst bekend was onder de naam SQL Data Services (SDSS). Dit kan gestructureerde relationele data zijn, maar ook ongestructureerde data. De data moet op verschillende standaard manieren te bereiken zijn, zowel SOAP als RESTful services kunnen worden gebruikt. Alle data wordt op een hiërarchische manier gestructureerd. Microsoft zorgt voor de beschikbaarheid en schaalbaarheid…

• Live Services

De Live services zijn nu reeds op de een of andere manier beschikbaar. Het betreft o.a. messaging, contact informatie en search. Al deze applicaties bewaren data, deze data wordt via services beschikbaar gesteld. Om deze data te gebruiken heb je het Live Framework nodig

Wat betekent dit voor mijn architectuur en ontwikkelplatform?

Je kunt nog steeds Visual Studio gebruiken en .NET applicaties ontwikkelen. Er zijn diverse .NET APIs beschikbaar om de services te gebruiken. Zijn er dan helemaal geen wijzigingen? Wijzigingen zijn er wel degelijk, je kunt bijvoorbeeld niet zomaar een applicatie “debuggen” in de cloud, logging is dus heel belangrijk. Zeker op het gebied van architectuur zijn er belangrijke voorwaarden. Je hebt in basis geen idee waar in de cloud jouw proces komt te draaien, je moet dus volledig stateless zijn. Verder heeft Microsoft het idee van een Starbucks winkel overgenomen (eindelijk). Starbucks is mijn favoriete winkelketen, ik ben hier dus blij mee. Dit is in essentie een loosely coupled architectuur. 

In basis betekent dit het volgende: wanneer je binnenkomt in een Starbucks bestel je jouw favoriete koffie bij de persoon achter de kassa. Je betaald je koffie. Deze Starbucks medewerker schrijft op een beker wat je wilt hebben en plaatst de beker in een queue. Een tweede persoon maakt de koffie. Deze medewerker leegt de queue. Zodra jouw beker uit de queue komt wordt jouw favoriete koffie gemaakt en overhandigd. Dit principe is ook aanwezig in het Azure Services Platform. Je hebt in basis twee soorten processen en een queue. Deze zijn standaard in de infrastructuur. Je hebt een input proces die de “bestelling” op neemt en de gewenste koffie opschrijft en in de queue plaatst. Je hebt een worker proces om het echte werk te doen en de queue te legen. Het resultaat: een eenvoudig schaalbaar proces (en heerlijke koffie).

 

Voor wie is het interessant?

Ik denk dat het Azure Services platform voor iedere organisatie interessant kan zijn. Er zijn verschillende scenario’s denkbaar. Het basis voordeel is wat mij betreft het idee van “utility computing”. Je betaald voor wat je gebruikt. Wanneer je dus klein begint, betaal je een “klein” bedrag. Wanneer je gaat groeien, dan ga je meer betalen. Het business model gaat concurreren met Amazon en Google. Dit betekent dat je voor een paar euro per dag terecht kunt op het Azure Services Platform. Persoonlijk denk ik dat de prijs veel “angst” zal weg nemen. Want er zijn natuurlijk genoeg bedenkingen en bezwaren. Gaat Microsoft wel goed om met mijn data? Is het platform wel snel genoeg? Al deze vragen zullen als sneeuw voor de zon verdwijnen wanneer de CEO het investeringsmodel over ziet…

Daarnaast komt Microsoft ook met een CRM en SharePoint variant binnen het Azure Services Platform. Dit is een logische stap waar veel organisaties van kunnen gaan profiteren.

 

Hoe kan je beginnen?

Microsoft heeft een CTP gereleased. Je kunt dus in de cloud aan de gang. Voor de ontwikkelaar is het interessant dat er een SDK beschikbaar is met een lokale “cloud omgeving”. Een omgeving waarin je lokaal de cloud kunt nabootsen, een omgeving waar je kunt debuggen in de cloud. Cloud computing, een interessante ontwikkeling. Met het Azure Services Platform kun je vandaag aan de slag. Je kunt de bekende tools gebruiken maar wel gebruik maken van een innovatief platform en een nieuwe ontwikkeling in Microsoft land!

LINQ to SQL is the Data Access Layer (DAL)

The last few weeks I have found the time to take a better look at LINQ. I studied the architecture and the technique in more detail. I have a special interest in LINQ to SQL since I love databases, especially Microsoft SQL Server. I have to admit I really like LINQ. The part I liked most is the native language integration in both C# and VB9. For a developer it feels very natural to use LINQ within the code.

It is really interesting to see what LINQ will bring to the developer community. I personally think that LINQ is the feature in VS2008 that brings real developer productivity. Many language enhancements make the language just more complex, but LINQ is the one that makes it simpler. Increased developer productivity is definitely something we (the software industry) can use. We should ask ourselves the question has our productivity really improved in the last 15 years? Personally I don’t think so. This is off course very bad for the image of the industry. LINQ seems to be a very promising technology to increase developer productivity. At least for the data access part of our applications.

When you start using LINQ it becomes very soon clear that LINQ is much more than only a data access technology. For example each “foreach” statement is a candidate to be replaced by a LINQ query. But the main part of LINQ is focused at data access (at least for me). LINQ has to do with data connections, OR/M, queries and data manipulation. Typically data access layer functionality. Although the technology is interesting the impact of LINQ at the architecture of our applications is of much more interest to me. It really surprises me that most articles and blog posts are about the technology while the design and architecture of an application is also very interesting. (I really like the series of articles Scott Guthrie has written)

After programming LINQ for a while the main question which comes into my mind is: “Is LINQ to SQL the Data Access Layer (DAL)?”. At the moment I really think the answer to this question is “yes”. I think that LINQ will change the design of many .NET applications in the near future. We finally will remove a layer!

What is a DAL?

Great question. When you google for a data access layer definition you will find many different statements en opinions. At Wikipedia you will find some description. Some general points (a.k.a tenetsJ) can be filtered by all the definitions:

- Responsibility for data access (querying & data manipulation)

- Abstraction of underlying data store (e.g. SQL Server)

- Mapping between OO and relation information

- Provides services

In my opinion the data access layer has indeed something to do with all four points listed above. In .NET this will be translated in a few assemblies which are referenced by the business layer.

What has LINQ to do with a DAL?

LINQ to SQL is about data access with a SQL Server. LINQ to SQL provides a model for the OR/Mapping and a data context. Using LINQ to SQL provides you with an easy programming model to access and manipulate data. These are important aspects you have to build in your DAL. So, LINQ is a great technology to use inside your DAL. You design and program the abstraction (classes, interfaces & methods) and provide the services (WCF) the rest is LINQ code.

I really think that I will see many solutions were LINQ indeed is used as described above. This will end up with “empty” methods which are nothing more than a wrapper around a LINQ statement. Something likes this:

public static class DataHelper
{

   public static IQueryable GetAllRestaurants()

   {
      DinnerNowDataContext context = new DinnerNowDataContext();
      return from r in context.Restaurant

      select r;

   }

}

 
Will this type of code really improve our designs? More important, will this type of code really improve the developer productivity? I don’t think so…

Another problem has to do with the LINQ language integration. You can use LINQ very usefully in your business and presentation layer as well. Even when you use a method as above you can still write a LINQ query in the business layer on top of the GetAllRestaurant() method. Is this correct from a architecture point of view? Why not, LINQ is just a great language feature which you use everywhere. But if that is the case, where do you write queries? In the data access layer? Or in the business layer? Or even in the presentation layer? This gives the developer many choices, and choices are bad for productivity!

Is there a better way to use LINQ in our design?

Yes, I do think so. If we start from the point of view that LINQ to SQL is our data access layer. We just build a data context and map our tables to classes with the standard VS2008 functionality. We configure our data store connection by using a configuration file and we are done. You have your data access layer. We simple do not discuss what goes in which layer, that will save a lot of time.

We allow our developers to use LINQ queries all over the place. It is just a language feature that improves the productivity and provides us with more readable code.

That’s it. I think LINQ to SQL is a great DAL (or whatever you wane call it). It is a mind shift. Stop programming useless classes. Start thinking about better software and a better productivity!

SQL Server peer-to-peer replication

In my last post I wrote about scaling SQL Server 2005. One of the most important technologies we have used to scale SQL Server 2005 is peer-to-peer replication.


This type of replication is a special transaction replication type. This type of replication is available in SQL Server Enterprise Edition since the 2005 version. The peer-to-peer replication is responsible for replicating transactions across the configured peers. Transactions marked for replication are transmitted and executed at other SQL Server databases. The peer-to-peer replication makes sure that database A and B stays in sync without circular references. This concept is great to start building a NLB for load balancing. At msdn you can find a good article about setting up a peer-to-peer replication topology.

Before setting up a peer-to-peer replication topology you should realize you are entering the world of SQL Server replication. This means you should be familiar with articles, publishers, subscriber, subscription and SQL Agent for example. Replication is a grown up, but also complex technology of SQL Server 2005. Get to know the basics before starting with peer-to-peer replication.

One of the misunderstandings has to do with the basics of the peer-to-peer replication: transactional replication. Only, and only transactions are replicated (in the right order). When you for example bulk insert a set of data without logging in the transaction log the data is not automatically replicated to the other peers. This means a manual action to get the other peers in sync. The order of the transactions is another concept to take notice of. When transaction A fails to be replicated, for whatever reason all other transactions (later in time) in the log will not be replicated. These transactions “wait” until the problem with transaction A is solved. When you start with peer-to-peer topology, get to know the transactional replication basics.

Once you decided to use a peer-to-peer replication topology, you must start thinking about synchronizing the peers. The replication topology has a snapshot option to get a new peer in sync with the rest. However when the database consists of a fair amount of data I advice to use the backup/ restore technology or simple attach the database. Make sure the schemas between the peers are identical!

Two important design issues are about the number of peers en conflict resolution. Keep the number of peers low. When you see the subscriptions and publication for a four node technology, you can imagine that this can become complex very soon. Microsoft recommends to the keep the number of peers below 12. I personally think 12 is a very high number. An alternative you can find in the second figure. However, this means when node B or C fails the transactions of A don’t reach node D and vice versa. The replication topology in the second figure is much easier to maintain and configure.

An other design issue has to do with conflict detection and resolving conflicts. Most of the cases a conflict situation comes up when somebody updates some data manually. In a normal situation, this data will be replicated as well. However, don’t be surprise when somebody at your organization blows up the whole peer-to-peer replication without even realizing it. The replication monitor can help you to detect problems, but there are no replication tools to help you resolving the problems. You are at your own…in some future post I might talk about resolving problems in a peer-to-peer replication topology.