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.
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!
Geen opmerkingen:
Een reactie posten