Skapa för affärsbehov
Alla designbeslut måste motiveras av ett behov i verksamheten. Den här designprincipen kan verka uppenbar, men är viktig att tänka på när du utformar Azure-program.
Måste programmet ha stöd för miljontals användare, eller några tusen? Finns det stora trafiktoppar eller en stadig arbetsbelastning? Vilken nivå av programstopp är acceptabelt? I slutändan driver affärskraven dessa designöverväganden.
Följande rekommendationer hjälper dig att utforma och skapa lösningar som uppfyller affärskraven:
Definiera affärsmål som mål för återställningstid (RTO), mål för återställningspunkt (RPO) och maximalt acceptabelt avbrott (MTO). Låt siffrorna ligga till grund för beslut om arkitekturen.
Anta till exempel att ditt företag kräver en mycket låg RTO och ett mycket lågt RPO. Du kan välja att använda en zonredundant arkitektur för att uppfylla dessa krav. Om ditt företag kan tolerera en högre RTO och RPO, kan tillägg av redundans lägga till extra kostnad utan affärsförmån.
Tänk på de felrisker som du behöver minimera. Följ designen för självåterställningsvägledning för att utforma din lösning så att den är motståndskraftig mot många typer av vanliga fellägen. Fundera på om du behöver ta hänsyn till mindre sannolika situationer, till exempel ett geografiskt område som drabbas av en större naturkatastrof som kan påverka alla tillgänglighetszoner i regionen. Att mildra dessa ovanliga risker är i allmänhet dyrare och innebär betydande kompromisser, så ha en tydlig förståelse för företagets risktolerans.
Dokumentera serviceavtal (serviceavtal) och servicenivåmål (SLO), inklusive tillgänglighets- och prestandamått. En föreslagen lösning kan till exempel ge 99,95 % tillgänglighet. Om detta serviceavtal uppfyller serviceavtalet är ett affärsbeslut.
Modellera program för din affärsdomän. Analysera affärskraven och använd dessa krav för att modellera lösningen. Överväg att använda en domändriven designmetod (DDD) för att skapa domänmodeller som återspeglar dina affärsprocesser och användningsfall.
Definiera funktionella och icke-funktionella krav. Funktionskrav avgör om ett program utför sin uppgift. Icke-funktionella krav avgör hur bra programmet presterar. Se till att du förstår icke-funktionella krav som skalbarhet, tillgänglighet och svarstid. Dessa krav påverkar designbeslut och teknikval.
Dela upp arbetsbelastningar i diskreta funktioner. En arbetsbelastning är en samling programresurser, data och stödinfrastruktur som fungerar tillsammans för att uppnå definierade affärsresultat. En arbetsbelastning består av komponenter och även utvecklings- och driftprocedurer. Arbetsbelastningar kan ofta delas upp i diskreta funktioner som överensstämmer med användar-, data- eller systemflöden och dessa flöden kan tillskrivas värde och ha icke-funktionella krav.
Olika användar-, data- eller systemflöden har ofta olika krav för tillgänglighet, skalbarhet, datakonsekvens och haveriberedskap. Med väl utformade system kan du optimera din design per flöde. För att uppnå detta måste du dela upp arbetsbelastningar i justerbara komponenter. En typisk strategi omfattar kategorisering av komponenter baserat på deras värde. Nivå 1-komponenter är till exempel avgörande och bör optimeras utan hänsyn till kostnader. Nivå 2-komponenter är betydande men kan tillfälligt minskas med minimala konsekvenser. Nivå 3-komponenter är valfria. hålla dem kostnadseffektiva och lätt hanterbara. Genom att skapa en gemensam förståelse för värdet av flöden kan alla utforma och utveckla en arbetsbelastning för att hålla balansen mellan kostnader och andra icke-funktionella krav.
Planera för tillväxt. En lösning kan ha stöd för aktuella behov för antal användare, transaktionsvolymer och datalagring, men den måste också hantera tillväxt utan större arkitektoniska ändringar. Tänk också på att din affärsmodell och dina affärskrav kan ändras över tid. Det är svårt att utveckla en lösning för nya användningsfall och scenarier om programmets tjänstmodell och datamodeller är för stela.
Justera affärsmodell och kostnad. Systemets livslängd påverkas av hur effektivt dess kostnader överensstämmer med affärsmodellen. Som arkitekt måste du överväga värdedrivrutiner och använda den insikten för att vägleda dina beslut. Du bör identifiera dimensionen där din lösning kommer att tillhandahålla värde (till exempel lönsamhet) och sedan se till att arkitekturen följer värdeströmmen. På så sätt kan din arkitektur maximera investeringsvärdet och ge avkastning på investeringen (ROI) som är anpassad till företagets förväntningar.
Hantera kostnader. I ett traditionellt lokalt program betalar du i förväg för maskinvara som kapitalutgifter. I ett molnprogram betalar du för de resurser du använder. Se till att du förstår dina tjänsters prismodell. De totala kostnaderna kan omfatta användning av nätverksbandbredd, lagring, IP-adresser och tjänstförbrukning.
Överväg även driftkostnader. I molnet behöver du inte hantera maskinvara eller infrastruktur, men du behöver fortfarande hantera programmet DevOps, incidenthantering och haveriberedskap.