I dette siste innlegget i bloggserien vår om Azure kostnader skal vi ta for oss flere måter å redusere Azure kostnadene på. Tiltakene vi går gjennom i dette innlegget vil i de fleste tilfeller kreve infrastrukturendringer og vil i så måte ikke være like enkle å gjennomføre som de vi gikk gjennom i forrige innlegg.
Enkelte av disse tiltakene vil heller ikke la seg kombinere med tiltak som reservasjon av kapasitet og Azure Hybrid Benefit så her er det viktig at man har et aktivt forhold til infrastrukturen sin og planlegger langsiktig.
Plattform som en tjeneste
Det første tiltaket her er kanskje det mest omfattende og det handler om å ta i bruk mer av plattform som en tjeneste og mindre av infrastruktur som en tjeneste. Om du er usikker på hva forskjellen på disse er så har vi skrevet et innlegg om det tidligere:
Microsoft Azure – Pizza som tjeneste.
Ved å ta i bruk plattform som en tjeneste så oppnår man en rekke fordeler, også utover rene kostnader, kontra det å håndtere infrastrukturen selv. Skaleringen blir enklere, sikkerheten blir høyere og til syvende og sist blir også ansvaret ditt og sluttregningen din lavere.
La oss ta for oss et eksempel hvor vi har en enkel nettside som bruker en database for innhold. Tradisjonelt sett ville mann satt opp en sånn type løsning omtrent slik:
Her har vi altså en linje fra internett som går inn til en brannmur, videre til webserveren som håndterer nettsiden også er det en forbindelse videre til databaseserveren gjennom en brannmur.
Hvis vi så gjør et enkelt estimat på hva dette kan koste med infrastruktur som en tjeneste i Azure så tar vi da utgangspunkt i at vi trenger 2 servere (web og database), 1 offentlig ip-adresse (for at nettsiden skal være tilgjengelig fra internett) + backup av serverne. Det vil da se omtrent slik ut:
Altså en kostnad på i underkant av 5 000,- per måned.
Dette eksemplet er en god kandidat for overgang til plattform som en tjeneste og hele miljøet kan erstattes av bare 2 tjenester: en App Service (webserver) og en database som en tjeneste (Azure Database). Om vi tar høyde for dette så ser regnestykket omtrent slik ut:
Det gir oss en kostnad på rett i overkant av 3 000,- per måned og en besparelse på rundt 35% eller rundt 1 700,- per måned.
I dette eksemplet er det også mulig å kombinere med reservasjon av kapasitet og Azure Hybrid Benefit som vi gikk gjennom i forrige innlegg. Da kan besparelsen bli enda større.
Serverløs SQL
Når vi først har diskutert plattform som en tjeneste så kommer vi ikke utenom det Microsoft kaller Azure SQL Database serverless. Navnet er kanskje litt misvisende da man ved å ta i bruk plattform som en tjeneste for SQL allerede er serverløse, men dette er en måte å tilby SQL som en tjeneste på med enda større fleksibilitet.
Med «vanlig» SQL som en tjeneste velger man et antall cpu kjerner eller DTU som skal allokeres og så har man de til rådighet. Faktureringen skjer da per time.
Med serverløs SQL så setter man i stedet en minimumsverdi og en maksimumsverdi for hvor mange kjerner man ønsker å ha til rådighet også skaleres det innenfor dette basert på belastning. Her kan man velge fra 0,5 kjerner helt opp til 40 kjerner. Siden denne skaleringen skjer automatisk og hurtig er også fakturering endret fra per time til per sekund. Dette sørger for at man ikke faktureres for maks antall kjerner mer enn akkurat den perioden man har maks belastning.
Et eksempel på det ser vi i dette bildet. Til venstre ser vi at denne SQL databasen har blitt belastet i overkant av 50% i en kort periode, ellers har belastningen ligget på 0%. På høyre side ser vi at det i samme periode har blitt fakturert for prosessortid, men i etterkant av belastningen har dette også gått ned til 0. Dette fordi vi har aktivert pausefunksjonen på databasen.
Pausefunksjonen som serverløs SQL tilbyr gjør at databasen settes på pause etter en valgt tid med inaktivitet. Dermed betaler man ikke for kostbar prosessortid, kun for lagringen av databasen. Dette gjør serverløs SQL optimal for løsninger hvor dataene sjelden aksesseres, men det er også mye å hente ved å ta det i bruk for dagligdagse systemer. Tenk for eksempel der hvor et system er i bruk hele arbeidsdagen, men når de ansatte har gått for dagen står det og går på tomgang frem til neste morgen. Der kunne man tatt i bruk serverløs SQL for å spare kostnader fra arbeidsdagens slutt og til de ansatte kommer tilbake på jobb dagen etter.
Bakdelen med serverløs SQL er at når den er i pausemodus så vil det ta litt tid å «vekke» den opp igjen. Dette gjør at første gang man prøver å koble til databasen mens den er i pausemodus så vil du få en feilmelding om at den ikke er tilgjengelig. Men hvis man så forsøker igjen et par minutter senere skal den være tilgjengelig som normalt.
Regioner
Som vi var innom i så er det forskjeller i prisene fra region til region i Azure. Dette gjør at for miljøer hvor fysisk avstand ikke har noen betydning så kan man spare kostnader på å velge en rimeligere region.
Som vi ser i dette eksemplet så vil den samme virtuelle maskinen ha omlag 59% høyere kostnad i regionen som heter Brasil, sørøst enn i den regionen som heter USA, øst. Med Norge, øst godt plassert mellom de to.
Denne metoden å redusere Azure kostnadene på vil ikke alltid være mulig å ta i bruk for produksjonsmiljøer fordi man ved å ha stor avstand mellom brukere av en tjeneste og selve tjenesten også får en økt forsinkelse og dermed en dårligere opplevelse. Men for test- og utviklingsmiljøer er det mulig å hente besparelser med denne metoden.
Oppgrader til nyere versjoner
Ved første øyekast er det ikke store forskjellen på de virtuelle maskinene i bildet over. De er i samme region og de er alle av størrelsen D2. Det er litt forskjell i mengden minne man får, men den største forskjellen på disse er kostnaden.
Årsaken til forskjellen i kostnadene er i versjonen av størrelsen som er valgt. Bakgrunnen til at det er høyere kostnader knyttet til eldre versjoner av størrelsene er at versjonene er knyttet til fysisk maskinvare. En gitt versjon av en størrelse er knyttet til, blant annet, en gitt fysisk prosessor. Etter hvert som de blir eldre blir de også dyrere for Microsoft å vedlikeholde og skaffe reservedeler til. Derfor insentiveres man til å bytte til nyere versjoner gjennom kostnadene.
Spot instanser
Med over 160 datasentre verden over skalert til å håndtere behovet for kapasitet til alle sine kunder vil det til enhver tid være overskuddskapasitet i Azure. Denne overskuddskapasiteten selger Microsoft unna til sterkt reduserte priser, som såkalte Spot instanser. Kostnaden for slik kapasitet vil variere med tilbud og etterspørsel, men her er det mulig med opptil 90% besparelse i forhold til veiledende priser.
Bakdelen med å ta i bruk dette er at hvis det ikke er tilgjengelig overskuddskapasitet så kan man eksempelvis ikke skru på servere som baserer seg på Spot instanser. Samtidig vil kjørende servere kunne bli skrudd av hvis Microsoft får behov for kapasiteten.
Der dette vil være nyttig er i miljøer som tåler avbrudd. Dette kan for eksempel være miljøer satt opp for å knuse store mengder data hvor man kan fortsette der man slapp når det blir ledig overskuddskapasitet igjen. Det kan også være test- og utviklingsmiljøer hvor man ikke har krav til oppetid.
Velger man å ta i bruk Spot instanser så har man muligheten til å velge hva som er kriteriet for at maskinene skal skrus av. Det kan enten være at det ikke er overskuddskapasitet igjen eller det kan være en makspris. Prisen for Spot instanser avhenger nemlig av hvor mye overskuddskapasitet som er tilgjengelig, så prisen vil øke etter hvert som det er mindre overskuddskapasitet.
Konklusjon
Som vi har sett i disse to siste innleggene i vår serie om Azure kostnader så er det en rekke tiltak man kan gjøre for å redusere Azure kostnadene. Noen av de krever lite eller ingenting i forhold til implementasjonen og driften av de, mens andre igjen vil innebære både infrastrukturendringer og at man senker forventningene til ytelse eller tilgjengelighet.
Felles for alle tiltakene vi har vært gjennom er at de krever at man tar et aktivt eierskap til Azure infrastrukturen eller at man har en proaktiv partner som hjelper deg med dette.
Man må også gjøre vurderinger på hvilke tiltak som passer i en gitt situasjon eller for en spesifikk løsning. Det er ingen av tiltakene som vil være perfekt i alle scenarioer og det er også forskjeller i om tiltakene lar seg kombinere med hverandre eller om det ene utelukker det andre.
Uansett hvilken situasjon man er i eller hvilke løsninger man benytter: vit at med Azure har du et vell av tiltak du kan gjøre for å redusere kostnadene.
