bloghoved rene løhde

Windows Azure: Egnede IT opgaver

Hvilke egenskaber og hvilke IT systemer og hvilke overvejelser er de vigtigste når man taler om udvikling og drift af applikationer på Windows Azure?

I første omgang er det de emner som har karakter af generelle cloud computing egenskaber: 

Den periodiske kørsel

Denne opgave er typisk noget som økonomiafdelingen forstår betydningen af, men som de samtidigt har svært ved at acceptere ud fra et investerings- og driftsperspektiv.

I den periodiske batch kørsel bruges massive hardware ressourcer til månedlige, kvartals eller f.eks årlige jobs. I resten af perioden kan hardwaren stå næsten uberørt. Det betyder at capital expense (CapEx) på hardwaren ikke udnyttes særlig godt og at operational expense (drift - OpEx) også er tilstede enten i perioder eller hele tiden.

Eksempler på den periodiske kørsel kan være: Månedsløn, kvartalsafregning eller årsopgørelser.

Den hurtige vækst
Dette IT job er for eksempel henvendt til scenarier hvor en virksomhed har behov for at udbrede en applikation, data eller lignende eller på anden måde har brug for massive IT ressourcer, her og nu. Det henvender sig typisk til forretningsenheder som har time-to-marked for en applikation, som konkurrenceparameter. 

Det bedste eksempel jeg kender og har været involveret i er en dansk virksomhed med en globaludbredelse. Virksomheden ønskede en selvbetjeningsapplikation til deres salgskanal. Piloten kunne udføres lokalt i Danmark, dagen efter kan de skalere til de nordiske lande og dagen efter ramme hele deres globale salgskanal. 

Det uforudsete load
Er det sværeste IT job at forudsige (Duhh!). Det er de scenarier hvor IT afdelingen kun har kort tid til at reagere på nye mønstre i datatrafik, server belastning eller lignende. Det kunne være den pludseligt lækkede og kompromiterende, men uhyre populære video med fætrene Krarup og Langballe som spiser shish kebab og ryger vandpipe iført det alt for kropsnære kostume de skal have på i CPH Pride optoget, det kan være en spontant nedfalden køreledning i hovedstadsområdet som betyder at alle togrejsende i hele landet skal kigge på forsinkede tog samtidigt eller det kan være pludseligt opståede flaskehals i financielle systemer, som kræver beregningskraft her og nu.

Eksemplerne er mange, men fælles for dem er systemernes evne til at reagere og stille de nødvendige ressourcer til rådighed. 

Det forudsete load
Uforudsete IT opgaver, kan traditionelt undskyldes i IT afdelingen, men hvad med det load man godt ved kommer lige om hjørnet? De IT opgaver som man kan intet gøre for at imødegå, fordi de nødvendige ressourcer ikke er tilstede eller prioriteret.

Den 5. marts i år skrev Danmarks Radio at det var et forårstegn at Skat.dk ikke var tilgængelig. Eksemplerne på det forudsete store IT job er utallige og nyhedsmedierne skriver ofte om dem. Andre eksempler: Online billetsalg af f.eks U2 koncert, Online Pizza bestilling i forbindelse med Super Bowl, SMS afstemning ved diverse TV begivenheder...osv. 

Det semi-forudsete load
Jeg har gjort mig selv til talsmand for det semiforudsete load blandt mine kollegaer hos Microsoft. Det er fordi jeg mener der er en kategori af IT tjenester som kan kategoriseres efter deres relation til begivenheder som har egne prognoser f.eks vejret.

Det drejer sig om løsninger som skaber ekstra trafik eller ressource forbrug på samme måde som det uforudsete load. Men jeg er af den opfattelse at IT løsninger som påvirkes af f.eks vejret burde have en 3-5 dages prognose og sandsynlighed indregnet, som ikke berettigerer til stemplet 'uforudset'. Jeg trækker på smilebåndet når jeg kan læse at DMI.dk et stykke inde i snestormen installerer en ekstra server ...har de ikke læst egne prognoser ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")'

Andre eksempler er trafikinformation og forsinkelser på f.eks vej- og jernbanenettet på grund af vejret. Jeg mener også at Askeskyens hærgen i løbet af april i år og Københavnslufthavns manglende kapacitet til de rejsende er i samme kategori.

Jeg vil på ingen måde pege fingre af de folk som står bag de respektive websites som er omtalt ovenfor. Få har haft ubegrænsede ressourcer og mange har prøvet at trafikken stiger uforudsigeligt. Jeg kan sagtens genkende DMIs kommentar om at medierne fik talt snestormen den 2. februar fuldstændigt ud af proportioner. 

Sælger det?

Ovenstående er nogle af de rigtige budskaber, men er det så derfor at kunder og partnere vælger Windows Azure som cloud platform? Kun delvist ... I næste blogpost vil jeg skrive om de 6 primære grunde til at nogle vælger hosting af en applikation på Azure.

Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Daniel Møller

Hej René

Fin blogpost.
En ting der irriterer mig lidt ved Azure er at den økonomiske model virker til at være ret fokuseret på "store" virksomheder.

Jeg savner lidt et "hobby-abonnement" eller "Alpha-abonnement" (forstået som i at servicen er live, men pt. kun har et meget begrænset antal brugere og stadig regnes for værende under udvikling). Jeg har en instans idag som jeg såmænd ikke har det helt store problem med at betale de her 500kr/mnd for, men der hvor det begynder at gøre lidt ondt er når man gerne vil bruge skyen til flere projekter, som man ikke ønsker at blande sammen (og derfor gerne vil have hver sin compute instans til), så koster det pludselig 500kr/mnd pr. projekt og så begynder det at gøre en smule ondt i privatøkonomien :-)

Det jeg egentlig gerne vil opnå er at kunne dele den kerne jeg har reserveret i min compute instans imellem alle de forskellige projekter jeg måtte lave til Azure, men stadig have en logisk opdelt kodebase pr. projekt (basalt set svarende til at kunne opsætte flere websites i IIS'en på den samme server havende 1 CPU).

Det er selvfølgelig et mindrer problem når man når det punkt hvor man får reelle betalende brugere på de forskellige services, så begynder man også at få behov for CPU tiden og forhåbentlig også for skaleringen på længere sigt, men i udviklings- og opstartsfasen på specielt hobby-niveau er modellen pt. lidt hård. Jeg ved godt at man kan udvikle i simuleringsmiljøet lokalt og bare vente med at lægge det online til man er helt klar til det, men jeg tror vi er mange der godt kan lide at se og bruge vores projekter i live-kørsel imens de stadig er under udvikling, også i forhold til at få vennerne på som alpha-testere og få noget feedback og lign. og med hobby-projekter kan udviklingstiden godt trække en del ud før man når til noget der ligner et færdigt produkt der kan tjenes penge på :-)

I professionel sammenhæng har jeg også overvejet Azure til visse former for periodiske kørsler (som du selv er inde på at skyen i princippet er oplagt til), men her synes jeg at Azure igen dikterer lidt for hårdt at jeg skal rode alle mine forskellige kørsels-jobs sammen i samme "solution" hvilket ikke passer særlig godt med den SOA-baserede arkitektur vi normalt anvender, men at betale 500 kr/mnd pr. job (som kun skal bruge 10 min af den reserverede kerne om måneden) er jo det glade vanvid.
Så indtil videre har vi valgt ikke at benytte Azure til disse jobs. Der mangler måske i det hele taget et "Task-abonnement", idet disse jobs jo ikke har brug for at have en hel kerne reserveret 24/7/360 for at lave eksempelvis en daglig/ugentlig/månedlig kørsel af begrænset varighed.

Der er helt sikkert et kæmpe potentiale i Azure, men det er lidt ærligeligt at den økonomiske model er lidt begrænsende i forhold til mange mindrer/spirende/potentielle brugs-scenarier, man ender hurtigt med at betale for meget mere end man reelt har brug for sålænge projekterne ikke er store nok til at være i kategorien hvor der er behov for at skalere ud over mange servere (men disse mindrer projekter er bare stadig oplagte at køre i Azure pga. det er administrations-frit, pålideligt og at når man får brug for skaleringen, så er muligheden tilstede). Jeg håber at det er noget I er opmærksomme på og at der f.eks. bliver mulighed for at kunne køre flere projekter under samme compute instance, det ville hjælpe utrolig meget på problemet (jeg har ikke noget imod at betale 500kr/mnd - jeg har kun noget imod at skulle betale 500kr/mnd * antallet af projekter).

Med venlig hilsen
Daniel Møller

  • 0
  • 0
René Løhde

Hej Daniel,

Tak for kommentaren.

Jeg har lige for et øjeblik siden offentliggjort mit næste blogpost i serien og som du kan se og har bemærket så er segmenteringen af audience sådan at Windows Azure ikke kan konkurrere med hobby-hjemmeside hosting.

Jeg forstår udemærket dine behov og den del af udvikler porteføljen som vi misser fordi vi ikke har en (midlertidig) gratis løsning for små løsninger.

Jeg har hørt det rigtig mange gange og vi diskuterer det ofte.
Jeg vil tror at Microsoft folk hører "I skulle gøre det gratis for små projekter lige som Google" lige så ofte som Google folk hører "I skulle lave en gratis offline cloud på min laptop, som Microsoft gør".

Hvis du ikke allerede har gjort det, så kan du lade din(e) stemme(r) blive hørt på:
http://www.mygreatwindowsazureidea.com/forums/34192-windows-azure-featur...

Læg mærke til de to "top idéer".

Derudover skal du vide at du med f.eks et MSDN abonnement har adgang til 750 gratis timer på Windows Azure (svarende til 1 VM fuld tid, en måned), hvis dit hobby projekt får karakter af "opstart" så kan du komme med i Bizspark-programmet som også giver dig 750 timer pr måned.

Angående det tekniske...jeg forstår hvad du mener med flere apps på samme maskine...der er muligt, men det vil nok være at twiste brugen af Azure en smule.

Mht til dit SOA eksempel og batchjobbet. Hvis du vil undgå at betale mellem kørsler (hvilket giver god mening!) så slet VM'en(eller VM'erne) efter hver kørsel og start redeploy når det bliver nødvendigt. Du kan faktisk uploade din applikationspakke og konfigurationsfil i Windows Azure storage og loade dem derfra når servicen skal redeployes.

Du kan redeploye via web-admin-portalen, cmdlets eller med webservices API'et.

Cmdlets cmd kunne se sådan ud:
"New-Deployment -serviceName <YOUR_SERVICE_NAME_LOWER_CASE> -subscriptionId <YOUR_SUBSCRIPTION_ID> -certificate (get-item cert:\CurrentUser\MY\<YOUR_CERTIFICATE_THUMPRINT>) -slot production –package <PACKAGE_LOCATION> -configuration <CONFIGURATION_LOCATION> -label 'Månedlig Lønkørsel'"

Du kan så evt sætte det op som et remote job med en bestemt frekvens.

Lad mig vide om det giver mening...du kan evt skrive til mig og så kan vi evt tage den face-to-face eller over tlf.

--René

  • 0
  • 0
Daniel Møller

Hej René

Tak for svaret. Jeg beskæftiger mig ikke med hobby-hjemmesideudvikling, så det er ikke i den forbindelse at jeg ser muligheder i Azure.

Jeg tror også at du misforstod mig lidt for jeg er ikke ude efter at få det gratis, jeg betaler gerne 500 kr/mnd for en compute instans i Azure - det er ganske billigt sammenlignet med en hosted server.

Mit problem er hovedsageligt at 1 kerne (a 500 kr/mnd) == 1 applikation. Det er ikke noget problem sålænge man kun udvikler på én applikation, men er lidt irriterende hvis man arbejder på flere forskellige projekter parallelt. Pointen er jo at de her services ikke bruger en brøkdel af den kerne de har tilrådighed - men de skal stadig gerne være tilgængelige for requests.

Sat lidt på spidsen svarer det til at jeg kun kan installere ét spil på min spillecomputer og hvis jeg får lyst til at spille et andet spil også, så må jeg ud og købe en ny computer - selvom min oprindelige egentlig rigelig fint kunne afvikle dem begge :-)

Tak for info om periodiske kørsler og redeploy af instanser, det største problem ved det er at man så skal sikre at automatisk redeploy afvikles fra en anden pålidelig lokation, så den ikke bliver misset af en eller anden årsag :-)

Ville være rart om Azure understøttede at man kunne opsætte nogle tidspunkter hvor ens compute instans skulle starte og lukkes ned.

Men jeg er godt klar over at vi er i den spæde start af Azure og at I har været nød til at tage nogle valg for at få en v1.0 op at køre.

Forhåbentlig kommer de her ting til hen ad vejen :-)

  • 0
  • 0
René Løhde

Ja, jeg forstår og du har ret.

Måden jeg forsøger at løse det på er f.eks.
hvis man køber på abonnement kan man få Månedsprisen 750 timer ned på omkring 330 kr afhængigt af dollar kursen.

Lad os så antage at dine test og prøvekørsler ikke behøver køre hele tiden. Så kan man f.eks køre 3 VM'er i 8 timer i døgnet inden for samme abonnement.

Det kan være at applikationerne ikke behøver køre weekender og nat...osv.

På den måde kan man økonomisere med timer. Så kan man tilgengæld arbejde på "mange" projekter med hver sin VM i "arbejdstiden".

Mht antal VM pr "kreditkort" - så er der default pr. projekt -> 6 hosted servies + 5 storage services. I praksis kan du vokse dit antal service uendeligt men det kræver lidt manuelt arbejde.

Mht de automatiske redeployments... ja, du har ret i at, det som overvåger, det som overvåger, det som overvåger .... applikationen, skal være pålideligt
:-).
Der er et bootstrap problem som dog ikke er unikt for cloud.

Der er to projekter jeg har været tæt på har man valgt forskellige tilgange:

  1. Vi har lavet et projekt hos en en tysk automobilfabrikant hvis skalering sker dynamisk med overvågning af KPIer sker fra deres eget eksisterende datacenter og at man herfra skalerer automatisk.

  2. I forbindelse med BaneDanmark projektet var det min opgave i under Proof of concept at vise den dynamiske skalering. I dette tilfælde lod jeg overvågningen ske fra en selvstændig Azure VM (dvs 2 VM for ellers er der ikke 99,9% SLA) dvs en Azure hosted app overvågede en anden. (Det er ikke i drift i dag ... så bare roligt jeg har ikke noget kode i den løsning :-))

Mht til at kunne konfigurere opstart af roller så ja det kunne være et fint supplement - pls find den på det der mygreatwindowsazureidea.com og stem for eller hvis du er den første - giv det som forslag :-)

--René

  • 0
  • 0
Log ind eller Opret konto for at kommentere