Žiaľ, tento termín nemá dobrý slovenský ekvivalent. „Wikipedia“ uvádza „multitenantnosť, mnohonárodnosť“. Niekedy sa to nazýva „viaceré vlastníctvo“. Tieto termíny môžu byť trochu mätúce, pretože predmet nie je v podstate spojený ani s prenájmom, ani s vlastníctvom. Ide skôr o architektúru softvéru a organizáciu jeho prevádzky. A to druhé nie je menej dôležité.
Začali sme formovať naše porozumenie multitenantalite súčasne s návrhom prístupu k oblakovej (službovej) modelovej práci „1C:Enterprise“. Bolo to pred niekoľkými rokmi. A od tej doby sa naše porozumenie neustále rozširuje. Neustále objavujeme na tomto téme nové a nové aspekty (výhody, nevýhody, zložitosti, osobitosti atď.).
Niekedy vývojári chápu pod multitenantnosťou celkom jednoduchý koncept: „ak majú dáta viacerých organizácií byť uložené v jednej databáze, je potrebné pridať do všetkých tabuliek stĺpec s identifikátorom organizácie a nastaviť podľa neho filter“. My sme samozrejme začali našu prácu na tejto otázke od tohto okamihu. Ale dosť rýchlo sme si uvedomili, že to je len jedna oblasť (taktiež, mimochodom, nie jednoduchá). A vlastne je to „celá krajina“.
Hlavnú myšlienku multitenantnosti môžeme opísať asi takto. Bežná aplikácia je ako rodinný dom, určený pre jednu rodinu, ktorá využíva jeho infraštruktúru (steny, strechu, vodovod, kúrenie a pod.). A multitenantná aplikácia je ako bytový dom. V ňom každá rodina využíva rovnaký typ infraštruktúry, ale infraštruktúra je realizovaná pre celý dom ako celok.
Je prístup multitenantnosti dobrý alebo zlý? Môžete nájsť veľmi rozličné názory. Zdá sa, že neexistuje „dobré alebo zlé“ vôbec. Je potrebné porovnávať výhody a nevýhody v kontexte konkrétnych riešených úloh. Ale to je samostatná téma…
V najjednoduchšom chápaní je cieľom multitenantnosti znížiť náklady na údržbu aplikácie prostredníctvom „spoločenstva“ nákladov na infraštruktúru. To je podobné znižovaniu ceny aplikácie prostredníctvom použitia sériového riešenia (možno s úpravou a dopracovaním), a nie písaním „na zákazku“. Iba v jednom prípade je k spoločnému vývoju pridaná práca, a v druhom – prevádzka.
Treba zdôrazniť, že tu nie je priamy vzťah k spôsobu predaja. Architektúra multitenantnosti sa môže úspešne uplatniť aj v podnikových alebo vládnych IT infraštruktúrach na automatizáciu veľkého počtu homogénnych pobočiek a podnikov holdingu.
Môžeme povedať, že multitenantnosť nie je len otázkou organizácie ukladania údajov. Je to celkový model fungovania aplikácie (vrátane významnej časti aspektov jej architektúry, modelu nasadenia a organizácie údržby).
Najzložitejšie a najzaujímavejšie na modeli multitenantnosti, ako sa nám zdá, je, že podstata aplikácie sa 'rozdeľuje'. Časť funkčnosti pracuje s konkrétnymi oblasťami údajov (bytmi) a 'nezaujíma sa' o to, že v iných bytoch sú obyvatelia. Naopak, časť vníma dom ako celok a pracuje pre všetkých obyvateľov. Pri tom posledná časť nemôže abstrahovať od toho, že predsa len ide o samostatné byty, a je potrebné zabezpečiť potrebnú úroveň granularity a bezpečnosti.
V ‚1C:Enterprise‘ sa model multitenantnosti realizuje na úrovni viacerých technológií. Tieto sú mechanizmy platformy ‚1C:Enterprise‘, mechanizmy ‚“ a „‘, mechanizmy (knihovny štandardných subsystémov).
Každý z týchto prvkov prispieva svojou časťou k výstavbe celkovej infraštruktúry bytového domu. Prečo je to realizované v niekoľkých technológiach, a nie v jednej, napríklad v platforme? Predovšetkým preto, že niektoré mechanizmy, podľa nášho názoru, môžu byť vhodne modifikované pri konkrétnych variantách nasadenia. No v všeobecnosti je to zložitá otázka a neustále stojíme pred voľbou – na akej úrovni je lepšie realizovať ten alebo onen aspekt multitenantnosti.
Je zrejmé, že základné časti mechanizmov bolo potrebné realizovať v platforme. Napríklad, samotné rozdelenie údajov. To, od čoho sa zvyčajne začína diskusia o multitenantnosti. Ale nakoniec model multitenantnosti ‚prešiel‘ cez podstatnú časť mechanizmov platformy a požadoval ich dopracovanie, a v niektorých prípadoch aj prehodnotenie.
Na úrovni platformy sme implementovali základné mechanizmy. Tieto mechanizmy umožňujú vytvárať aplikácie, ktoré fungujú v modeli multitenancy. Aby však aplikácie "žili a pracovaly" v tomto modeli, potrebujeme systém na správu ich "životnosti". Za to zodpovedajú technológie 1cFresh a unifikovaná vrstva biznis logiky na úrovni BSP. Rovnako ako infraštruktúra v bytovom dome zabezpečuje rezidentom všetko potrebné, technológie 1cFresh zabezpečujú aplikáciám, ktoré fungujú v modeli multitenancy, všetko potrebné. A aby aplikácie mohli interagovať s touto infraštruktúrou (bez podstatných úprav), sú do nich vkladané príslušné "zásuvky" vo forme subsystémov BSP.
Z pohľadu mechanizmov platformy je ľahké všimnúť si, že s narastajúcim skúsenostiam a vývojom cloudového nasadenia "1C:Podnikania" rozširujeme súbor mechanizmov, ktoré sú zapojené do tejto architektúry. Uveďme jeden príklad. V modeli multitenancy sa zásadne mení rozloženie rolí účastníkov správy aplikácií. Výrazne sa zvyšuje úloha (úroveň zodpovednosti) tých, ktorí zodpovedajú za prevádzku aplikácií. Je potrebné, aby mali výkonnejšie nástroje na kontrolu aplikácií. Pretože používatelia aplikácií (rezidenti) dôverujú predovšetkým poskytovateľovi, s ktorým spolupracujú. Na tento účel sme v verzii 8.3 implementovali nový . Tento mechanizmus umožňuje správcov poskytovateľa obmedziť slobodu vývojárov aplikácií na potrebnú úroveň bezpečnosti – v podstate izolovať prácu aplikácie pre každého rezidenta v určitých mantineloch "pieskoviska" (sandbox).
Zaujímavá je aj architektúra na správu aplikácií, ktoré fungujú v režime multitenancy (čo sa realizuje v technológiách 1cFresh a BSP). Tu, v porovnaní s bežným modelom nasadenia, sa výrazne zvyšujú požiadavky na automatizáciu procesov riadenia. Takýchto procesov je desiatky: vytváranie nových oblastí údajov („bytov“), aktualizácia aplikácií, aktualizácia normatívnych informácií, zálohovanie a pod. A samozrejme, zvyšujú sa aj požiadavky na úroveň spoľahlivosti a dostupnosti. Napríklad, pre zabezpečenie spoľahlivej interakcie aplikácií s komponentmi riadiaceho systému sme implementovali technológiu asynchrónneho volania s garantovaným doručením.
Veľmi jemným momentom je spôsob zdieľania údajov a procesov. Na prvý pohľad sa to môže zdať jednoduché (ak si niekto myslí). Najväčšiu zložitost predstavuje rovnováha medzi centralizáciou údajov a procesov a decentralizáciou. Na jednej strane, centralizácia umožňuje znížiť náklady (diskového priestoru, procesorových zdrojov, úsilí administrátorov…). Na druhej strane, obmedzuje slobodu „nájomníkov“. To je práve jeden z momentov „rozpoltenia“ aplikácie, keď musí vývojár rozmýšľať súčasne o aplikácii v úzkom zmysle (obsluhujúcej jednu „byt“) a v širokom zmysle (obsluhujúcej všetkých „nájomníkov“).
Príkladom takejto „dilemy“ môže byť normatívna a referenčná informácia. Samozrejme, existuje pokušenie urobiť ju spoločnou pre všetkých „nájomníkov“ budovy. To umožňuje uchovávať ju v jednom exemplári a aktualizovať ju naraz pre všetkých. Ale občas sa stane, že nejakému nájomníkovi sú potrebné špecifické zmeny. Ako prekvapujúco, ale v praxi sa to vyskytuje, aj pre informácie, ktoré sú špecifikované regulátormi (štátnymi orgánmi). Vzniká tak zložitá otázka: zdieľať alebo nezdieľať? Samozrejme, je lákavé urobiť spoločnú informáciu pre všetkých a súkromnú pre tých, ktorí chcú. A to už vedie k celkom zložitému riešeniu. Ale na tom pracujeme...
Ďalším príkladom je návrh implementácie pravidelných procesov (provádzaných podľa plánu, iniciovaných riadiacim systémom atď.). Na jednej strane ich je možné implementovať pre každú oblasť údajov zvlášť. Je to jednoduchšie a pohodlnejšie. Na druhej strane však takáto malá granularita vytvára veľkú záťaž na systém. Na zníženie záťaže je potrebné implementovať zdieľané procesy. Tieto však vyžadujú podrobnejšie spracovanie.
Samozrejme, vyvstáva veľmi dôležitá otázka. Ako zabezpečiť pre vývojárov aplikácií prácu v režime multitenancy? Čo pre to musia urobiť? Samozrejme, snažíme sa, aby ťažkosť technologických a infraštruktúrnych otázok ležala čo najviac na pleciach dodávaných technológie, zatiaľ čo vývojár aplikácie by sa mal sústrediť len na úlohy biznis logiky. Ale ako pri iných dôležitých architektonických otázkach, určité predstavy o práci v modeli multitenancy by mali mať vývojári aplikácií a niektoré úsilie pri vývoji aplikácií bude potrebné. Prečo? Pretože existujú momenty, ktoré technológia nedokáže zabezpečiť automaticky bez zohľadnenia semantiky údajov. Napríklad definícia hraníc zdieľania informácií. Ale snažíme sa, aby tieto komplikácie boli čo najmenšie. Príklady realizácie takýchto aplikácií už existujú.
Dôležitým aspektom v kontexte realizácie multitenancy v „1C:Enterprise“ je to, že vytvárame hybridný model, v ktorom jedna aplikácia môže fungovať v režime multitenancy aj v bežnom režime. To je veľmi náročná úloha a predmet samostatnej diskusie.
Zdroj: habr.com
