Bygg efter behoven i verksamheten

Alla designbeslut måste motiveras av ett behov i verksamheten

Den här designprincipen kan tyckas självklar, men är ändå viktig att ha i åtanke när du ska utforma en lösning. Förväntar du dig flera miljoner användare eller några tusen? Är ett programavbrott på en timme acceptabelt? Förväntar du dig stora trafikstörningar eller en förutsägbar arbetsbelastning? I slutändan måste alla designbeslut motiveras av ett behov i verksamheten.

Rekommendationer

Definiera affärsmål, inklusive mål för återställningstid (RTO), mål för återställningspunkt (RPO) och högsta tillåtna avbrottstid (MTO). Låt siffrorna ligga till grund för beslut om arkitekturen. För att uppnå ett lågt RTO-värde kan du till exempel implementera automatisk redundansväxling till en sekundär region. Klarar din lösning däremot ett högre RTO-värde kanske en sådan hög redundans inte är nödvändig.

Dokumentera servicenivåavtal (SLA) och servicenivåmål (SLO), inklusive statistik för tillgänglighet och prestanda. Kanske ger lösningen du bygger en tillgänglighet på 99,95 %. Räcker det? Svaret är ett affärsbeslut.

Modellera tillämpningen utifrån företagsdomänen. Börja med att analysera affärskraven. Utgå från dessa krav när du modellerar tillämpningen. Överväg att använda en metod med en domän-driven design (DDD) för att skapa domänmodeller som återspeglar affärsprocesser och användningsfall.

Sammanställ både funktionella och icke-funktionella krav. Funktionella krav ger dig möjlighet att bedöma om programmet uppnår rätt mål. Icke-funktionella krav ger dig möjlighet att bedöma om programmet uppnår de rätta målen på ett effektivt sätt. Framför allt är det viktigt att du förstår dina krav avseende skalbarhet, tillgänglighet och svarstid. Dessa krav påverkar dina designbeslut och valet av teknik.

Uppdela efter arbetsbelastning. Begreppet ”arbetsbelastning” i det här sammanhanget är en diskret funktion eller beräkningsuppgift som logiskt kan separeras från andra uppgifter. Olika arbetsbelastningar kan ställa olika krav på tillgänglighet, skalbarhet, datakonsekvens och haveriberedskap.

Planera för tillväxt. En lösning kanske uppfyller dina befintliga behov vad gäller antalet användare, transaktionsvolym, datalagring och så vidare. En robust tillämpning kan i stället hantera tillväxt utan några större förändringar av arkitekturen. Se Design för skalbarhet och Partition runt gränser. Ta också hänsyn till att din affärsmodell och dina affärskrav troligen kommer att förändras över tid. Om service- och datamodellerna för en tillämpning är alltför fasta blir det svårt att vidareutveckla tillämpningen för nya användningsområden och scenarier. Se Design för utveckling.

Hantera kostnader. I ett traditionellt lokalt program betalar du i förskott för maskinvara som kapitalutgifter. Med en molnbaserad tillämpning betalar du för de resurser du förbrukar. Se till att du förstår prismodellen för de tjänster som du använder. Den totala kostnaden omfattar utnyttjande av nätverksbandbredd, lagring, IP-adresser, användning av tjänster och andra faktorer. Mer information finns i Priser för Azure. Du bör också ta hänsyn till dina driftskostnader. Du behöver inte hantera maskinvara eller annan infrastruktur i molnet, men du behöver fortfarande kunna hantera tillämpningar som DevOps, incidentåtgärder, katastrofåterställning och så vidare.