Helaas bestaat er geen goede Nederlandstalige term voor dit begrip. "Wikipedia" geeft "multi-tenant, meervoudige huur". Soms wordt dit "meervoudig eigendom" genoemd. Deze termen kunnen wat verwarrend zijn, omdat het onderwerp eigenlijk niets te maken heeft met huur of eigendom. Het is een kwestie van softwarearchitectuur en de organisatie van het gebruik ervan, waarbij laatstgenoemde niet minder belangrijk is.
We begonnen ons begrip van multitenancy te vormen op het moment dat we de aanpak voor het cloud (service) model van "1C:Enterprise" gingen ontwerpen. Dat was enkele jaren geleden. Sindsdien breidt ons begrip zich voortdurend uit. We ontdekken voortdurend nieuwe aspecten van dit onderwerp (voordelen, nadelen, moeilijkheden, bijzonderheden, enz.).
Soms begrijpen ontwikkelaars multitenancy als iets heel eenvoudigs: "om gegevens van verschillende organisaties in één database op te slaan, moet je een kolom met de organisatie-identifier aan alle tabellen toevoegen en een filter daarop instellen". Natuurlijk zijn we ook onze aanpak als volgt begonnen. Maar al snel realiseerden we ons dat dit slechts één aspect is (ook overigens niet gemakkelijk). Het is in feite een "hele wereld".
De belangrijkste idee van multitenancy kan ongeveer als volgt worden beschreven. Een gewone applicatie is een huis dat is ontworpen voor het wonen van één familie, die gebruikmaakt van de infrastructuur (wanden, dak, watervoorziening, verwarming, enz.). Een multitenancy-applicatie is daarentegen een appartementencomplex. Elke familie maakt gebruik van dezelfde infrastructuur, maar de infrastructuur is gerealiseerd voor het gehele gebouw.
Is de multitenancy-aanpak goed of slecht? Hierover zijn zeer verschillende meningen te vinden. Het lijkt erop dat er geen "goed of slecht" in het algemeen is. Je moet de voor- en nadelen vergelijken in de context van de specifieke taken die moeten worden opgelost. Maar dat is een apart onderwerp...
In de eenvoudigste zin is het doel van multitenancy om de kosten van het onderhoud van de applicatie te verlagen door de kosten van de infrastructuur "gemeenschappelijk" te maken. Dit is vergelijkbaar met de vermindering van de kosten van de applicatie door het gebruik van een schaling oplossing (mogelijk met aanpassing en uitbreiding) in plaats van een "op maat gemaakte" oplossing. Alleen in het ene geval wordt de ontwikkeling gemeenschappelijk gemaakt, terwijl in het andere geval het gebruiksgemak wordt gedeeld.
Wij herhalen dat er hier geen directe koppeling is aan de verkoopmethode. De multitenancy-architectuur kan perfect worden toegepast in een zakelijke of overheids-IT-infrastructuur voor de automatisering van een groot aantal soortgelijke vestigingen, bedrijven van een holding.
Men kan zeggen dat multitenancy niet alleen een kwestie is van gegevensopslagorganisatie. Het is het hele werkmodel van de applicatie (inclusief een significant deel van de architectuuraspecten, de implementatiemodel en het onderhoudsorganisatie).
Het meest complexe en interessante aan het multitenancy-model is, zoals wij denken, dat de essentie van de applicatie "opgedeeld" wordt. Een deel van de functionaliteit werkt met specifieke datavelden (appartementen) en "interesseert zich niet" voor de bewoners in andere appartementen. Een ander deel beschouwt het gebouw als geheel en werkt direct voor alle bewoners. Tegelijkertijd kan de laatste zich niet onttrekken aan het feit dat het toch afzonderlijke appartementen zijn, en het is noodzakelijk om een passend niveau van granulariteit en veiligheid te waarborgen.
In "1C:Enterprise" wordt het multitenancy-model geïmplementeerd op het niveau van verschillende technologieën. Dit zijn mechanismen van het "1C:Enterprise" platform, de mechanismen van "» en «" mechanismen (bibliotheken van standaard subsystemen).
Elk van deze elementen draagt bij aan de opbouw van de algemene infrastructuur van het appartementencomplex. Waarom wordt dit in verschillende technologieën geïmplementeerd en niet in één, bijvoorbeeld in het platform? Vooral omdat een deel van de mechanismen, naar onze mening, heel goed kan worden aangepast aan de specifieke implementatievariant. Maar in algemene termen is dit een complexe kwestie en staan we voortdurend voor de keuze – op welk niveau we het beste een bepaald aspect van multitenancy kunnen implementeren.
Het is duidelijk dat de basismechanismen in het platform moesten worden geïmplementeerd. Bijvoorbeeld, de eigenlijke scheiding van data. Dat is waar het gesprek over multitenancy meestal mee begint. Maar uiteindelijk heeft het multitenancy-model een aanzienlijk deel van de mechanismen van het platform doorlopen en eisen tot verbetering, en in sommige gevallen heroverweging, gesteld.
Op het niveau van het platform hebben we precies de basismechanismen geïmplementeerd. Deze maken de creatie van applicaties mogelijk die werken in een multitenancy-model. Maar om ervoor te zorgen dat applicaties ‘leven en functioneren’ in zo'n model, is een systeem voor het beheer van hun ‘levenscyclus’ nodig. Dit wordt verzorgd door technologieën zoals 1cFresh en de verenigde laag van bedrijfslogica op het niveau van BSP. Zoals de infrastructuur in een appartementencomplex de bewoners van alles voorziet wat ze nodig hebben, zo voorzien de technologieën 1cFresh alle benodigde middelen voor applicaties die in het multitenancy-model werken. En om ervoor te zorgen dat applicaties met deze infrastructuur kunnen interageren (zonder significante aanpassingen), worden er passende ‘aansluitingen’ in de vorm van BSP-subsystemen in hen geplaatst.
Vanuit het perspectief van de mechanismen van het platform is het gemakkelijk op te merken dat naarmate we ervaring opdoen en de cloudvariant van ‘1C:Enterprise’ ontwikkelen, we het aantal mechanismen dat bij deze architectuur is betrokken uitbreiden. We geven een voorbeeld. In het multitenancy-model verandert de rolverdeling van de deelnemers aan het onderhoud van applicaties aanzienlijk. De rol (verantwoordelijkheidsniveau) van degenen die verantwoordelijk zijn voor de exploitatie van applicaties neemt aanzienlijk toe. Het is voor hen noodzakelijk geworden om krachtigere controle-instrumenten voor applicaties te hebben. Dit komt omdat de gebruikers van applicaties (bewoners) vooral vertrouwen op de provider waarmee ze samenwerken. Daarom hebben we in versie 8.3 een nieuwe . Dit mechanisme stelt beheerders van de provider in staat om de vrijheid van applicatieontwikkelaars te beperken tot het noodzakelijke beveiligingsniveau – in wezen het werk van de applicatie voor elke bewoner binnen bepaalde kaders van een ‘sandbox’ (sandbox) te isoleren.
De architectuur voor het beheren van applicaties in een multitenancy-modus (zoals geïmplementeerd in 1cFresh en BSP) is ook bijzonder interessant. In vergelijking met een traditionele implementatiemodel, zijn de vereisten voor procesautomatisering hier aanzienlijk hoger. Er zijn tientallen dergelijke processen: het aanmaken van nieuwe datasets ("appartementen"), het bijwerken van applicaties, het actualiseren van normatieve informatie, back-ups, enzovoort. En natuurlijk stijgen de eisen voor betrouwbaarheid en beschikbaarheid. Bijvoorbeeld, om een betrouwbare interactie van toepassingen met de beheersystemen te waarborgen, hebben we een technologie voor asynchrone oproepsystemen met gegarandeerde bezorging geïmplementeerd.
Een zeer subtiel punt is de manier waarop gegevens en processen worden gedeeld. Het lijkt misschien eenvoudig (voor degenen die dat denken) bij eerste aanblik. De grootste uitdaging is het vinden van een balans tussen centralisatie van gegevens en processen en decentralisatie. Aan de ene kant vermindert centralisatie de kosten (schijfruimte, CPU-resources, de inspanningen van beheerders…). Aan de andere kant beperkt het de vrijheid van de "huurders". Dit is precies een van de momenten van de "splitsing" van de applicatie, waarbij de ontwikkelaar tegelijkertijd moet nadenken over de applicatie in enge zin (die één "appartement" bedient) en in brede zin (die alle "huurders" bedient).
Een voorbeeld van zo'n "dilemma" is normatieve en referentie-informatie. Uiteraard is de verleiding groot om deze gemeenschappelijk te maken voor alle "huurders" van het gebouw. Dit maakt het mogelijk om het in één exemplaar op te slaan en het onmiddellijk voor iedereen bij te werken. Maar soms heeft een bepaalde huurder specifieke aanpassingen nodig. Vreemd genoeg komt dit in de praktijk voor, zelfs voor informatie die door regelgevers (overheidsinstanties) is gespecificeerd. Dit leidt tot een complexe vraag: moeten we delen of niet? Natuurlijk is het verleidelijk om algemene informatie voor iedereen en specifieke informatie voor degenen die dat willen te creëren. Maar dat leidt tot een zeer complexe implementatie. Daar werken we aan...
Een ander voorbeeld is het ontwerpen van de implementatie van reguliere processen (uitgevoerd volgens een schema, geïnitieerd door het beheersysteem, enz.). Aan de ene kant kunnen ze voor elk gegevensgebied afzonderlijk worden geïmplementeerd. Dit is eenvoudiger en handiger. Maar aan de andere kant creëert zo'n fijne granulariteit een grote belasting voor het systeem. Om de belasting te verlagen, moeten gemeenschappelijke processen worden geïmplementeerd. Maar deze vereisen een zorgvuldiger uitwerking.
Er rijst vanzelfsprekend een belangrijke vraag. Hoe kunnen applicatieontwikkelaars multitenancy implementeren? Wat moeten ze hiervoor doen? Natuurlijk streven we ernaar dat de lasten van technische en infrastructuurkwesties zoveel mogelijk op de schouders van de geleverde technologie komen te liggen, terwijl de applicatieontwikkelaar zich alleen bezighoudt met businesslogica. Maar net als bij andere belangrijke architecturale kwesties, is het nodig dat applicatieontwikkelaars enige kennis hebben van hoe multitenancy werkt en dat er inspanningen vereist zijn bij de ontwikkeling van applicaties. Waarom? Omdat er zaken zijn die de technologie niet automatisch kan waarborgen zonder rekening te houden met de semantiek van gegevens. Bijvoorbeeld het bepalen van de grenzen van informatieverdeling. Maar we proberen ervoor te zorgen dat deze complicaties minimaal zijn. Er zijn al voorbeelden van dergelijke applicaties.
Een belangrijk aspect in de context van multitenancy-implementatie in '1C:Enterprise' is dat we een hybride model creëren waarin één applicatie zowel in multitenancy-modus als in normale modus kan werken. Dit is een vrij complexe taak en vereist afzonderlijke bespreking.
Bron: habr.com
