Sestavování pro obchodní potřeby

  • Článek
  • 2 min ke čtení

Každé rozhodnutí o návrhu musí být podloženo obchodním požadavkem.

Tento princip návrhu se může zdát zřejmý, ale je velmi důležité na něj při návrhu řešení pamatovat. Předpokládáte miliony uživatelů nebo několik tisíc počítačů? Je jednorázové výpadky aplikace přijatelné? Očekáváte velké shluky v provozu nebo předvídatelné zatížení? Každé rozhodnutí o návrhu musí být nakonec podloženo obchodním požadavkem.

Doporučení

Definujte obchodní cíle organizace, včetně plánované doby obnovení (RTO), cíle bodu obnovení (RPO) a maximálního přípustného výpadku (MTO). Tato čísla by měla být podkladem pro rozhodnutí o architektuře. K dosažení nízké hodnoty RTO můžete například implementovat automatické převzetí služeb při selhání v sekundární oblasti. Pokud ale vaše řešení může tolerovat vyšší hodnotu RTO, může být tento stupeň redundance zbytečný.

Zdokumentujte smlouvy o úrovni služeb (SLA) a cíle úrovně služeb (SLO), včetně metrik dostupnosti a výkonu. Může vytvářet řešení, které nabízí 99,95% dostupnost. Je to dostatečné? Odpověď je obchodním rozhodnutím.

Modelujte aplikaci kolem obchodní domény. Začněte analýzou obchodních požadavků. Použijte tyto požadavky k modelování aplikace. Zvažte použití přístupu pomocí návrhu řízeného doménou (DDD) k vytvoření modelů domény, které odrážejí obchodní procesy a případy použití.

Zachyťte požadavky na funkce i jiné požadavky. Požadavky na funkce umožňují posoudit, jestli aplikace dělá správné věci. Jiné požadavky umožňují posoudit, jestli aplikace dělá tyto věci dobře. Konkrétně se ujistěte, že rozumíte požadavkům na škálovatelnost, dostupnost a latenci. Tyto požadavky ovlivní rozhodnutí o návrhu a volbu technologie.

Rozložit podle úlohy. Pod pojmem „úloha“ v tomto kontextu rozumíme oddělenou funkci nebo výpočetní úkol, které je možné logicky oddělit od ostatních úloh. Různé úlohy můžou mít různé požadavky na dostupnost, škálovatelnost, konzistenci dat a zotavení po havárii.

Plánujte růst. Řešení může vyhovovat vašim aktuálním potřebám z hlediska počtu uživatelů, objemu transakcí, úložiště dat a tak dále. Robustní aplikace ale může zvládnout růst bez významných změn architektury. Přečtěte si témata Návrh pro horizontální navýšení kapacity a Obcházení omezení prostřednictvím dělení. Mějte také na paměti, že váš obchodní model a obchodní požadavky se pravděpodobně časem změní. Pokud budou model služby a datové modely aplikace příliš pevné, bude obtížné rozvíjet aplikaci pro nové případy použití a scénáře. Přečtěte si Návrh s možností dalšího vývoje.

Spravujte náklady. V tradiční místní aplikaci platíte předem svůj hardware jako kapitálové výdaje. V cloudové aplikaci platíte za prostředky, které spotřebujete. Ujistěte se, že rozumíte cenovém modelu pro služby, které spotřebováváte. Celkové náklady budou zahrnovat využití šířky pásma sítě, úložiště, IP adresy, používání služeb a další faktory. Další informace najdete v tématu ceny Azure. Zvažte také provozní náklady. V cloudu nemusíte spravovat hardware nebo další infrastrukturu, ale pořád potřebujete spravovat vaše aplikace, včetně DevOps, reakce na incidenty, zotavení po havárii a tak dále.