Bruke WAF-mønstre i virkelige arkitekturer

Å bruke WAF-mønstre på virkelige arkitekturer er ikke en teoretisk øvelse – det krever at hvert designvalg vurderes opp mot de fem søylene, og at De foretar velinformerte avveininger. Et vanlig utgangspunkt er arkitekturdiagrammet: Følg banen til en brukerforespørsel gjennom hver komponent, og spør for hvert trinn hva som skjer hvis komponenten svikter, hva den koster, og hvordan den er sikret.

Se for Dem en tradisjonell monolittisk webapplikasjon: én VM som kjører webserver og database sammen bak en offentlig IP-adresse. Målt mot WAF-søylene skårer denne dårlig på alle fem: ingen redundans (pålitelighet), database på samme vert som web-laget (sikkerhet), VM som alltid er på, uavhengig av trafikken (kostnad), ingen CI/CD (fremragende drift) og bare vertikal skalering (ytelseseffektivitet).

For å ivareta pålitelighet kan webnivået fordeles på flere VM-er i ulike tilgjengelighetssoner, databasen kan sikres med georeplikering til en sekundær region, og en Azure Load Balancer kan plasseres foran. Dette eliminerer det enkelte feilpunktet og gjør at applikasjonen kan fortsette å fungere ved et sone- eller regionutfall uten manuell inngripen.

For sikkerhetspilaren kan webnivået og databasen plasseres i ulike subnett med NSG-regler som bare tillater webnivået å koble til databaseporten. Lagre tilkoblingsstrengen til databasen i Azure Key Vault, og bruk en managed identity i webappen til å hente den under kjøring — slik unngår du hardkodet påloggingsinformasjon i applikasjonskode og konfigurasjonsfiler.

For kostnadsoptimalisering kan du erstatte VM-er som alltid er på, med et Virtual Machine Scale Set som skalerer inn utenom perioder med høy belastning. For databasen bør du vurdere om en administrert PaaS-tjeneste, for eksempel Azure SQL Database med et passende DTU-nivå, koster mindre enn en full VM med SQL Server. Kjøp Reserved Instances for eventuell grunnkapasitet du kan forutsi 12 måneder frem i tid.

Forbedre driftsmessig fremragende løsninger ved å definere hele infrastrukturen som Bicep- eller ARM-maler lagret i versjonskontroll. Bygg en CI/CD-pipeline i Azure Pipelines eller GitHub Actions som automatisk distribuerer infrastrukturendringer og applikasjonskode. Legg til distribusjonsporter — automatiserte smoke-tester og manuell godkjenning — før endringer når produksjonsmiljøet.

For ytelseseffektivitet kan du introdusere Azure Cache for Redis foran databasen for å hurtigbufre spørringer som leses ofte, og redusere belastningen på databasen. Distribuer statiske ressurser (bilder, CSS, JavaScript) gjennom Azure CDN, slik at de leveres fra noder nær brukere over hele verden. Belastningstest applikasjonen etter hver endring for å bekrefte at forbedringene kan måles.

Alle arkitekturendringer innebærer en avveining. En arkitektur med flere soner forbedrer for eksempel påliteligheten, men øker kostnadene (to soner = to VM-er). Hurtigbufring med Redis forbedrer ytelsen, men øker driftskompleksiteten (enda en tjeneste som må overvåkes og vedlikeholdes). God arkitekturdokumentasjon beskriver disse avveiningene uttrykkelig, slik at fremtidige arkitekter forstår hvorfor beslutningene ble tatt.

Unngå å forsøke å oppnå perfeksjon i én enkelt redesign — denne tilnærmingen er kostbar, risikabel og langsom. Ta i stedet i bruk en syklus for trinnvise forbedringer: gjennomfør en Well-Architected-gjennomgang, identifiser de tre viktigste problemene med størst effekt, korriger dem, mål forbedringen og gjenta. Denne tilnærmingen samordner arkitekturforbedringer med smidig leveranse og gjør fremdriften synlig for interessentene i hver sprint.

Microsoft publiserer referansearkitekturer for vanlige arbeidsbelastningsmønstre i Azure Architecture Center. Disse omfatter arkitekturer for webapplikasjoner, mikrotjenester på AKS, datapipeliner for analyse og mye mer. Hver referansearkitektur er allerede vurdert opp mot WAF-pilarene og inneholder merknader om avveiningene som er gjort for det aktuelle mønsteret.

Bruk Architecture Decision Records (ADRs) til å dokumentere viktige arkitekturvalg, konteksten de ble tatt i, alternativene som ble vurdert, og konsekvensene for WAF-pilarene. ADR-er som lagres i versjonskontroll sammen med kodebasen, gir en etterprøvbar historikk som hjelper nye teammedlemmer med å forstå hvorfor arkitekturen ser ut som den gjør.

I denne leksjonen lærte du at WAF-mønstre brukes ved å vurdere hver arkitekturbeslutning opp mot alle fem pilarene, at forbedringer kan gjennomføres trinnvis ved å starte med problemene som har størst effekt, og at avveininger må dokumenteres slik at fremtidige arkitekter forstår begrunnelsen. Neste tema er Azure-SLA-er og hvordan du beregner sammensatte SLA-er for arkitekturer med flere tjenester.