Tworzenie pod kątem potrzeb biznesowych
Każda decyzja projektowa musi być uzasadniona potrzebą biznesową. Ta zasada projektowania może wydawać się oczywista, ale ma kluczowe znaczenie dla projektowania aplikacji platformy Azure.
Czy twoja aplikacja musi obsługiwać miliony użytkowników, czy kilka tysięcy? Czy występują duże wzrosty ruchu, czy stałe obciążenie? Jaki poziom awarii aplikacji jest akceptowalny? Ostatecznie wymagania biznesowe napędzają te zagadnienia dotyczące projektowania.
Poniższe zalecenia ułatwiają projektowanie i tworzenie rozwiązań spełniających wymagania biznesowe:
Zdefiniuj cele biznesowe, takie jak cel czasu odzyskiwania (RTO), cel punktu odzyskiwania (RPO) i maksymalna tolerowana awaria (MTO). Te liczby powinny ułatwić podjęcie decyzji o architekturze.
Załóżmy na przykład, że Twoja firma wymaga bardzo niskiego celu czasu odzyskiwania i bardzo niskiego celu punktu odzyskiwania. Możesz użyć architektury strefowo nadmiarowej, aby spełnić te wymagania. Jeśli twoja firma może tolerować wyższy cel czasu odzyskiwania i cel punktu odzyskiwania, dodanie nadmiarowości może zwiększyć dodatkowe koszty bez korzyści biznesowych.
Rozważ ryzyko awarii, które należy wyeliminować. Postępuj zgodnie ze wskazówkami dotyczącymi samodzielnego naprawiania, aby zaprojektować rozwiązanie tak, aby było odporne na wiele typów typowych trybów awarii. Zastanów się, czy należy uwzględnić mniej prawdopodobne sytuacje, takie jak obszar geograficzny, w którym występuje poważna klęska żywiołowa, która może mieć wpływ na wszystkie strefy dostępności w regionie. Łagodzenie tych nietypowych zagrożeń jest na ogół droższe i wiąże się ze znaczącymi kompromisami, dlatego jasne jest zrozumienie tolerancji firmy na ryzyko.
Dokumentowanie umów dotyczących poziomu usług (SLA) i celów poziomu usług (SLO), w tym metryk dostępności i wydajności. Na przykład proponowane rozwiązanie może zapewnić dostępność na 99,95%. To, czy cel slo spełnia umowę SLA, jest decyzją biznesową.
Modelowanie aplikacji dla domeny biznesowej. Przeanalizuj wymagania biznesowe i użyj tych wymagań, aby modelować rozwiązanie. Rozważ użycie podejścia do projektowania opartego na domenie (DDD) w celu utworzenia modeli domen, które odzwierciedlają procesy biznesowe i przypadki użycia.
Zdefiniuj wymagania funkcjonalne i niefunkcjonalne. Wymagania funkcjonalne określają, czy aplikacja wykonuje swoje zadanie. Wymagania niefunkcjonalne określają, jak dobrze działa aplikacja. Upewnij się, że rozumiesz wymagania niefunkcjonalne, takie jak skalowalność, dostępność i opóźnienie. Te wymagania wpływają na decyzje projektowe i wybory technologiczne.
Dekompiluj obciążenia w dyskretne funkcje. Obciążenie to kolekcja zasobów aplikacji, danych i infrastruktury pomocniczej, która działa razem w celu osiągnięcia zdefiniowanych wyników biznesowych. Obciążenie składa się ze składników, a także procedur programistycznych i operacyjnych. Obciążenia często można rozkładać na dyskretne funkcje, które są zgodne z przepływami użytkownika, danych lub systemu, a te przepływy mogą być przypisywane wartości i mają wymagania niefunkcjonalne.
Różne przepływy użytkowników, danych lub systemu często mają różne wymagania dotyczące dostępności, skalowalności, spójności danych i odzyskiwania po awarii. Dobrze zaprojektowane systemy umożliwiają optymalizowanie projektu na przepływ. Aby to osiągnąć, należy podzielić obciążenia na regulowane składniki. Typowa strategia obejmuje kategoryzowanie składników na podstawie ich wartości. Na przykład składniki warstwy 1 mają kluczowe znaczenie i powinny być zoptymalizowane bez względu na wydatki. Składniki warstwy 2 są znaczące, ale można je tymczasowo zmniejszyć z minimalnymi konsekwencjami. Składniki warstwy 3 są opcjonalne; zachować je ekonomiczne i łatwe do zarządzania. Ustanowienie wspólnego zrozumienia wartości przepływów pomaga wszystkim projektować i rozwijać obciążenie, zachować równowagę między kosztami a innymi wymaganiami niefunkcjonalne.
Zaplanuj wzrost. Rozwiązanie może obsługiwać bieżące potrzeby dotyczące liczby użytkowników, woluminów transakcji i magazynu danych, ale musi również obsługiwać wzrost bez istotnych zmian architektury. Należy również wziąć pod uwagę, że model biznesowy i wymagania biznesowe mogą ulec zmianie w czasie. Trudno jest rozwinąć rozwiązanie dla nowych przypadków użycia i scenariuszy, jeśli model usługi i modele danych aplikacji są zbyt sztywne.
Dopasowanie modelu biznesowego i kosztów. Długowieczność systemu ma wpływ na to, jak skutecznie jego koszty są zgodne z modelem biznesowym. Jako architekt musisz wziąć pod uwagę czynniki wartości i użyć tych szczegółowych informacji, aby kierować decyzjami. Należy zidentyfikować wymiar, w którym rozwiązanie będzie dostarczać wartość (np. rentowność), a następnie upewnić się, że architektura jest zgodna ze strumieniem wartości. Dzięki temu architektura może zmaksymalizować wartość inwestycji, co daje zwrot z inwestycji (ROI), który jest zgodny z oczekiwaniami biznesowymi.
Zarządzaj kosztami. W tradycyjnej aplikacji lokalnej płacisz z góry za sprzęt jako wydatki kapitałowe. W aplikacji w chmurze płacisz za używane zasoby. Upewnij się, że rozumiesz model cen usług. Łączne koszty mogą obejmować użycie przepustowości sieci, magazyn, adresy IP i użycie usługi.
Należy również rozważyć koszty operacji. W chmurze nie musisz zarządzać sprzętem ani infrastrukturą, ale nadal musisz zarządzać usługą DevOps aplikacji, reagowaniem na zdarzenia i odzyskiwaniem po awarii.