“Skyet, med chance for storm”

Overvejer du eller har du flyttet dit IT i skyen?

Så gør dig selv den tjeneste, at se vejrudsigten.

Om det er Peter Tanev på TV2, på tekstTV eller app’en på din smartphone.

Det betyder ikke så meget.

Hvad der betyder noget er forudsigeligheden.

Hvor sandsynligt er det at vejrudsigten holder stik?

Spørg en hvilken som helst landbrugsarbejder og vedkommende vil sige dig, at det er en af de helt store uforudsigeligheder i jobbet.

Det kommer også til at gælde dit IT i skyen.

En svær nød, at knække. Bestemt.

Men med den rette opsætning kan du faktisk selv ændre vejrudsigten.

Og få det cloud-IT setup du og din virksomhed fortjener.

Et cloud-IT setup der ikke æder dit budget som en sulten tornado.

2. De typiske stormvejr i Cloud

Den typiske virksomhed der flytter ind i Azure vil typisk komme med det vi kalder ‘klassisk jern’. Det vil være en masse serverracks pakket med:

• Processorkerner (Virtuelle Maskiner)
• Databaser (SQL, NoSQL, m.fl.)
• Harddiske (SSD, HDD, m.fl.)

Enten fra egen (on-premise) eller lejet (hosting) kælder.

Når ‘kælderen’ rykker (læs: Migrerer) op i Azure, vil oftest være så tæt på ‘virkeligheden i kælderen’.

Virtuelle Maskiner (VM) er stort set en til en (1:1) i Azure.

Det samme gælder for SQL Database servere og harddiske (nu bare under *paraplyen ‘*Storage Accounts’).

Derfor er det disse resursetyper vi også vil gå i sømmene.

De største udgifter vil typisk findes her.

Et scenarie du kun vil se i takt med en cloud-migrering.

‍

OBS

For at få adgang til dashboard i Azure Cost Management modulet, skal du som minimum have rettigheder: ‘læs / read’ under **“Billing Data”.

Ellers vil du kun se, at du mangler rettigheder.

Se Microsoft’s egen guide til at få/give Billing Data rettigheder (læs: ‘permissions’) →

‍

2.1 Resursetyper pr. år

Helikopterperspektivet: Hvordan ser forbruget i din infrastruktur ud fra toppen?

Det er det første overblik du bør danne dig. Hvordan omkostningerne af din samlede pulje af resurser i Azure.

De seneste 12 måneder, filtreret på type.

Des flere aktive resursetyper du har, des mere regnbuefarvet vil diagrammet se ud.

Det er vigtigt at måle op imod de indledende estimater, budgetter og KPI’er i (forhåbentligt!!!) har sat op, indledningsvist.

Når du har dannet dig det overblik, skal du herefter grave dybere for at se udsving på daglig basis.

Det er mildt sagt håbløst at opnå med et 12 måneders overblik.

Det gør du ved at skrue 12 måneder ned til 3 måneder, som er det næste skridt i dit detektivarbejde.

‍

‍

📊 Seneste 12 mdr - Azure Resurse-typer

Tjekliste -> Du skal se efter:

[ ]  Hvordan det stemmer det overens med jeres estimater og budgetter?

[ ]  Hvilke resursetyper koster mest og grunde til dette?

[ ]  Er udsvingene forventelige og stabile?

‍

Se “12 Months By Resource Type →”

‍

2.2 Resursetype pr. kvartal

Med 3 måneders overblikket, filtret på resursetyper, får du mulighed for at se Azure-forbruget på daglig basis.

Hvis I migrerede til Azure for nyligt vil det typisk være her i bør starte.

Har I været i gang i længere tid giver det mening at se ned hvor udsvingene fra 12 måneders oversigten er størst.

Det I skal se efter er derfor stadig ‘stabilitet eller udsving’.

Hvis i for nyligt er migreret til Azure vil i typisk se en del ustabilitet i migrerings-perioden. Kurven vil for de fleste stabilisere (læs: ”flade ud”) efter migreringen.

Det kan være batchjobs, som får kurven til at skyde i vejret. Er de forventede eller afviger de fra jeres forventninger.

Eksempelvis har vi set fejl i scripts og konfigurationer der spammer resurserne med kald, der selvfølgelig også koster penge.

Eller er der unormal høj trafik på de forretningsapplikationer resurserne understøtter. Er VM egress (læs: data ud) af systemet forventet eller unormalt høj.

Se eksempelvis hvordan hvordan Troy Hunt’s “Have I Been Pwned” blev ‘Pwned’ af sine cloud-udgifter på dette link →

En sidebemærkning: Ofte kan man spotte mulige cyberangreb på baggrund af forbrugsmønstre som disse.

Grundlæggende skal i se efter om hvorvidt i håndterer jeres Azure resurser økonomisk smart.

‍

📊 3 mdr - Dagligt forbrug af Azure Resursetyper

☑️ Tjekliste

[ ]  Tider: Er der forbrug uden for normal arbejdstid?

• Hverdage: Før 8:00 og efter 17:00
• Weekender/helligdage/mærkedage: Skal de være tændte eller ej?
• Tidszoner: har tidszoner en betydning for om resurser skal være tændt/slukket?

[ ]  Uden for forretningsaktivitet, i hvilket omfang formår I at

• slukke for VM’er når der ikke er forretningsaktivitet
• skalere Diske ned til lavest mulige performance tier
• skalere Databaser ned til lavest mulige DTU og performance tier

[ ] Stabilitet eller afvigelser i forbrug:

• Data og trafik ud (egress)?
• Data og trafik ind (ingress)?

Vurder heraf

• Får slukket og nedskaleret jeres servere når der ikke er aktivitet på dem? (Fyraften, Weekender, Helligdage, osv.)

‍

Se 3 Months Daily By Resource Type →

‍

2.3 Virtuelle Maskiner

Den mest naturlige overgang fra 3 måneders overblikket vil være, at se på jeres Virtuelle Maskiner (VM) i Azure.

Særligt med udgangspunkt i trafik og aktivitet på de forskellige VM’er.

Ligesom før (3 måneders forbrug per resursetype) bør dit fokus være på “stabilitet eller udsving.”

Særligt forbrug uden for normal arbejdstid, på VM’er der ikke bruges i produktion.

VM’er i Azure er forholdsvist lige til at slukke når de ikke skal bruges og tændes når de skal.

Det kan være en tidsrøver, da der er ventetid forbundet med handlingen. Ligesom når du tænder og slukker din PC-, Mac-, eller Linux maskine.

Det næste du bør lede efter er hvordan forbruget på VM’er er sammensat.

Trafik ind (ingress) er gratis i Azure. Dog kun inden for din valgte region (eks. West Europe). Er trafikken på tværs af regioner (eks. West Europe til US East), så falder betalingshammeren.

Dernæst kommer førnævnte egress (data ud af Azure, til internettet) som koster afhængigt af hvor den bliver flyttet hen.

Det kan hurtigt blive et tidskrævende detektivarbejde at finde frem til ‘hvorfor’ forbruget stikker i vejret.

Et tip her er at binde VM’er sammen omkring de forretningsapplikationer og underliggende miljøer som VM’er understøtter (Governance opgave).

På den måde kan du referere tilbage til den pågælende applikationsejer og dennes afdeling/team/projekt/andet for forklaring og retfærdiggørelse.

Det sidste og også mest obskure fokuspunkt er licenser.

Jeg ved det.

Microsoft, og de fleste andre softwaregiganter, har alle dage lavet nogle mildest talt uigennemsigtige licensmodeller.

Azure er mindst ligeså. Se bare her:

I Azure kan du minimalt købe 8 OS Core licenser og du runder altid op til nærmeste 8.

Du skal derfor regne din licensmængde således:

1. 3 vCPU = 8 OS Core licenser
2. 6 vCPU = 8 OS Core licenser
3. 12 vCPU = 16 OS Core licenser

Underligt, men sandt.

‍

📊 3 mdr oversigt - Virtuelle Maskiner (VM)

☑️ Tjekliste

[ ] Datatrafik (Egress/Bandwidth) Ud - Hvor stor trafik har I ud af systemet? (Datatrafik Ud [Ingress] er gratis!)

[ ] Pris og Type pr./af Maskine?

• Hvor er omkostningerne størst?
• Overenstemmelse med trafik?
• Er der potentiale for optimering (eks. Right-sizing)

[ ] Afvigelser (‘Spikes’) på VM’er og Bandwidth

• Er der irregulære mønstre?

Vurder heraf

• Er der irregulære mønstre ift. trafik ind og, især, UD af serverne?
• HINT: Udover at spotte potentielt ‘dumme’ omkostninger, kan dette også påpege evt. angreb på jeres system (eks. DDoS)

‍

Se 3 Months Virtual Machine By Service Name →

‍

Disclaimer: Vores VM-oversigt er ikke det bedste eksempel, da vi har relativt lille trafik pr. måned. Vores udgifter ligger primært i lagring (læs: Storage) og database-services.

Iflg. Microsoft’s egne best practices, er det her du nemmest kan gøre noget ved omkostningerne.

Det er reelt set ‘bare’ at trykke på knappen.

STOP!

Inden du kaster dig over knappen, så husk at du skal gøre det på HVER VM.

Jovist, du kan scripte dig ud af det.

Men det kræver finger-spitz-gefühl, at du ved hvad du laver.

Bare for din egen skyld.

‍

2.4 Diske - Forbrug ift. Virtuelle Maskiner

“Ingen VM uden diske”. Var det ikke det Bäncke der sagde det?

Hvor om alting er, så er det ret simpelt. Der skal være lagring tilknyttet VM’er. Derfor giver det mening at du danner dig et overblik over trafikken på de diske.

I stil med VM-licenser skal du holde øje med din disk-tiering.

En del af Azure's VM typer kommer med midlertidig storage (læs: lager). Typisk vil man koble permanent lagerenhed(er) på given VM.

Migrerer eller har du migreret fra et virtualiseret miljø, eks. fra VMware, så vil jeres disk-partitioner sikkert have forskellige størresler.

Vi ser mange der har delt 1 Tb (1000 Gb) diske op i 2-5 virtuelle diske (eks. 5 x 200 Gb)

Sagen er, I Azure (og andre clouds) betaler du ikke for den egentlige kapacitet pr. Gb. Men for næste størrelse.

Derfor, hvis du har 5 x 200 Gb virtuelle diske du migrerer i skyen, så betaler du ikke for 200 Gb.

Nej, du betaler for 256 Gb.

Ligesom når du vælger lagerplads på din PC, Mac, smartphone, tablet, osv.

Tieringen i Azure er derfor lig med 4² .

• 4 Gb
• 8 Gb
• 16 Gb
• ->
• 32000 Gb (32 Tb)

Nu er spændet fra 200 til 256 ikke så voldsomt.

Men sig at du har lavet en 300 Gb partition. Der betaler du for 512 Gb.

Og hvis 1250 Gb = 2000 Gb betaling.

Det synes nemt. Men vi ser desværre rigtig mange begå fejlen og blive bonget for meget på deres lager.

Særligt når de ikke engang udnytte max kapacitet på diskene.

Dernæst har du 'in-ud operationer' på diskene (IOPS). De koster også (dog gratis på Premium tiers).

Så er der redundans og backup.

Det kommer vi til i den efterfølgende sektion.

‍

📊 3 mdr - Forbrug pr Disk (ift. VM)

☑️ Tjekliste

[ ] Typer vs. Pris af diske på tenant (din infrastruktur)

• Storage (Kapacitetsmængde)
• Tiers (Performance)

[ ] Mængden og frekvensen af operationer (IOPS) på dine diske (særligt læs/write kan blive dyrt)

[ ] Irregulære mønstre på særligt læs/write handlinger på diskene?

• Her kan fejl konfigurationer eller kode/script-bugs være syndere, hvis eks. automatik lagrer uforholdsvis meget data (tilbage til HIBP eksemplet tidliger→)

‍

Vurder heraf

• om du har over- eller under-provisioneret dine diske
• hvor du skal fokusere dine optimeringer

‍

Se 3 Months Disks By Meter →

‍

Herfra bør du dykke ned i “3 måneders oversigt på Storage Accounts.”

Det tager vi i næste overbliksbillede.

‍

2.5 Storage Accounts

Sidst, men ikke mindst, i denne omgang, har vi Storage Accounts.

Kort fortalt er Storage accounts en samling af disk-enheder (HDD, SSD, Blob, FileServer, osv.)

Her skal du ikke se efter hvilke enheder du har og hvad fordelingen er på de forskellige typer af diske.

I stedet skal du se efter hvad der sker på tværs af dine diske (Storage Accounts).

Altså hvad det operationer koster. Nærmere bestemt skal du se efter operations-omkostninger ift.:

Hot, Cold, Archive storage

1. Hot = Højere performance + højere pris
2. Cold = Lavere performance + lavere pris
3. Archive = Laveste performance + laveste pris

Sjældent ses det, at virksomheder danner sig et overblik og tager stilling til aktiviteten på deres lagerplads.

Og det er forståeligt.

Det kræver nemlig Premium lagringsenheder for at få den indsigt.

Derfor kører de fleste diske ofte på en Hot tiering model, men som vi så finder ubrugte det meste af tiden.

Her ville det være smart at se på hvorvidt man kan nedgradere til en Cold tiering.

Som minimum.

Har virksomheden historik, som du ved kun bruges når f.eks. myndigheder banker på, så er Archive tiering oftest det bedste og billigste valg.

Hvis du gerne vil have den indsigt uden at skulle opgradere til premium tiers, så har vi bygget et model til lige netop dette i Ximplifi.

Ræk ud for at høre mere her →

Operationer

Her skal du se efter om noget stikker ud ift. læs, skriv og liste (læs: indeksering) af jeres diske

1. Samlede read operationer
2. Samlede write operationer
3. Samlede list operationer
4. Samlede *batch *****[read/write/list] operationer

Særligt vigtigt her er, ligesom med VM og SQL, om der er sammenhæng og konsistens.

F.eks. om der i weekender er samme forbrug som i hverdage.

Eller der på anden vis er udsving som du ikke kan redegøre for.

Backup og redundans

Lokal (LRS) - kopier på tværs af samme datacenter

Zone (ZRS) - kopier på tværs af tilgængelige zoner i samme region

Geografisk (GRS) - kopier på tværs af to (2) regioner (eks. West Europe og US)

Geo-zone (GZRS) - kopier inden for én region og én geo-replikering i en anden region

Det bliver hurigt knudret. Men du skal holde for øje er ift. hvor kritisk jeres lagrede data er.

LRS har lavere SLA oppetid/holdbarhed (dog alligevel 99,99999999999%), hvor GZRS har 99,9999999999999999%).

Som du nok allerede har gættet er prisen også derefter.

Derfor, spørg dig selv om du virkelig har brug for replikering på tværs af geografier.

Særligt hvis din foretrukne region sjældent rammes af force majeure som naturkatastrofer, krig, el. lign.

Du kan dykke dybere i Microsoft egen dokumentation på Azure Storage redundancy her →.

‍

📊 3 mdr oversigt - Forbrug på tværs af Storage Accounts

☑️ Tjekliste

[ ] Tiering - Stemmer aktivitet på diske overens med faktisk forbrug?

• Hot → Cold → Archive

[ ] Operationer - Irregulære mønstre i det forventede forbrug?

• skriv/write operations
• liste/list operations
• batch operations
• [ ]  Backup - Stemmer jeres backup behov overens med jeres forbrug?
• Kan der optimeres ift. Backup/redundans zoner?

Vurder heraf

• Mulighed for nedgradering fra Hot til Cold eller Archive?
• Sammenhæng (eller mangel på samme) ift. operationer og faktisk aktivitet
• Mulighed for mindre redundans/backup

Se 3 Months Storage Account Daily By Meter →

‍

2.6 SQL - Forbrug SQL Server

Denne her kan godt være lidt forvirrende. Så træk lige vejret en gang. Dybt.

Ok, vi går i gang…

Bruger du SQL databaser (læs: relationelle datatabeller), så har du muligvis en stor pengesluger i dit skab.

Særligt i Azure.

Ligesom med VM’er er der en del parametre du kan skrue på, som vil påvirke dine omkostninger.

Azure SQL IaaS

Først og fremmest, så kan du vælge den rene Infrastruktur (IaaS) model, hvor du ‘bare’ lejer kapaciteten og selv står for vedligehold, opdatering, patching, osv.

Her ‘samler’ du i princippet selv din SQL maskine, med virtuelle kerner (vCPU) og Disk (Storage).

Her skal du være opmærksom på

• vCores/vCPU’er (ligesom ved VM)
• Diske (ligesom ved Diske)
• Licenser (OS Core licenser)

Ligesom Microsoft’s lidt obskure licensmodel på VM’er, så gælder lignende faktum ift. SQL Core Licenser.

Her er reglen dog 4. Du kan minimalt købe 4 SQL licenser og du runder altid op til nærmeste 4.

Derfor hedder licensregnestykket:

1. 1 SQL cores = 4 SQL licenser
2. 3 SQL cores = 4 SQL licenser
3. 5 SQL cores = 8 SQL licenser

So und so weiter.

Det er lidt af en jungle og er ikke særligt veldokumenteret. Men det er underligt nok sandheden.

Her bør du tjekke op med dine licensspecialister og din Cloud Solutions Provider (CSP) eller Microsoft om der er mulighed for Hybrid Benefit.

Jeg vil ikke gå i dybden med det. Men kort sagt kan du få en til en rabat på dine Azure licenser, hvis du i forvejen har købt dem til dit On-premise (læs: kælder) miljø.

Det er dog ikke for evigt, men en hjælpende hånd op i Azure.

Det gælder også for Core Licenser til Cores og vCPU’er (VM).

Læs mere om Azure Hybrid Benefit her →

Azure SQL PaaS

Alternativt går du platform (PaaS) vejen, hvor du lader Microsoft stå for alt det.

Via PaaS handler du i stedet med det vi kalder DTU’er (Digital Transaction Unit).

Det er hamrende bøvlet, men er i grove træk en samlet betegnelse for bl.a. SQL’ens

• Computerkraft (CPU)
• Lagring (GB)
• IOPS
• RAM
• Backup
• Oppetid (SLA)

Afhængigt af hvor krævende din applikationer eller miljøer er, kan du vælge mellem 3 (tre) størrelser (tiers):

1. Basic (mindre krævende workloads)
2. Standard (mere krævende workloads)
3. Premium (intensive workloads)

Du vil se en slider på “DTU’er” og “Data max størrelse”.

Grundlæggende afgør de, tilsammen, performance og backup for din database server.

Og selvfølgelig, jo højere krav desto højere pris.

Ingen overraskelser der (sarkasme kan forekomme).

Opsummering

SQL databaser, særligt dem i pre-produktion, er ofte en stor pengesluger.

PaaS er på papiret den dyrere model her.

Men går du op i den tid i bruger på vedligehold, så kan der være en god case i at gå PaaS-vejen.

‍

📊 3 mdr oversigt - Forbrug på tværs af SQL servere

☑️ Tjekliste

[ ]  Betalingsmodel - Muligheder ift. miljøer, aktivetet og faktisk forbrug

• Pay as you Go ←→ Reserved Instance (ift. aktivet på miljøer)

[ ]  Licensering - Mulighed for Hybrid Benefit

• Licenser til jeres On-premise der kan konverteres til Azure licenser

[ ]  Arkitektur - IaaS vs. PaaS

• Giver jeres nuværende arkitektur mening ift. pris / arbejdstid (vedligehold og håndtering)

Vurder heraf

• Købs-model - Har i den rigtige betalingsmodel til SQL i Azure eller er der mulighed for at lave om på jeres arkitektur (rearchitect)
• Provisionering - Er der sammenhæng i jeres forbrug og den aktivitet der er på SQL serverne og kan der optimeres her

‍

Se 3 Months SQL Server By Meter →

‍

3. Migrer med VMware?

VIGTIGT! Når du migrerer op i Azure er det nemt at falde i “lift-and-shift” fælden ved, at tage applikationen ‘as is’ i kælderen og op i Azure.

For langt de fleste vil deres kælder-jern i en eller flere instanser være virtualiseret:  CPU’er og diske er partitioneret (læs: skilt ad) ift. applikationers kravsspecifikationer.

Typisk i et VMware cluster. For ren og skær resurseoptimerings skyld.

Det giver rigtig god mening. Hvis du har nok computerkraft, pakket ind i en kasse (server) til, at drifte flere applikationer, så gør det.

Problemet sker når du migrerer op i Azure, sætter Azure Migrate igang, og lader data flyde fra kælder til cloud. Azure skelner nemlig ikke dine resurser efter

‍

4. Licenser i Azure

Som du nok har måtte sande, så er licenser i Azure ikke bare noget vi lige gør.

Det kræver at du holder tungen fladt og solidt, lige i munden.

‍

☝ Regel

Når det kommer til licenser vil Azure kun RUNDE OP. Aldrig ned.

Virtuelle Maskiner: Min. køb af 8. kernelicenser (Core/vCPU), dertil pris per 8 stk. (købt i pakker af 16 🤷)

Databaser: Min. køb af 4 kernelicenser, dernæst pris pr. 2 stk.

Storage: Betale for nærmeste storage tier/GB (64GB, 128GB, 252GB, 518GB, 1036GB…)

‍

5. Handling og håndtering

Guiden og tjeklisterne er tænkt som et startskud til, at give dig overblikket over de vigtigste elementer i din Azure infrastruktur.

Det udgangspunkt vi, i Ximplifi, bruger når vi bliver hidkaldt.

Og ja, der er rigtig, som i RIGTIG, mange bevægelige dele du skal holde øje med.

Det er dog ikke den spændende del af arbejdet.

Det spændende er hvem.

Hvem skal udføre arbejdet?

Fejlfinde, udsving, optimere, osv.

Det er ikke nødvendigvis sjovt-spændende.

Men interessant da det først er nu, her, at du og din organisation skal finde frem til løsningerne.

Hvad vil i gøre ved det? Og hvem skal gøre noget ved det?

For hvert sekund der flyver, flyver dine udgifter op i skyen.

Til Microsoft Azure.

‍

5.2 Dynamisk håndtering

Hvis du gerne vil undgå det ‘spændende’ (ofte sure) arbejde, så slip ikke her.

Ximplifi hjælper dig lige præcis her.

Den vender Azure på hovedet og sætter dine resurser automatisk på pause.

Det eneste du og dine brugere nu skal er, at tænde for dem.

Ximplifi holder konstant øje og analyserer for muligheder for, at minimere dine cloud-udgifter.

Så du og dine ingeniører, interne som eksterne, ikke spilder dyrebar tid.

På det Azure burde gøre, ud af boksen.

‍

6. Ræk ud og hør mer’

Vi er klar til at hjælpe dig.

Vi har gjort det mange gange før.

Vi ved hvordan vi afhjælper dig med udgifterne.

‍

Mød mig her→

‍

Eller skriv til os på get@ximplifi.io

God cloud-vind 🌬️