Sdílet prostřednictvím

Vytvářejte pro obchodní potřeby

Každé rozhodnutí o návrhu musí být podloženo obchodním požadavkem. Tento princip návrhu může vypadat jako zřejmý, ale při návrhu aplikací Azure je zásadní mít na paměti.

Musí vaše aplikace podporovat miliony uživatelů nebo několik tisíc? Dochází k velkým nárůstům provozu nebo stabilnímu zatížení? Jaká úroveň výpadku aplikace je přijatelná? Obchodní požadavky nakonec tyto aspekty návrhu řídí.

Následující doporučení vám pomůžou navrhnout a sestavit řešení, která splňují obchodní požadavky:

  • Definujte obchodní cíle , jako je cíl doby obnovení (RTO), cíl bodu obnovení (RPO) a maximální tolerovatelný výpadek (MTO). Tato čísla by měla být podkladem pro rozhodnutí o architektuře.

    Předpokládejme například, že vaše firma vyžaduje velmi nízké RTO a velmi nízké RPO. K splnění těchto požadavků můžete použít zónově redundantní architekturu. Pokud vaše firma dokáže tolerovat vyšší dobu obnovení (RTO - Recovery Time Objective) a cíl bodu obnovení (RPO - Recovery Point Objective), může přidání nadbytečného zabezpečení přinést další náklady bez obchodního přínosu.

  • Zvažte rizika selhání, která potřebujete zmírnit. Pokud chcete navrhnout řešení tak, aby bylo odolné vůči mnoha typům běžných režimů selhání, postupujte podle pokynů návrhu pro samoopravení. Zvažte, jestli potřebujete zohlednit méně pravděpodobné situace, jako je geografická oblast, u které dochází k závažné přírodní katastrofě, která by mohla ovlivnit všechny zóny dostupnosti v dané oblasti. Zmírňování těchto neobvyklých rizik je obecně dražší a zahrnuje významné kompromisy, proto mějte jasné porozumění k toleranci podnikání vůči riziku.

  • Zdokumentují smlouvy o úrovni služeb (SLA) a cíle úrovně služeb (SLA), včetně metrik dostupnosti a výkonu. Například navrhované řešení může poskytovat 99,95% dostupnost. Zda SLO splňuje SLA, je obchodní rozhodnutí.

  • Modelujte aplikace pro vaši obchodní doménu. Analyzujte obchodní požadavky a tyto požadavky použijte k modelování řešení. Zvažte použití přístupu návrhu řízeného doménou (DDD) k vytváření doménových modelů, které odrážejí obchodní procesy a případy použití.

  • Definujte funkční a nefunkční požadavky. Funkční požadavky určují, jestli aplikace provádí svou úlohu. Nefunkční požadavky určují, jak dobře aplikace funguje. Ujistěte se, že rozumíte nefunkčním požadavkům, jako je škálovatelnost, dostupnost a latence. Tyto požadavky ovlivňují rozhodnutí o návrhu a technologické volby.

  • Rozdělte úlohy do samostatných funkcí. Úloha je kolekce prostředků aplikací, dat a podpůrné infrastruktury, které společně fungují, aby bylo dosaženo definovaných obchodních výsledků. Úloha se skládá z komponent a také vývojových a provozních postupů. Úlohy se často dají rozdělit do diskrétních funkcí, které odpovídají tokům uživatelů, dat nebo systémů a tyto toky můžou být přiřazené hodnotě a mají nefunkční požadavky.

    Různé toky uživatelů, dat nebo systémů mají často různé požadavky na dostupnost, škálovatelnost, konzistenci dat a zotavení po havárii. Dobře navržené systémy vám umožňují optimalizovat svůj návrh pro jednotlivé toky. Abyste toho dosáhli, musíte rozdělit úlohy do upravitelných komponent. Typická strategie zahrnuje kategorizaci komponent na základě jejich hodnoty. Například komponenty vrstvy 1 jsou zásadní a měly by být optimalizované bez ohledu na výdaje. Komponenty vrstvy 2 jsou významné, ale je možné je dočasně snížit s minimálními důsledky. Komponenty vrstvy 3 jsou volitelné; udržovat je nákladově efektivní a snadno spravovatelné. Vytvoření sdíleného porozumění hodnotě toků pomáhá každému navrhovat a vyvíjet úlohu, udržovat rovnováhu mezi náklady a dalšími požadavky na nefunkční funkce.

  • Plánujte růst. Řešení může podporovat aktuální potřeby počtu uživatelů, objemu transakcí a úložiště dat, ale musí také zvládnout růst bez velkých změn architektury. Vezměte také v úvahu, že se obchodní model a obchodní požadavky můžou v průběhu času měnit. Je těžké vyvíjet řešení pro nové případy použití a scénáře, pokud je model služeb a datové modely aplikace příliš pevné.

  • Sladění obchodního modelu a nákladů Dlouhověkost systému je ovlivněna tím, jak efektivně jsou náklady v souladu s obchodním modelem. Jako architekt musíte zvážit hodnoty obchodních faktorů a tento přehled použít k vedení vašich rozhodnutí. Měli byste identifikovat dimenzi, ve které vaše řešení poskytuje hodnotu (například ziskovost), a pak se ujistěte, že architektura následuje po hodnotovém toku. Díky tomu může vaše architektura maximalizovat hodnotu pro investice a přinést návratnost investic (ROI), která je v souladu s obchodními očekáváními.

  • Spravujte náklady. V tradiční místní aplikaci platíte předem za hardware jako kapitálové výdaje. V cloudové aplikaci platíte za prostředky, které využíváte. Ujistěte se, že rozumíte cenovému modelu služeb. Celkové náklady můžou zahrnovat využití šířky pásma sítě, úložiště, IP adresy a spotřebu služeb.

    Zvažte také provozní náklady. V cloudu nemusíte spravovat hardware ani infrastrukturu, ale stále potřebujete spravovat aplikace DevOps, reakce na incidenty a zotavení po havárii.

Další kroky

  • Last updated on