dinsdag 16 juli 2013

SignalR in ASP.NET.

Websites worden steeds moderner. Waar we het vroeger (begin jaren 90) nog moesten doen met een homepage, waarop wat persoonlijke informatie stond en een rubriekje "Mijn favoriete links" (Het enige interessante op die pagina's omdat search engines niet of nauwelijks bestonden), worden nu complete applicaties via de webbrowser aangeboden. Deze ontwikkeling ging bepaald niet over rozen. De webarchitectuur was zo gebouwd dat alle initiatief bij de client (webbrowser) lag. De client deed de requests en de server (webserver) reageerde alleen op die requests. Het was uit den boze dat een webserver op eigen houtje contact ging opnemen met een webbrowser (waarschijnlijk zou je continu verveeld worden met commerciële websites waar je niet om gevraagd hebt). Toch kan het voor applicaties belangrijk zijn dat zij op de hoogte worden gehouden van de laatste wijzigingen. Denk bijvoorbeeld aan een applicatie die de aandelenkoersen laat zien of een nieuwsapplicatie die steeds het laatste nieuws wil laten zien (real-time informatie). Met de huidige webarchitectuur is dat eigenlijk niet mogelijk. Gelukkig zijn er slimme mensen die hierop iets bedacht hebben. Hier volgen een paar technieken:

  1. Polling. De browser doet herhaaldelijk, na een x aantal seconden, een request naar de webserver. Dit kan de webbrowser zelf doen of je gebruikt het XmlHttpRequest object (een onzichtbaar minibrowsertje in de webbrowser, het kloppende hart achter de Ajax technologie). Hierbij is alleen de kans groot dat er requests naar een webserver worden gestuurd, terwijl de webserver helemaal geen wijzigingen te bieden heeft.
  2. Pushlets. Met deze techiek wordt de webbrowser eigenlijk aan het lijntje gehouden. De browser doet een request naar de webserver die een response stuurt, maar de webserver zal de response nooit afsluiten. De webbrowser blijft dus continu laden. De webserver kan nu data naar de webbrowser sturen wanneer het hem uitkomt. Nadeel is de gebrekkige controle over de verbinding en je hebt de webbrowser beroofd van een verbinding hetgeen significante vertragingen kan opleveren omdat webbrowsers steeds maar twee verbindingen tegelijk naar de webserver open mogen hebben.
  3. Long Polling. De webbrowser stuurt een request naar de webserver, maar die reageert pas als hij nieuwe data heeft (opzettelijk laat reageren). Dit pakketje wordt dan naar de webbrowser gestuurd waarna het hele spel opnieuw begint.
  4. WebSockets. Nieuw in html5. Met WebSockets worden alle hierboven genoemde kunstgrepen naar de eeuwige internetvelden verwezen. Met WebSockets kan een duplexverbinding tussen webbrowser en webserver worden opgezet. Als die duplexverbinding eenmaal is opgezet, kan de webserver op ieder moment data naar de webbrowser sturen en visa versa. Nadeel is wel dat je een moderne browser moet hebben die WebSockets ondersteunt (Zie caniuse voor ondersteuning)
WebSockets is met afstand de meest gewenste oplossing, maar je zult maken krijgen met webbrowsers die WebSockets niet ondersteunen. Voor die clients zul je de oudere technieken moeten toepassen. Hier is SignalR nu heel handig in.


SignalR (R = Realtime) is een toolkit waarmee men real-time webapplicaties kan maken. Het is op zich niet nieuw. SignalR was al een tijdje via Nuget te krijgen en met de Visual Studio 2012.2 update waren ook de templates beschikbaar. De kracht van SignalR zit hem in het gegeven dat het helemaal gebouwd is om snelheid en support. In de basis zal SignalR gebruik maken van WebSockets, maar als die niet voorhanden zijn, zal SignalR moeiteloos omschakelen naar Comet technieken, zoals pushlets en long polling.

Hoogste tijd om SignalR eens in de praktijk te testen. Hiervoor heb ik in Visual Studio 2013 Preview eerst een leeg MVC-project aangemaakt. De volgende stap is een SignalR Hub class toevoegen aan het project. Dit kan het best via het contextmenu/Add New Item (afbeelding 1). 

Afbeelding 1. De SignalR template.

De template zal ook de nodige referenties leggen en wat Javascripts toevoegen. De (gemodificeerde) genereerde class zie je hieronder.

public class MySignalRHub : Hub
{
    public void Verstuur(string message)
    {
        Clients.All.straalUit(message);
    }
}
MySignalHub is een class die erft van de class Hub, een class uit de SignalR bibliotheek. De Hub class is eigenlijk de service waar alle commando's binnenkomen. De Verstuur methode bevat een dynamische aanroep (straalUit) op de SignalR property Clients.All. Het aparte van deze methode is dat hij niet bestaat. Je kunt hem dus noemen zoals je wilt en argumenten specificeren die je wilt. Geloof het of niet, de service is nu gereed. Nu moeten we alleen nog een url voor de service specificeren. Dat doe je in de Global.asax, in de Application_Start methode via de extensie MapHubs die standaard de route "/signalr" aanmaakt.

protected void Application_Start()
{
    RouteTable.Routes.MapHubs();

    AreaRegistration.RegisterAllAreas();
    RouteConfig.RegisterRoutes(RouteTable.Routes);
}
Aan de servicekant ben je nu helemaal klaar. Helaas bleek in de preview van Visual Studio 2013 de extensie MapHubs onvindbaar. Na het verwijderen van SignalR en opnieuw toevoegen in Nuget, bleek dat probleem opgelost.

Het clientgedeelte is niet veel lastiger. Je voegt eerst de volgende javascripts toe

<script src="~/Scripts/jquery-1.6.4.min.js"></script>
<script src="~/Scripts/jquery.signalR-1.1.2.min.js"></script>
<script src="/signalr/hubs"></script>
De laatste referentie naar "/signalr/hubs" zal een javascript opleveren dat een aantal handige objecten bevat. Die objecten zijn gegenereerd op basis van jouw Hub class en verdient daardoor dan ook de naam Hub-proxy. Hieronder staat de rest van de client implementatie waarbij #message een textbox is, #send een button en #values een leeg <ul> element.

<script type="text/javascript">
    $(function ()
    {
        var proxy = $.connection.mySignalRHub;
        proxy.client.straalUit = function (message)
        {
            $('<li/>').appendTo("#values").text(message);
        };

        $.connection.hub.start().done(function ()
        {
            $('#send').click(function ()
            {
                proxy.server.verstuur($('#message').val());
                $('#message').val('');
            });
        });
    });
</script>
De variabele "proxy" is een instantie van de gegenereerde Hub-proxy mySignalRHub (die niet geheel toevallig ook de naam van de Hub draagt). Merk op dat de methodenamen uit de Hub-class ook netjes zijn overgenomen. Voor de client is dit alles wat je hoeft te doen. 

SignalR is een prachtig tool om real-time webapplicaties te bouwen. Het neemt een heleboel complexiteiten uit handen. Door te erfen van de Hub-class, kunnen we vrij eenvoudig services maken die, naast het onderhouden van de verbindingen, ook nog eens de aangemelde webbrowsers bijhoudt. Als alternatief voor de Hub-class kun je ook erfen van de PersistantConnection class, die basaler is dan de Hub class, maar wel meer controle geeft.
Wanneer het op schaalbaarheid aankomt, laat SignalR zich niet onbetuigd. Met evenveel gemak kan SignalR inhaken op Windows Azure Service Bus (bijvoorbeeld via Topic/Subscription) waardoor het geheel ook in Windows Azure goed draait (hoe dat moet, zie je in deze deze blog).

Ik kan niet anders zeggen dat de makers van SignalR een erg mooi product hebben afgeleverd. Ooit heb ik een multi-user game geschreven op basis van WebSockets. Als ik toen van SignalR had geweten, had mij dat veel tijd en moeite gescheeld.

Meer informatie over SignalR:

woensdag 10 juli 2013

Less - Dynamic Stylesheets in ASP.NET MVC 5

Een paar weken geleden is de eerste preview van Visual Studio 2013 uitgekomen. Over een aantal verbeteringen heb ik in mijn vorige blog al geschreven. In deze preview kunnen we ook kennis maken met ASP.NET MVC 5. Deze versie ondersteunt een aantal handige tools, zoals Twitter Bootstrap, SignalR, CoffeeScript en Less. Over Less wil ik het in deze blog hebben.
Al tijden gebruiken webontwikkelaars Cascading StyleSheets (css) voor het uiterlijk van webpagina's. Je hebt html dat aangeeft wat er op de pagina komt te staan en css dat verantwoordelijk is hoe de inhoud van de pagina eruit komt te zien. Hierbij moet je denken aan kleuren, lettertypes, afmetingen en allerlei gelikte effecten. Het grote nadeel van css is dat het vrij statisch is. In de praktijk resulteert dat in veel dubbele code. Natuurlijk kan een handig css-schrijver veel van deze problemen omzeilen, maar helaas is niet iedereen een ster in css. Met Less kunnen je als het ware css programmeren. Hieronder een voorbeeld dat het nut van Less duidelijk maakt.

.style1
{
    background-color:#7F34D3;
}

.style2
{
    color:#7F34D3;
}

.style3
{
    border: 0.2rem solid #7F34D3;
}

Natuurlijk is dit een nogal absurd voorbeeld, maar het komt vaak voor dat kleurcodes her en der in stylesheets opduiken. Ga die later dan maar eens aanpassen. Bovendien zegt #7F34D3 natuurlijk helemaal niets.
Met Less zou hetzelfde script er als volgt uitzien.

@paars#7F34D3;

.style1
{
    background-color:@paars;
}

.style2
{
    color:@paars;
}

.style3
{
    border: 0.2rem solid @paars;
}

Het eerste dat opvalt, is het statement @paars. Dit is in Less een variabele. Achter de ":" staat dan de waarde van die variabele. Merk op dat de variabele @paars nu overal gebruikt kan worden hetgeen de leesbaarheid en het hergebruik aanzienlijk bevordert.

Natuurlijk begrijpt een browser helemaal niets van dat gebrabbel. Vandaar dat er een compiler aanwezig moet zijn die dit alles vertaalt naar echt css. Deze compiler heb je in twee varianten: Een JavaScript versie voor de client en eentje voor op de server. Om de serverversie te gebruiken, moeten we eerst een compiler downloaden. Dat kan het eenvoudigst via nuget. De benodigde compiler voor .NET heet dotless. Nuget zal ook de benodigde referenties (dotless.Core) leggen en de web.config in orde maken. Hieronder zie je de wijzigingen die nuget maakt (andere zaken zijn eruit gelaten).

<configuration>
  <configSections>
    <section name="dotless" type="dotless.Core.configuration.DotlessConfigurationSectionHandler, dotless.Core" />
  </configSections>
  <system.web>
    <httpHandlers>
      <add path="*.less" verb="GET" type="dotless.Core.LessCssHttpHandler, dotless.Core" />
    </httpHandlers>
  </system.web>
  <system.webServer>
    <handlers>
      <add name="dotless" path="*.less" verb="GET" type="dotless.Core.LessCssHttpHandler,dotless.Core" resourceType="File" preCondition="" />
    </handlers>
  </system.webServer>
  <dotless minifyCss="false" cache="true" web="false" 
               handleWebCompression="false" />
</configuration>

Belangrijk hierbij zijn de httpHandlers waarbij de extensie .less wordt gekoppeld aan de compiler. Wanneer er een request met een .less extensie binnenkomt, zal het .less-bestand gecompileerd worden en het resultaat (puur css) wordt naar de client gestuurd. Bij het dotless element kun je verder nog aangeven of het script gecomprimeerd en/of gecached moet worden. Het attribuut handleWebCompression is nodig omdat het anders niet werkt in Visual Studio 2013.

De infrastructuur is nu in orde. Tijd om Less te gebruiken. Aan het webproject voegen we een "LESS Style Sheet" toe via het contextmenu "Add New Item" (afbeelding 1).


Afbeelding 1. Een Less bestand toevoegen.
Laten we eens het eerdere Less-script in een webpagina hangen. Dit gaat op dezelfde manier als bij normale css-bestanden, alleen verwijs je nu naar het .less-bestand.


<link href="~/Content/test.less" rel="stylesheet" />

In afbeelding 2 is het resultaat te zien.


Afbeelding 2. Less in action.
Een ander krachtig concept in Less is Mixings. Mixings kun je het best vergelijken met functies. Het is een verzameling css-eigenschappen die je in andere css-definities aanroept. 

@paars : #7F34D3;

.style1
{
    color:@paars;
}

.style2 (@radius, @color: @paars)
{
    border.2rem solid @color;
    border-radius@radius
}

.style3
{
    .style1;
    .style2(10%);
    opacity:.5;
}
.style1 en .style2 zijn functies (mixins). In .style2 zie je ook het gebruik van parameters (@radius en @color), met @color een optionele parameter. In .style3 worden .style1 en .style2 aangeroepen. Het uiteindelijke resultaat hiervan is hieronder weergegeven.


.style1
{
    background-color#7f34d3;
}

.style2
{
    color#7f34d3;
}

.style3
{
    color#7f34d3;
    border0.2rem solid #7f34d3;
    border-radius10%;
    opacity.5;
}
Less beschikt ook over een aantal operatoren, zoals "+", "-", "*" en "/". Daarbij wordt eventueel gepeuter met eenheden uit handen genomen. Hieronder zie je een aantal voorbeelden.

@screen_width400px;
@box_height@screen_width/4;
@green:#0f0;
@red:#f00;

#container
{
    height@box_height;
}

    #container .small
    {
        float:left;
        min-width: (@screen_width/4);
        background-color:@green;
    }

    #container .medium
    {
        float:left;
        min-width: (2 * (@screen_width/4));
        background-color:@red;
    }

Wanneer dit script door de less-compiler wordt getrokken, leidt dat tot het volgende css:

#container {
  height100px;
}
#container .small {
  floatleft;
  min-width100px;
  background-colorlime;
}
#container .medium {
  floatleft;
  min-width200px;
  background-colorred;
}

In Less heb je de beschikking over guards. Guards kun je zien als condities, zoals je die ook in if/else instructies tegenkomt. Hiervoor wordt het speciale sleutelwoord "when" gebruikt. Uiteraard kunnen meerdere condities gespecificeerd worden. Voor een "OR" gebruik je dan de komma "," en voor de "AND" het sleutelwoord "and". Ook "NOT" wordt ondersteund. Hieronder volgt een less-script dat laat zien hoe guards werken.

@screen_width400px;
@green:#0f0;
@red:#f00;

.container (@width) when (@width > 100) and (@width < 600)
{
    color:@green;
}
.container (@width) when (@width =< 100), (@width >= 600)
{
    color:@red;
}

#block1
{
    .container(800px);
}
#block2
{
    .container(500px);
}

Dit script resulteert in het volgende css:

#block1 {
  background-colorred;
}
#block2 {
  background-colorlime;
}
Natuurlijk biedt Less nog veel meer functionaliteiten. Zo kun je namespaces definiëren waarin je mixins plaatst, er is een grote set aan voorgedefinieerde functies en je kunt zelfs javascriptfuncties door Less laten uitvoeren, hoewel dat sterk afgeraden wordt. Meer hierover op de website van Less.

Less is een sterk tooltje waarmee css wordt gegenereerd. Alles wat je in less kunt, zou je natuurlijk ook zonder less kunnen doen. De kracht van Less zit echter in het hergebruik binnen css en de structurering van de code die in css erg gecompliceerd kan zijn. Bovendien kunnen less-scripts opgenomen worden in bundles, een techniek in ASP.NET waarmee meerdere scripts tot één groot script wordt gebundeld, daarmee kostbare round trips besparend. Kortom, een aanrader. 

woensdag 3 juli 2013

Visual Studio 2013

Ruim tien jaar geleden maakte ik voor het eerst kennis met .NET. Het was de allereerste versie: .NET 1.0, voor een nieuw op te zetten CRM-applicatie. Aanvankelijk wilde ik Java hiervoor inzetten omdat .NET zo nieuw was en zichzelf nog moest bewijzen. De eigenaar van het bedrijf vond .NET marketingtechnisch "beter bekken". Met een verantwoordelijkheid minder ben ik toen aan de slag gegaan met .NET 1.0 en de daarbij behorende Visual Studio 2002. Voor die tijd behoorlijk gelikt, maar vergeleken met de hedendaagse versies wel erg "clunky". Na Visual Studio 2002 kwam Visual Studio 2003, gevolgd door Visual Studio 2005, 2008, 2010 en Visual Studio 2012 (afbeelding 1).


Afbeelding 1. Good old Visual Studio 2012.
Visual Studio 2012 oogt nogal saai. Weinig kleur en lastig te zien waar het scherm nu begint of eindigt, maar werkt verder prima. Kennelijk jeukten de handen van het Visual Studio team, want inmiddels is de eerste preview van Visual Studio 2013 al weer gelanceerd. Reden om eens een kijkje te nemen.

Het eerste dat opvalt, is dat de kleuren weer terug zijn. Sterker nog, je kunt kiezen uit drie verschillende thema's: Blue, Light en Dark. Wanneer je Light kiest, krijg je zo'n beetje de look en feel zoals bij Visual Studio 2012. Alles lijkt één geheel te vormen. Met het thema Blue zijn de menu's en titel bars duidelijk onderscheidbaar (afbeelding 3) en voor de nachtbrakers hebben ze een Dark thema toegevoegd (afbeelding 2)


Afbeelding 2. Visual Studio in de nachtstand (thema: Dark).
Kleurtjes en thema's zijn allemaal mooi en aardig, maar er moet ook mee gewerkt worden. In dat opzicht zitten er een aantal interessante toevoegingen in Visual Studio 2013. In afbeelding 3 zie je een paar leuke functionaliteiten. Boven definities (class, method, property etc) kun je nu zien welke code de betreffende definitie gebruikt. Het beperkt zich vooralsnog tot verwijzingen binnen dezelfde assembly, maar wel handig als je aan de grote voorjaarschoonmaak in de code begint. Als voor de betreffende definitie ook nog eens een unit test aanwezig is, zie je dat ook meteen terug inclusief het resultaat van de unit test.
Persoonlijk ben ik bijzonder gecharmeerd van de vernieuwde scrollbar. In plaats van een saaie grijze balk wordt nu de gehele code in de scrollbar geprojecteerd. Middels een soort van vergrootglas (scrollbar preview) kun je stukken code elders in het bestand bekijken zonder de code verschuiven.


Afbeelding 3. Een aantal nieuwe functionaliteiten in de editor.
In Visual Studio heb je al lange tijd de "Go to definition" optie waarmee je snel naar andere definities kunt springen. Nadeel is wel dat je uit je werkvenster bent. In Visual Studio 2013 zit nu een heuse gluurfunctie (Peek definition) waarmee je de definitie in jouw werkvenster te zien krijgt (afbeelding 4). Vanuit dit gluurvenster kun je weer verder gluren waarbij de navigatiegeschiedenis netjes wordt bijgehouden.


Afbeelding 4. Peek Definition. Een zeer handige functionaliteit.
Uiteraard zijn er nog veel meer handige toevoegingen, maar daarvoor verwijs ik naar de presentatie van Cathy Sullivan.


Naast Visual Studio 2013 is ook een nieuwe versie van het .NET framework uitgebracht. .NET 4.5.1 is een in-place update. Dat houdt in dat de installatie van .NET 4.5.1 de oude versie 4.5 overschrijft. Een gedurfde onderneming met de in-place update van versie 4.5 nog zo vers in het geheugen. Zo'n minimale versieverhoging doet weinig spectaculairs vermoeden. De meeste verbeteringen zitten dan ook in de debugger. Vanaf Visual Studio 2005 was het al mogelijk om tijdens debuggen code aan te passen (Edit and Continue). Dit gold echter alleen voor 32-bits applicaties. Acht jaar later, na lang aandringen door de gemeenschap, kan dit nu ook met 64-bits applicaties.
Wat ik persoonlijk erg handig vind, is het bekijken van de resultaten van geneste aanroepen. Bekijk het volgende stukje code eens

int result = SomeCalc(4 * OtherCalc(24 + YetAnotherCalc(3)));
Als we de uitkomsten van OtherCalc en YetAnotherCalc wilden inspecteren, waren we eigenlijk veroordeeld tot de volgende herschrijfactie.

int res1 = YetAnotherCalc(3);
int res2 = OtherCalc(res1);
result = SomeCalc(res2);

res1 en res2 konden vervolgens geïnspecteerd worden. Met .NET 4.5.1 hoeft dit gelukkig niet meer. Nu kunnen we de tussentijdse resultaten, gedecoreerd met sierlijke pijltjes, in het "autos" windows bekijken (afbeelding 5).


Afbeelding 5. De tussentijdse resultaten van methodes in een geneste aanroep
Een andere beduidende verbetering vind ik de ADO.NET connection resiliency. Dat klinkt ingewikkeld genoeg om nader te bekijken. Wanneer je een verbinding maakt met een database, die op een andere machine draait, ben je afhankelijk van de verbinding tussen de machines. Wanneer die verbinding verbroken wordt, resulteert dat in een fraaie exceptie (die meestal niet verwacht is waardoor de eindgebruiker ermee opzadeld wordt). Om dit af te vangen, moest je vaak lastige retry strategieën implementeren. Op LAN-netwerken kwam zo'n netwerkonderbreking niet zo vaak voor, maar met de groeiende populariteit van Windows Azure Sql Database wordt dit probleem realistischer dan ooit. In .NET 4.5.1 is dit nu opgelost met ADO.NET connection resiliency. Wanneer een verbinding verbroken is, kan ADO.NET de verbinding zelf weer herstellen.

Tot zover een aantal verbeteringen die mij het meest aanspreken. Meer verbeteringen zijn te bewonderen in de presentatie van Habib Heydarian op Channel 9

maandag 1 juli 2013

Elastic Computing in Windows Azure

Afgelopen donderdag was ik op kantoor bij besteproduct te Arnhem om te werken aan het gedistribueerde cache systeem van Windows Azure. We waren net live gegaan met de frontend van besteproduct, die nu ook in Windows Azure draait, maar het handmatig cachen verliep niet helemaal volgens verwachting. Tijdens mijn onderzoek viel het mij ineens op dat er iets gewijzigd was bij de Cloud Services. Het menu-item "SCALE" had het achtervoegsel "preview" gekregen. Vreemd want dat scale zat er al lang in. Daar kon je instellen hoeveel instanties van jouw website er in de lucht moesten zijn. Nadere inspectie leverde een nieuwe functionaliteit op: autoscale (afbeelding 1)


Afbeelding 1. Nieuw bij Cloud Services: De autoscale optie.
Het zal toch niet waar zijn?!?! Windows Azure is nu uitgerust met een heuse autoscaler, waarover ik een tijdje terug in een blog berichtte. Toen vermeldde ik ook al dat er commerciële autoscalers in omloop waren. Die zullen deze recente ontwikkeling niet echt op prijs stellen. Persoonlijk vind ik deze functionaliteit een logisch gevolg en verbaas mij erover dat dit er al niet veel eerder in zat.

Nog even een korte toelichting op de meerwaarde van deze functionaliteit (meer details in mijn blog Elastic Computing). De toegevoegde waarde van Windows Azure zit hem in het gegeven dat je moeiteloos meer (virtuele) servers kunt inschakelen wanneer dat nodig is en ze net zo eenvoudig weer kunt verwijderen. Met eigen servers is dat, vanwege contractuele afspraken, niet zo eenvoudig. Je kunt machines bijhuren/kopen, maar je komt er niet zo gemakkelijk meer vanaf. In Windows Azure kun je op ieder tijdstip machines toevoegen of verwijderen. En dat in een fractie van een paar minuten. Met elastic computing kun je dit op- of afschalen zelfs automatiseren op basis van het resourcegebruik, zoals processorbelasting en geheugengebruik. Dit automatiseren kun je zelf doen of je koopt een programmaatje dat dat doet. Nu is het dus onderdeel van Windows Azure (zij het een preview)

In afbeelding 1 zie je dat autscale standaard uit staat en dat je de keuze hebt uit schalen op basis van processorgebruik (CPU) of op basis van een wachtrij (QUEUE). Wanneer we CPU selecteren, krijgen we ineens een heleboel opties te zien (afbeelding 2)


Afbeelding 2. De extra opties wanneer we schaling op basis van CPU kiezen.
Allereerst kunnen we de "Instance Range" instellen. Hier bepalen we hoeveel instanties (virtuele servers) er minimaal moeten en maximaal mogen draaien. Vervolgens stellen we de "Target CPU"  in. Hier geven we het gebied op waarbinnen het gemiddeld processorgebruik moet liggen. Op basis van deze waarden zal Windows Azure gaan schalen. Wanneer de waarde beneden de onderwaarde komt, zal er afgeschaald worden en wanneer de waarde hoger dan de bovenwaarde ligt, zal er een opschaling plaatsvinden. Vervolgens kun je aangeven met hoeveel instanties er telkens opgeschaald (Scale up by) wordt. Omdat schalen tijd kost, kun je ook aangeven na hoeveel minuten er opnieuw geschaald mag worden. Hetzelfde kun je ook instellen voor het afschalen (Scale down by). Vergeet niet op de listig verborgen "Save" knop onderin beeld te drukken.
De eerste test was ietswat merkwaardig. Initieel begonnen we met twee instanties en toen we de autoscale activeerde, zaten we op nog maar één instantie, merkwaardig als de minimale hoeveelheid instanties op twee is afgeregeld. Twintig minuten later stond hij gelukkig weer op twee. Geen reden tot paniek dus. 

De scale optie "QUEUE" zal schaling realiseren op basis van het aantal queueberichten dat een instantie kan afhandelen. Wanneer we "QUEUE" selecteren, krijgen we het venster uit afbeelding 3


Afbeelding 3. De schaalopties wanneer we schaling op basis van queue selecteren.
Hier kunnen we wederom aangeven hoeveel instanties er minimaal en maximaal in de lucht mogen zijn. Vervolgens moeten we aangeven welke queue bekeken moet worden. Daarvoor selecteren we eerst een storage account, waarin de queue gedefinieerd is, en vervolgens de queue zelf. Target per machine is een belangrijke. Hier geef je op hoeveel queueberichten een machine maximaal kan afhandelen. De berekening is eenvoudiger dan je in eerste instantie zou vermoeden. Windows Azure bekijkt hoeveel berichten er in de queue staan en deelt deze door het aantal instanties dat momenteel draait. Is de uitkomst groter dan de ingestelde target-per-machinewaarde, dan zal er een opschaling plaats vinden. Wanneer de uikomst kleiner is, vindt er een afschaling plaats. Wederom kun je aangeven met hoeveel instanties er op- of afgeschaald wordt en na hoeveel minuten.

De autoscaler is een zeer welkome aanwinst in de cloudservices. De vraag is natuurlijk hoe lang deze optie gratis blijft. Persoonlijk zou ik ook op geheugengebruik willen schalen, maar op basis van CPU lijkt mij een goede start. Bij schaling op basis van de queue vind ik het jammer dat je geen queue uit de service bus kunt opgeven. Wellicht komt dat later nog. Het is tenslotte nog een preview. Het begin is er in ieder geval.