Azure

Hva det er

Azure, eller Microsoft Azure med fullt navn, er en katalog med datakraft som Microsoft leier ut fra sine egne datasentre: virtuelle maskiner, lagringskontoer, administrerte databaser, kjøring av containere, private nettverk og verktøyene for å drive alt sammen, betalt etter bruk. Fram til april 2014 solgte Microsoft det som Windows Azure, og da fikk det navnet det har i dag.

Hver forespørsel til Azure, enten det er et klikk i portalen, en kommando i Azure CLI eller PowerShell, et kall fra et SDK eller en mal, kommer inn gjennom den samme døra: Azure Resource Manager, som autentiserer forespørselen, sjekker at den er tillatt, og sender den videre til tjenesten som gjør jobben. En virtuell maskin, en databaseserver og en DNS-sone er alle ressurser i dens forstand, hver med en ID, en type og et sett egenskaper.

Ressursene er ordnet i et hierarki med fire nivåer. Hver ressurs hører til nøyaktig én ressursgruppe, en mappe ment for det som rulles ut, oppdateres og slettes sammen; sletter du gruppen, slettes alt i den. Ressursgrupper ligger i et abonnement (subscription), som på én gang er en enhet for fakturering og en grense for tilgang og kvoter. Abonnementer samles i administrasjonsgrupper (management groups), som kan nøstes i opptil seks nivåer og alle samles under én enkelt rotgruppe for katalogen. Rolletildelinger, policyer og budsjetter som settes på ett nivå, gjelder alt under det.

Over hele hierarkiet ligger identiteten. En organisasjons brukere, grupper og applikasjoner bor i en leietaker (tenant) i Microsoft Entra ID, katalogen Microsoft kalte Azure Active Directory fram til 2023, og hvert Azure-abonnement stoler på nøyaktig én slik leietaker til å logge inn folk og avgjøre hva de har lov til.

Hvorfor det er viktig

De fleste team som kjører på Azure, havnet der gjennom noe de allerede hadde. Et selskap der de ansatte logger inn i Microsoft 365, har allerede folkene sine i en Entra-leietaker, og et abonnement som stoler på den leietakeren, kan gi de samme kontoene tilgang til servere og databaser uten en ekstra brukerkatalog å vedlikeholde. For en leverandør avgjøres valget av Azure derfor mindre av funksjonstabeller enn av hvor kundens identiteter og data allerede ligger.

Hierarkiet er den andre grunnen, fordi styringen ligger i det. Microsofts veiledning om å organisere ressurser anbefaler egne abonnementer for utvikling, testing og produksjon, slik at miljøene ikke kan vokse seg avhengige av hverandre, og slik at hvert av dem kan ha sine egne policyer og sin egen linje på regningen. Azure Policy håndhever så husreglene på det nivået policyen er tildelt. Den kan avvise en endring, f.eks. en ressurs opprettet i en region organisasjonen ikke bruker, eller logge den så noen kan se på den senere, og Microsoft råder til å starte en ny policy i revisjonsmodus (audit) før den får lov til å blokkere noe.

Den tredje grunnen er at Azure kan beskrives i stedet for å klikkes fram. Resource Manager tar imot deklarative maler, skrevet i JSON eller i Bicep, og finner selv ut hva som må opprettes eller endres. Kjører du den samme malen to ganger, blir resultatet det samme, og Azure lagrer tilstanden til det som ble rullet ut, så det finnes ingen egen tilstandsfil å passe på. Et oppsett skrevet på denne måten kan gjennomgås som en pull request, bygges opp igjen etter en dårlig dag og kopieres til et nytt miljø ved å endre parameterne. Det er hovedforsvaret mot et Azure-oppsett som bare én person forstår.

Slik ser det ut i praksis

Siden om teknologiene nevner Google Cloud og AWS som de skyene selskapet vanligvis jobber i, med Azure der kunden allerede holder til. To oppføringer i porteføljen viser Azure-arbeidet fra hver sin ende.

På infrastruktursiden ble tre Azure-miljøer nedfelt som kode, alle fra de samme Bicep-malene: api og www som Azure Container Apps i et administrert miljø, en PostgreSQL Flexible Server, Redis til caching, Front Door med en WAF-policy ytterst, og et VNet, NSG og privat DNS under, med Log Analytics koblet på for diagnostikk og containerbildene hentet fra prosjektets Azure Container Registry. Fordi malene er parameterisert, er et nytt miljø eller en endring i et eksisterende en pull request, og avvik sluttet å være et mysterium, fordi koden er sannhetskilden.

På utgivelsessiden var produksjonssettingen til Azure et ansvar fra ende til annen. Utgivelser følger en fast rute gjennom utvikling, staging og produksjon, i stedet for at noen pusher rett til et miljø i drift. Leveransepipelinen bygger og leverer containerbildene, og Bicep-malene holder målinfrastrukturen lik fra ett miljø til det neste. Hemmelighetene holdes for seg, atskilt fra konfigurasjonen som skiller ett Azure-miljø fra et annet, så den samme bygde artefakten flytter gjennom hvert miljø og plukker opp de riktige innstillingene der den lander, uten ad hoc-produksjonssettinger for hånd innimellom.

Hvor det går galt

De dyre feilene i Azure har som regel samme form: et gap mellom det noen tror Azure gjorde eller tillot, og det Resource Manager faktisk gjorde.

En utrulling lar ting bli stående og setter ting tilbake. Resource Manager ruller ut i inkrementell modus som standard. I den modusen blir en ressurs som finnes i ressursgruppen, men mangler i malen, latt i fred, så når du sletter en database fra malfilen, fortsetter serveren å gå og å koste penger. Den samme modusen bruker hver egenskap på nytt for hver ressurs den ruller ut igjen, og en egenskap malen utelater, settes tilbake til standardverdien. En innstilling noen endret i portalen, blir derfor overskrevet ved neste rutinemessige utgivelse. Forhåndsvisningen what-if kan advare om begge deler, men Microsoft påpeker at utdataene kan inneholde støy, falske positive der en reell endring er lett å overse. Malen bør oppgi hver verdi som avviker fra standarden, og en deployment stack, som kobler fra eller sletter ressursene som faller ut av en mal, tar seg av det som blir liggende igjen.

Alle miljøene deler ett abonnement. Det er den raskeste måten å komme i gang på: ett abonnement, én ressursgruppe per miljø og brede roller tildelt øverst, så ingen blir stoppet. Produksjon og test deler da rolletildelinger, policyer, kvoter og én regning, og et skript som er rettet mot testgruppen, kjører med rettigheter som også når produksjon. Egne abonnementer under en administrasjonsgruppe gir hvert miljø sin egen tilgang, sine egne regler og sine egne kostnader.

En katalogadministrator blir tatt for en ressursadministrator. Roller i Microsoft Entra, som Global Administrator, styrer katalogen: brukere, grupper, passord og domener. Azure-roller, som Owner og Contributor, styrer ressurser. Som standard når den ene typen ikke inn i den andre. En Global Administrator kan slå på en bryter som gir vedkommende User Access Administrator på rotnivå, og det lar dem se hver ressurs og tildele tilgang i hvert abonnement i leietakeren. Bryteren finnes for å gjenvinne tilgangen til et abonnement, og Microsofts råd er å fjerne den forhøyede tilgangen når jobben er gjort. Blir den stående, er det en katalogkonto som kan gi seg selv hvilken som helst ressurs.

En container-app som aldri sover. Azure Container Apps kan skalere de fleste applikasjoner ned til null replikaer når ingenting kaller dem, og det er en del av grunnen til at tjenesten frister for små tjenester. Applikasjoner som skalerer på CPU- eller minnebelastning, er unntaket og kan ikke skalere til null. En app som får en CPU-regel, holder minst én replika i gang gjennom hver stille natt, så en tjeneste som ble valgt fordi den er billig når den står i ro, bør skalere på HTTP-trafikk eller en annen kilde til hendelser.

Les mer

• Azure documentation — Microsofts oversikt over veiledninger, hurtigstarter og referanser for hver tjeneste i Azure.
• What is Azure Resource Manager? — laget hver forespørsel går gjennom, og hvordan du deler inn ressursgrupper.
• Organize your Azure resources — Cloud Adoption Framework om administrasjonsgrupper, abonnementer og ressursgrupper.
• Deployment modes — hva inkrementell modus lar stå igjen, og hvilke egenskaper en ny utrulling setter tilbake.
• Deployment stacks — å styre ressursene i en mal som én enhet, også dem som er fjernet fra malen.
• Azure roles and Microsoft Entra roles — hvor katalogroller slutter, hvor ressursroller begynner, og hvordan forhøyet tilgang binder dem sammen.