Bouwen voor zakelijke behoeften
Elk ontwerpbesluit moet worden onderbouwd door een bedrijfsvereiste. Dit ontwerpprincipe lijkt misschien duidelijk, maar is van cruciaal belang om rekening te houden bij het ontwerpen van Azure-toepassingen.
Moet uw toepassing miljoenen gebruikers of een paar duizend gebruikers ondersteunen? Zijn er grote verkeerspieken of een stabiele werkbelasting? Welk niveau van toepassingsstoring is acceptabel? Uiteindelijk zijn zakelijke vereisten een basis voor deze ontwerpoverwegingen.
De volgende aanbevelingen helpen u bij het ontwerpen en bouwen van oplossingen om te voldoen aan bedrijfsvereisten:
Definieer bedrijfsdoelstellingen zoals beoogde hersteltijd (RTO), RPO (Recovery Point Objective) en maximale toegestane storing (MTO). Deze cijfers moeten leidend zijn voor beslissingen over de architectuur.
Stel dat uw bedrijf een zeer lage RTO en een zeer lage RPO nodig heeft. U kunt ervoor kiezen om een zone-redundante architectuur te gebruiken om aan deze vereisten te voldoen. Als uw bedrijf een hogere RTO en RPO tolereert, kan het toevoegen van redundantie extra kosten toevoegen zonder bedrijfsvoordeel.
Houd rekening met de foutrisico's die u moet beperken. Volg het ontwerp voor zelfherstelrichtlijnen om uw oplossing zo te ontwerpen dat deze bestand is tegen veel soorten veelvoorkomende foutmodi. Overweeg of u rekening moet houden met minder waarschijnlijke situaties, zoals een geografisch gebied met een grote natuurramp die van invloed kan zijn op alle beschikbaarheidszones in de regio. Het beperken van deze ongebruikelijke risico's is over het algemeen duurder en brengt aanzienlijke compromissen met zich mee, dus heb een duidelijk inzicht in de tolerantie van het bedrijf voor risico's.
Documenteer serviceovereenkomsten (SLA's) en serviceniveaudoelstellingen (SLO's), inclusief metrische gegevens over beschikbaarheid en prestaties. Een voorgestelde oplossing kan bijvoorbeeld een beschikbaarheid van 99,95% opleveren. Of die SLO voldoet aan de SLA, is een zakelijke beslissing.
Modeltoepassingen voor uw bedrijfsdomein. Analyseer de bedrijfsvereisten en gebruik deze vereisten om de oplossing te modelleren. Overweeg het gebruik van een DDD-benadering (Domain-Driven Design) om domeinmodellen te maken die overeenkomen met uw bedrijfsprocessen en gebruiksvoorbeelden.
Functionele en niet-functionele vereisten definiëren. Functionele vereisten bepalen of een toepassing de taak uitvoert. Niet-functionele vereisten bepalen hoe goed de toepassing presteert. Zorg ervoor dat u weet wat niet-functionele vereisten zijn, zoals schaalbaarheid, beschikbaarheid en latentie. Deze vereisten zijn van invloed op ontwerpbeslissingen en technologische keuzes.
Werkbelastingen ontleden in discrete functionaliteit. Een workload is een verzameling toepassingsresources, gegevens en ondersteunende infrastructuur die samenwerken om gedefinieerde bedrijfsresultaten te bereiken. Een workload bestaat uit onderdelen en ook ontwikkel- en operationele procedures. Workloads kunnen vaak worden opgesplitst in discrete functionaliteit die is afgestemd op gebruikers-, gegevens- of systeemstromen en deze stromen kunnen worden toegeschreven aan waarde en niet-functionele vereisten hebben.
Verschillende gebruikers-, gegevens- of systeemstromen hebben vaak verschillende vereisten voor beschikbaarheid, schaalbaarheid, gegevensconsistentie en herstel na noodgevallen. Met goed ontworpen systemen kunt u uw ontwerp per stroom optimaliseren. Hiervoor moet u workloads opsplitsen in aanpasbare onderdelen. Een typische strategie omvat het categoriseren van onderdelen op basis van hun waarde. Laag 1-onderdelen zijn bijvoorbeeld cruciaal en moeten worden geoptimaliseerd zonder rekening te houden met kosten. Laag 2-onderdelen zijn aanzienlijk, maar kunnen tijdelijk worden verminderd met minimale gevolgen. Onderdelen van laag 3 zijn optioneel; houd ze kostenefficiënt en gemakkelijk beheersbaar. Door een gedeeld inzicht te krijgen in de waarde van stromen, kan iedereen een workload ontwerpen en ontwikkelen, een evenwicht houden tussen kosten en andere niet-functionele vereisten.
Houd rekening met groei. Een oplossing ondersteunt mogelijk de huidige behoeften voor het aantal gebruikers, het transactievolume en de gegevensopslag, maar moet ook de groei afhandelen zonder grote architecturale wijzigingen. Houd er ook rekening mee dat uw bedrijfsmodel en bedrijfsvereisten na verloop van tijd kunnen veranderen. Het is moeilijk om een oplossing te ontwikkelen voor nieuwe use cases en scenario's als het servicemodel en de gegevensmodellen van de toepassing te stijf zijn.
Bedrijfsmodel en -kosten uitlijnen. De levensduur van een systeem wordt beïnvloed door hoe effectief de kosten in overeenstemming zijn met het bedrijfsmodel. Als architect moet u waardefactoren overwegen en dat inzicht gebruiken om uw beslissingen te begeleiden. U moet de dimensie identificeren waarin uw oplossing waarde levert (zoals winstgevendheid), en zorg ervoor dat de architectuur de waardestroom volgt. Op deze manier kan uw architectuur de waarde voor investeringen maximaliseren, wat resulteert in een rendement op investeringen (ROI) dat is afgestemd op bedrijfsverwachtingen.
Houd de kosten onder controle. In een traditionele on-premises toepassing betaalt u vooraf voor hardware als kapitaaluitgaven. In een cloudtoepassing betaalt u voor de resources die u verbruikt. Zorg ervoor dat u het prijsmodel van uw services begrijpt. Totale kosten kunnen het gebruik van netwerkbandbreedte, opslag, IP-adressen en serviceverbruik omvatten.
Houd ook rekening met de kosten van bewerkingen. In de cloud hoeft u geen hardware of infrastructuur te beheren, maar u moet nog steeds toepassing DevOps, reactie op incidenten en herstel na noodgevallen beheren.