Niestety, ten termin nie ma dobrego polskiego odpowiednika. „Wikipedia” podaje „wielokrotne wynajmowanie, wielozarządzanie”. Czasami nazywa się to „wieloma posiadaniami”. Te terminy mogą być nieco mylące, ponieważ przedmiot nie jest związany zasadniczo ani z wynajmem, ani z posiadaniem. To kwestia samej architektury oprogramowania i organizacji jego eksploatacji. I to ostatnie jest równie ważne.
Zaczęliśmy formować nasze zrozumienie multitenancy równocześnie z projektowaniem podejścia do chmurowego (usługowego) modelu działania „1C:Enterprise”. Było to kilka lat temu. Od tego czasu nasze zrozumienie ciągle się rozszerza. Nieustannie odkrywamy nowe aspekty tego tematu (plusy, minusy, trudności, cechy itp.).
Czasami deweloperzy rozumieją przez multitenancy dość prostą koncepcję: „aby dane kilku organizacji były przechowywane w jednej bazie, trzeba dodać do wszystkich tabel kolumnę z identyfikatorem organizacji i ustawić filtr według niej”. My również, oczywiście, rozpoczęliśmy naszą pracę nad tym zagadnieniem od tego momentu. Jednak dość szybko zrozumieliśmy, że to tylko jedna płaszczyzna (nawiasem mówiąc, również trudna). A w rzeczywistości to „cały świat”.
Główną ideę multitenancy można opisać mniej więcej tak. Zwykła aplikacja to dom jednorodzinny, przeznaczony do zamieszkania przez jedną rodzinę, która korzysta z jego infrastruktury (ściany, dach, wodociąg, ogrzewanie itd.). A aplikacja multitenancy to wielomieszkaniowy budynek. W nim każda rodzina korzysta z tego samego zestawu infrastruktury, ale sama infrastruktura jest zrealizowana dla całego budynku.
Czy podejście multitenancy jest dobre czy złe? Można znaleźć bardzo różne opinie na ten temat. Wydaje się, że nie ma pojęcia „dobrego lub złego” w ogóle. Należy porównywać plusy i minusy w kontekście konkretnych rozwiązywanych zadań. Ale to osobny temat…
W najprostszej definicji celem multitenancy jest obniżenie kosztów utrzymania aplikacji poprzez „upowszechnienie” kosztów infrastruktury. To ruch podobny do obniżenia ceny aplikacji poprzez zastosowanie rozwiązania seryjnego (możliwe z dostosowaniem i przeróbką), a nie pisania na „zamówienie”. Tylko w jednym przypadku upowszechnia się rozwój, a w drugim – eksploatację.
Co więcej, powtarzamy, że nie ma tu bezpośredniego związku z metodą sprzedaży. Architektura multitenancy może być z powodzeniem stosowana również w korporacyjnej lub rządowej infrastrukturze IT w celu automatyzacji dużej liczby podobnych oddziałów czy przedsiębiorstw holdingowych.
Można powiedzieć, że multitenancy to nie tylko kwestia organizacji przechowywania danych. To model działania aplikacji jako całości (w tym znaczna część aspektów jej architektury, model wdrożenia i organizacja serwisowania).
Najbardziej skomplikowane i interesujące w modelu multitenancy, jak nam się wydaje, jest to, że istota aplikacji "dzieli się". Część funkcjonalności działa z konkretnymi obszarami danych (mieszkaniami) i "nie interesuje się" tym, co dzieje się z mieszkańcami w innych mieszkaniach. Z kolei część postrzega dom jako całość i działa jednocześnie dla wszystkich mieszkańców. Przy tym ostatnia nie może abstrahować od faktu, że jednak są to osobne mieszkania i należy zapewnić odpowiedni poziom granularności i bezpieczeństwa.
W "1C:Przedsiębiorstwie" model multitenancy jest realizowany na poziomie kilku technologii. To mechanizmy platformy "1C:Przedsiębiorstwa", mechanizmy” i „", mechanizmy (biblioteki standardowych podsystemów).
Każdy z tych elementów wnosi swój wkład w budowę wspólnej infrastruktury wielomieszkaniowego domu. Dlaczego jest to realizowane w kilku technologiach, a nie w jednej, na przykład w platformie? Przede wszystkim dlatego, że część mechanizmów, naszym zdaniem, w pełni zasługuje na modyfikację przy konkretnym wariancie wdrożenia. Jednak w ogólnym zarysie to nie jest prosty temat, i ciągle stajemy przed wyborem – na jakim poziomie najlepiej realizować dany aspekt multitenancy.
Oczywiście zasadniczą część mechanizmów trzeba było zrealizować w platformie. Na przykład, to własne podział danych. To, od czego zwykle zaczyna się rozmowę o multitenancy. Ale ostatecznie model multitenancy "przejechał się" po istotnej części mechanizmów platformy i wymagał ich poprawy, a w niektórych przypadkach nawet przemyślenia na nowo.
Na poziomie platformy wdrożyliśmy podstawowe mechanizmy. Umożliwiają one tworzenie aplikacji działających w modelu wielodostępnym (multitenancy). Aby jednak aplikacje mogły "żyć i działać" w takim modelu, potrzebny jest system zarządzania ich "żywotnością". Za to odpowiadają technologie 1cFresh oraz zharmonizowana warstwa logiki biznesowej na poziomie BSP. Tak jak w budynku wielorodzinnym infrastruktura zapewnia mieszkańcom wszystko, co niezbędne, tak technologie 1cFresh zapewniają aplikacjom, działającym w modelu wielodostępnym, to, co potrzebne. Aby aplikacje mogły współdziałać z tą infrastrukturą (bez znacznych modyfikacji), wprowadza się odpowiednie „interfejsy” w postaci systemów BSP.
Z punktu widzenia mechanizmów platformy łatwo zauważyć, że w miarę zdobywania doświadczenia i rozwoju chmurowej wersji użycia „1C:Przedsiębiorstwo” rozszerzamy zestaw mechanizmów zaangażowanych w tę architekturę. Podamy jeden przykład. W modelu wielodostępnym istotnie zmienia się rozkład ról uczestników obsługi aplikacji. Zdecydowanie zwiększa się rola (poziom odpowiedzialności) tych, którzy odpowiadają za eksploatację aplikacji. Zaczęli oni potrzebować bardziej zaawansowanych narzędzi do kontroli aplikacji. Ponieważ użytkownicy aplikacji (mieszkańcy) przede wszystkim ufają dostawcy, z którym współpracują. W tym celu zrealizowaliśmy w wersji 8.3 nowy . Ten mechanizm umożliwia administratorom dostawcy ograniczenie swobody twórców aplikacji do wymaganego poziomu bezpieczeństwa – w praktyce izoluje pracę aplikacji dla każdego mieszkańca w określonych ramach „piaskownicy” (sandbox).
Nie mniej interesująca jest architektura zarządzania aplikacjami działającymi w trybie multitenancy (to, co jest realizowane w technologiach 1cFresh i BSP). W porównaniu do tradycyjnego modelu wdrażania, wymagania dotyczące automatyzacji procesów zarządzania są tutaj znacznie wyższe. Takich procesów jest dziesiątki: tworzenie nowych obszarów danych („mieszkań”), aktualizacja aplikacji, aktualizacja informacji normatywnych, tworzenie kopii zapasowych itd. Oczywiście wzrastają także wymagania dotyczące niezawodności i dostępności. Na przykład, aby zapewnić niezawodne interakcje aplikacji z składnikami systemu zarządzania, wdrożyliśmy technologię asynchronicznego wywołania z gwarantowaną dostawą.
Bardzo delikatnym aspektem jest sposób współdzielenia danych i procesów. Na pierwszy rzut oka wydaje się to proste (jeśli komuś się tak wydaje). Największą trudnością jest znalezienie równowagi między centralizacją danych i procesów a decentralizacją. Z jednej strony centralizacja pozwala zmniejszyć koszty (przestrzeni dyskowej, zasobów procesora, wysiłków administratorów…). Z drugiej strony ogranicza swobodę „mieszkańców”. To właśnie jeden z aspektów „rozdzielenia” aplikacji, kiedy deweloper musi myśleć jednocześnie o aplikacji w wąskim sensie (obsługującej jedno „mieszkanie”) i w szerokim sensie (obsługującej od razu wszystkich „mieszkańców”).
Przykładem takiej „dylematy” może być informacja normatywna. Oczywiście, wielka pokusa, aby uczynić ją wspólną dla wszystkich „mieszkańców” budynku. Pozwala to na przechowywanie jej w jednym egzemplarzu oraz aktualizację jednocześnie dla wszystkich. Ale zdarza się, że jakiemuś mieszkańcowi potrzebne są specyficzne zmiany. Nie jest to takie dziwne — w praktyce zdarza się to nawet w przypadku informacji, które zostały specyfikowane przez regulatorów (organy rządowe). Powstaje więc niełatwe pytanie: współdzielić czy nie współdzielić? Oczywiście kuszące byłoby stworzenie wspólnych informacji dla wszystkich oraz prywatnych dla chętnych. A to już prowadzi do znacznie trudniejszej realizacji. Ale nad tym pracujemy...
Innym przykładem jest projektowanie realizacji regularnych procesów (wykonywanych według harmonogramu, inicjowanych przez system zarządzający itp.). Z jednej strony można je wdrożyć dla każdej domeny danych osobno. Jest to prostsze i bardziej wygodne. Jednak z drugiej strony, taka drobna granularność powoduje duże obciążenie systemu. Aby je zredukować, należy wdrażać zharmonizowane procesy. Wymaga to jednak bardziej starannego opracowania.
Oczywiście pojawia się bardzo istotne pytanie. Jak deweloperzy aplikacji mogą zapewnić działanie w trybie multitenancy? Co muszą w tym celu zrobić? Oczywiście dążymy do tego, aby ciężar technologicznych i infrastrukturalnych kwestii w maksymalnym stopniu spoczywał na dostarczanej technologii, a programista aplikacji koncentrował się jedynie na zadaniach logiki biznesowej. Ale tak jak w przypadku innych istotnych pytań architektonicznych, deweloperzy aplikacji muszą mieć pewne wyobrażenie o działaniu w modelu multitenancy i podjąć pewne wysiłki w trakcie tworzenia aplikacji. Dlaczego? Ponieważ są aspekty, których technologia nie może zagwarantować automatycznie, nie uwzględniając semantyki danych. Na przykład, to samo zdefiniowanie granic podziału informacji. Ale staramy się, aby te trudności były małe. Przykłady realizacji takich aplikacji już istnieją.
Istotnym aspektem w kontekście wdrażania multitenancy w '1C:Przedsiębiorstwie' jest to, że tworzymy hybrydowy model, w którym jedna aplikacja może działać zarówno w trybie multitenancy, jak i w zwykłym trybie. To dość skomplikowane zadanie i temat osobnej dyskusji.
Źródło: habr.com
