Wiele najemców czy wiele wystąpień?

Próbuję zbudować oparte na sieci rozwiązanie SaaS i ruszam w drogę, w której nie jestem pewien, czy będę używać wielu dzierżawców lub wielu instancji. Postaram się opisać, co próbuję osiągnąć, a każde podejście ma zalety i wady (moja opinia, zgodnie z tym, co czytam). Podaj swoje sugestie na wypadek, gdyby coś przeoczyłem w jednym podejściu w stosunku do drugiego.

Aplikacja, którą próbuję zbudować, to, jak wspomniałem, rozwiązanie SaaS, w którym firmy mogą tworzyć swoje konta, a każde konto / firma ma własnych użytkowników, klientów, produkty, usługi ... itd. Każdy użytkownik; kto jest pracownikiem firmy; powiązane z jednym kontem / firmą będą miały dostęp tylko do swoich klientów, produktów i usług swojej firmy. Firmy mogą mieć nieograniczoną liczbę klientów, produktów i usług, dlatego każda firma powinna mieć własne centrum danych.

W tym celu zdecydowałem się utworzyć wspólną bazę danych (zapisując poświadczenia wszystkich użytkowników do celów logowania) i wiele wspólnych schematów baz danych (baza danych na konto / firmę). Zasadniczo Multi Tenancy .

Następnie ktoś zasugerował użycie zamiast tego Multi Multi Instance , gdzie każda firma będzie miała własną instancję aplikacji (tj. Kod, biblioteki, bazy danych, frameworki itp.) Całkowicie oddzieloną od innych firm. Brzmi to lepiej, ponieważ nie muszę dbać o dodatkową warstwę, w której muszę upewnić się, że użytkownicy każdego najemcy mają dostęp tylko do danych swojej firmy. Myślę, że warto wspomnieć, że zależy mi na Dockerze, aby osiągnąć to podejście (nigdy wcześniej go nie używałem), ale myślę, że brakuje mu funkcji (więcej o nich później) będę potrzebować w przyszłości (przynajmniej nie znajdź je przy odrobinie wyszukiwania).

Jednak każde podejście ma swoje zalety i wady, więc nie mogłem podjąć decyzji, które podejście wybrać. Oto lista, ale odsłonię się ze względu na brak wiedzy na ich temat, więc może być coś, czego nie jestem świadomy, lub rozwiązanie problemu, którego nie znalazłem w Internecie: [Każde podejście ma uporządkowana lista, której śledziłem jeden po drugim]

Wiele najemców :

1. Współdzielony host / sprzęt, wspólny kod i wiele baz danych.
2. Jest to łatwiejsze do rozszerzenia funkcjonalności kodu i naprawienia błędów (kod współdzielony).
3. Jest to trudniejsze do rozszerzenia sprzętowe (można skorzystać z usługi cloud) lub przenieść bazę indywidualnego najemcy do innego systemu bez wykonywania zmian w kodzie.
4. Co najważniejsze, jak wspomniałem wcześniej, muszę dodać dodatkową warstwę do systemu, aby upewnić się, że użytkownik faktycznie należy do jego firmy i nie ma dostępu do informacji innych firm.

Wiele wystąpień :

1. Udostępniony lub nieudostępniony host / sprzęt, kod na instancję i baza danych na instancję.
2. Jest to trudniejsze do rozszerzenia funkcjonalności lub poprawiać błędy (nie jestem pewien, czy istnieje sposób, aby zrobić to w Döcker gdzie można dodać funkcje / funkcji do jednej instancji lub Docker pojemnika i wdrożyć go do innych).
3. Jest to łatwiejsze , aby przenieść całe wystąpienie do innego hosta / sprzętu.
4. Jako instancja nie muszę zajmować się tą warstwą, ponieważ każda instancja będzie miała własną bazę danych.

Wszystkie zalety i wady są zbędne w przypadku, gdy chcę zrobić coś ręcznie (jako ręczne tworzenie instancji dla każdego dzierżawcy), i dlatego wątpię w rozwiązanie Docker, chyba że istnieje sposób na rozwiązanie tego, co może być głównym powód pytania. Byłbym wdzięczny, gdybyś odpowiedział na pytanie, odnosząc się do rozwiązań, i dlaczego uważasz, że to podejście jest lepsze od drugiego.

W przypadku, gdyby to pomogło (może?), Używamy Laravela jako głównego frameworka back-endu (wszystkie RESTfully).

W tej chwili zadaję sobie dokładnie to samo pytanie.

Opieram się na rozwiązaniu dla jednej dzierżawy z wieloma instancjami, ale nie podjąłem jeszcze ostatecznej decyzji. Pozwól, że podzielę się kilkoma przemyśleniami:

Główną historyczną zaletą architektury wielu dzierżawców jest lepsze wykorzystanie zasobów infrastruktury przez wzajemne wykorzystanie (pojedynczy system operacyjny, pojedyncza baza danych, pojedyncza warstwa aplikacji) i lepsze wykorzystanie tych zasobów (gdy jednego użytkownika nie ma, drugi może korzystać z tego samego zasobu) .

Znacznie upraszcza to także cykl życia oprogramowania : wdrażasz nowe wersje w jednym wystąpieniu, wszyscy klienci są aktualizowani w tym samym czasie.

Wydaje się jednak, że ostatnie postępy w technologii chmurowej sprawiają, że pierwsza klasa zalet jest w dużej mierze dostępna w architekturze z wieloma instancjami (instancja na klienta) (mam tu na myśli konkretnie platformę taką jak Jelastic, ale jestem pewien, że istnieją inne, które zapewniają te same funkcje):

• PaaS oparty na kontenerach
• Inicjowanie i automatyczne skalowanie pojemników (pojemniki elastyczne)

W związku z tym zarządzanie sprzętem i platformą nie stanowi już problemu dostawcy oprogramowania. Zasoby są dzielone znacznie wydajniej niż wcześniej na poziomie infrastruktury i platformy .

Nadal będzie istnieć narzut związany z wieloma wystąpieniami (niektóre aplikacje i oprogramowanie pośrednie będą uruchamiane N razy zamiast tylko jednego), ale znacznie niższy niż w przypadku korzystania z oddzielnej (wirtualnej) maszyny na wystąpienie. Baza danych może być mimo to współdzielona (jeden schemat na instancję, kilka schematów na serwer DB)

Również :

• Automatyzacja tworzenia nowych instancji jest możliwa poprzez interfejs API PaaS
• Automatyzacja wdrażania nowych wersji jest możliwa dzięki API PaaS, bez przestojów (zajmuje trochę pracy, aby wprowadzić)
• Skalowanie jest zawsze wyłączone, nigdy wyższe. Nie musimy się martwić o ogromne zbiory danych na poziomie instancji.

Oczywiście potrzebowalibyśmy pewnego rodzaju centralnej usługi, która zarządza tym wszystkim automatycznie (np. Tworzenie instancji, gdy nowy użytkownik utworzy konto). Pozwoliłoby to również rozwiązać problemy z płatnościami i licencjami, interakcjami między instancjami itp. Ta centralna usługa może być dość złożona i trudna do opracowania, ale dobrą rzeczą jest to, że nie musimy jej wdrażać z góry (teraz, gdy nie mamy zbyt wiele zasoby), podczas gdy wielu dzierżawców musiałoby od samego początku zostać upieczonych w aplikacji.

Co prowadzi mnie do ostatecznych korzyści z opracowania pojedynczego najemcy na bardzo wczesnym etapie (przedinwestycyjnym) projekt startowy:

• Tę samą (lub prawie taką samą) wersję aplikacji można wdrożyć lokalnie jako urządzenie wirtualne lub kontener dokerów, a nawet na maszynie zarządzanej przez klienta (niektóre firmy nadal niechętnie korzystają z chmury i może pomóc w początkowym etapie uruchamiania, aby nie wypchnąć ważnych wczesnych użytkowników)
• Szybciej wydostać produkt z ograniczonymi zasobami (warstwa aplikacji i schemat bazy danych jest znacznie mniej skomplikowany), może uzyskać „głupi” produkt z jedną instancją najemcy jako pierwszy (MVP) dla pierwszych użytkowników i pokazać wartość biznesową aplikacji potencjalnym inwestorom i dodaj całą automatyzację chmury
• Może być postrzegany jako argument sprzedaży dla klientów martwiących się o bezpieczeństwo danych: dane są lepiej enkapsulowane, ponieważ każdy klient ma swój własny schemat, a nawet bazę danych. Znacznie mniejsze ryzyko „rozlania”

Uwaga: oczywiście myślę tutaj o aplikacji biznesowej, w której klientami byliby firmy (każdy z wieloma indywidualnymi użytkownikami), a nie osoby fizyczne. Nie ma sensu uruchamiać osobnej instancji aplikacji dla każdego użytkownika (czy też nie?)

Możliwa jest także obsługa obu opcji (pula dzierżawców w wielu instancjach).

Opowiadam się za przyczyną wielu przypadków naturalnej izolacji. Instancja każdego klienta działa we własnych procesach, a dane są izolowane we własnej bazie danych. W razie potrzeby można zaktualizować instancje do nowych wersji dla poszczególnych klientów / instancji.

Systemy oparte na najemcach wiążą się z ryzykiem bezpieczeństwa informacji. Zastanów się, jak łatwo zapomnieć o klauzuli „WHERE tenantId = x”. Głównym powodem korzystania z systemu obsługującego dzierżawę byłaby wydajność, procesy mają dużą wagę, ponieważ współużytkowanie procesu pozwala potencjalnie uzyskać więcej z jednego komputera. To było bardziej prawdziwe, myślę, że w 32-bitowym świecie jest teraz na maszynach 64-bitowych, które mają znacznie więcej pamięci RAM.

System z wieloma instancjami potrzebowałby nieco więcej narzędzi do tworzenia i konfigurowania środowiska, takiego jak bazy danych i instancje aplikacji internetowych. Można argumentować, że i tak potrzebujesz tego skryptu również dla wdrożeń pojedynczych instancji. Ma to inne zalety, takie jak możliwość konfigurowania środowisk programistycznych i testowych

Pozostawiłbym możliwości dzierżawcy, dopóki nie będzie można tego uzasadnić (koszt inżynierii vs. pieniądze zaoszczędzone na infrastrukturze (sprzętowej) dzięki współużytkowaniu procesów).