Optimér jeres cloud-ressourcer i takt med løsningernes modenhed og find de 'skjulte' besparelser

Det koster selvfølgelig penge at drive sine softwareløsninger.

Hvis man driver dem on-premise risikerer man at have indkøbt for meget hardware for at kunne følge med et muligt forretnings- og udviklingsbehov eller for at klare spidsbelastninger - men i cloud behøver man ikke at provisionere for mange ressourcer, så projekter og organisationer kan jo helt undgå dén situation. Derved kan IT-chefen læne sig tilbage og stole på få optimal værdi for sit budget? Eller hvad?

Der er to klassiske situationer hvor man provisionerer for mange eller for store ressourcer i skyen. Det positive scenarie: Organisationen starter mange nye projekter og er meget innovativ. Det negative scenarie: Der er ikke opbygget tilstrækkelig viden om IT-driften i skyen. Provisioneringen sker på andre præmisser end ved traditionel on-premise drift, hvor man kun får nye eller større ressourcer, når driftsafdelingen installerer dem.

Uanset hvad er det muligt at styre de omkostninger, man har i skyen. Der kan opsættes overvågning, stilles krav om at driftsafdelingen er inde over provisionering af nye ressourcer og man kan jævnligt rydde op. Det kræver nye kompetencer i driftsafdelingen at tage dét ansvar på sig, på en ny måde.

Man kan derudover stille fokus på omkostninger som et krav til DevOps-projekter i organisationen. Denne blog er funderet i et DevOps-mindset, men principperne kan også bruges i en organisation, hvor udvikling og drift er opdelt.

I det følgende nævnes ind-/ud-/op-/ned skalering. Det kan sammenlignes med spande – hvis man skalerer op og ned, så skifter man størrelsen på spandene. Hvis man skalerer ud og ind, så tilføjer eller fjerner man spande.

Timing

Når man skal begynde at kigge på omkostningerne, kan der være følgende triggere:

Man kan vælge at gøre det fra start - men her vil man mangle viden om hvor man skal fokusere sin indsats, da man endnu ikke har empiri for hvordan ressourcerne bliver belastet over tid.

Man kan også gøre det når Azure’s indbyggede guide anbefaler det - men i den situation er det måske Azure, der mangler viden om hvordan ressourcerne bliver anvendt over tid.

Man kan også vælge at gøre det når man får notifikationer/alarmer fra Azure om at et budget er overskredet - men det kræver at man på forhånd har været i stand til at opsætte et budget, der er realistisk. Det kan være svært, da der også her mangler empiri for hvordan ressourcerne bliver belastet over tid.

Hos os gør vi det løbende, i takt med vores projekters modenhed og kundernes stigende fokus på omkostninger forbundet med deres ’nye’ cloud-løsninger.

En besparelse på 58%

På et af vores projekter fra finanssektoren, hvor vi drifter en større del af kundens infrastruktur, har vi identificeret et par oplagte besparelsesområder.

En stor del af kundens systemer bygger på Azure App Services, der giver nærmest ubegrænset adgang til IT-ressourcer, så vi gnidningsfrit kan levere på nye forretningsmæssige ønsker, så snart at de dukker op.

Efterhånden som systemerne er blevet modne og tydelige brugsmønstre kan identificeres og forudses, analyserer vi løbende den anvendte kapacitet op mod den provisionerede. Dermed kan vi identificere områder hvor kapaciteten kan justeres.

Udviklingsprocessen for kunden kører efter CI/CD-principper så der er behov for udviklings- og test-miljøer hvor alle ændringer trykprøves, før de kommer i drift. I opstartsfasen af projektet var det svært at forudse behovet for disse miljøers tilgængelighed, men efterhånden som ressourcebehovet for både manuelle og automatiske tests blev mere forudsigeligt, opstod der naturligt muligheder for at minimere omkostningerne til disse ressourcer.

Forudsigeligheden gjorde at vi var i stand til at opsætte automatisk justering af antallet af instanser i App Service planen for testmiljøet afhængigt af den planlagte arbejdstid.

En graf over de resulterende besparelser kan ses nedenfor (Y-aksens skala er konverteret til et indeks), hvor det let kan aflæses, at den automatiske justering virkede fra omkring d. 3. maj. Sammenlignet med konfigurationen før d. 3. maj, er der opnået en besparelse på 28,6%.

Alle vores projekter udnytter naturligt Azures indbyggede metoder til automatisk at skalere ressourcer, herunder de forskellige skaleringsmuligheder for App Services. Azure tilbyder dog ikke nogen automatisk skalering af den provisionerede App Service Plan SKU, hvilket låser en større del af driftsomkostningerne. SKU er Azures begreb for en specifik konfiguration af et Azure-produkt – f.eks. er App Service Plan SKU’en “P2v3” navnet for en bestemt ”størrelse” af server med 4 cores, 16 GB RAM og 250 GB storage.

Af den grund har vi udviklet mekanismer der nedskalerer App Service Plan SKU’er for udviklingsmiljøet, uden for den planlagte arbejdstid – naturligvis med et design, der tillader at de hurtigt kan starte op igen, hvis en situation skulle påkræve udvikling i ydertimerne.

En graf over de resulterende besparelser kan ses nedenfor (Y-aksens skala er konverteret til et indeks). Omkring d. 16. april blev der implementeret en automatisk skalering af SKU’en for App Service Planerne i udviklingsmiljøet, så der anvendes en mindre SKU i aftentimerne og weekender. Sammenlignet med konfigurationen før d. 16. april, er der opnået en besparelse på 58%.

Ressourcer sat under lup

Hos en anden kunde har vi lavet back-end til en omfattende online shop. Da projektet havde opnået en vis modenhed, blev vi enige med kundens IT-chef om at beregne omkostningerne for deres cloud-ressourcer for at se om omkostningerne kunne reduceres. Da belastningen af ressourcerne var velkendt så var forudsætningerne for at opnå en besparelse også gode.

De største poster på tværs af udviklings-, test- og produktionsmiljøer har derfor været sat under lup. De mest omkostningstunge ressourcer, havde størst fokus. Der er mange ressourcer, der ikke blev prioriteret ud fra en betragtning om, at udviklingstimerne ikke vil kunne finansieres igennem besparelser for de pågældende ressourcer.

Konkret er der arbejdet med besparelser på Azure SQL, Api Management, App Service Plan og Data Factory.

For Azure SQL er der relativ tidligt i projektet benyttet reserverede instanser (man kan betale en fast og lavere pris for et antal instanser og binder sig til gengæld i en periode på for eksempel et år). Man kan reservere for 1 eller 3 år ad gangen, så det er et godt eksempel på en ressource, hvor man ikke kan optimere omkostningerne, før man har et vist kendskab til belastningen.

Api Management bliver skaleret ned i udviklings- og testmiljøet i de timer hvor der ikke udvikles og testes.

App Service plan skal kunne skaleres meget hurtigt ud, når slutbrugerne handler online for at kunne følge med det ofte store antal requests. De fleste kunder handler mandag til fredag mellem klokken 6 og klokken 16. Desuden er nogle requests lavet til paged (når et kald er paged returnerer man eksempelvis kun 100 elementer ad gangen og kalder derefter igen, hvis kunden vil have flere data.), hvilket kan give flere, men mindre requests, og dermed afhjælpe belastningen på den enkelte instans. Derudover blev der for kunden lavet en letvægtsudgave af responses, som kan bruges i de tilfælde hvor online shoppen kun skal bruge en delmængde af data fra de oprindelige responses. Endelig blev der suppleret med flere regler for ud- og ind-skalering, så der ikke skaleres lige så hurtigt uden for de tidspunkter hvor der normalt er flest kunder online.

Data Factory kan være del af svaret

Azure Data Factory kan benytte en self-hosted integration runtime. Den eksisterer nemlig allerede hos den pågældende kunde, af andre årsager og den er billigere end en Azure integration runtime. Derudover er alle Copy-aktiviteter (del-opgave i Data Factory som kopierer data) i Data Factory blevet konfigureret med 2 Data Integration Units, så der ikke benyttes default, som er dyrere. Tilsvarende er alle Data Flow aktiviteter blevet konfigureret til at bruge 8 vCores, medmindre det er et kritisk Data Flow, der kræver mere. Oveni er der også sat timeouts på Pipelines og Data Flows, så de ikke bliver ved med at forsøge at blive færdige, hvis der for eksempel er data eller services, der ikke er tilgængelige. Desuden bliver pipelines nu også scheduleret, så data kun er opdateret i onlineshoppens travleste timer. Der er ydermere også etableret automatisk overvågning af, at de forskellige aktiviteter i Azure Data Factory, fortsat har den billigste konfiguration.

Efter pipeline-arbejdet med kunden kunne vi konstatere, at omkostningerne for ovenstående ressourcer kunne nedbringes med mellem 10% og 50% hvilket er en betydelig besparelse på IT-budgettet.

Hvad kan I gøre, for at se jeres løsninger efter i sømmene?

Stiller dit projekt eller din organisation mon de rigtige krav til at optimere jeres omkostninger på jeres cloud-løsning? Her er et par af de spørgsmål, I kan starte med at stille jer selv:

• Har I de rigtige kompetencer til at optimere omkostninger?

• Kommer I fra et drift- og udviklings-setup og skal over i DevOps?

• Hvor mange penge vil I kunne spare på jeres cloud-løsninger uden at det øger jeres time-to-market eller sænker jeres mulighed for at eksperimentere med nye løsninger der understøtter forretningen?

Om der er noget at hente, kan ofte afklares på forholdsvis kort tid efter at have set jeres set-up igennem. Ønsker I hjælp til processen så er vi selvfølgelig klar til at hjælpe og kun et telefonopkald væk.

Få fat i en af vores cloud eksperter her: T/ +45 72 20 30 60 eller ræk ud via kontakt-formen nedenfor.