Build az üzleti igényekhez
Minden tervezési döntés legyen igazolható egy üzleti igénnyel. Ez a tervezési elv nyilvánvalónak tűnhet, de fontos szem előtt tartani az Azure-alkalmazások tervezésekor.
Az alkalmazásnak több millió felhasználót vagy néhány ezer felhasználót kell támogatnia? Nagy a forgalom, vagy állandó a számítási feladat? Milyen szintű alkalmazáskimaradás elfogadható? Végső soron az üzleti követelmények hajtják ezeket a tervezési szempontokat.
Az alábbi javaslatok segítenek az üzleti követelményeknek megfelelő megoldások tervezésében és összeállításában:
Üzleti célkitűzések meghatározása, például helyreállítási időkorlát (RTO), helyreállítási pont célkitűzése (RPO) és maximális tűrhető kimaradás (MTO). Az architektúrával kapcsolatos döntéseket ezen információk alapján kell meghoznia.
Tegyük fel például, hogy a vállalkozása nagyon alacsony RTO-t és nagyon alacsony RPO-t igényel. Dönthet úgy, hogy zónaredundáns architektúrát használ ezeknek a követelményeknek a teljesítéséhez. Ha vállalata képes elviselni a magasabb RTO-t és RPO-t, a redundancia hozzáadása többletköltséget jelenthet az üzleti előnyök nélkül.
Vegye figyelembe azokat a meghibásodási kockázatokat, amelyeket csökkentenie kell. Kövesse a Tervezés öngyógyító útmutatást , hogy a megoldás rugalmas legyen a gyakori meghibásodási módok számos típusával szemben. Fontolja meg, hogy figyelembe kell-e vennie a kevésbé valószínű helyzeteket, például egy olyan földrajzi területet, amely jelentős természeti katasztrófát tapasztal, amely a régió összes rendelkezésre állási zónáját érintheti. Ezeknek a nem gyakori kockázatoknak a mérséklése általában drágább, és jelentős kompromisszumokkal jár, ezért tisztában kell lenni a vállalkozás kockázattűrésével.
Szolgáltatásiszint-szerződések (SLA-k) és szolgáltatásiszint-célkitűzések (SLO-k) dokumentálása, beleértve a rendelkezésre állási és teljesítménymetrikákat. Egy javasolt megoldás például 99,95%-os rendelkezésre állást biztosíthat. Üzleti döntés, hogy az SLO megfelel-e az SLA-nak.
Modellalkalmazások üzleti tartományhoz. Elemezze az üzleti követelményeket, és használja ezeket a követelményeket a megoldás modellezéséhez. Fontolja meg a tartományalapú tervezési (DDD) megközelítés használatát az üzleti folyamatokat és használati eseteket tükröző tartománymodellek létrehozásához.
Funkcionális és nem funkcionális követelmények meghatározása. A funkcionális követelmények határozzák meg, hogy egy alkalmazás végrehajtja-e a feladatát. A nem funkcionális követelmények határozzák meg, hogy az alkalmazás milyen jól teljesít. Ügyeljen arra, hogy megértse a nem funkcionális követelményeket, például a méretezhetőséget, a rendelkezésre állást és a késést. Ezek a követelmények befolyásolják a tervezési döntéseket és a technológiai döntéseket.
Bontsa le a számítási feladatokat különálló funkciókra. A számítási feladatok olyan alkalmazáserőforrások, adatok és támogató infrastruktúra gyűjteményei, amelyek együttesen működnek a meghatározott üzleti eredmények elérése érdekében. A számítási feladatok összetevőkből, valamint fejlesztési és üzemeltetési eljárásokból állnak. A számítási feladatok gyakran különálló funkciókká bonthatók, amelyek összhangban vannak a felhasználóval, az adatokkal vagy a rendszerfolyamatokkal, és ezek a folyamatok hozzárendelhetők értékként, és nem funkcionális követelményekkel rendelkeznek.
A különböző felhasználói, adat- vagy rendszerfolyamatok gyakran eltérő követelményekkel rendelkeznek a rendelkezésre állásra, a méretezhetőségre, az adatkonzisztenciára és a vészhelyreállításra vonatkozóan. A jól megtervezett rendszerek lehetővé teszik a tervezés folyamatonkénti optimalizálását. Ennek eléréséhez a számítási feladatokat állítható összetevőkre kell bontania. Egy tipikus stratégia magában foglalja az összetevők érték alapján történő kategorizálását. Az 1. rétegbeli összetevők például kulcsfontosságúak, és költségmentesen kell optimalizálni. A 2. rétegbeli összetevők jelentősek, de minimális következményekkel átmenetileg csökkenthetők. A 3. rétegbeli összetevők nem kötelezőek; költséghatékonyak és könnyen kezelhetők. A folyamatok értékének közös megértése segít abban, hogy a számítási feladatok tervezése és fejlesztése mindenki számára egyensúlyt teremtsen a költségek és az egyéb nem funkcionális követelmények között.
Tervezzen a növekedéssel. Előfordulhat, hogy egy megoldás támogatja a felhasználók számának, a tranzakciómennyiségnek és az adattárolásnak a jelenlegi igényeit, de jelentős architekturális változások nélkül is kezelnie kell a növekedést. Vegye figyelembe azt is, hogy az üzleti modell és az üzleti követelmények idővel változhatnak. Nehéz új használati esetekre és forgatókönyvekre megoldást fejleszteni, ha az alkalmazás szolgáltatási modellje és adatmodelljei túl merevek.
Üzleti modell és költség igazítása. A rendszer élettartamát befolyásolja, hogy a költségek mennyire összhangban vannak az üzleti modellel. Tervezőként figyelembe kell vennie az értékhajtókat, és ezt a megállapítást kell használnia a döntések irányításához. Meg kell határoznia azt a dimenziót, amelyben a megoldás értéket fog nyújtani (például a jövedelmezőséget), majd győződjön meg arról, hogy az architektúra követi az értékáramot. Így az architektúra maximalizálhatja a befektetés értékét, és megtérülést (ROI) eredményez, amely igazodik az üzleti elvárásokhoz.
Felügyelje a költségeket. Egy hagyományos helyszíni alkalmazásban előre fizet a hardverért tőkeköltségként. Egy felhőalkalmazásban a felhasznált erőforrásokért kell fizetnie. Győződjön meg arról, hogy ismeri a szolgáltatások díjszabási modelljét. A teljes költség magában foglalhatja a hálózati sávszélesség használatát, a tárolást, az IP-címeket és a szolgáltatáshasználatot.
Vegye figyelembe az üzemeltetési költségeket is. A felhőben nem kell kezelnie a hardvert vagy az infrastruktúrát, de továbbra is kezelnie kell az alkalmazás DevOps-ját, az incidensmegoldást és a vészhelyreállítást.