De reden waarom je twee instanties van een Windows Azure Service nodig hebt, is om een optimale beschikbaarheid van je website te garanderen. Ten eerste omdat de Windows Azure fabric zomaar kan bepalen, dat jouw instantie van een service moete verhuizen binnen het DataCenter. De reden kan zijn kapotte hardware of instabiliteit van je service. Door twee instanties is je site netjes beschikbaar tijdens deze verhuizing.
Ook zelf kun je daar mooi voordeel van hebben. Als je een site of Hosted Service upgrade, dan wil je niet dat je site niet meer beschikbaar is. Helaas kent Windows Azure niet iets als een ‘Site is temporary out of order’- sign, maar krijg je als klant gewoon een vette 404 voor je kiezen. Daarom is het wel mooi, dat Windows Azure zorgt voor de juiste beschikbaarheid.
Het uploaden van de package.
De eerste role wordt geupdate.
Daarna de tweede role.
Mooi he. Deden onze on premises systeembeheerders ook maar zo hun werk 😉
LET OP: Dit gaat niet altijd goed. Als je Hosted Service gebruik maakt van een Database en bij de update van de Hosted Service horen database wijzigingen (met name Model wijzigingen), dan moet je daar een goede strategie voor bepalen. Bijvoorbeeld de wijzigingen in de Database pas uitvoeren als de Hosted Service volledig is geupgrade, maar dan moet de nieuwe versie om kunnen gaan met het niet aanwezig zijn van deze wijzigingen. Hoe dan ook food for Thought!
