maandag 11 januari 2010

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…

Geen opmerkingen:

Een reactie posten