Azure

molnplattformen från Microsoft

Vad det är

Azure, eller Microsoft Azure med fullständigt namn, är en katalog av datorkraft som hyrs ut från Microsofts egna datacenter: virtuella maskiner, lagringskonton, hanterade databaser, drift av containrar, privata nätverk och verktygen för att sköta dem, betalt efter användning. Microsoft sålde det som Windows Azure fram till april 2014, då det fick sitt nuvarande namn.

Varje begäran till Azure, vare sig det är ett klick i portalen, ett kommando i Azure CLI eller PowerShell, ett anrop via ett SDK eller en mall, kommer in genom samma ytterdörr: Azure Resource Manager, som autentiserar och auktoriserar den och lämnar den vidare till den tjänst som gör arbetet. En virtuell maskin, en databasserver och en DNS-zon är alla resurser i dess mening, var och en med ett id, en typ och en uppsättning egenskaper.

Resurserna ordnas i en hierarki med fyra nivåer. Varje resurs hör till exakt en resursgrupp (resource group), en mapp avsedd för sådant som driftsätts, uppdateras och tas bort tillsammans; att ta bort gruppen tar bort allt i den. Resursgrupper ligger inuti en prenumeration (subscription), som på en gång är en enhet för fakturering och en gräns för åtkomst och kvoter. Prenumerationer samlas i hanteringsgrupper (management groups), som kan nästlas i upp till sex nivåer och som alla leder upp till en enda rothanteringsgrupp för katalogen. Rolltilldelningar, policyer och budgetar som sätts på en nivå når allt under den.

Över hela hierarkin ligger identiteten. En organisations användare, grupper och applikationer finns i en klientorganisation (tenant) i Microsoft Entra ID, den katalog som Microsoft kallade Azure Active Directory fram till 2023, och varje prenumeration i Azure litar på exakt en sådan klientorganisation för att logga in människor och avgöra vad de får göra.

Varför det spelar roll

De flesta team som kör i Azure kom dit via något de redan hade. Ett företag vars personal loggar in i Microsoft 365 har redan sina människor i en klientorganisation i Entra, och en prenumeration som litar på den klientorganisationen kan ge samma konton åtkomst till servrar och databaser utan en andra användarkatalog att underhålla. För en leverantör avgörs valet av Azure därför mindre av funktionstabeller än av var kundens identiteter och data redan finns.

Hierarkin är det andra skälet, eftersom styrningen bor i den. Microsofts vägledning om att organisera resurser rekommenderar separata prenumerationer för utveckling, test och produktion, så att miljöerna inte kan växa fast i beroenden av varandra och var och en kan bära sina egna policyer och sin egen rad på fakturan. Azure Policy upprätthåller sedan husreglerna på den nivå där en policy tilldelas. Den kan neka en ändring, t.ex. en resurs som skapas i en region som organisationen inte använder, eller logga den så att någon kan granska den, och Microsoft råder att en ny policy först körs i granskningsläge innan den får blockera något.

Det tredje skälet är att Azure kan beskrivas i stället för att klickas fram. Resource Manager tar emot deklarativa mallar, skrivna i JSON eller i Bicep, och räknar själv ut vad som ska skapas eller ändras. Mallarna är idempotenta: att köra samma mall två gånger ger samma resultat, och Azure lagrar tillståndet för det som driftsattes, så det finns ingen separat tillståndsfil att ta hand om. En infrastruktur som skrivs på det sättet kan granskas som en pull request, byggas upp igen efter en dålig dag och kopieras till en ny miljö genom att parametrarna ändras, vilket är det främsta skyddet mot en Azure-uppsättning som bara en person förstår.

Så ser det ut i praktiken

Enligt sidan om teknikstacken arbetar företaget i Google Cloud och AWS, med Azure där kunden redan finns. Två uppdrag i portfolion visar Azure-arbetet från båda ändar.

På infrastruktursidan, i rollen som DevOps-ingenjör, skrevs tre Azure-miljöer ned som kod, alla ur samma Bicep-mallar: api och www som Azure Container Apps i en hanterad miljö, en PostgreSQL Flexible Server, Redis för cachning, Front Door med en WAF-policy längst fram och ett VNet, en NSG och privat DNS under alltihop, med Log Analytics inkopplat för diagnostik och containeravbildningar som hämtas från projektets Azure Container Registry. Mallarna är parametriserade, så en ny miljö eller en ändring av en befintlig är en pull request. Avvikelser slutade vara ett mysterium, för sanningskällan är koden, och att få upp infrastrukturen eller återställa den handlar om att tillämpa mallarna i stället för att minnas vad som klickades fram förra gången.

På releasesidan, i rollen som Site Reliability Engineer, ägdes driftsättningen till Azure från början till slut. Releaser följer en fast väg, utveckling, sedan staging, sedan produktion, i stället för att någon pushar direkt till en skarp miljö. CI/CD-pipelinen bygger avbildningarna och levererar dem, och mallarna i Bicep ser till att målinfrastrukturen är densamma i varje miljö. Den konfiguration som är specifik för varje Azure-miljö förvaras åtskild från hemligheterna, så samma byggda artefakt förs vidare genom varje miljö och plockar upp rätt inställningar där den hamnar, utan några manuella ad hoc-driftsättningar inblandade.

Var det går fel

De dyra misstagen i Azure brukar ha samma form: ett glapp mellan det som någon tror att Azure gjorde, eller tillät, och det som Resource Manager faktiskt gjorde.

En malldriftsättning lämnar saker kvar och lägger tillbaka andra. Resource Manager driftsätter som standard i inkrementellt läge. I det läget lämnas en resurs som finns i resursgruppen men saknas i mallen orörd, så att ta bort en databas ur mallfilen lämnar servern igång, och den fortsätter att faktureras. Samma läge tillämpar varje egenskap på nytt hos varje resurs som det driftsätter igen, och en egenskap som mallen utelämnar återställs till sitt standardvärde. En inställning som någon ändrade i portalen skrivs därför över vid nästa rutinmässiga release. Förhandsgranskningen what-if kan varna för båda, men Microsoft påpekar att dess utdata kan innehålla brus, falska positiva bland vilka en verklig ändring är lätt att missa. Mallen bör ange varje värde som skiljer sig från standard, och en deployment stack, som kopplar loss eller tar bort de resurser som faller ur en mall, tar hand om det som blir kvar.

Alla miljöer delar en prenumeration. Det är det snabbaste sättet att komma i gång: en prenumeration, en resursgrupp per miljö och breda roller som tilldelas högst upp så att ingen blir blockerad. Produktion och test delar då rolltilldelningar, policyer, kvoter och en enda faktura, och ett skript som riktas mot testgruppen körs med rättigheter som också når produktion. Separata prenumerationer under en hanteringsgrupp ger varje miljö sin egen åtkomst, sina egna regler och sina egna kostnader.

En katalogadministratör tas för en resursadministratör. Roller i Microsoft Entra, t.ex. Global Administrator, styr katalogen: användare, grupper, lösenord och domäner. Roller i Azure RBAC, t.ex. Owner och Contributor, styr resurser. Som standard når ingen av uppsättningarna in i den andra. En Global Administrator kan slå om en växel som ger kontot rollen User Access Administrator på rotnivå, vilket låter det se varje resurs och tilldela åtkomst i varje prenumeration i klientorganisationen. Växeln finns för att återfå åtkomsten till en prenumeration, och Microsofts vägledning är att ta bort den förhöjda åtkomsten när arbetet är klart. Lämnas den på plats är det ett katalogkonto som kan ge sig självt vilken resurs som helst.

En containerapp somnar aldrig. Azure Container Apps kan skala de flesta applikationer till noll repliker när ingenting anropar dem, vilket är en del av lockelsen för små tjänster. Applikationer som skalar på CPU- eller minnesbelastning är undantaget och kan inte skala till noll. En app som har fått en CPU-regel håller minst en replik igång genom varje lugn natt, så en tjänst som valdes för att den skulle vila billigt bör skala på HTTP-trafik eller någon annan händelsekälla.

Läs mer

Ordlista