Tento termín bohužel nemá dobrý ruský ekvivalent. Wikipedie poskytuje „Vícenásobný pronájem, vícenásobný pronájem.“ Tomu se někdy říká „vícenásobné vlastnictví“. Tyto pojmy mohou být poněkud matoucí, protože dané téma v podstatě nesouvisí ani s pronájmem, ani s vlastnictvím. Je to otázka softwarové architektury a organizace jejího provozu. Ta druhá je neméně důležitá.
Naše chápání multitenancy jsme začali rozvíjet současně s návrhem přístupu k cloudovému (servisnímu) operačnímu modelu pro 1C:Enterprise. To bylo před několika lety. A od té doby se naše chápání neustále rozšiřuje. Neustále objevujeme nové aspekty tohoto tématu (klady, zápory, složitosti, zvláštnosti atd.).
Vývojáři někdy interpretují multitenancy jako velmi jednoduchý koncept: „Chcete-li ukládat data z více organizací do jedné databáze, musíte do všech tabulek přidat sloupec s ID organizace a nastavit na něj filtr.“ My jsme samozřejmě od tohoto bodu začali s prací na této problematice. Rychle jsme si ale uvědomili, že se jedná jen o jedno pole (a mimochodem složité). Ve skutečnosti je to „celá země“.
Základní myšlenku multitenancy lze popsat zhruba následovně. Typickou aplikací je chata určená pro jednu rodinu, která sdílí její infrastrukturu (zdi, střechu, vodovod, topení atd.). Multitenancy aplikací je však bytový dům. Každá rodina využívá stejnou infrastrukturu, ale samotná infrastruktura je implementována pro celou budovu.
Je multitenancy dobrý, nebo špatný přístup? Názory na tuto záležitost se velmi liší. Zdá se, že neexistuje nic jako „dobrý nebo špatný“. Klady a zápory je třeba zvážit s ohledem na konkrétní řešené problémy. Ale to je jiné téma...
V nejjednodušším slova smyslu je cílem multitenancy snížit náklady na údržbu aplikací „socializací“ nákladů na infrastrukturu. Jedná se o stejný přístup jako snížení nákladů na aplikaci použitím standardního řešení (možná s úpravami a vylepšeními), spíše než vývojem řešení na míru. Rozdíl je v tom, že v jednom případě je socializován vývoj a v druhém provoz.
Navíc, zopakujme, to není přímo vázáno na metodu prodeje. Multitenanční architekturu lze snadno aplikovat v podnikové nebo oddělení IT infrastruktury k automatizaci velkého počtu podobných poboček nebo holdingových společností.
Dalo by se říci, že multitenancy je víc než jen otázka organizace úložiště dat. Je to model pro provoz celé aplikace (včetně významných aspektů její architektury, modelu nasazení a organizace údržby).
Nejsložitějším a nejzajímavějším aspektem modelu multitenancy je podle našeho názoru to, že základní funkcionalita aplikace je rozdvojená. Některé funkce pracují s konkrétními datovými oblastmi (byty) a nevědí o přítomnosti obyvatel v jiných bytech. Jiné funkce vnímají budovu jako celek a fungují pro všechny obyvatele současně. Ty však nemohou ignorovat skutečnost, že se koneckonců jedná o jednotlivé byty a je nutné zajistit potřebnou úroveň granularity a zabezpečení.
V systému 1C:Enterprise je model multitenancy implementován na úrovni několika technologií. Jedná se o mechanismy platformy 1C:Enterprise, mechanismy"A"» mechanismy (knihovny standardních subsystémů).
Každý z těchto prvků přispívá k celkové infrastruktuře budovy s více nájemníky. Proč je to implementováno ve více technologiích, a ne v jedné, například v platformě? Především proto, že se domníváme, že některé mechanismy lze vhodně upravit pro konkrétní scénář nasazení. Obecně se však jedná o složitou problematiku a neustále čelíme volbě, která vrstva je pro implementaci jednotlivých aspektů multitenantství nejlepší.
Je zřejmé, že základní mechanismy musely být v platformě implementovány. Například samotné oddělení dat – to, co obvykle zahajuje diskuse o multitenancích. Model multitenancí však nakonec ohrozil značnou část mechanismů platformy a vyžadoval jejich zdokonalení a v některých případech i přehodnocení.
Na úrovni platformy jsme implementovali základní mechanismy. Ty umožňují vytváření aplikací běžících v multi-tenancy modelu. Pro správné fungování aplikací v tomto modelu je však nutný systém pro správu jejich životního cyklu. Toho je dosaženo pomocí technologií 1cFresh a jednotné vrstvy obchodní logiky na úrovni systému podpory podnikání (BSS). Stejně jako infrastruktura v bytovém domě poskytuje obyvatelům vše, co potřebují, technologie 1cFresh poskytují vše potřebné pro aplikace běžící v multi-tenancy modelu. Aby aplikace mohly s touto infrastrukturou interagovat (bez významných úprav), jsou do nich zabudovány příslušné „konektory“ v podobě subsystémů BSS.
Pokud jde o mechanismy platformy, je snadné vidět, že s tím, jak získáváme zkušenosti a vyvíjíme cloudové řešení 1C:Enterprise, rozšiřujeme mechanismy zapojené do této architektury. Uveďme jeden příklad. V modelu multitenancy se výrazně mění rozdělení rolí mezi účastníky údržby aplikací. Role (úroveň odpovědnosti) těch, kteří jsou odpovědní za provoz aplikace, se výrazně zvýšila. Nyní vyžadují výkonnější nástroje pro řízení aplikací. Je to proto, že uživatelé aplikací (tenanti) důvěřují v první řadě poskytovateli, se kterým spolupracují. Abychom to řešili, implementovali jsme ve verzi 8.3 novou funkci. Tento mechanismus umožňuje správcům poskytovatelů omezit svobodu vývojářů aplikací na požadovanou úroveň zabezpečení – v podstatě izolovat provoz aplikace pro každého klienta v rámci specifického sandboxu.
Stejně zajímavá je architektura pro správu aplikací běžících v multi-tenancy režimu (jak je implementována v technologiích 1cFresh a BSP). Zde jsou ve srovnání se standardním modelem nasazení výrazně vyšší požadavky na automatizaci procesů správy. Existují desítky takových procesů: vytváření nových datových oblastí („apartmány“), aktualizace aplikací, aktualizace regulačních informací, zálohy atd. A samozřejmě se zvyšují požadavky na spolehlivost a dostupnost. Například pro zajištění spolehlivé interakce mezi aplikacemi a komponentami systému správy jsme implementovali systém asynchronních volání s garantovaným doručením.
Velmi jemným bodem je způsob sdílení dat a procesů. Zdá se to jednoduché (pokud se to někomu zdá) jen na první pohled. Největší výzvou je nalezení rovnováhy mezi centralizací dat a procesů a decentralizací. Centralizace na jedné straně snižuje náklady (místo na disku, procesorové prostředky, úsilí administrátorů atd.). Na druhé straně omezuje svobodu „nájemníků“. To je právě jeden z aspektů „rozdvojení“ aplikace, kdy vývojář musí aplikaci současně zvažovat v užším smyslu (obsluhujícím jeden „byt“) i v širším smyslu (obsluhujícím všem „nájemníkům“ současně).
Příkladem takového „dilemata“ jsou regulační a referenční informace. Přirozeně je lákavé je sdílet pro všechny „obyvatele“ budovy. To umožňuje jak jejich uložení v jedné kopii, tak i jejich aktualizaci pro všechny najednou. Někdy však konkrétní obyvatel vyžaduje specifické změny. Kupodivu se to v praxi děje i u informací specifikovaných regulačními orgány (vládními agenturami). To představuje obtížnou otázku: zobecňovat, či nezobecňovat? Je samozřejmě lákavé učinit informace obecnými pro všechny a soukromými pro ty, kteří je chtějí. To však vede k poměrně složité implementaci. Ale pracujeme na tom...
Dalším příkladem je návrh pravidelných procesů (plánovaných, iniciovaných řídicím systémem atd.). Na jedné straně je lze implementovat samostatně pro každou datovou oblast. To je jednodušší a pohodlnější. Na druhou stranu však taková jemnozrnná implementace vytváří značnou zátěž systému. Pro snížení této zátěže je nutné implementovat sdílené procesy. Ty však vyžadují pečlivější návrh.
To přirozeně vyvolává zásadní otázku. Jak mohou vývojáři aplikací zajistit multitenanci? Co musí udělat? Samozřejmě se snažíme zajistit, aby břemeno technologických a infrastrukturních otázek co nejvíce dopadlo na bedra dodávané technologie a vývojář aplikací musel přemýšlet výhradně z hlediska obchodní logiky. Stejně jako u jiných důležitých architektonických otázek však musí vývojáři aplikací mít určité pochopení toho, jak multitenancy funguje, a během vývoje aplikace bude vyžadováno určité úsilí. Proč? Protože existují aspekty, které technologie nemůže automaticky řešit bez zohlednění sémantiky dat. Například definování hranic sdílených informací. Snažíme se však tyto výzvy co nejvíce omezit. Příklady takových implementací aplikací již existují.
Důležitým aspektem implementace multitenancy v 1C:Enterprise je, že vytváříme hybridní model, ve kterém může jedna aplikace fungovat jak v multitenancy, tak ve standardním režimu. To je velmi složitý úkol a předmět samostatné diskuse.
Zdroj: www.habr.com
