SQL Azure Databases

Als ik een sessie doe over Windows Azure, dan komt daar ook SQL Azure bij ter sprake. Bijna altijd komt er een opmerking over de maximale grootte van een SQL Azure database.

Even een klein recap. Er zijn 2 edities van SQL Azure beschikbaar: Web en Business. Op dit moment heb ik nog geen verschillen tussen die twee kunnen ontdekken, maar wellicht gaat dat ooit nog komen. De Web editie is er alleen als 1 Gb en 5 Gb. De Business editie begint bij 10 Gb en eindigt bij 50 Gb, in stappen van 10 Gb. Vanaf december zal het maximum overigens liggen op 150 Gb (zie hier). De kosten van een SQL Azure database worden op dag basis bepaald. Het is geen lastig rekenmodel.

Op dit moment is het maximum van een SQL Azure database dus 50 Gb. Tijdens veel van mijn sessie hoor ik dan, dat mensen dat weinig vinden. In eerste instantie dacht ik dat ook, maar ik heb mijn menig bijgesteld.

Mijn laatste grote (niet Windows Azure gerelateerde) opdracht was een project bij een overheidsinstelling. Bij dit project maakte we gebruik van SQL Server databases. De beheerders hadden daar geen probleem mee, maar wel met de groei. Met de groei van de databases zouden ook de storage vraag en de backup tijd toenemen. Op zichzelf niet zo erg, maar om hun SLA’s te kunnen halen moest de backup wel in een bepaalde tijd geklaard zijn. En voor een aantal fikse databases was dat lastig. Uiteindelijk zijn er schoningsscripts gebouwd en is er efficiënter met de databases omgegaan.

En deze situatie geldt ook gewoon voor SQL Azure. We zullen weer efficienter met de databases om moeten gaan. Met wat we er in stoppen en wat we bewaren etc. Tenslotte zullen alle kosten gerelateerd moeten zijn aan een business case / behoefte. Als dat niet het geval is, dan zul je een oplossing moeten verzinnen.

Tijdens mijn praatjes geef ik ook altijd aan, dat wij als developers in de afgelopen jaren nogal gemakzuchtig zijn geworden. Disks / CPU en memory kosten bijna geen drol en zijn er bijna in overvloed. We werden niet gedwongen om na te denken, zoals we in de begintijd met schaarste wel deden. Veel oudere ICT-ers kennen dit nog wel, toegangspadanalyses etc.

Kijk dus goed naar wat je in de database wilt bewaren en opslaan. En kijk of er niet een ander wellicht goedkoper alternatief is. Windows Azure storage is erg efficient voor blobs etc. Windows Azure storage tables is erg efficient voor niet relationele data. Dus deze zaken hoef je niet in een SQL Azure database op te slaan.

En als je dan toch iets in een SQL Azure database gaat opslaan, denk dan ook na over schoningstermijnen en schoningsscript. In mijn blogpost van een aantal maanden geleden beschrijf ik een alternatief.

Windows Azure en Cloud computing in zijn algemeenheid dwingen ons om kosten en daarmee vaak ook over efficiëntie na te denken. Dat is geen bedreiging dat is een kans! Je zou het nu ook al moeten doen.

Windows Azure Storage vs Local Storage

Als ik sessies doe over Windows Azure, dan zeg ik altijd dat wij als software engineers/architecten weer goed moeten nadenken over kosten. Want Windows Azure mag dan misschien duurder lijken in vergelijking met een on premise situatie, maar dat hebben we als ontwikkelaars ook gewoon zelf in de hand.

Oke, de verschillende VM’s hebben natuurlijk vaste kosten. En zoals ik in mijn vorige blogpost uitgelegd hebt, kun je daar ook verstandig mee omgaan door rollen te combineren. Hierbij een overzichtje van de standaard kosten van een VM per maand. Let op deze tabel geldt voor 1 instantie. Kijk hier voor de kosten van meerdere instanties.

     

month

VM

Storage

per hour

Extra Large

2040

0.96

700.80

Large

1000

0.48

350.40

Medium

490

0.24

175.20

Small

225

0.12

87.60

Extra Small

20

0.05

36.50

Het combineren van rollen kan dus voordeel opleveren, maar ook efficiënt programmeren kan geld besparen. Zoals dit voorbeeld (code voorbeeld overgenomen van Maarten Balliauw).

clip_image002

Onnodig om te vertellen dat hiermee CPU klok tikken te verdienen en dus geld te besparen is.

Een besparing kunnen we ook bewerkstelligen door efficient om te gaan met lokale storage. De storage in een VM is in eerste instantie bedoeld voor je applicatie of website. Uiteraard kun je plaatjes voor je website ook op deze lokale disk kwijt, maar realiseer je dan twee dingen. Ten eerste deze storage kan niet onder een CDN regime vallen. Daarmee moeten je gebruikers altijd dezelfde afstand afleggen naar het plaatje, ook als ze het Windows Azure datacenter niet direct in hun buurt is. Ten tweede deze lokale disk in verhouding erg duur is.

In onderstaande tabel heb ik de kosten van een VM inclusief hun storage neergezet. De storage kosten zijn berekend door maand bedrag te delen door de beschikbare storage.

     

month

storage costs

VM

Storage

per hour

GB / month

Extra Large

2040

0.96

700.80

0.34

Large

1000

0.48

350.40

0.35

Medium

490

0.24

175.20

0.36

Small

225

0.12

87.60

0.39

Extra Small

20

0.05

36.50

1.83

Voor de criticasters die zeggen dat de VM prijs niet volledig bepaald wordt door de storage, maar ook door de CPU/Mem/Network. Stel dan eens dat deze verhouding de helft is, dan nog is local storage voor de kleine VM’s nog steeds duur.

     

month

storage costs

VM

Storage

per hour

GB / month

Extra Large

2040

0.96

350.40

0.17

Large

1000

0.48

175.20

0.18

Medium

490

0.24

87.60

0.18

Small

225

0.12

43.80

0.19

Extra Small

20

0.05

18.25

0.91

Maar realiseer je dan ook, dat je van een instantie altijd minimaal twee nodig hebt. Dat de local storage dan ook verdubbeld en dus de kosten ook.

Uiteraard kun je mijn berekening bediscussiëren. Het punt dat ik wil maken, is het feit dat wij als ontwikkelaars en architecten wel degelijk invloed hebben op de kosten van een Windows Azure applicatie.

Maar laat opmerkingen horen in de remarks. Thanks!

Combineren WebRole en WorkerRole Windows Azure

Soms is het kosten efficiënt om een WebRole en een WorkerRole te combineren. Op deze manier nut je de volledige capaciteit van de VM/Server uit, zonder dat je extra instanties nodig hebt.

Stel je het volgende scenario voor. Je hebt een WebRole met 2 Websites en je hebt een WorkerRole. Maar nu blijkt dat de WorkerRole met een minder grote VM had kunnen draaien. Dan kun je uiteraard een kleinere VM kiezen, maar als je al een XS gekozen hebt?

Sterker nog, de WebRole met zijn 2 WebSites gebruikt ook niet de volle kracht van de VM.

clip_image002_thumb1

Dan lijkt het interessant om beide rollen samen te voegen.

clip_image004_thumb

Dat samenvoegen gaat simpel, door de WorkerRole logica te verplaatsen naar de WebRole. Dat kan door de methode Run() toe te voegen aan de WebRole.cs.

Let op: je zult eventuele specifieke settings uit app.config of Role configuration wel moeten verplaatsen van WorkerRole naar de WebRole web.config of Role configuration.

public override void Run()
{
  Trace.WriteLine("WorkerRole entry point called", "Information"
);
  while (true
)
  {
    <own logic>

    Trace.WriteLine("Working", "Information"
);
  }
  base.Run();
}

Hier een meer uitgewerkt voorbeeld.

clip_image006_thumb1

In de Local Development Emulator zie je dan ook daadwerkelijk de Traces langs komen. Terwijl de website gewoon in de browser geopend is en volledig functioneel. Uiteraard merk je als gebruiker van de Website niets dat er op de achtergrond nog een ander proces hard aan het werk is. Als je dat wel merkt, dan hebben we het daar zo over.

clip_image008_thumb

De andere kant om kan natuurlijk ook. Je hebt een WorkerRole en wilt daar een WebRole bijzetten. Je zult dan wel logica voor het starten van de website moeten inbouwen. De eerste kant uit is het eenvoudigst.