Žal, ta termin nima dobrega slovenskega ekvivalenta. „Wikipedia“ navaja „multitenantnost, večkratna najemnost“. Včasih to imenujejo „večkratno lastništvo“. Ti termini lahko povzročajo nekaj zmede, saj tema v bistvu ni povezana niti z najemom niti z lastništvom. Gre za vprašanje arhitekture programske opreme in organizacije njene rabe. Pri čemer je slednje prav tako pomembno.
Naše razumevanje multitenancy smo začeli oblikovati ravno takrat, ko smo začeli zasnovati pristop k oblačni (storitev) modelu dela „1C: Pred podjetji“. To je bilo pred nekaj leti. In od takrat se naše razumevanje nenehno širi. Nenehno odkrivamo nove in nove vidike te teme (prednosti, slabosti, zapletenosti, značilnosti itd.).
Včasih razvijalci pod multitenancy razumejo precej preprosto stvar: „da bi podatki več organizacij bili shranjeni v eni bazi, je treba v vse tabele dodati stolpec z identifikatorjem organizacije in po njem nastaviti filtriranje“. Tudi mi smo se, seveda, začeli obravnavati to vprašanje od tega trenutka. A hitro smo spoznali, da je to samo ena majhna površina (ki je tudi precej zahtevna). Na splošno pa je to „cela dežela“.
Glavno idejo multitenancy lahko opišemo takole. Običajna aplikacija je kot vikend hiša, namenjena enemu družinskemu življenju, ki izkorišča njeno infrastrukturo (stene, streha, vodovod, ogrevanje itd.). Multitenancy aplikacija pa je večstanovanjska hiša. V njej vsaka družina uporablja enak set infrastrukture, toda sama infrastruktura je zasnovana za celotno hišo.
Je pristop multitenancy dober ali slab? Na to vprašanje lahko najdemo zelo različna mnenja. Zdi se, da ni „dobro ali slabo“ na splošno. Primerjati je treba prednosti in slabosti v kontekstu specifičnih rešitev. A to je že druga tema…
V najpreprostejšem razumevanju je cilj multitenancy zmanjšati stroške vzdrževanja aplikacije z „delitvijo“ stroškov infrastrukture. To je enak proces kot zmanjšanje stroškov aplikacije z uporabo masovno proizvedenega rešitve (morda z nastavitvami in izboljšavami), namesto pisanja „po naročilu“. V enem primeru se deli razvoj, v drugem – obratovanje.
Poudarimo, da tu ni neposredne povezave na način prodaje. Arhitektura multitenancy se lahko popolnoma uporablja tudi v korporativni ali vladni IT-infrastrukturi za avtomatizacijo velikega števila enotnih poslovalnic, podjetij holdinga.
Lahko rečemo, da multitenancy ni le vprašanje organizacije shranjevanja podatkov. To je model delovanja aplikacije kot celote (vključno z bistvenimi vidiki njene arhitekture, modelom uvajanja in organizacijo vzdrževanja).
Najbolj zapleteno in zanimivo pri modelu multitenancy, kot se nam zdi, je, da se bistvo aplikacije "razdvoji". Del funkcionalnosti deluje s specifičnimi področji podatkov (stanovanji) in "ne zanima" ga, da v drugih stanovanjih živijo stanovalci. Drugi del dojema hišo kot celoto in deluje takoj za vse stanovalce. Pri tem se zadnji ne more abstrahirati od dejstva, da gre vendarle za posamezna stanovanja, in je treba zagotoviti potrebno raven granularnosti in varnosti.
V "1C:Podjetju" se model multitenancy uresničuje na ravni več tehnologij. To so mehanizmi platforme "1C:Podjetja", mehanizmi "» and «", mehanizmi (knjižnice standardnih podsystemov).
Vsak od teh predmetov prispeva k oblikovanju skupne infrastrukture večstanovanjskega doma. Zakaj se to uresničuje v več tehnologijah in ne v eni, na primer, na platformi? Predvsem zato, ker se nam zdi, da je del mehanizmov primerno modificirati za specifično različico uvajanja. Toda v splošnem je to zapleteno vprašanje in nenehno smo pred odločitvijo – na kateri ravni je najbolje uresničiti določen vidik multitenancy.
Očitno je, da je bilo osnovni del mehanizmov treba uresničiti na platformi. Na primer, dejansko razdelitev podatkov. To je tisto, od česar se običajno začne pogovor o multitenancy. Toda na koncu je model multitenancy "prešel" skozi veliko število mehanizmov platforme in zahteval njihovo dopolnitev, v nekaterih primerih pa celo ponovno razmišljanje.
Na ravni platforme smo implementirali osnovne mehanizme. Ti omogočajo ustvarjanje aplikacij, ki delujejo v modelu multitenancy. Vendar pa, da bi aplikacije 'živele in delovale' v tem modelu, potrebujemo sistem za upravljanje njihove 'življenjske dobe'. Za to poskrbijo tehnologije 1cFresh in enoten sloj poslovne logike na ravni BSP. Tako kot infrastruktura večstanovanjskega objekta skrbi za vse potrebne stvari za prebivalce, tehnologije 1cFresh zagotavljajo vse potrebno aplikacijam, ki delujejo v modelu multitenancy. Da bi aplikacije lahko sodelovale s to infrastrukturo (brez bistvenih izboljšav), se v njih vnesejo ustrezni 'vtiči' v obliki podsystemov BSP.
Z vidika mehanizmov platforme je lahko opaziti, da s pridobivanjem izkušenj in razvojem oblačnega načina uporabe '1C:Podjetja' širimo nabor mehanizmov, ki so vključeni v to arhitekturo. Pripravimo en primer. V modelu multitenancy se bistveno spreminja razporeditev vlog udeležencev pri vzdrževanju aplikacij. Bistveno se povečuje vloga (stopnja odgovornosti) tistih, ki so odgovorni za obratovanje aplikacij. Potrebno je, da imajo močnejša orodja za nadzor aplikacij. Uporabniki aplikacij (prebivalci) zaupljajo predvsem ponudniku, s katerim delajo. Zato smo v različici 8.3 implementirali nov . Ta mehanizem omogoča administratorjem ponudnika, da omejijo svobodo razvijalcev aplikacij na potrebno stopnjo varnosti – v bistvu izolirajo delovanje aplikacije za vsakega prebivalca v določenih okvirih 'peskovnika' (sandbox).
Zelo zanimiva je tudi arhitektura za upravljanje aplikacij, ki delujejo v načinu multitenancy (to, kar se uresničuje v tehnologijah 1cFresh in BSP). Tukaj, v primerjavi s tradicionalnim modelom uvajanja, znatno naraščajo zahteve po avtomatizaciji procesov upravljanja. Takih procesov je desetine: ustvarjanje novih podatkovnih področij („stanovanj“), posodabljanje aplikacij, posodabljanje normativnih informacij, varnostno kopiranje itd. In seveda naraščajo zahteve po ravni zanesljivosti in dostopnosti. Na primer, za zagotavljanje zanesljive interakcije aplikacij s komponentami sistema upravljanja smo uvedli tehnologijo asinhronih klicnih sistemov z zagotovljeno dostavo.
Zelo občutljiv trenutek je način souporabe podatkov in procesov. Na prvi pogled se to zdi preprosto (če se komu tako zdi). Največjo težavo predstavlja ravnotežje med centralizacijo podatkov in procesov ter decentralizacijo. Po eni strani centralizacija omogoča zmanjšanje stroškov (diskovnega prostora, procesorskih virov, naporov administratorjev…). Po drugi strani pa omejuje svobodo „stanovalcev“. To je prav eden od trenutkov „razdvajanja“ aplikacije, ko se mora razvijalec istočasno ukvarjati z aplikacijo v ozkem pomenu (ki služi enemu „stanovanju“) in v širokem pomenu (ki služi vsem „stanovalcem“).
Kot primer te „dileme“ lahko navedemo normativno-informacijske podatke. Seveda je velika skušnjava, da bi jih naredili skupne za vse „stanovalce“ hiše. To omogoča, da jih hranimo v enem izvodu in jih posodobimo takoj za vse. A zgodi se, da nekemu stanovalcu potrebne specifične spremembe. Kakorkoli že, v praksi se to pojavlja, celo za informacije, ki jih določajo regulativni organi (državni organi). Pojavi se zapleteno vprašanje: souporabiti ali ne souporabiti? Očitno je mamljivo ustvariti skupne informacije za vse in zasebne za tiste, ki jih želijo. A to vodi v precej zapleteno realizacijo. Na tem delamo…
Drugim primjerom je projektiranje i implementacija redovitih procesa (izvršavane prema rasporedu, inicirane upravljačkim sustavom itd.). S jedne strane, mogu se implementirati za svako područje podataka posebno. To je jednostavnije i praktičnije. No, s druge strane, takva sitna granularnost stvara veliku opterećenost sustava. Kako bismo smanjili opterećenje, potrebno je implementirati zajedničke procese. No oni zahtijevaju pažljiviju obradu.
Naravno, postavlja se vrlo važno pitanje. Kako osigurati rad aplikacijskih programera u režimu multitenancy? Što moraju učiniti za to? Naravno, težimo tome da teret tehnoloških i infrastrukturnih pitanja maximo bude na ramenima isporučene tehnologije, dok bi aplikacijski programer razmišljao samo o poslovnoj logici. No kao i s drugim važnim arhitektonskim pitanjima, aplikacijski programeri moraju imati barem neku predstavu o radu u modelu multitenancy i neka napora će biti potrebna prilikom razvoja aplikacija. Zašto? Zato što postoje aspekti koje tehnologija ne može automatski osigurati bez razmatranja semantike podataka. Na primjer, definiranje granica zajedničkog korištenja informacija. Međutim, trudimo se da ti izazovi budu što manji. Već postoje primjeri implementacije takvih aplikacija.
Važna točka u kontekstu implementacije multitenancy u "1C:Poduzeću" je to što kreiramo hibridni model, u kojem jedna aplikacija može raditi kako u režimu multitenancy, tako i u običnom režimu. To je prilično složen zadatak i predmet je zasebne rasprave.
Izvor: habr.com
