Grundpelare för Azure Well-Architected Framework

Slutförd

Molnet har ändrat hur organisationer löser sina affärsutmaningar och hur program och system utformas. Rollen som lösningsarkitekt är inte begränsad till att leverera affärsvärde genom programmets funktionskrav. De måste också se till att lösningen är utformad på ett sätt som är skalbart, motståndskraftigt, effektivt och säkert.

Lösningsarkitekturer handlar om planering, design, implementering och pågående förbättringar av ett tekniksystem. Ett systems arkitektur måste balansera och justera affärskraven med de tekniska funktioner som behövs för att köra dessa krav. Slutarkitekturen är en balans mellan risker, kostnader och kapaciteten för hela systemet samt dess komponenter.

Välstrukturerat Azure-ramverk

Azure Well-Architected Framework är en uppsättning vägledande principer för att skapa lösningar av hög kvalitet i Azure. Det finns ingen metod som passar alla för att utforma en arkitektur, men det finns några universella begrepp som gäller oavsett arkitektur, teknik eller molnleverantör.

De här begreppen är inte heltäckande, men om du fokuserar på dem kan du skapa en tillförlitlig, säker och flexibel grund för ditt program.

Azure Well-Architected Framework består av fem grundpelare:

  • Kostnadsoptimering
  • Driftsäkerhet
  • Prestandaeffektivitet
  • Tillförlitlighet
  • Säkerhet

An illustration that shows the pillars of the Azure Well-Architected Framework.

Kostnadsoptimering

Du vill utforma din molnmiljö så att den är kostnadseffektiv för drift och utveckling. Ineffektivitet och slöseri av molnutgifter ska identifieras för att säkerställa att du lägger pengarna där du får mest valuta för dem.

An illustration that shows increasing quality, speed, and efficiency while maintaining decreasing costs.

Driftsäkerhet

Genom att dra nytta av moderna utvecklingsmetoder som DevOps kan du aktivera snabbare utvecklings- och distributionscykler. Du behöver ha en bra övervakningsarkitektur på plats för att kunna identifiera fel och problem innan de inträffar, eller åtminstone innan dina kunder märker av dem. Automatisering är en viktig aspekt av den här grundpelaren för att undvika avvikelser och fel samtidigt som den driftmässiga flexibiliteten ökar.

Prestandaeffektivitet

För att en arkitektur ska fungera bra och vara skalbar, måste den korrekt matcha resurskapacitet efter efterfrågan. Traditionellt åstadkommer man detta i molnarkitekturer genom att program skalas dynamiskt baserat på aktivitet i programmet. Efterfrågan på tjänster ändras så det är viktigt att din arkitektur kan anpassa sig efter efterfrågan. Genom att utforma din arkitektur med prestanda och skalbarhet i åtanke ger du en bra upplevelse för dina kunder samtidigt som du är kostnadseffektiv.

An illustration that shows how resources in the cloud scale dynamically based on demand, resulting in highly efficient usage. When resources are implemented at a fixed level, it results in inefficient usage during low demand and shortage during high demand.

Tillförlitlighet

Varje arkitekts värsta mardröm är att arkitekturen slutar fungera utan att det går att återställa den. En lyckad molnmiljö är skapad på ett sätt som förutser fel på alla nivåer. En del av att förutse de här felen är att designa ett system som kan återställas från fel, inom den tid som krävs av dina intressenter och kunder.

An illustration that shows two virtual machines in a virtual network. One of the machines is shown as failed, while the other is working to service customer requests.

Säkerhet

Data i olika former är oftast den värdefullaste delen av din organisations tekniska fotavtryck. I den här grundpelare fokuserar du på att skydda åtkomsten till din arkitektur genom autentisering och skydda ditt program och dina data från nätverkssårbarheter. Du bör också skydda integriteten för dina data via verktyg som kryptering.

Du måste tänka på säkerheten i programmets hela livscykel, från design och implementering till distribution och drift. Molnet ger skydd mot olika hot, till exempel nätverksintrång och DDoS-attacker. Men du behöver fortfarande bygga in säkerhet i program, processer och organisationskulturen.

An illustration that shows the types of security threats and attacks that might affect your data in the cloud.

Allmänna designprinciper

Förutom de här grundpelarna finns det vissa enhetliga designprinciper som du bör tänka på i din arkitektur.

  • Aktivera arkitekturutveckling: Ingen arkitektur är statisk. Tillåt utveckling av din arkitektur genom att använda nya tjänster, verktyg och tekniker när de är tillgängliga.

  • Använd data för att fatta beslut: Samla in data, analysera dem och använd dem för att fatta beslut kring din arkitektur. Från kostnadsdata till prestanda, till användarbelastning, med hjälp av data kan du göra rätt val i din miljö.

  • Utbilda och aktivera: Molntekniken utvecklas snabbt. Utbilda dina utvecklings-, drifts- och affärsteam för att hjälpa dem fatta rätt beslut och skapa lösningar för att lösa affärsproblem. Dokumentera och dela konfigurationer, beslut och metodtips inom din organisation.

  • Automatisera: Automatisering av manuella aktiviteter minskar driftskostnaderna, minimerar fel som introduceras genom manuella steg och ger konsekvens mellan miljöer.

Delat ansvar

När du flyttar till molnet uppstår en modell med delat ansvar. I den här modellen hanterar molnleverantören vissa aspekter av ditt program, vilket ger dig det återstående ansvaret.

Du är ansvarig för allt i en lokal miljö. När du övergår till infrastruktur som en tjänst (IaaS) och sedan till PaaS (Plattform som en tjänst) och Programvara som en tjänst (SaaS) tar molnleverantören på sig mer av det här ansvaret.

Det här delade ansvaret spelar en roll i dina arkitektoniska beslut, eftersom dessa beslut kan påverka kostnader, säkerhet och programmets tekniska och operativa funktioner. Genom att överlåta dessa ansvarsområden till din provider kan du fokusera på att generera värde i verksamheten och lägga mindre vikt vid aktiviteter som inte är centrala.

An illustration that shows the level of shared responsibilities in each type of cloud-service model.

Designalternativ

I en idealisk arkitektur skulle du skapa den säkraste, mest högpresterande, högtillgängliga och effektiva miljön som möjligt. Men som med allt finns det kompromisser.

För att skapa en miljö med den högsta nivån för alla pelare så finns det en kostnad. Kostnaden kan vara i pengar, tid till leverans eller driftsmässig flexibilitet. Varje organisation har olika prioriteringar som påverkar de designval som görs i varje pelare. När du utformar din arkitektur måste du avgöra vilka kompromisser som är acceptabla och vilka som inte är det.

När du skapar en Azure-arkitektur finns det många saker att tänka på. Du vill att din arkitektur är säker, skalbar, tillgänglig och återställningsbar. För att göra det möjligt måste du fatta beslut baserat på kostnader, organisationsprioriteringar och risker.