Helaas heeft deze term geen goede Russischtalige analoog. Wikipedia geeft "multi-tenancy, meerdere tenancy." Dit wordt ook wel 'meervoudig eigendom' genoemd. Deze termen kunnen enigszins verwarrend zijn, omdat het onderwerp niet inherent verband houdt met huren of bezitten. Dit is een kwestie van software-architectuur en de organisatie van de werking ervan. En dat laatste is niet minder belangrijk.
We begonnen ons begrip van multitenancy te formuleren op hetzelfde moment dat we een benadering begonnen te ontwerpen voor het cloud(service)-werkmodel in 1C:Enterprise. Dit was een aantal jaren geleden. En sindsdien is ons begrip voortdurend uitgebreid. We ontdekken voortdurend meer en meer nieuwe aspecten van dit onderwerp (voor- en nadelen, moeilijkheden, kenmerken, enz.).
Soms zien ontwikkelaars multitenancy als een heel eenvoudig onderwerp: “om de gegevens van meerdere organisaties in één database op te slaan, moet je aan alle tabellen een kolom met de organisatie-identifier toevoegen en daar een filter op instellen.” Uiteraard zijn wij vanaf dit moment ook begonnen met onze studie van de kwestie. Maar ze realiseerden zich al snel dat dit maar één opruiming was (trouwens ook niet gemakkelijk). Over het algemeen is dit een “heel land”.
Het basisidee van multitenancy kan ongeveer als volgt worden omschreven. Een typische toepassing is een huisje dat is ontworpen om één gezin te huisvesten en dat gebruik maakt van de infrastructuur (muren, dak, watervoorziening, verwarming, enz.). Een multitenancy-aanvraag is een appartementengebouw. Daarin gebruikt elk gezin dezelfde infrastructuur, maar de infrastructuur zelf wordt voor het hele huis geïmplementeerd.
Is de multitenancy-aanpak goed of slecht? Hierover kun je heel verschillende meningen vinden. Er lijkt helemaal geen ‘goed of slecht’ te bestaan. Je moet de voor- en nadelen vergelijken in de context van de specifieke taken die worden opgelost. Maar dit is een apart onderwerp...
In de eenvoudigste zin is het doel van multitenancy het verlagen van de kosten voor het onderhoud van een applicatie door de infrastructuurkosten te ‘socialiseren’. Dit is dezelfde beweging als het verlagen van de kosten van een applicatie door gebruik te maken van een productieoplossing (mogelijk met maatwerk en aanpassingen), in plaats van deze “op bestelling” te schrijven. Slechts in één geval is de ontwikkeling gesocialiseerd, en in het andere geval - uitbuiting.
Bovendien herhalen we dat er geen directe link is met de verkoopmethode. Multitenancy-architectuur kan ook worden gebruikt in de IT-infrastructuur van een bedrijf of afdeling om een groot aantal vergelijkbare vestigingen en holdings te automatiseren.
We kunnen zeggen dat multitenancy niet alleen een kwestie is van het organiseren van gegevensopslag. Dit is een model van hoe de applicatie als geheel functioneert (inclusief een aanzienlijk deel van de architectuur, het implementatiemodel en de onderhoudsorganisatie).
Het moeilijkste en interessantste aan het multitenancy-model is volgens ons dat de essentie van de toepassing ‘verdeelt’. Een deel van de functionaliteit werkt met specifieke dataruimtes (appartementen) en is “niet geïnteresseerd” in het feit dat er bewoners in andere appartementen zijn. En sommigen zien het huis als één geheel en werken voor alle bewoners tegelijk. Tegelijkertijd kan laatstgenoemde niet voorbijgaan aan het feit dat het tenslotte om afzonderlijke appartementen gaat en dat er voor het noodzakelijke niveau van granulariteit en veiligheid moet worden gezorgd.
In 1C:Enterprise wordt het multitenancy-model geïmplementeerd op het niveau van verschillende technologieën. Dit zijn de mechanismen van het 1C:Enterprise-platform, de mechanismen van"En"", mechanismen (bibliotheken van standaardsubsystemen).
Elk van deze items draagt bij aan de constructie van de algehele infrastructuur van een appartementencomplex. Waarom wordt dit in meerdere technologieën geïmplementeerd, en niet in één, bijvoorbeeld in een platform? In de eerste plaats omdat sommige mechanismen, naar onze mening, heel geschikt zijn om aan te passen voor een specifieke implementatieoptie. Maar over het algemeen is dit een moeilijke vraag, en we worden voortdurend geconfronteerd met de keuze: op welk niveau is het beter om dit of dat aspect van multitenancy te implementeren.
Het is duidelijk dat het basisgedeelte van de mechanismen in het platform moest worden geïmplementeerd. Nou ja, bijvoorbeeld de daadwerkelijke gegevensscheiding. Dit is waar mensen meestal beginnen te praten over multitenancy. Maar uiteindelijk ‘reisde’ het multitenancy-model door een aanzienlijk deel van de mechanismen van het platform en vereiste verfijning en in sommige gevallen een heroverweging ervan.
Op platformniveau hebben we precies de basismechanismen geïmplementeerd. Hiermee kunt u applicaties maken die in een multitenancy-model draaien. Maar om applicaties in een dergelijk model te laten ‘leven en werken’, heb je een systeem nodig om hun ‘levensactiviteiten’ te beheren. 1cFresh-technologieën en een uniforme bedrijfslogicalaag op BSP-niveau zijn hiervoor verantwoordelijk. Net zoals in een appartementencomplex de infrastructuur de bewoners alles biedt wat ze nodig hebben, zo bieden de technologieën van 1cFresh alles wat ze nodig hebben voor applicaties die in een multitenancy-model draaien. En zodat applicaties (zonder noemenswaardige aanpassingen) met deze infrastructuur kunnen communiceren, worden de bijbehorende “connectoren” daarin geplaatst in de vorm van BSP-subsystemen.
Vanuit het oogpunt van platformmechanismen is het gemakkelijk op te merken dat naarmate we ervaring opdoen en de cloud-use case ‘1C:Enterprise’ ontwikkelen, we de samenstelling van de mechanismen die bij deze architectuur betrokken zijn, uitbreiden. Laten we één voorbeeld geven. In het multitenancy-model veranderen de rollen van deelnemers aan applicatieservices aanzienlijk. De rol (verantwoordelijkheidsniveau) van degenen die verantwoordelijk zijn voor het bedienen van applicaties neemt aanzienlijk toe. Het werd voor hen noodzakelijk om over krachtigere applicatiecontroletools te beschikken. Omdat applicatiegebruikers (bewoners) in de eerste plaats vertrouwen op de provider waarmee ze werken. Om dit te doen, hebben we een nieuwe geïmplementeerd . Met dit mechanisme kunnen providerbeheerders de vrijheid van applicatieontwikkelaars beperken tot het vereiste beveiligingsniveau - in essentie om de werking van de applicatie voor elke tenant binnen een bepaalde sandbox te isoleren.
Niet minder interessant is de architectuur voor het beheren van applicaties die in multitenancy-modus werken (wat is geïmplementeerd in 1cFresh- en BSP-technologieën). Hier zijn, vergeleken met het conventionele implementatiemodel, de eisen voor de automatisering van beheerprocessen aanzienlijk verhoogd. Er zijn tientallen van dergelijke processen: het creëren van nieuwe datagebieden ("appartementen"), het updaten van applicaties, het updaten van regelgevende informatie, back-ups, enz. En natuurlijk worden de eisen aan het niveau van betrouwbaarheid en beschikbaarheid steeds groter. Om een betrouwbare interactie tussen applicaties en besturingssysteemcomponenten te garanderen, hebben we bijvoorbeeld asynchrone oproepsysteemtechnologie met gegarandeerde levering geïmplementeerd.
Een heel subtiel punt is de manier waarop gegevens en processen worden gesocialiseerd. Het lijkt alleen op het eerste gezicht eenvoudig (als het voor iemand lijkt). De grootste uitdaging is de balans tussen centralisatie van data en processen en decentralisatie. Enerzijds kunt u dankzij centralisatie de kosten verlagen (schijfruimte, processorbronnen, beheerdersinspanningen...). Aan de andere kant beperkt het de vrijheid van de “huurders”. Dit is precies een van de momenten van “splitsing” van de applicatie, waarbij de ontwikkelaar tegelijkertijd moet nadenken over de applicatie in enge zin (ten dienste van één “appartement”) en in brede zin (alle “huurders” tegelijk bedienen) .
Als voorbeeld van een dergelijk ‘dilemma’ kan men informatie over regelgeving en referenties aanhalen. Natuurlijk is de verleiding groot om het voor alle ‘huurders’ van het huis gemeenschappelijk te maken. Hierdoor kunt u het in één exemplaar opslaan en voor iedereen tegelijk bijwerken. Maar het komt voor dat sommige bewoners specifieke veranderingen nodig hebben. Vreemd genoeg komt dit in de praktijk ook voor bij informatie die door toezichthouders (overheidsinstanties) wordt gespecificeerd. Dit blijkt een lastige vraag: socialiseren of niet socialiseren? Het is natuurlijk verleidelijk om de informatie voor iedereen algemeen en privé te maken voor degenen die dat willen. En dit leidt al tot een zeer moeilijke implementatie. Maar we zijn er mee bezig...
Een ander voorbeeld is het ontwerp van de implementatie van reguliere processen (uitgevoerd volgens een schema, geïnitieerd door het controlesysteem, etc.). Enerzijds kunnen ze voor elk datagebied afzonderlijk worden geïmplementeerd. Het is gemakkelijker en handiger. Maar aan de andere kant zorgt een dergelijke fijne granulariteit voor een grote belasting van het systeem. Om de belasting te verminderen, moet u gesocialiseerde processen implementeren. Maar ze vereisen een zorgvuldiger onderzoek.
Dit roept uiteraard een zeer belangrijke vraag op. Hoe kunnen applicatieontwikkelaars multitenancy garanderen? Wat moeten ze hiervoor doen? Uiteraard streven wij ernaar om ervoor te zorgen dat de lasten van technologische en infrastructurele vraagstukken zoveel mogelijk op de schouders van de geleverde technologie komen te liggen, en denkt de applicatieontwikkelaar alleen in termen van bedrijfslogische taken. Maar net als bij andere belangrijke architecturale kwesties moeten applicatieontwikkelaars enig inzicht hebben in het werken in het multitenancy-model en zal er enige inspanning nodig zijn bij het ontwikkelen van applicaties. Waarom? Omdat er punten zijn die de technologie niet automatisch kan bieden zonder rekening te houden met de semantiek van de gegevens. Bijvoorbeeld dezelfde definitie van de grenzen van informatiesocialisatie. Maar we proberen deze moeilijkheden klein te houden. Er zijn al voorbeelden van implementatie van dergelijke toepassingen.
Een belangrijk punt in de context van het implementeren van multitenancy in 1C:Enterprise is dat we een hybride model creëren waarin één applicatie zowel in multitenancy-modus als in de normale modus kan werken. Dit is een zeer moeilijke taak en het onderwerp van een aparte discussie.
Bron: www.habr.com