Sdílet prostřednictvím

Přístupy architektury pro řídicí roviny ve víceklientských řešeních

  • Článek

Řídicí roviny jsou důležitou součástí softwaru jako služby (SaaS) a víceklientských řešení, zejména kvůli správě řešení ve velkém měřítku. Obvykle existují dvě hlavní komponenty, které tvoří řídicí rovinu:

  • Katalog tenantů, ve kterém jsou uložené důležité informace o vašich tenantech, například:
  • Procesy správy změn v prostředí, které se aktivují událostmi životního cyklu tenanta Například onboarding tenanta, offboarding tenanta a veškerá požadovaná pravidelná údržba.

Řídicí rovina je sama o sobě aplikací. Potřebujete pečlivě zvážit řídicí rovinu a navrhnout ji se stejnou rigorií a postarat se o to, abyste ji používali s jakoukoli jinou částí řešení. Další informace o tom, co je řídicí rovina, proč byste ji měli použít a co je potřeba vzít v úvahu při návrhu, najdete v tématu Důležité informace o řídicích rovinách s více tenanty.

Tento článek popisuje některé přístupy, které můžete zvážit při návrhu a vytvoření řídicí roviny. Seznam zde popsaných přístupů není vyčerpávající. I když jsou všechny přístupy platné, existují i další platné architektury.

Přístupy a vzory, které je potřeba zvážit

Následující tabulka shrnuje rozdíly mezi některými přístupy, které můžete zvážit pro řídicí rovinu. Ruční, nízkokódové a vlastní přístupy se porovnávají.

Situace Ruční Nízký kód Vlastní
Provozní režie Vysoká Nízká střední Nízká
Frekvence událostí životního cyklu, pro které je přístup vhodný Vzácný Občasné Často
Čas a složitost implementace Nízká Střední Vysoká
Odpovědnosti za údržbu řídicí roviny Nízká Střední Vysoká
Schopnost být testován Nízká Střední Vysoká
Riziko nekonzistence Vysoká Střední-nízká Nízká

Ruční procesy

Není vždy nezbytné vytvořit plně automatizovanou řídicí rovinu, zejména když začínáte a máte jen malý počet tenantů.

Katalog tenantů můžete mít někam centrálně umístěný, například v excelovém sešitu nebo souboru JSON uloženém v místě, ke kterému má váš tým přístup. Bez ohledu na formát je vhodné ukládat informace strukturovaným způsobem, abyste mohli snadno pracovat s daty prostřednictvím kódu programu.

Poznámka:

Ruční řídicí rovina je skvělý způsob, jak začít se správou víceklientské aplikace, ale je vhodný jenom pro malý počet tenantů (méně než 5–10). Administrativní režie a riziko nekonzistence se zvýší u každého tenanta, který ručně nasadíte. Tento přístup byste měli použít jenom v případě, že máte jenom několik tenantů a nepotřebujete automatizované nebo samoobslužné onboarding.

Pro procesy, jako je onboarding tenanta a aktivity údržby:

  • Kdykoli je to možné, vytvořte skripty nebo automatizované kanály, i když je spustíte ručně. Pomocí skriptů nebo kanálů zajistíte, aby se kroky spouštěly konzistentně pro každého tenanta.
  • U úkolů, které nemůžete na začátku skriptovat, důkladně a explicitně zdokumentujte proces. Zdokumentujte, jak a proč. Pokud někdo dokončí automatizaci úkolu v budoucnu, měl by mít dobrý přehled o obou.

Následující diagram znázorňuje jeden způsob použití ručních procesů pro počáteční řídicí rovinu:

Diagram znázorňující jeden způsob použití skriptů a dalších ručních procesů pro řídicí rovinu

Stáhněte si soubor aplikace Visio s touto architekturou.

Výhody ručního přístupu

  • Lightweight: Dokumentace, skripty a kanály se dají snadno vyvíjet a upravovat. To je vhodné při zjišťování procesů, protože je můžete rychle iterovat a vyvíjet.
  • Nízké náklady: Údržba a provoz ručního přístupu je levná.
  • Ověří váš proces: I když nakonec hodláte použít automatizovanější přístup, je dobrým způsobem, jak ověřit strategii údržby před tím, než budete investovat do vývoje robustnější automatizace.

Nevýhody ručního přístupu

  • Nedostatek kontroly: Tento přístup spoléhá na to, že všichni, kteří se účastní, dělají správnou věc. Někdo se může od předepsaného procesu odchýlit, ať už omylem, nebo úmyslně. Každá změna procesu zvyšuje riziko nekonzistence ve vašem prostředí, což znesnadňuje průběžnou správu.
  • Výzvy řízení přístupu: Když tento přístup používáte, obvykle potřebujete udělit široce vymezený, vysoce podmíněný přístup každému, kdo pracuje s vaším řešením, což ztěžuje dodržování osvědčených postupů pro segmentaci přístupu.
  • Škálovatelnost: Práce potřebná ke spouštění ručních procesů se škáluje s počtem tenantů, které potřebujete spravovat.
  • Testovatelnost: Ruční procesy se obtížně ověřují a testují.

Kdy zvážit přechod z ručního přístupu

  • Pokud váš tým nemůže držet krok s množstvím práce, kterou potřebuje k údržbě aplikace. Pokud se například počet tenantů škáluje nad rámec kritického bodu, který je pro většinu týmů mezi 5 a 10 tenanty.
  • Pokud očekáváte růst tenanta nad rámec kritického počtu tenantů a potřebujete se připravit na práci, která se týká správy tohoto počtu tenantů.
  • Pokud potřebujete zmírnit riziko nekonzistence. Můžete například pozorovat některé chyby, ke kterým dochází, protože někdo nesleduje procesy správně, nebo kvůli příliš mnoho nejednoznačnosti procesů. Riziko nekonzistence obvykle roste, protože se ručně nasadí více tenantů a s rostoucím týmem.

Rovina řízení s minimem kódu

Řídicí rovina bez kódu nebo bez kódu je vytvořená na platformě, která je navržená k automatizaci obchodních procesů a sledování informací. Existuje mnoho platforem, které umožňují provádět tyto úlohy bez psaní vlastního kódu.

Příkladem jedné z těchto platforem je Microsoft Power Platform. Pokud používáte Power Platform, můžete katalog tenantů ponechat v Dynamics 365, Dataverse nebo Microsoftu 365. Můžete také zvážit zachování stejného katalogu tenantů, který používáte pro ruční procesy, pokud nechcete plně potvrdit automatizaci všeho na začátku.

V případě onboardingu a údržby tenanta můžete pomocí Power Automate spouštět pracovní postupy, které provádějí správu tenantů, konfigurují tenanty, aktivují kanály nebo volání rozhraní API atd. Pomocí Power Automate můžete sledovat změny v katalogu tenantů, pokud jsou data někde přístupná pro Power Automate. Pokud používáte ruční katalog tenantů, dají se pracovní postupy Power Automate aktivovat také ručně. Pokud potřebujete, aby někdo z týmu ověřil něco nebo provedl další kroky, které nelze plně automatizovat, můžete do pracovních postupů zahrnout kroky ručního schvalování.

Tento přístup vám také umožňuje poskytovat zákazníkům samoobslužnou registraci tím, že webové aplikaci umožní přímo přidávat záznamy do katalogu tenantů bez zásahu člověka.

Následující diagram znázorňuje, jak můžete vytvořit řídicí rovinu pomocí samoobslužné registrace pomocí platformy Microsoft Power Platform:

Diagram znázorňující jeden způsob použití Power Automate a Dataverse jako roviny řízení s minimem kódu

Stáhněte si soubor aplikace Visio s touto architekturou.

Výhody přístupu s nízkým kódem

  • Zjednodušené: Často je rychlé a levné vytvořit sadu pracovních postupů s nízkým kódem a připojit je k okolním systémům.
  • Používá nástroje platformy: Pomocí nativních funkcí platformy můžete ukládat data, vytvářet portály pro správu, které může váš tým používat, a monitorovat pracovní postupy při jejich spuštění. Použitím nativních funkcí platformy se vyhnete vytváření mnoha komponent sami.
  • Přizpůsobitelné: Pokud potřebujete další přizpůsobení, můžete pracovní postupy obvykle rozšířit o vlastní kód a procesy. Power Automate můžete například použít k aktivaci pracovního postupu nasazení v GitHub Actions nebo můžete vyvolat Azure Functions ke spuštění vlastního kódu. To také pomáhá usnadnit postupné provádění.
  • Nízká režie: Služby s nízkým kódem jsou obvykle plně spravované, takže nemusíte spravovat infrastrukturu.

Nevýhody přístupu s nízkým kódem

  • Požadované odborné znalosti: K vytváření procesů a efektivnímu používání těchto platforem potřebujete proprietární znalosti. Mnoho organizací už tyto nástroje používá, takže váš tým už možná má potřebné znalosti, ale nemusí. Měli byste zvážit, jestli potřebujete vytrénovat svůj tým, abyste mohli tyto platformy efektivně používat.
  • Správa: Správa může být náročná na správu velkých objemů konfigurace s nízkým kódem.
  • Testovatelnost: Zvažte, jak testovat a propagovat změny v řídicí rovině. Ve spravované platformě je vytvoření typického procesu DevOps pro testování a propagaci změn obtížnější, protože změny se obvykle provádějí prostřednictvím konfigurace, ne prostřednictvím kódu.
  • Návrh: Pečlivě se zamyslete nad tím, jak splnit nefunkční požadavky, jako je zabezpečení a spolehlivost. Tyto požadavky se často spravují na platformě s nízkým kódem.

Kdy zvážit přechod od přístupu s nízkým kódem

  • Nakonec se vaše požadavky můžou stát tak složité, že je nebudete moct citlivě začlenit do řešení s nízkým kódem. Když potřebujete obejít omezení nástrojů tak, aby vyhovovala vašim potřebám, je pravděpodobně vhodné se odejít ze spravovaného řešení a k vlastní řídicí rovině.

Vlastní řídicí rovina

Můžete také zvážit vytvoření vlastní zcela přizpůsobené řídicí roviny. Tato možnost poskytuje největší flexibilitu a výkon, ale také vyžaduje nejvíce práce. Katalog tenantů je obvykle uložený v databázi. V tomto případě nepracujete přímo s katalogem, ale spravujete ho prostřednictvím rozhraní pro správu, což může být vlastní aplikace nebo systém, jako je aplikace pro správu vztahů se zákazníky (CRM) vaší organizace.

Obvykle vytvoříte sadu součástí řídicí roviny, která je navržená pro všechny funkce správy tenanta. Tyto komponenty můžou zahrnovat portál pro správu nebo jiné uživatelské rozhraní, rozhraní API a komponenty pro zpracování na pozadí. Pokud potřebujete dělat věci, jako je nasazení kódu nebo infrastruktury, když dojde k událostem životního cyklu tenanta, kanály nasazení můžou také vytvořit řídicí rovinu.

Ujistěte se, že jakékoli dlouhotrvající zpracování používá příslušné nástroje. Můžete například použít Durable Functions nebo Azure Logic Apps pro komponenty, které orchestrují onboarding nebo nasazení tenanta, nebo pro komponenty, které potřebují komunikovat s externími systémy.

Stejně jako přístup s nízkým kódem vám tento přístup umožňuje poskytovat zákazníkům samoobslužnou registraci tím, že webové aplikaci umožní přímo přidávat záznamy do katalogu tenantů bez zásahu člověka.

Následující diagram znázorňuje jeden ze způsobů, jak vytvořit základní vlastní řídicí rovinu, která poskytuje samoobslužnou registraci:

Diagram znázorňující řídicí rovinu vytvořenou pomocí Durable Functions, databáze SQL a sběrnice Service Bus

Stáhněte si soubor aplikace Visio s touto architekturou.

Výhody vlastního přístupu

  • Úplná flexibilita a přizpůsobitelnost: Máte úplnou kontrolu nad tím, co vaše řídicí rovina dělá, a můžete ji změnit, pokud se změní vaše požadavky.
  • Testovatelnost: Pro aplikaci řídicí roviny můžete použít standardní životní cyklus vývoje softwaru (SDLC) a implementovat normální přístupy pro testování a nasazení, stejně jako u hlavních aplikací.

Nevýhody vlastního přístupu

  • Odpovědnost za údržbu: Tento přístup vyžaduje větší režii údržby, protože potřebujete vytvořit vše sami. Řídicí rovina je stejně důležitá jako jakákoli jiná část aplikace. Při vývoji, testování a provozu řídicí roviny musíte mít velkou pozornost, abyste měli jistotu, že je spolehlivá a zabezpečená.

Hybridní přístupy

Můžete také zvážit použití hybridního přístupu. Můžete použít kombinaci ručních a automatizovaných systémů nebo můžete použít spravovanou platformu, jako je Microsoft Power Platform, a rozšířit ji o vlastní aplikace. Pokud potřebujete přizpůsobitelnost vlastní řídicí roviny, ale nechcete nutně vytvářet a udržovat plně vlastní systém, zvažte implementaci hybridního přístupu. Nezapomeňte, že v určitém okamžiku se vaše automatizovaná přizpůsobení ručních procesů nebo spravovaná platforma může stát tak složitá jako plně přizpůsobený systém. Bod rozdělení se pro každou organizaci liší, ale pokud je hybridní přístup těžkopádný k údržbě, měli byste zvážit přechod na plně vlastní systém.

Postupné provádění

I když víte, že chcete řídicí rovinu nakonec automatizovat, nemusíte s tímto přístupem nutně začínat. Běžným přístupem během počátečních fází vytváření aplikace je začít s ruční řídicí rovinou. S tím, jak vaše aplikace postupuje a onboarduje více tenantů, byste měli začít identifikovat kritické body a podle potřeby je automatizovat a přejít na hybridní přístup. S tím, jak více automatizujete, můžete mít nakonec plně automatizovanou řídicí rovinu.

Antipatterny, aby se zabránilo

  • Spoléhání se na ruční procesy příliš dlouho. I když je vhodné používat ruční procesy, když začnete nebo když máte nízký počet tenantů a vyžadujete poměrně odlehčenou správu, je potřeba naplánovat škálování na automatizované řešení během růstu. Pokud potřebujete najmout další členy týmu, aby udrželi krok s poptávkou po ručních procesech, je to dobrý signál, že byste měli začít automatizovat části řídicí roviny.
  • Použití nevhodných nástrojů pro dlouhotrvající pracovní postupy Nepoužívejte například standardní funkce Azure, synchronní volání rozhraní API nebo jiné nástroje, které mají časový limit provádění pro provádění dlouhotrvajících operací, jako jsou nasazení Azure Resource Manageru nebo orchestrace s více kroky. Místo toho používejte nástroje, jako jsou Azure Logic Apps, Durable Functions a další nástroje, které můžou provádět dlouhotrvající pracovní postupy nebo posloupnosti operací. Další informace najdete v tématu o výkonu a spolehlivosti a vzoru asynchronní žádosti a odpovědi ve službě Azure Functions.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

Další přispěvatelé:

Další kroky