Bouwen voor bedrijfsbehoeften

Elk ontwerpbesluit moet worden onderbouwd door een bedrijfsvereiste. Dit ontwerpprincipe lijkt misschien voor de hand liggend, maar is van cruciaal belang om rekening mee 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 constante werkbelasting? Welk niveau van toepassingsuitval is acceptabel? Uiteindelijk worden deze ontwerpoverwegingen door zakelijke vereisten aangedreven.

De volgende aanbevelingen helpen u bij het ontwerpen en bouwen van oplossingen om te voldoen aan bedrijfsvereisten:

  • Definieer bedrijfsdoelstellingen zoals RTO (Recovery Time Objective), Recovery Point Objective (RPO) en maximaal toegestane onderbreking (MTO). Deze cijfers moeten leidend zijn voor beslissingen over de architectuur.

    Stel dat uw bedrijf een zeer lage RTO en een zeer lage RPO vereist. 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 kan tolereren, kan het toevoegen van redundantie extra kosten met zich mee, zonder dat dit bedrijfsvoordeel oplevert.

  • Houd rekening met de foutrisico's die u moet beperken. Volg de richtlijnen ontwerpen voor zelfherstel 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 alle beschikbaarheidszones in de regio kan treffen. Het beperken van deze ongebruikelijke risico's is over het algemeen duurder en brengt aanzienlijke compromissen met zich mee, dus zorg ervoor dat u een duidelijk inzicht hebt in de risicotolerantie van het bedrijf.

  • 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.

  • Modelleer toepassingen 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 uw bedrijfsprocessen en gebruiksvoorbeelden weerspiegelen.

  • Definieer functionele en niet-functionele vereisten. Functionele vereisten bepalen of een toepassing de taak uitvoert. Niet-functionele vereisten bepalen hoe goed de toepassing presteert. Zorg ervoor dat u inzicht hebt in niet-functionele vereisten, zoals schaalbaarheid, beschikbaarheid en latentie. Deze vereisten zijn van invloed op ontwerpbeslissingen en technologische keuzes.

  • Werkbelastingen opstropen. Workload in deze context betekent een discrete mogelijkheid of rekentaak die logisch kan worden gescheiden van andere taken. Verschillende workloads kunnen verschillende vereisten hebben voor beschikbaarheid, schaalbaarheid, gegevensconsistentie en herstel na noodgevallen.

  • Houd rekening met groei. Een oplossing kan ondersteuning bieden voor de huidige behoeften voor het aantal gebruikers, het transactievolume en de gegevensopslag, maar moet ook de groei kunnen verwerken zonder grote architectuurwijzigingen. 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 gebruiksscenario's en scenario's als het servicemodel en de gegevensmodellen van de toepassing te star zijn.

  • Kosten beheren. 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. De totale kosten kunnen bestaan uit netwerkbandbreedtegebruik, opslag, IP-adressen en serviceverbruik.

    Houd ook rekening met operationele kosten. In de cloud hoeft u geen hardware of infrastructuur te beheren, maar u moet wel de DevOps-toepassing, incidentrespons en herstel na noodgevallen beheren.

Volgende stappen