Altijd rekening houden met de zakelijke behoeften

Elk ontwerpbesluit moet worden onderbouwd door een bedrijfsvereiste

Dit ontwerpprincipe kan duidelijk zijn, maar het is wel belangrijk om dit steeds in het achterhoofd te houden bij het ontwerpen van een oplossing. Verwacht u miljoenen gebruikers of een paar duizend? Is een toepassingsstoring van één uur acceptabel? Verwacht u grote bursts in het verkeer of een voorspelbare workload? Uiteindelijk moet elk ontwerpbesluit worden onderbouwd door een bedrijfsvereiste.

Aanbevelingen

Definieer bedrijfsdoelstellingen, waaronder de beoogde hersteltijd (RTO), het beoogde herstelpunt (RPO) en de maximale toegestane onderbreking (MTO). Deze cijfers moeten leidend zijn voor beslissingen over de architectuur. Als u bijvoorbeeld een lage RTO wilt, kunt u kiezen voor automatische failover naar een secundaire regio. Maar als uw oplossing overweg kan met een hogere RTO, is die mate van redundantie mogelijk niet nodig.

Documenteer SLA's (Service Level Agreements) en serviceniveaudoelstellingen (SLO's), met inbegrip van beschikbaarheid en prestatiemetrieken. U kunt bijvoorbeeld een oplossing bouwen met een beschikbaarheid van 99,95%. Is dat voldoende? Het antwoord is een zakelijke overweging.

Modelleer de toepassing rond het bedrijfsdomein. Begin met een analyse van de bedrijfsvereisten. Gebruik deze vereisten om de toepassing te modelleren. Overweeg het gebruik van een DDD-aanpak (Domain-Driven Design) om domeinmodellen te maken die de bedrijfsprocessen en gebruiksscenario's weerspiegelen.

Verzamel zowel functionele als niet-functionele vereisten. Functionele vereisten maken het mogelijk om te beoordelen of de toepassing de juiste dingen doet. Niet-functionele vereisten maken het mogelijk om te beoordelen of de toepassing die dingen goed doet. Het is met name belangrijk dat u een goed beeld hebt van de vereisten ten aanzien van schaalbaarheid, beschikbaarheid en latentie. Deze vereisten hebben namelijk invloed op ontwerpbeslissingen en de keuze van de technologie.

Decomposeren op workload. Binnen deze context betekent de term werkbelasting een op zichzelf staande capaciteit of rekentaak, die logisch kan worden gescheiden van andere taken. Verschillende werkbelastingen hebben mogelijk verschillende vereisten voor beschikbaarheid, schaalbaarheid, gegevensconsistentie en herstel na noodgevallen.

Houd rekening met groei. Het is goed mogelijk dat een oplossing voldoet aan de huidige behoeften, voor zaken zoals het aantal gebruikers, het transactievolume en de opslag van gegevens. Een robuuste toepassing moet echter kunnen meegroeien zonder dat de architectuur ingrijpend hoeft te worden aangepast. Zie Ontwerpen voor uitschalen en Partitioneren rond limieten voor meer informatie. Houd er ook rekening mee dat uw bedrijfsmodel en zakelijke vereisten na verloop van tijd waarschijnlijk zullen veranderen. Als het servicemodel en de gegevensmodellen van een toepassing te star zijn, wordt het lastig om de toepassing aan te passen voor nieuwe gebruiksvoorbeelden en -scenario's. Zie Ontwerpen voor evolutie voor meer informatie.

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 begrijpt dat wordt gehanteerd voor de services die u wilt gebruiken. De totale kosten omvatten het gebruik van netwerkbandbreedte, opslag, IP-adressen, services en andere factoren. Zie Prijzen voor Azure voor meer informatie. Vergeet ook niet uw operationele kosten. In de cloud hoeft u weliswaar niet de hardware of andere infrastructuur te beheren, maar u bent wel zelf verantwoordelijk voor het beheer van uw toepassingen, waaronder DevOps, respons op incidenten, herstel na noodgevallen, enzovoort.