Hvordan redusere Azure-kostnader med hendelsesdrevet arkitektur og hvilemodus som standard

I dette innlegget tar vi deg med på reisen fra "alltid-på"-tjenester til Hvilemodus som standard – systemer som sover til de vekkes av faktiske hendelser. Vi kombinerer FinOps-prinsipper, konkrete Azure-mønstre og en anonymisert casestudie fra en bedrift.

1. Utfordringen med alltid-på-tjenester

Mange virksomheter lanserer API-er og bakgrunnsjobber som kjører 24/7 i Azure. Dette fører til:

• Høyt budsjettforbruk selv i perioder med minimal trafikk.

• Kontinuerlig behov for patching, overvåking og feilhåndtering.

• Uforutsette kostnadssprang ved plutselige trafikkspikes.

En bedrift oppdaget at deres Web API brukte 65 % av månedsbudsjettet på inaktiv driftstid – før de rullet ut hendelsesdrevet design.

2. Casestudie: Anonymisert teknologibedrift

Før overgang:

• Kostnad per måned: 15 000 NOK (kilde: interne målinger).

• Utnyttelsesgrad: 30 % (CPU/minne i bruk).

• Gjennomsnittlig svartid: 250 ms.

Etter overgang til Hvilemodus som standard:

• Kostnad per måned: 6 000 NOK (–60 %, kilde: interne målinger).

• Kostnad ved inaktivitet: 0 NOK.

• Gjennomsnittlig svartid: 200 ms.

Prosjektleder: "Med hendelsesdrevet arkitektur sparer vi tid på drift og kan fokusere på nye funksjoner."

3. Hva er Hvilemodus som standard?

Hvilemodus som standard vil si at komponentene våkner kun når data eller trafikk krever det. Arkitekturen består av:

1. API Management som HTTP-frontend.

2. Meldingskøer (Service Bus, Event Grid eller Storage Queue).

3. Serverless-beregning (Azure Functions) eller containere skalert til null (Azure Container Apps).

Fordelen er enkel: Vi betaler kun for faktisk arbeidsmengde, ikke tomgang.

4. Anbefalte Azure-komponenter

API Management 

• Eksponerer et sikkert endepunkt uten behov for egen VM-hosting.

Meldingskøer

• Azure Service Bus for transaksjonelle meldinger, dead-lettering og FIFO-rekkefølge.

• Azure Event Grid for publiser-/abonner-mønstre med høy fan-out.

• Azure Storage Queue for et rimelig og enkelt alternativ.

Beregningsmotorer

• Azure Functions trigges automatisk ved nye kømeldinger og skalerer til null.

• Azure Container Apps med KEDA skalerer containere etter kølengde eller egendefinerte metrikker.

Serverless-lagring

• Blob Storage med livssyklusregler for automatisk flytting til Cool eller Archive tier.

• Cosmos DB Serverless for data som sjelden leses eller skrives.

5. Teknisk dybde: retry og dead-letter

En robust løsning krever tydelig retry-logikk og dead-letter-håndtering. Her er en detaljert flyt:

3.1 Ved feil: Systemet forsøker automatisk å prosessere meldingen på nytt opptil tre ganger.

3.2 Ved suksess: Meldingen markeres som ferdig.

Denne flyten sikrer at feilede meldinger kan fanges opp manuelt uten tap av data.

6. Slik kommer vi i gang – steg for steg

1. Kartlegg trafikkmønstre og responstidskrav.

2. Velg kø-mekanisme etter behov (Service Bus, Event Grid, Storage Queue).

3. Definer funksjoner med retry-regler, timeout og logging.

4. Sett opp Azure Monitor og Application Insights for sanntidsinnsikt.

5. Optimaliser lagring med livssyklusregler og Cosmos DB Serverless.

6. Analyser kostnader regelmessig og juster skaleringsparametere.

7. Ytelseskriterier

Typiske ytelseskriterier som påvirker valg av kø-teknologi:

• Latenstid: Service Bus gir lavere latenstid enn Storage Queue, men Event Grid er best for fan-out.

• Meldingsvolumer: Storage Queue håndterer høye volumer rimelig, mens Service Bus er bedre for transaksjonelle meldinger.

Neste steg

Vi håper du er inspirert til å utforske hendelsesdrevet arkitektur i din egen organisasjon. Ta gjerne kontakt med meg direkte for spørsmål, erfaringer, rådgivning, FinOps-vurdering av dagens Azure-arkitektur eller utredning av målarkitektur.

Les også